From owner-Big-Internet@munnari.OZ.AU Tue May 3 07:44:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25558; Tue, 3 May 1994 04:46:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA04685; Tue, 3 May 1994 04:22:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA04666; Tue, 3 May 1994 04:01:48 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24618; Tue, 3 May 1994 04:23:26 +1000 (from yakov@watson.ibm.com) Message-Id: <9405021823.24618@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2289; Mon, 02 May 94 14:23:24 EDT Date: Mon, 2 May 94 14:23:24 EDT To: big-internet@munnari.OZ.AU Subject: IP Technical Criteria Folks, I think it would benefit the Internet if the IPng provides a clear separation between the information used for identifying an end-point of a transport connection and the information used to route to the end-point of a transport connection. This would simplify such things as support for mobility, autoconfiguration, accounting, etc... Therefore I'd like to suggest to add the following to the IPng Technical Criteria: Separation between End Point Identifier and Routing Information: IPng must provide for a globally agreed upon mechanism that would allow separating the information used by a transport layer for the purpose of end-point identification from the information used by routers to forward a packet to a particular end-point. However, IPng must also allow to overload the semantics of a particular field in the IPng header with the information about both the end-point identifier and the information needed to route to that end-point. Yakov Rekhter From owner-Big-Internet@munnari.OZ.AU Tue May 3 08:15:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03107; Tue, 3 May 1994 08:15:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA04865; Tue, 3 May 1994 07:53:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA04862; Tue, 3 May 1994 07:43:25 +1000 Received: from sgigate.SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02798; Tue, 3 May 1994 08:05:04 +1000 (from lear@yeager.corp.sgi.com) Received: from relay.sgi.com (relay.sgi.com [192.26.51.36]) by sgigate.sgi.com (8.6.4/8.6.4) with SMTP id PAA25534; Mon, 2 May 1994 15:04:38 -0700 Received: from yeager.corp.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgigate.sgi.com:0003858921@mcimail.com id AA21544; Mon, 2 May 94 15:04:34 -0700 Received: by yeager.corp.sgi.com (931110.SGI/911001.SGI) for @sgi.com:firewalls@GreatCircle.COM id AA16051; Mon, 2 May 94 15:04:31 -0700 From: lear@yeager.corp.sgi.com (Eliot Lear) Message-Id: <9405021504.ZM16049@yeager.corp.sgi.com> Date: Mon, 2 May 1994 15:04:31 -0700 In-Reply-To: "Robert G. Moskowitz" <0003858921@mcimail.com> "Re: NATs" (Apr 29, 5:39am) References: <40940429103904/0003858921NA3EM@mcimail.com> X-Mailer: Z-Mail-SGI (3.1S.0 3mar94 MediaMail) To: "Robert G. Moskowitz" <0003858921@mcimail.com>, Eric Fleischman , brian , ipv4 ale , big internet , firewalls Subject: Re: NATs Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 I think it's important to stress that network level security is in some sense orthoganol to application layer security. Used today, network layer security provides end to end privacy to the network code. It does you no good to have that privacy if the hosts on either end leak like sieves. On the other hand, if you're looking for a secure pipe, where you have secure ends on both sides, network layer security is just fine, regardless of the applications on either side. -- Eliot Lear [lear@sgi.com] From owner-Big-Internet@munnari.OZ.AU Tue May 3 13:00:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07098; Tue, 3 May 1994 10:35:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA04999; Tue, 3 May 1994 10:13:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA04985; Tue, 3 May 1994 09:58:30 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04137; Tue, 3 May 1994 08:43:25 +1000 (from news@sgi.com) Received: by sgi.sgi.com (940426.SGI.8.6.9/910110.SGI) for Big-Internet@munnari.OZ.AU id PAA21861; Mon, 2 May 1994 15:34:34 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: lear@yeager.corp.sgi.com (Eliot Lear) X-Approved: newsmail@sgi.sgi.com From: lear@yeager.corp.sgi.com (Eliot Lear) Subject: Re: NATs Content-Type: text/plain; charset=us-ascii Message-Id: Mime-Version: 1.0 Date: Mon, 2 May 1994 22:27:55 GMT I think it's important to stress that network level security is in some sense orthoganol to application layer security. Used today, network layer security provides end to end privacy to the network code. It does you no good to have that privacy if the hosts on either end leak like sieves. On the other hand, if you're looking for a secure pipe, where you have secure ends on both sides, network layer security is just fine, regardless of the applications on either side. -- Eliot Lear [lear@sgi.com] From owner-Big-Internet@munnari.OZ.AU Tue May 3 14:05:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14231; Tue, 3 May 1994 14:05:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA05180; Tue, 3 May 1994 13:43:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA05166; Tue, 3 May 1994 13:39:09 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14100; Tue, 3 May 1994 14:00:19 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA07379; Mon, 2 May 94 20:59:42 -0700 Received: by xirtlu.zk3.dec.com; id AA29963; Mon, 2 May 1994 23:59:37 -0400 Message-Id: <9405030359.AA29963@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: IP Technical Criteria In-Reply-To: Your message of "Mon, 02 May 94 14:23:24 EDT." <9405021823.24618@munnari.oz.au> Date: Mon, 02 May 94 23:59:31 -0400 X-Mts: smtp Yakov, I agree with you. Also I like the way you worded it to provide degrees of freedom technically so evolution can take place as opposed to revolution. )--> Customers like that kind of thinking. take care, /jim From owner-Big-Internet@munnari.OZ.AU Tue May 3 21:40:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29827; Tue, 3 May 1994 21:40:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA05546; Tue, 3 May 1994 21:18:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA05543; Tue, 3 May 1994 21:14:07 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28612; Tue, 3 May 1994 20:48:54 +1000 (from kre@munnari.OZ.AU) To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: IP Technical Criteria In-Reply-To: Your message of "Mon, 02 May 1994 14:23:24 EDT." <9405021823.24618@munnari.oz.au> Date: Tue, 03 May 1994 20:48:54 +1000 Message-Id: <16573.767962134@munnari.OZ.AU> From: Robert Elz Date: Mon, 2 May 94 14:23:24 EDT From: yakov@watson.ibm.com Message-ID: <9405021823.24618@munnari.oz.au> I think it would benefit the Internet if the IPng provides a clear separation between the information used for identifying an end-point of a transport connection and the information used to route to the end-point of a transport connection. I totally agree with this, and have done for ages. Then your proposed wording ... IPng must provide for a globally agreed upon mechanism that would allow separating the information used by a transport layer for the purpose of end-point identification from the information used by routers to forward a packet to a particular end-point. That part is just fine, however ... However, IPng must also allow to overload the semantics of a particular field in the IPng header with the information about both the end-point identifier and the information needed to route to that end-point. I don't see the point of this at all. While this may be a consideration that one might use to assist in choosing between the various protocols, I hardly see it as a requirement. It hardly seems material to me if (say) one candidate IPng used (say) 20 byte "addresses", which contained both an EID, and routing info, in one field, and another contained (say), 8 bytes of routing info, and 8 bytes of EID in different fields, with no overloading at all. In fact, I think that if there was no other difference, I'd much prefer the latter, as being a cleaner separation of functionality. kre From owner-Big-Internet@munnari.OZ.AU Wed May 4 03:41:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04403; Wed, 4 May 1994 03:30:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA05831; Wed, 4 May 1994 03:08:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA05817; Wed, 4 May 1994 02:49:03 +1000 From: yakov@watson.ibm.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02295; Wed, 4 May 1994 02:38:56 +1000 (from yakov@watson.ibm.com) Received: from [129.34.139.4] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27092 Tue, 3 May 1994 22:39:34 +1000 (from yakov@watson.ibm.com) Message-Id: <9405031239.27092@mulga.cs.mu.OZ.AU> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2219; Tue, 03 May 94 08:29:23 EDT Date: Tue, 3 May 94 08:29:23 EDT To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU Subject: IP Technical Criteria Ref: Your note of Tue, 03 May 1994 20:48:54 +1000 Robert, >> However, IPng must also allow to overload the semantics of a particular >> field in the IPng header with the information about both end-point >> identifier and the information needed to route to that end-point. >I don't see the point of this at all. While this may be a consideration >that one might use to assist in choosing between the various protocols, I >hardly see it as a requirement. It hardly seems material to me if (say) >one candidate IPng used (say) 20 bytes "addresses", which contained >both an EID, and routing info, in one field, and another contained >(say), 8 bytes of routing info, and 8 bytes of EID in different field >with no overload at all. The distiction I was trying to make is between the following cases: (a) There is an explicit separation between EID and routing info -- the two are carried in separate fields. This way entities that are concerned with routing (e.g. routers) may ignore EID information. Likewise, entities that are concerned with EIDs (e.g. hosts) may ignore routing information. (b) There is a *single* field in a packet. The EID info is represented by the value of the *whole* field. The routing info is represented by the value of the *same whole* field. I would assume that the length of the field in (b) would be less than the sum of lenghts of the two fields in (a). Thus (b) would allow for a more compact representation of information. I was suggesting that the IPng should allow for both (a) and (b). Yakov. From owner-Big-Internet@munnari.OZ.AU Wed May 4 06:25:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10733; Wed, 4 May 1994 06:25:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA06104; Wed, 4 May 1994 06:03:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA06065; Wed, 4 May 1994 05:29:28 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02165; Wed, 4 May 1994 02:35:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: from [18.26.0.82] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA28054 Tue, 3 May 1994 23:23:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05370; Tue, 3 May 94 09:20:58 -0400 Date: Tue, 3 May 94 09:20:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405031320.AA05370@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, yakov@watson.ibm.com Subject: Re: IP Technical Criteria Cc: jnc@ginger.lcs.mit.edu I think it would benefit the Internet if the IPng provides a clear separation between the information used for identifying an end-point of a transport connection and the information used to route to the end-point of a transport connection. Agree with this (modulo the assertion that the last-hop router always send, i.e. routes, the packet to an interface, not an endpoint :-). However, IPng must also allow to overload the semantics of a particular field in the IPng header with the information about both the end-point identifier and the information needed to route to that end-point. I wonder if you could explain your design motivation for wanting this. To me, it seems to conflict with the "clear separation" above. It's more complex, and to me, complexity is bad, unless there's some very substantial advantage to be gained. The Internet is going to be very complex anyway, so extra complexity bother me. It's not at all clear to me what advantage, other than perhaps some space savings, is to be gained. Could you please provide a little more detail on your thinking? Noel From owner-Big-Internet@munnari.OZ.AU Wed May 4 06:26:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10777; Wed, 4 May 1994 06:26:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA06119; Wed, 4 May 1994 06:04:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA06079; Wed, 4 May 1994 05:37:37 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02286; Wed, 4 May 1994 02:38:41 +1000 (from kasten@mailserv-D.ftp.com) Received: from [128.127.2.122] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27701 Tue, 3 May 1994 23:01:04 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 3 May 1994 08:58:26 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 3 May 1994 08:58:26 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA02604; Tue, 3 May 94 08:57:14 EDT Date: Tue, 3 May 94 08:57:14 EDT Message-Id: <9405031257.AA02604@mailserv-D.ftp.com> To: yakov@watson.ibm.com Subject: Re: IP Technical Criteria From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 1440 Yakov, We currently have a section called "Unique Naming" which, I believe, covers your intent here. Are you proposing a new requirement, different from "Unique Naming" or are you suggesting that the wording of the current requirement be clarified to better state the requirement or extended to explicitly mention the issues that you raise? > I think it would benefit the Internet if the IPng provides a clear > separation between the information used for identifying an end-point of > a transport connection and the information used to route to the > end-point of a transport connection. This would simplify such things as > support for mobility, autoconfiguration, accounting, etc... > > Therefore I'd like to suggest to add the following to the IPng > Technical Criteria: > > Separation between End Point Identifier and Routing Information: > > IPng must provide for a globally agreed upon mechanism that would allow > separating the information used by a transport layer for the purpose > of end-point identification from the information used by routers to > forward a packet to a particular end-point. However, IPng must also > allow to overload the semantics of a particular field in the IPng > header with the information about both the end-point identifier and the > information needed to route to that end-point. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed May 4 06:49:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05550; Wed, 4 May 1994 04:05:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA05901; Wed, 4 May 1994 03:43:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA05858; Wed, 4 May 1994 03:16:26 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04497; Wed, 4 May 1994 03:34:14 +1000 (from kre@munnari.OZ.AU) To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: IP Technical Criteria In-Reply-To: Your message of "Tue, 03 May 1994 08:29:23 EDT." <9405031239.27092@mulga.cs.mu.OZ.AU> Date: Wed, 04 May 1994 03:34:15 +1000 Message-Id: <16621.767986455@munnari.OZ.AU> From: Robert Elz Date: Tue, 3 May 94 08:29:23 EDT From: yakov@watson.ibm.com Message-ID: <9405031239.27092@mulga.cs.mu.OZ.AU> I was suggesting that the IPng should allow for both (a) and (b). In that case I think I'd change the wording of the second half of your paragraph to simply say "The EID need not occur as a separate field in the packet headers". That makes it clear that the protocol doesn't need to carry around separate baggage if it has some other way of transporting the info, but without giving the impression that that's the only way. That's fine. However, in your two cases ... (b) There is a *single* field in a packet. The EID info is represented by the value of the *whole* field. The routing info is represented by the value of the *same whole* field. This one I find a bit hard to believe. An EID which is the same as what is needed for routing doesn't seem very useful for anyone else, and basically provides an easy out for any IPng candidate that doesn't really want to provide EIDs. An EID that was part of a field that also contained routing info I can see as a definite possibility, and might very well mean less bytes in headers (or might not, depending on other aspects of the design). kre From owner-Big-Internet@munnari.OZ.AU Wed May 4 07:00:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12141; Wed, 4 May 1994 07:00:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA06165; Wed, 4 May 1994 06:38:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA06160; Wed, 4 May 1994 06:28:13 +1000 Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06823; Wed, 4 May 1994 04:39:36 +1000 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA21968); Tue, 3 May 94 13:39:04 CDT Received: by sabine.is.rice.edu (AA28069); Tue, 3 May 94 13:36:49 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9405031836.AA28069@sabine.is.rice.edu> Subject: TUBA implementation (fwd) To: big-internet@munnari.OZ.AU, sipp@sunroof2.eng.sun.com Date: Tue, 3 May 94 13:36:48 CDT X-Mailer: ELM [version 2.3 PL11] In the interests of openness and fair play, I forward this bit of info. Francis Dupont > From: Francis Dupont > To: tuba@lanl.gov > Subject: TUBA implementation > Date: Tue, 03 May 1994 11:26:17 +0200 > Sender: Francis.Dupont@inria.fr > > I have moved my native dual stack implementation for SunOS + NET 2 > to NetBSD for Sparc. Now I can distribute it with source license problems, > then if you want it you can ask me (or Alex Reijnierse or Marcel Wiget) > for it. > > Regards > > Francis.Dupont@inria.fr > > PS: NetBSD runs on PCs, Sparcs (SLC, ELC, IPC, IPX, SS1, SS1+, SS2), etc... > The network code is still NET 2 but should be upgraded to 4.4 Lite asap. > -- Regards, Bill Manning From owner-Big-Internet@munnari.OZ.AU Wed May 4 07:14:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09408; Wed, 4 May 1994 05:50:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA06060; Wed, 4 May 1994 05:28:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA06046; Wed, 4 May 1994 05:18:26 +1000 From: yakov@watson.ibm.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01838; Wed, 4 May 1994 02:27:57 +1000 (from yakov@watson.ibm.com) Received: from watson.ibm.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA28351 Tue, 3 May 1994 23:46:35 +1000 (from yakov@watson.ibm.com) Message-Id: <9405031346.28351@mulga.cs.mu.OZ.AU> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3151; Tue, 03 May 94 09:36:31 EDT Date: Tue, 3 May 94 09:36:31 EDT To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU Subject: IP Technical Criteria Ref: Your note of Tue, 3 May 94 09:20:58 -0400 Noel, >>However, IPng must also allow to overload the semantics of a particular >>field in the IPng header with the information about both the end-point >>identifier and the information needed to route to that end-point. > >I wonder if you could explain your design motivation for wanting this. >To me, it seems to conflict with the "clear separation" above. It is assumed that when the same field is overloaded with both the end-point identifier and routing information, then the length of this field is less than the sum of the length of the two fields (the first field carries the end-point identifier, and the second carries the routing info). Thus overloading the same field would provide a more compact representation of the information. That, in turn, reduces the resources needed to carry and process the information. Yakov. From owner-Big-Internet@munnari.OZ.AU Wed May 4 07:38:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12196; Wed, 4 May 1994 07:02:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA06191; Wed, 4 May 1994 06:40:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA06157; Wed, 4 May 1994 06:26:08 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05309; Wed, 4 May 1994 03:58:35 +1000 (from yakov@watson.ibm.com) Message-Id: <9405031758.5309@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7645; Tue, 03 May 94 13:58:23 EDT Date: Tue, 3 May 94 13:58:22 EDT To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU Subject: IP Technical Criteria Ref: Your note of Wed, 04 May 1994 03:34:15 +1000 Robert, >> (b) There is a *single* field in a packet. The EID info is represented >> by the value of the *whole* field. The routing info is represented >> by the value of the *same whole* field. >This one I find a bit hard to believe. An EID which is the same as what >is needed for routing doesn't seem very useful for anyone else, and >basically provides an easy out for any IPng candidate that doesn't >really want to provide EIDs. Since the IPng has to provide for both options (a) and (b), it follows that an IPng candidate *must* provide for separate EID and routing info. *In addition* to this, the candidate *must* also provide the ability to use *exactly the same field* as both the EID and the routing info. So, case (b) doesn't provide an "easy out"... With respect to whether overloading the same field with both EID and routing info is useful, just look at the addresses in IPv4 -- for a non-mobile host an IP address provides both routing info and EID. Yakov. From owner-Big-Internet@munnari.OZ.AU Wed May 4 08:17:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14706; Wed, 4 May 1994 08:10:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA06259; Wed, 4 May 1994 07:48:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA06234; Wed, 4 May 1994 07:17:02 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13583; Wed, 4 May 1994 07:36:41 +1000 (from kre@munnari.OZ.AU) To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: IP Technical Criteria In-Reply-To: Your message of "Tue, 03 May 1994 13:58:22 EDT." Date: Wed, 04 May 1994 07:36:41 +1000 Message-Id: <16674.768001001@munnari.OZ.AU> From: Robert Elz Date: Tue, 3 May 94 13:58:22 EDT From: yakov@watson.ibm.com I'm afraid that I'm just getting very confused. I hope that the problem is just one of digging your intentions out of the words and not something more substantial. Since the IPng has to provide for both options (a) and (b), This isn't what I'd require at all, I'd say that an IPng candidate must provide one of (a) or (b), not both. Let the group proposing the particular candidate pick which they prefer. *In addition* to this, the candidate *must* also provide the ability to use *exactly the same field* as both the EID and the routing info. So, case (b) doesn't provide an "easy out"... But this is where I'm really confused. If the protocol provides the ability to use a field as either an EID or routing info, who decides which is which, and on what basis? This seems wild to me - either the EID and the routing info are simply the same thing, in which case I don't really treat it as an EID at all (though in the absense of anything else it can fill the role, with limitations), or they're different things that at various times occupy the same field in packets. Wacko. With respect to whether overloading the same field with both EID and routing info is useful, just look at the addresses in IPv4 Yes, I know it can be done like that, its to avoid the problems this causes that I'd like to see EIDs introduced at all. I don't see any benefit in adding a new label without adding new functionality to go along with it. Let me say what I think the criteria should be, then we can see if we're just disagreeing about how to write down the same thing. - IPng candidates must provide an EID associated with each packet (not necessarily carried in every packet). - Where an EID is carried in a packet it may be in a field of its own, or found as some part of some other field (which may be a routing field). - Transport protocols running over IPng must use the EID where addressing information of some kind is needed, and not any routing information that may also be in use. This allows the routing information to be altered in an active transport level association. That's it, no other rules in this area, design choices made by candidate IPng protocols may of course be considered when deciding which has done the best job. kre From owner-Big-Internet@munnari.OZ.AU Wed May 4 12:28:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20776; Wed, 4 May 1994 11:05:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA06414; Wed, 4 May 1994 10:43:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA06389; Wed, 4 May 1994 10:21:15 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19863; Wed, 4 May 1994 10:42:51 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA07489; Tue, 3 May 94 20:42:47 EDT Date: Tue, 3 May 94 20:42:47 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9405040042.AA07489@itd.nrl.navy.mil> To: big-Internet@munnari.OZ.AU Subject: EIDs, addresses, etc. If one does not include the source EID in every packet and one has per-packet encryption (e.g. SP3, NLSP, SIPP ESP), how does one figure out the correct decryption algorithm, mode, key, etc. ?? This information is normally indexed using a Security Association Identifier (SAID) and address information in current practice. In realistically large Internets, an SAID cannot be globally unique in practice because there is no reasonable way to keep all hosts in the network informed of which SAID values are currently in use by other hosts. Existing practice is for the SAID to be locally unique combining with perhaps the source address (used as a source EID) to guarantee global uniqueness. I think it is highly desirable to have EIDs in each packet for this reason. I suspect many other reasons make it highly desirable to have EIDs in every packet. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Wed May 4 16:20:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04133; Wed, 4 May 1994 16:20:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA06682; Wed, 4 May 1994 15:58:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA06679; Wed, 4 May 1994 15:56:02 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03908; Wed, 4 May 1994 16:17:40 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24906; Wed, 4 May 1994 08:17:36 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16733; Wed, 4 May 1994 08:17:36 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405040617.AA16733@dxcoms.cern.ch> Subject: Re: IP Technical Criteria To: big-internet@munnari.OZ.AU (bigi) Date: Wed, 4 May 1994 08:17:35 +0200 (MET DST) In-Reply-To: <9405031758.5309@munnari.oz.au> from "yakov@watson.ibm.com" at May 3, 94 01:58:22 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 605 Yakov, > > With respect to whether overloading the same field with > both EID and routing info is useful, just look at the addresses > in IPv4 -- for a non-mobile host an IP address provides both > routing info and EID. > Yes, but it provides both *badly*. Route aggregation was not designed in, and adding it (CIDR) means that hosts may have to change their EID if the service provider changes. SIPP addresses as currently defined seem to have some of the same problem; changing provider changes your address, and there is no EID. NSAPAs have the locator and ID buried in a single structure. Brian From owner-Big-Internet@munnari.OZ.AU Wed May 4 18:40:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09973; Wed, 4 May 1994 18:40:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA06803; Wed, 4 May 1994 18:18:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA06789; Wed, 4 May 1994 18:06:32 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09578; Wed, 4 May 1994 18:28:12 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA03850; Wed, 4 May 1994 10:28:11 +0200 Message-Id: <199405040828.AA03850@mitsou.inria.fr> To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Cc: big-internet@munnari.OZ.AU (bigi) Subject: Re: IP Technical Criteria In-Reply-To: Your message of "Wed, 04 May 1994 08:17:35 +0200." <9405040617.AA16733@dxcoms.cern.ch> Date: Wed, 04 May 1994 10:28:11 +0200 From: Christian Huitema => => SIPP addresses as currently defined seem to have some of the same => problem; changing provider changes your address, and there is no EID. => NSAPAs have the locator and ID buried in a single structure. => => Brian Brian, SIPP routing information is provided by a list of "addresses", each of which belongs to one particular hierarchy. There are at least two formats of addresses in the current design, i.e. provider based and "hardware based" (IEEE-802); the former provide location information while the latter don't - or at least not outside the local subnet. Both provide unique identification, although one may argue that provider based identification is only valid as long as the contract with the subscriber remains in effect. Note that the dependency is the contract, not the particular decision to use provider X at time T. If an association started with a provider X address, it can at any time switch to another provider. The initial packets will just carry the address pair "from A to X"; the following packet will carry something like "from A to X through Y". Or through Z, or whatever: X will only play a "unique identifier" role at that point. Supporting "provider selection" including in the middle of a connexion is in fact part of the absolute requirements of e.g. RBOC, for legal reasons. If a system administrator really believes in the EID concept, he is absolutely free to always use a two components list, i.e. the current provider address followed by the "non routing" identifier. In that case, all packets will be routed "from A to H through X" where H is a pure EID and X is a provider address. Selecting another provider can be done by routing the packet "from A to H through Y" (in all my examples, "from A" can infact also be expressed as a EID/provider address pair). Indeed, the system administrator which makes this decision will have to compare the cost (more octets in every packet) and the benefit (connexions or "associations" survive contract with provider). By the way, the "provider/hardware" pair can also be used if the provider address only identifies the subnet or the subnet's router, in the IPX fashion. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Wed May 4 20:25:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14100; Wed, 4 May 1994 20:25:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA06901; Wed, 4 May 1994 20:03:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA06876; Wed, 4 May 1994 19:32:20 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11558; Wed, 4 May 1994 19:16:50 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA28233; Wed, 4 May 1994 11:16:41 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21160; Wed, 4 May 1994 11:16:40 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405040916.AA21160@dxcoms.cern.ch> Subject: Re: IP Technical Criteria To: big-internet@munnari.OZ.AU (bigi) Date: Wed, 4 May 1994 11:16:40 +0200 (MET DST) In-Reply-To: <199405040828.AA03850@mitsou.inria.fr> from "Christian Huitema" at May 4, 94 10:28:11 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 333 Christian, Thanks for the clarification about what is possible with SIPP addresses. However note that the current concrete SIPP addressing proposal doesn't seem to exploit these possibilities (I refer to draft-ietf-sip-unicast-addr-00.txt which refers to SIPP despite the name). My comments are directed to that proposal. Brian From owner-Big-Internet@munnari.OZ.AU Thu May 5 01:05:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24298; Thu, 5 May 1994 01:05:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA07138; Thu, 5 May 1994 00:43:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA07135; Thu, 5 May 1994 00:41:48 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24228; Thu, 5 May 1994 01:03:28 +1000 (from yakov@watson.ibm.com) Message-Id: <9405041503.24228@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9949; Wed, 04 May 94 11:03:28 EDT Date: Wed, 4 May 94 11:03:27 EDT To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU Subject: EIDs vs routing info > >Let me say what I think the criteria should be, then we can see >if we're just disagreeing about how to write down the same thing. > >- IPng candidates must provide an EID associated with each > packet (not necessarily carried in every packet). I think it should be in every packet (see also message from Ran Atkinson). > >- Where an EID is carried in a packet it may be in a field of > its own, or found as some part of some other field > (which may be a routing field). It is important to say that if an EID is carried as part of a field, then there is either (a) some form of info in a packet that identifies the position of the EID in that field, or (b) there is a global agreement on the position of the EID in that field. > >- Transport protocols running over IPng must use the EID where > addressing information of some kind is needed, and not > any routing information that may also be in use. This > allows the routing information to be altered in an > active transport level association. That is fine. So far we seem to agree on the requirement for the IPng to provide the ability to have a separate EID and routing information (this may be either explicit as two separate fields, or implicit as two disjoint parts of the same field). There seems to be a disagreement on whether it would be useful to also allow semantics overlay of the same field with both the EID and routing info. The only reason I think this feature (semantics overlay) maybe useful is to provide a more compact information representation. If that is viewed as not sufficiently important, we may drop this feature. I don't have a strong opinion on this, and would like to hear what other folks on the big-internet think about this. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu May 5 02:15:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27429; Thu, 5 May 1994 02:15:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA07257; Thu, 5 May 1994 01:53:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA07254; Thu, 5 May 1994 01:46:31 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27135; Thu, 5 May 1994 02:07:50 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA08494; Wed, 4 May 94 08:55:59 -0700 Received: by xirtlu.zk3.dec.com; id AA07607; Wed, 4 May 1994 11:55:52 -0400 Message-Id: <9405041555.AA07607@xirtlu.zk3.dec.com> To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Cc: big-internet@munnari.OZ.AU (bigi) Subject: Re: IP Technical Criteria In-Reply-To: Your message of "Wed, 04 May 94 08:17:35 +0200." <9405040617.AA16733@dxcoms.cern.ch> Date: Wed, 04 May 94 11:55:45 -0400 X-Mts: smtp Brian, >SIPP addresses as currently defined seem to have some of the same >problem; changing provider changes your address, and there is no EID. >NSAPAs have the locator and ID buried in a single structure. I am proposing right now on SIPP list that the strategy move to what has been stated by Kre and Noel in recent previous mail regarding EIDs and Locators. NSAPs are not required to make it happen. Not that NSAPs could not be used, but it is not necessary to make SIPP perform in this manner. I have no problen using a 'fixed part' within an address structure such as an NSAP format that was defined for the Internet to give me EID fixed address part for my transport code base. There are many good reasons for an EID that contains no routing state. The one I am focusing on now is that the transport layer can really benefit from an EID that is a fixed length address in IPng. /jim /jim From owner-Big-Internet@munnari.OZ.AU Thu May 5 02:17:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27500; Thu, 5 May 1994 02:17:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA07283; Thu, 5 May 1994 01:55:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA07251; Thu, 5 May 1994 01:46:07 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27112; Thu, 5 May 1994 02:05:22 +1000 (from kre@munnari.OZ.AU) To: yakov@watson.ibm.com Cc: big-internet@munnari.OZ.AU Subject: Re: EIDs vs routing info In-Reply-To: Your message of "Wed, 04 May 1994 11:03:27 EDT." Date: Thu, 05 May 1994 02:05:21 +1000 Message-Id: <16777.768067521@munnari.OZ.AU> From: Robert Elz Date: Wed, 4 May 94 11:03:27 EDT From: yakov@watson.ibm.com I think it should be in every packet (see also message from Ran Atkinson). Fine, you're probably right, however I don't want to prejudge (ie: require) this, if someone can work out some other way that they can convince us will work, that's fine too. It is important to say that if an EID is carried as part of a field, then there is either (a) some form of info in a packet that identifies the position of the EID in that field, or (b) there is a global agreement on the position of the EID in that field. Absolutely - there clearly needs to be a way to find EIDs for lots of reasons, a proposal that suggested hiding the EID somewhere in there (maybe even moving it around amongst whatever fields weren't otherwise used in a particular packet) would not last long at all. There seems to be a disagreement on whether it would be useful to also allow semantics overlay of the same field with both the EID and routing info. I'm not sure on that (on the disagreement). If a candidate protocol wants to do that, and can justify it, then fine. However I would certainly not require all proposals to be able to operate that way. Let them do it however they feel best, then we can judge the results. If a proposal wants to suggest 512 byte EIDS in every packet (both src & dest) that's OK. I don't think they'd have a chance of being accepted, but there may be some good reason for what seems to me now to be an absurd waste of space. Let it be proposed and then justified if it can be. Require only what is needed to provide the functionality we must have. kre From owner-Big-Internet@munnari.OZ.AU Thu May 5 02:50:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28958; Thu, 5 May 1994 02:50:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA07324; Thu, 5 May 1994 02:28:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA07310; Thu, 5 May 1994 02:10:35 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28262; Thu, 5 May 1994 02:32:13 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA04963; Wed, 4 May 1994 18:32:25 +0200 Message-Id: <199405041632.AA04963@mitsou.inria.fr> To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: EIDs vs routing info In-Reply-To: Your message of "Thu, 05 May 1994 02:05:21 +1000." <16777.768067521@munnari.OZ.AU> Date: Wed, 04 May 1994 18:32:24 +0200 From: Christian Huitema >Fine, you're probably right, however I don't want to prejudge >(ie: require) this, if someone can work out some other way >that they can convince us will work, that's fine too. Yep. The use of the EID in transport protocols is for identifying the connection context, through a "source EID, dest EID, source port, dest port" combination. Suppose now that the transport context is retrieved by + , as in e.g. XTP. The source EID has no role there. And just in case somebody asks the question, it has no security usage either - you will need some kind of crypto-checksum for authentification in any case, which works exactly as well with "association-id" as with "EID+port". Besides, access control and authentication should be based on high level identifications, e.g. distinguished names or domain names. Certainly not on machine addresses or binary EIDs. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Thu May 5 06:55:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07845; Thu, 5 May 1994 06:55:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA07570; Thu, 5 May 1994 06:33:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA07556; Thu, 5 May 1994 06:21:16 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07432; Thu, 5 May 1994 06:42:56 +1000 (from yakov@watson.ibm.com) Message-Id: <9405042042.7432@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6827; Wed, 04 May 94 16:42:56 EDT Date: Wed, 4 May 94 16:42:55 EDT To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU Subject: IP Technical Criteria Ref: Your note of Wed, 4 May 94 16:32:21 -0400 Noel, >So it is just space saving, right ? In that case, I'm not at all sure >I can agree it's a good move to allow this. It's a fairly minor >optimization, with potentially very bad consequences As I mentioned before, I don't have *very* strong feeling on this. That is, I'll be willing to drop this if there is enough consensus that we can live without this space saving, and just require the IPng to have *separate* EID and routing info. We just need to look whether this space saving would play any role when operating in certain environments (e.g. slow speed links). Yakov. From owner-Big-Internet@munnari.OZ.AU Thu May 5 06:59:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07922; Thu, 5 May 1994 06:59:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA07585; Thu, 5 May 1994 06:37:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA07553; Thu, 5 May 1994 06:10:45 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07121; Thu, 5 May 1994 06:32:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14203; Wed, 4 May 94 16:32:21 -0400 Date: Wed, 4 May 94 16:32:21 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405042032.AA14203@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, yakov@watson.ibm.com Subject: Re: IP Technical Criteria Cc: big-internet@munnari.OZ.AU >> However, IPng must also allow to overload the semantics of a particular >> field in the IPng header with the information about both the end-point >> identifier and the information needed to route to that end-point. > I wonder if you could explain your design motivation for wanting this. > ... It's more complex, and to me, complexity is bad, unless there's some > very substantial advantage to be gained. The Internet is going to be very > complex anyway, so extra complexity bother me. It's not at all clear to > me what advantage, other than perhaps some space savings, is to be > gained. It is assumed that when the same field is overloaded ... then the length of this field is less than the sum of the length of the two fields... Thus overloading the same field would provide a more compact representation of the information. That, in turn, reduces the resources needed to carry and process the information. So, it is just space savings, right? In that case, I'm not at all sure I can agree it's a good move to allow this. It's a fairly minor optimization, with potentially very bad consequences. For instance, in the perceived push to save space, one might be tempted to have a single overloaded field with compromise syntax, rather than having separate EID and locator fields, each with optimal syntax for that purpose. This will have a negative impact on the flexibility and adaptability, and thus of the lifetime, of the design. If the only point of this is to save space, it seems to me not at all a good tradeoff. Bits are fairly cheap *today*, and if we're trying to design something with a 30 year lifetime, we should be looking at the economics over the whole life-cycle, not just today. What am I missing? Noel From owner-Big-Internet@munnari.OZ.AU Thu May 5 08:07:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05239; Thu, 5 May 1994 05:45:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA07492; Thu, 5 May 1994 05:23:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA07467; Thu, 5 May 1994 04:51:28 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02909; Thu, 5 May 1994 04:34:16 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA09670; Wed, 4 May 94 14:34:06 EDT Date: Wed, 4 May 94 14:34:06 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9405041834.AA09670@itd.nrl.navy.mil> To: big-Internet@munnari.OZ.AU Subject: EIDs, transport state, & SAIDs Christian Huitema wrote: % Suppose now that the transport context is retrieved by + % , as in e.g. XTP. The source EID % has no role there. And just in case somebody asks the question, it has % no security usage either - you will need some kind of crypto-checksum % for authentification in any case, which works exactly as well with % "association-id" as with "EID+port". Besides, access control and % authentication should be based on high level identifications, e.g. % distinguished names or domain names. Certainly not on machine % addresses or binary EIDs. I respectfully suggest that for large multicast groups it is not trivial to get all the receiving systems to agree a priori about the association ID. Among other things, who in the group makes that decision ? It _does_ have security relevance because one needs to have some unique identifier to figure out which authentication/encryption algorithm, mode, key, and ICV are being used for each packet. That unique identifier may be a higher level identifier (e.g. a FQDN), but must be present in each IP packet if we are to have per IP packet security processing. For these reasons, the SIPP security specs say that the combination of sender EID (i.e. 1st 64-bits of the SIPP address sequence) and SAID is globally unique and that more than one sender might use the same SAID value. Trying to guarantee global uniqueness of SAIDs or similar identifiers without including source or destination EID (where an Address may well function as an EID) appears too complex to be desirable. I should note that I would love to have someone explain to me why I am confused and why it is feasible in a large Internet to have a globally unique SAID (i.e. the SAID is globally unique by itself), because I could simplify SIPP security processing if that were so. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Thu May 5 11:14:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14097; Thu, 5 May 1994 09:50:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA07740; Thu, 5 May 1994 09:28:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA07737; Thu, 5 May 1994 09:27:20 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10309; Thu, 5 May 1994 08:08:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15029; Wed, 4 May 94 18:08:38 -0400 Date: Wed, 4 May 94 18:08:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405042208.AA15029@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, yakov@watson.ibm.com Subject: Mandatory EID's Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu > I think [the EID] should be in every packet I don't want to prejudge (ie: require) this, if someone can work out some other way that they can convince us will work, that's fine too. I think about this occasionally. Particulary in the case where there's an end-end flow set up, where all you really need in the packet is the flow-id, actually. I remain uneasy about pulling them out, for reasons I find hard to articulate. If for no other reason, if the packet winds up someplace bizarre (due to a coding fault, or whatever) it's nice to have *something* in the packet that says who it's *really* from and to. Of course, you could make the same argument about the locators too. If they weren't likely to be so darn long (not to mention variable length), I'd be happy to put them in every packet too, for much the same reason. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 5 11:35:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18106; Thu, 5 May 1994 11:35:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA07838; Thu, 5 May 1994 11:13:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA07824; Thu, 5 May 1994 11:02:33 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17672; Thu, 5 May 1994 11:23:18 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA09234; Wed, 4 May 1994 18:23:06 -0700 Date: Wed, 4 May 1994 18:23:06 -0700 From: Tony Li Message-Id: <199405050123.SAA09234@lager.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: kre@munnari.OZ.AU, yakov@watson.ibm.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Mandatory EID's I remain uneasy about pulling them out, for reasons I find hard to articulate. If for no other reason, if the packet winds up someplace bizarre (due to a coding fault, or whatever) it's nice to have *something* in the packet that says who it's *really* from and to. True. However, wouldn't you really rather have a locator in there so that you can revert to hop-by-hop forwarding? Of course, you could make the same argument about the locators too. If they weren't likely to be so darn long (not to mention variable length), I'd be happy to put them in every packet too, for much the same reason. Yup. This is the tradeoff that I made. Locators stay in the header for packets in flows. Tony From owner-Big-Internet@munnari.OZ.AU Thu May 5 13:52:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19596; Thu, 5 May 1994 12:10:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA07879; Thu, 5 May 1994 11:48:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA07865; Thu, 5 May 1994 11:36:06 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17080; Thu, 5 May 1994 11:07:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15703; Wed, 4 May 94 21:07:11 -0400 Date: Wed, 4 May 94 21:07:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405050107.AA15703@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, int-serv@isi.edu, nimrod-wg@bbn.com, rsvp@isi.edu Subject: "Flows" mailing list. Cc: jnc@ginger.lcs.mit.edu So, I received a total of 28 replies (including myself) about the question of whether or not we should have a separate flows mailing list. The count was: 5 No, 3 Maybe (as in "I don't know if we need this list, but it you create it add me"), 20 Yes. Since I think that this constitutes rough consensus, the list has been set up. The list itself is "flows@research.ftp.com", and there's the usual "flows-request@research.ftp.com" for *ALL* requests to be added or deleted (but see below). The kind of things the list should deal with are questions like: - Do we have a single mechanism across all subsystems (routing, resource allocation, etc) to name the packets which are part of a flow? - If so, what is it? - Do we have a single mechanism across all subsystems to install flow state in the routers? - If so, what is it? - How do we do multicast flow setup/maintainence, especially for large multi-cast groups? All who voted "Yes" or "Maybe" have been added. Everyone on the Nimrod-WG mailing list has also been added; I did that since the "flow" subsystem of the Nimrod group of subsystem will probably be mostly discussed there. If anyone on the Nimrod WG mailing list didn't want on, my apologies in advance, but I thought that would probably also save having most of you write in to say "please add me". The archives are available for anonymous ftp from research.ftp.com in the directory pub/flow/Archives/ (note the uppercase A!). The 'current' archive file is named archive. back archives are available as archive-ddMmmyy or archive-ddMmmyy.Z. ddMmmyy is the date that the archive file was saved. for example, if there are two files, archive-01Mar94.Z and archive-03Mar94.Z, archive-03Mar94.Z will have the traffic from shortly before midnight on 01Mar94 up to shortly before midnight on 03Mar94. Thanks to Frank Kastenholz for setting this up, and FTP for hosting. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 5 16:15:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29503; Thu, 5 May 1994 16:15:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA08098; Thu, 5 May 1994 15:53:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA08084; Thu, 5 May 1994 15:31:23 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28631; Thu, 5 May 1994 15:52:52 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id WAA16766; Wed, 4 May 1994 22:52:42 -0700 Date: Wed, 4 May 1994 22:52:42 -0700 From: Tony Li Message-Id: <199405050552.WAA16766@lager.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU, tli@cisco.com, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Thu, 5 May 94 00:55:34 -0400 <9405050455.AA16719@ginger.lcs.mit.edu> Subject: Mandatory EID's > I remain uneasy about pulling [EID's] out, for reasons I find hard to > articulate. If for no other reason, if the packet winds up someplace > bizarre ... it's nice to have *something* in the packet that says who > it's *really* from and to. True. However, wouldn't you really rather have a locator in there so that you can revert to hop-by-hop forwarding? Nope. I can't speak for other designs, but in Nimrod either it was sent as on datagram service, in which case it *already* has the locators, or it's part of a flow, and you don't need them. (If it's datagram service, it also has to have the EID's, since it's a transaction, and may be the only packet.) Understood and agreed. The corner case that you have to look at is the loss of flow state. I agree that if you have an EID, you can (probably) do sufficient work to return some error message to the source. Alternatively, if you have locators in the packet, you have the ability to a) forward the packet as a datagram and/or b) re-establish soft state for the flow based on the locator information. Locators are going to be long, and variable length; not the kind of data you want in the internetwork header in every packet. Well, if you assume that they're going to be that long, yes, I guess they will be. ;-) Me, I want a tractable datagram service too, so I'm not willing to concede that. The source and destination locators may be viewed as just part of the user state, along with the user-selected path, resource reservations, etc. If you aren't going to put all that into the headers, there's only limited use for having some of it. Locators are much more painful to include in all packets than EID's. These two things together cause them to fail to make the cut that EID's made. You're making the (rash?) assumption that most flows will not be straightforward. For the sake of discussion I'm willing to imagine a world where the bulk of all traffic is a flow rather than datagram service, but I find it a MUCH bigger leap to believe that every flow will be doing something more than best effort delivery. Of course, one alternative is to mod the header to make the appropriate locators included in the packet only if they would be of some use. For example, there's no point in the source locator if you want no error message. There's no point in the destination locator if you aren't willing to fallback to datagram mode. Tony From owner-Big-Internet@munnari.OZ.AU Thu May 5 16:42:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21344; Thu, 5 May 1994 12:48:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA07920; Thu, 5 May 1994 12:23:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA07917; Thu, 5 May 1994 12:13:27 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12299; Thu, 5 May 1994 09:11:37 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA06881; Wed, 4 May 94 16:13:33 -0700 Date: Wed, 4 May 94 16:13:33 -0700 From: Eric Fleischman Message-Id: <9405042313.AA06881@atc.boeing.com> To: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil Subject: Proposed IPng Business Requirements IPng Business Requirements Eric Fleischman May 4, 1994 Boeing Computer Services This is Straw Man IPng document seeking to address relevant business issues which impact the IPng Decision. As such, this is a possible companion document along with the "IPng Criteria Document" to be used to evaluate the IPng Alternatives. It is the belief of the author that each of the points within this document are as technical as any point within the criteria document. The difference, of course, is that the requirements within this document stem from the business requirements mentioned in the IPng White Papers and discussed within IPng Directorate meetings and over the IPng Directorate mail list. By contrast, the requirments within the Criteria document stem from two Birds of a Feather sessions within two different IETFs as well as extensive dialogs within the Big-Internet mail list. Consequently, the Criteria document's requirements are considerably more mature and universally accepted than any of the requirements enumerated here. 1.0 IPng Needs Enhanced Functionality over IPv4 The most important business requirement for IPng is that there must be a reason why end users will WANT to deploy IPng. We believe that the most compelling reason for users to WANT to deploy IPng is if IPng has functionality which users need and desire. Hence our first requirement: IPng must provide at least as much functionality as IPv4 and should contain enhanced functionality over IPv4. Functionality, in this definition, refers to capabilities and services. Popularly desired "cutting edge" functionalities include enhanced support for real time services, multimedia, mobility, and plug-and-play networking. 2.0 Ease of Transition from IPv4 IPng implies "change" -- the change from the current IPv4 stack to an IPng stack. From the end user's perspective, change implies the expenditure of time and money. Therefore, IPng should be so built that the overhead of changing from IPv4 to IPng will be minimal. This implies the existance of viable tools and approaches to minimize this change. Hence our second requirement: It must be easy to transition from IPv4 to IPng. This requirement may be fulfilled in may ways. It seems that a highly desirable (but not manditory) outcome of this requirement is to have existing IPv4 communities be able to indefinitely communicate with IPng systems via optional address extension capabilities. 3.0 IPng to be a Convergence Target End users hope to achieve interoperability between their computing devices. Each different deployed data communications protocol family implies added support costs for the users as well as diminished interoperability. The bottom line is that protocol family diversity negatively impacts the value of the end user's investment in computing technologies. For this reason it is desirable that IPng serve as a protocol to which other non- TCP/IP protocols may converge. This leads to our third requirement: We desire the selected IPng protocol to be able to technically serve as a protocol to which many different network layer protocols, not only IPv4, can converge. For this reason, we require that the selected IPng protocol have adequate addressing capabilities to be able to flexibly "support" the transition addressing needs of other existing network layer protocols (e.g., IPX, CLNP) should they also wish to transition to IPng. IPng should not lack any significant functionality of such existing protocols. 4.0 Generalised Encapsulation Method A fundamental IPng goal is to deploy "one protocol to bind them all." This may be achieved via migrating diverse technologies to IPng (previous requirement) or by using IPng as an encapsulation vehicle (this requirement) to join discontinuous non-TCP/IP protocol families. Hence our fourth requirement: A generalised encapsulation method (GEM) should be standardised such that an arbitrary datagram protocol can be carried over (or tunnelled through) the Internet before, during and after its transition to IPng. A specific issue with tunnels is their operational coordination (only possible between consenting adults). Self-configuring tunnels are highly desirable. [Some DNS support for tunnels may be needed - there is probably a way of having tunnels configure themselves by use of DNS info about addresses for the protocol to be tunnelled.] 5.0 Extensable Addressing Required It is widely presupposed that the computer industry is about to be revolutionized by an algorithmic change in which currently dumb devices (e.g., thermostates, electric wall sockets, light switches) will become networked coupled with the deployment of brand new address- intensive technologies (e.g., wireless applications, "home video"). This algorithmic change is commonly referred to as "toasternet". Unfortunately, like all revolutionary algorithmic changes, we are unable as a community to envision exactly what toasternet will really entail. Consequently, we need a flexible infrastructure which is able to handle whatever actually occurs. This implies the need to over-engineer the addressing capabilities of IPng so that it could adequately handle toasternet even to the extent of providing IPng addressing capabilities which we can not justify today based on our current technologies. That is, IPng must be able to endure until 2020 or longer (to minimize the number of end user transitions based on Internet scalability issues) and must therefore be overengineered and overdesigned to flexibly weather these future environments. For this reason requirement number 6 is formulated: IPng must provide flexible addressing. IPng addresses must be optionally extendable to support address lengths longer than the preferred minimum "fixed length" number of bytes/words. 6.0 User Addressing should be Autonomous Re-addressing devices costs time and money. This is particularly onerous for the very large user. For this reason the user's address space must be autonomous from the Internet in the sense that requirements for the user to re-address must solely be made by the user based upon requirements of their internal network as opposed to external (Internet) requirements to the user. This leads to requirement number 7: IPng users must be given autonomous addresses to use within their own internal networks. These addresses must not contain Internet dependencies which would demand that the user must readdress their devices solely due to changes within the Internet. 7.0 Clear Transition from IPv4 APIs to IPng APIs Billions of dollars of user-written applications currently exist. These applications use exposed Application Programming Interfaces (APIs). End users will not be able to migrate their extensive base of user-written applications from IPv4 to IPng unless tools and transition approaches to migrate these applications exist -- and the resulting IPng APIs are upwardly compatable from the IPv4 APIs. This implies the need for user code to be easily modified from using existing IPv4 APIs to use IPng APIs. Hence requirement number 8: There must be a defined and easy transition from IPv4 APIs to IPng APIs. 8.0 Local Addresses Some end users use local addresses as an aid within their total corporate computer security approach. Local addresses are addresses which are solely known (unique) within the corporation and are unknown (or non-unique) within the world-wide Internet community. Use of local addresses have proven to be very useful for these users to "hide" certain highly proprietary environments from the Internet. For this reason we have requirement number 8: The addressing approach must provide a capability to support local addresses. 9.0 Aggregation for Corporate Internets The IPng alternative must have adequate aggregation capabilities so that the addressing and routing needs of vast (private) user populations may be met (i.e., INTERNAL corporate networks). In addition to aiding the aggregation needs of the world-wide Internet community, the IPng approach's addressing must be able to identify the internal routing hierarchies of private corporation (i.e., hierarchies internal to the corporation without regard to the world-wide Internet infrastructure) as follows: * identify internal domains (e.g. the parts of our company located on different continents), * identify major campuses within the domains * identify "networks" within the larger campuses * identify subnetworks within the networks. 10.0 Decentralized Administration The world wide Internet is a network of networks. Each network within this larger community is administrated independently from the other networks within that community. Hence requirement #10: IPng addresses must permit multiple address administration authorities to exist in support of the world-wide Internet infrastructure with little or no coordination among them. 11.0 Other requirements A great many other factors are A Good Thing from a business perspective and should be targeted for implementation for business reasons within IPng. A short list of these desirable attributes now follows: * Policy routing support * Accounting support * Firewall-friendly * Network management-friendly * No licensing fees 9.0 Acknowledgements This draft is a straw man proposal which is largely based on notes received from Brian Carpenter. Brian's notes stem from a summary of relevant comments made on the IPng Directorate mail list. Brian should not be blamed or faulted by any mis-statements made by me in this document. Similarly, the author hopes that the readers of this document will be charitable. From ipng-request@cmf.nrl.navy.mil Tue May 3 06:27:00 1994 Received: by atc.boeing.com (5.57) id AA08679; Tue, 3 May 94 06:26:59 -0700 Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA06104 for ; Tue, 3 May 1994 09:20:14 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14591; Tue, 3 May 1994 15:19:40 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03678; Tue, 3 May 1994 15:19:38 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405031319.AA03678@dxcoms.cern.ch> Subject: Re: Second IPng Requirments Document To: ipng@cmf.nrl.navy.mil Date: Tue, 3 May 1994 15:19:38 +0200 (MET DST) In-Reply-To: <9404291950.AA12236@atc.boeing.com> from "Eric Fleischman" at Apr 29, 94 12:50:20 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1325 Status: RO Eric, I suppose everybody else is at Interop since nobody reacted. I think this is a very good start, in fact I have little to say. > > IPng must provide at least as much functionality as IPv4 and > should contain enhanced functionality over IPv4. > > Functionality, in this definition, refers to capabilities and services. > Popularly desired "cutting edge" functionalities include enhanced support > for real time services, multimedia, mobility, and plug-and-play networking. I would add support of commercial information services (authentication and accounting). ... > IPng users must be given autonomous addresses to use within their > own internal networks. These addresses must not contain Internet > dependencies which would demand that the user must readdress > their devices solely due to changes within the Internet. I assume that this is not meant to imply that the address prefix never changes, but that the subscriber's internal addressing scheme msut never be forced to change. You also probably want to make it clear that auto-configuration is not a general alternative to this requirement. (As a matter of fact, we find that automatically assigned Level 3 addresses are not a panacea - they complicate network management to about the same extent that they simplify it.) Brian From owner-Big-Internet@munnari.OZ.AU Thu May 5 17:27:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00998; Thu, 5 May 1994 16:50:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA08150; Thu, 5 May 1994 16:28:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA08147; Thu, 5 May 1994 16:25:35 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26498; Thu, 5 May 1994 14:55:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16719; Thu, 5 May 94 00:55:34 -0400 Date: Thu, 5 May 94 00:55:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405050455.AA16719@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, tli@cisco.com Subject: Re: Mandatory EID's Cc: jnc@ginger.lcs.mit.edu > I remain uneasy about pulling [EID's] out, for reasons I find hard to > articulate. If for no other reason, if the packet winds up someplace > bizarre ... it's nice to have *something* in the packet that says who > it's *really* from and to. True. However, wouldn't you really rather have a locator in there so that you can revert to hop-by-hop forwarding? Nope. I can't speak for other designs, but in Nimrod either it was sent as on datagram service, in which case it *already* has the locators, or it's part of a flow, and you don't need them. (If it's datagram service, it also has to have the EID's, since it's a transaction, and may be the only packet.) Locators are going to be long, and variable length; not the kind of data you want in the internetwork header in every packet. > Of course, you could make the same argument about the locators too. > If they weren't likely to be so darn long ... I'd be happy to put them > in every packet too, for much the same reason. Yup. This is the tradeoff that I made. Locators stay in the header for packets in flows. Looking at the costs and benefits, I don't think this is optimal. The source and destination locators may be viewed as just part of the user state, along with the user-selected path, resource reservations, etc. If you aren't going to put all that into the headers, there's only limited use for having some of it. Locators are much more painful to include in all packets than EID's. These two things together cause them to fail to make the cut that EID's made. Noel From owner-Big-Internet@munnari.OZ.AU Fri May 6 01:35:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20216; Fri, 6 May 1994 01:35:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA08629; Fri, 6 May 1994 01:13:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA08593; Fri, 6 May 1994 00:59:29 +1000 Received: from Princeton.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19591; Fri, 6 May 1994 01:21:03 +1000 (from jwagner@Princeton.EDU) Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.110/princeton) id AA20559; Thu, 5 May 94 11:09:34 -0400 Received: from clytemnestra.Princeton.EDU by ponyexpress.princeton.edu (5.65c/1.113/newPE) id AA19903; Thu, 5 May 1994 11:09:37 -0400 Received: by clytemnestra.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA15159; Thu, 5 May 94 11:09:32 EDT Message-Id: <9405051509.AA15159@clytemnestra.Princeton.EDU> To: flows@research.ftp.com Cc: big-internet@munnari.OZ.AU Subject: Re: Mandatory EID's In-Reply-To: Your message of "Wed, 04 May 1994 22:52:42 PDT." <199405050552.WAA16766@lager.cisco.com> X-Mailer: exmh version 1.3 4/7/94 Date: Thu, 05 May 1994 11:09:29 EDT From: John Wagner This discussion is about flows, but I've cc'd it to big-internet for those who haven't joined the new flow list yet. Please remove big-internet if you reply. > > > I remain uneasy about pulling [EID's] out, for reasons I find hard to > > articulate. If for no other reason, if the packet winds up someplace > > bizarre ... it's nice to have *something* in the packet that says who > > it's *really* from and to. > > True. However, wouldn't you really rather have a locator in there so > that you can revert to hop-by-hop forwarding? > > Nope. I can't speak for other designs, but in Nimrod either it was > sent as on datagram service, in which case it *already* has the > locators, or it's part of a flow, and you don't need them. (If it's > datagram service, it also has to have the EID's, since it's a > transaction, and may be the only packet.) > > Understood and agreed. The corner case that you have to look at is > the loss of flow state. I agree that if you have an EID, you can > (probably) do sufficient work to return some error message to the > source. > > Alternatively, if you have locators in the packet, you have the > ability to a) forward the packet as a datagram and/or b) re-establish > soft state for the flow based on the locator information. Something about this doesn't seem right. Having the locator in the packet does not provide enough information to make either decision. A flow has QOS attributes associated with it. I can have multiple flows between two hosts, each flow having different QOS requirements, with the result being the actual routes through the network may be different for each flow. None of those routes necessarily match the route chosen for a datagram. I don't think you can ever chose (a) unless the packet carries around a flag that says it is ok to do so. The same logic applies to (b). Without the complete QOS requirement I cannot compute the next hop (router), let alone the entire path to the destination. It may be that the majority of traffic has no QOS requirements and in this case (a) and (b) are possible. But I still think you need something in the packet to indicate no QOS applies. John Wagner From owner-Big-Internet@munnari.OZ.AU Fri May 6 05:31:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23763; Fri, 6 May 1994 03:21:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA08727; Fri, 6 May 1994 02:58:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA08702; Fri, 6 May 1994 02:33:16 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22702; Fri, 6 May 1994 02:54:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21558; Thu, 5 May 94 12:54:25 -0400 Date: Thu, 5 May 94 12:54:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405051654.AA21558@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, tli@cisco.com Subject: Re: Mandatory EID's Cc: jnc@ginger.lcs.mit.edu >> wouldn't you really rather have a locator in there so that you can >> revert to hop-by-hop forwarding? > in Nimrod either it was sent as on datagram service, in which case it > *already* has the locators, or it's part of a flow, and you don't need > them. The corner case that you have to look at is the loss of flow state. I think about this a fair amount, but I don't think it's insoluble at reasonable cost and simplicity. It seems to me that in any routing architecture, once a router crashes, the upstream router will continue to send packets into a black hole (via the old routing table entry) until it figures out that that router is down, at which point, it recomputes all the routing table entries to go around the outage. I think a similar process is workable for flows; if a router crashes and loses state, the upstream neighbours will know it, know which flows go through it, and can remedy the situation. In the interim, *either* design will lose packets, right? You can often do local repair, through a process I won't get into here, but I think it makes sense to retain the design principle that the endpoint is always the "fix of last resort". Just as when the routers drop user data packets, it's up to the endpoint to resend them, in the same way, the ultimate responsibility for repair of damaged flow state can be put back to the endpoint of the flow. That way, you only wind up doing local repairs where it's simple and easy; hopefully that will catch most cases, without a lot of complex mechanism to catch every last case. Alternatively, if you have locators in the packet, you have the ability to ... re-establish soft state for the flow based on the locator information. That's assuming that the only user state is the locators; if there was more, it doesn't help. > Locators are going to be long, and variable length; not the kind of data > you want in the internetwork header in every packet. I want a tractable datagram service too, so I'm not willing to concede that. I'm not sure I see what you're conceding. Datagram applications are typically not high-performance ones (and things like NFS don't count as "datagram"); they are DNS, etc. What's the problem if datagram is a little more inefficient, by virtue of having to put the locators in the packet? (In Nimrod, at least, the New Datagram Mode will forward them very efficiently...) > The source and destination locators may be viewed as just part of the > user state, along with the user-selected path, resource reservations, > etc. If you aren't going to put all that into the headers, there's only > limited use for having some of it. You're making the (rash?) assumption that most flows will not be straightforward. ... I'm willing to imagine a world where the bulk of all traffic is a flow rather than datagram service, but I find it a MUCH bigger leap to believe that every flow will be doing something more than best effort delivery. Well, I must admit, it's a bit difficult to forsee what's going to happen. It does seem to me that with all these things like authentication, billing, etc bearing down on us there's a good chance there will be a lot, but it's ahrd to say for sure. However, look at it this way. Go back to the point above; any scheme loses packets until you realize the next-hop router has crashed, then you recover. It's not clear there will *ever* be an opportunity to use those locators to forward the traffic, if there is a local repair! Then, for the cases where there isn't local repair, what does having the ability to maybe (i.e. if you aren't screwed with authentication, etc) forward some packets until end-end repair happens buy you, really? Is it worth the overhead of carrying the locators around in all the packets? Can you really not afford to lose some packets? (Seems unlikely, since we do it all the time now, and you'll have just lost a bunch when the next-hop router crashed *anyway*.) This is sort of the "if it's not broken, don't fix it" system design rule; you're putting a lot of energy into optimizing a low-probability repair case that's not worth optimizing. Noel From owner-Big-Internet@munnari.OZ.AU Fri May 6 11:30:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04198; Fri, 6 May 1994 08:35:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA08996; Fri, 6 May 1994 08:13:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA08982; Fri, 6 May 1994 07:59:15 +1000 Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29941; Fri, 6 May 1994 06:30:55 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA16499 (5.65c/IDA-1.4.4nsd for ); Thu, 5 May 1994 13:30:45 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA25251 (5.65c/IDA-1.4.4-910725 for ); Thu, 5 May 1994 13:30:44 -0700 Message-Id: <199405052030.AA25251@remmel.NSD.3Com.COM> To: big-internet@munnari.OZ.AU Subject: Re: Mandatory EID's In-Reply-To: Your message of "Wed, 04 May 94 22:52:42 PDT." <199405050552.WAA16766@lager.cisco.com> Date: Thu, 05 May 94 13:30:43 -0700 From: tracym@NSD.3Com.COM > Of course, one alternative is to mod the header to make the > appropriate locators included in the packet only if they would be of > some use. For example, there's no point in the source locator if you > want no error message. There's no point in the destination locator if > you aren't willing to fallback to datagram mode. > > Tony CATNIP provides the ability to have headers without source and/or destination addresses. (Tony hasn't yet grabbed that part of it for TURNIPP, however) Cheers, Tracy From owner-Big-Internet@munnari.OZ.AU Fri May 6 11:30:46 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04443; Fri, 6 May 1994 08:49:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA16707 Fri, 6 May 1994 08:46:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA09026; Fri, 6 May 1994 08:21:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA08965; Fri, 6 May 1994 07:46:06 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27437; Fri, 6 May 1994 05:11:10 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA09897; Thu, 5 May 1994 12:11:01 -0700 Date: Thu, 5 May 1994 12:11:01 -0700 From: Tony Li Message-Id: <199405051911.MAA09897@lager.cisco.com> To: jwagner@Princeton.EDU Cc: flows@Research.Ftp.Com, big-internet@munnari.OZ.AU In-Reply-To: John Wagner's message of Thu, 05 May 1994 11:09:29 EDT <9405051509.AA15159@clytemnestra.Princeton.EDU> Subject: Mandatory EID's > Alternatively, if you have locators in the packet, you have the > ability to a) forward the packet as a datagram and/or b) re-establish > soft state for the flow based on the locator information. Something about this doesn't seem right. Having the locator in the packet does not provide enough information to make either decision. You are correct. I was assuming that there was separate information in the packet to control the repair behavior. I informally call this the "Dave Clark Byte" as he pointed out the need for it in IPng proposals. This byte can encode a number of different options and its semantics is not entirely clear yet, but we can envision: - drop packet, no error - drop packet, return error - forward packet using hop-by-hop (using your flavor of locator or eid) - forward packet using hop-by-hop and return error - forward packet using hop-by-hop and establish this flow state - this packet includes full flow information, recompute full flow state More permutations are possible, of course. Tony From owner-Big-Internet@munnari.OZ.AU Fri May 6 11:31:56 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05530; Fri, 6 May 1994 09:23:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA16688 Fri, 6 May 1994 08:45:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA09011; Fri, 6 May 1994 08:20:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA08968; Fri, 6 May 1994 07:53:13 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28519; Fri, 6 May 1994 05:50:49 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Thu, 5 May 1994 12:50:27 -0700 Date: Thu, 5 May 1994 12:50:27 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199405051950.AA08944@zephyr.isi.edu> To: big-internet@munnari.OZ.AU, tli@cisco.com, jnc@ginger.lcs.mit.edu Subject: Re: Mandatory EID's Noel wrote: *> *> You can often do local repair, through a process I won't get into here, but I *> think it makes sense to retain the design principle that the endpoint is *> always the "fix of last resort". Just as when the routers drop user data *> packets, it's up to the endpoint to resend them, in the same way, the ultimate *> responsibility for repair of damaged flow state can be put back to the *> endpoint of the flow. That way, you only wind up doing local repairs where *> it's simple and easy; hopefully that will catch most cases, without a lot of *> complex mechanism to catch every last case. *> BTW, This is exactly the idea behind "triggered refreshes" proposed for RSVP. When a break happens, there would be an attempt to repair it locally ASAP by immediately sending local state setup messages along the new route. But ultimate responsibility still rests with the end systems. Bob Braden From owner-Big-Internet@munnari.OZ.AU Fri May 6 13:58:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11235; Fri, 6 May 1994 11:32:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA09177; Fri, 6 May 1994 11:08:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA09173; Fri, 6 May 1994 11:04:05 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04559; Fri, 6 May 1994 08:53:06 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id PAA01797; Thu, 5 May 1994 15:52:59 -0700 Date: Thu, 5 May 1994 15:52:59 -0700 From: Tony Li Message-Id: <199405052252.PAA01797@lager.cisco.com> To: tracym@nsd.3com.com Cc: big-internet@munnari.OZ.AU Subject: Re: Mandatory EID's CATNIP provides the ability to have headers without source and/or destination addresses. (Tony hasn't yet grabbed that part of it for TURNIPP, however) Consider it grabbed. In fact, further discussion over on the flows mailing list convinced me that there's no need for any type of locator OR eid in a flow-routed packet. Tony From owner-Big-Internet@munnari.OZ.AU Fri May 6 14:05:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14463; Fri, 6 May 1994 12:40:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA09271; Fri, 6 May 1994 12:18:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA09255; Fri, 6 May 1994 12:06:57 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09670; Fri, 6 May 1994 11:00:04 +1000 (from endrizzi@phantasm.sctc.com) Received: from SCTC.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA21140 Fri, 6 May 1994 10:59:50 +1000 (from endrizzi@phantasm.sctc.com) Received: from sccmailhost.sctc.com (elvis.sctc.com) by SCTC.COM (4.1/SCTC-010592) id AA10060; Thu, 5 May 94 19:56:07 CDT Received: from sccmailhost.sctc.com by sccmailhost.sctc.com id 138130000; 5 May 94 19:55 CDT Received: from phantasm by sccmailhost.sctc.com id 129880000; 5 May 94 19:54 CDT Received: from dreez.sctc.com by phantasm.sctc.com (4.1/SMI-4.2) id AA23484; Thu, 5 May 94 19:53:18 CDT Received: by dreez.sctc.com (5.0/SMI-4.2) id AA20294; Thu, 5 May 1994 19:53:08 +0600 Message-Id: <9405060053.AA20294@dreez.sctc.com> To: Eliot Lear Cc: "Robert G. Moskowitz" <0003858921@mcimail.com>, Eric Fleischman , brian , ipv4 ale , big internet , firewalls Reply-To: endrizzi@phantasm.sctc.com Subject: Re: NATs In-Reply-To: Your message of "Mon, 02 May 1994 15:04:31 PDT." <9405021504.ZM16049@yeager.corp.sgi.com> X-Mailer: exmh version 1.3delta 3/31/94 Date: Thu, 05 May 1994 19:53:06 -0500 From: Michael Endrizzi Content-Length: 711 In message <9405021504.ZM16049@yeager.corp.sgi.com>, Eliot Lear writes: >I think it's important to stress that network level security is in >some sense orthoganol to application layer security. Used today, >network layer security provides end to end privacy to the network >code. It does you no good to have that privacy if the hosts on >either end leak like sieves. > amen brother. Besides, if something is encrypted don't waste your time breaking the crypto but go after the keys. Keys are kept by application level programs protected by Unix permission bits.....wow. (According to Garfinkel and Spafford "Practical Unix Security" footnote page 282, this is a big problem with Kerberos) dreez From owner-Big-Internet@munnari.OZ.AU Sat May 7 03:24:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12398; Sat, 7 May 1994 02:43:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA10005; Sat, 7 May 1994 02:18:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA09928; Sat, 7 May 1994 01:50:09 +1000 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11282; Sat, 7 May 1994 02:11:43 +1000 (from Robert_Ullmann.LOTUS@CRD.lotus.com) Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA05729; Fri, 6 May 94 12:13:33 EDT Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA25008; Fri, 6 May 94 12:17:56 EDT Date: Fri, 6 May 94 12:17:56 EDT Message-Id: <9405061617.AA25008@Mail.Lotus.com> Received: by DniMail (v1.0); Fri May 6 12:17:54 1994 EDT To: UNIXML::"Big-Internet@munnari.OZ.AU"@lotus.com Subject: Re: Mandatory EID's >Consider it grabbed. In fact, further discussion over on the flows >mailing list convinced me that there's no need for any type of locator >OR eid in a flow-routed packet. When Tony finishes grabbing parts of Catnip for Turnipp, it will *be* Catnip. Tony: Catnip is supposed to be the converged protocol you are pushing so hard for. So why don't you contribute to it, since it has the advantage of being formally in the proposal process? Best Regards, Robert From owner-Big-Internet@munnari.OZ.AU Sun May 8 14:05:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09904; Sun, 8 May 1994 11:57:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA11594; Sun, 8 May 1994 11:34:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA11591; Sun, 8 May 1994 11:28:14 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09690; Sun, 8 May 1994 11:49:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08958; Sat, 7 May 94 21:49:38 -0400 Date: Sat, 7 May 94 21:49:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405080149.AA08958@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: IP Technical Criteria Cc: jnc@ginger.lcs.mit.edu > So [the reason for allowing overlaying the EID and locator] is just space > saving, right? In that case, I'm not at all sure I can agree it's a good > move to allow this. It's a fairly minor optimization, with potentially > very bad consequences As I mentioned before, I don't have *very* strong feeling on this. That is, I'll be willing to drop this if there is enough consensus that we can live without this space saving, and just require the IPng to have *separate* EID and routing info. I imagine it wouldn't be trivial to get this consensus, but I didn't hear a big uproar in reply to your message, so maybe it's possible. We just need to look whether this space saving would play any role when operating in certain environments (e.g. slow speed links). Umm. My thinking about low speed links is that it's almost impossible to design a practical internetwork protocol that is good enough to use, as is, on the really low-speed links. Those links will always need local, tuned, compression to work well; people use VJ compression on 1200 bps lines now, with the 20 byte IPv4 header; all the IPng candidates are longer. This principle actually extends to other things; the Internet assume a certain minimum service model, and any local medium which can't meet that has to be locally enhanced so it does provide that level of support. Examples other than minimum useful bandwidth are legion; packet size is one. ATM's frames are obviously a problem, but even if you have a net with 128 byte maximum size, say, I'll bet you'd wind up doing local fragmentation-reassembly. Another is reliabilty; if you have links with have a 10% chance of drop, and string 10 in a row, all of a sudden your packets have only a 35% chance of getting through. That probably wouldn't be good enough; you'd add some local reliability features. Here's another thing to think about; even if we minimize the internetwork header, there are still the reliable stream, application, etc headers. Are we going to go and bit-push them all? So, what all this means to me is that since some links are going to have to have local compression anyway, you shouldn't try to optimize for that goal; rather, you should optimize for the common case, i.e. high speed links, on which header size (as long as it's not ridiculous) is not that big an issue. Also, you go for maximizing the design lifetime, since the replacement cost is so fiendishly high; this means straightforward and clear, among other things. That means not trying to minimize the packet headers by tricks like overloading fields... Noel From owner-Big-Internet@munnari.OZ.AU Mon May 9 18:58:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03735; Mon, 9 May 1994 17:42:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA12990; Mon, 9 May 1994 17:19:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA12965; Mon, 9 May 1994 16:54:13 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24951; Mon, 9 May 1994 14:19:07 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA01586; Sun, 8 May 94 23:19:34 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa23060; 9 May 94 4:10 GMT Date: Sun, 8 May 94 23:16 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Eric Fleischman To: big internet To: ipng Subject: Re: Proposed IPng Business Requirements point 3.0 Message-Id: <72940509041627/0003858921NA4EM@mcimail.com> ---------------------------------------------------------------------- 3.0 IPng to be a Convergence Target End users hope to achieve interoperability between their computing devices. Each different deployed data communications protocol family implies added support costs for the users as well as diminished interoperability. The bottom line is that protocol family diversity negatively impacts the value of the end user's investment in computing technologies. For this reason it is desirable that IPng serve as a protocol to which other non- TCP/IP protocols may converge. This leads to our third requirement: We desire the selected IPng protocol to be able to technically serve as a protocol to which many different network layer protocols, not only IPv4, can converge. For this reason, we require that the selected IPng protocol have adequate addressing capabilities to be able to flexibly "support" the transition addressing needs of other existing network layer protocols (e.g., IPX, CLNP) should they also wish to transition to IPng. IPng should not lack any significant functionality of such existing protocols. -------------------------------------------------------------------------- Ugh, I have a little trouble with this wording. Perhaps it is the word 'capabilites'. This implies that it ca directly subsume all current and secretly in the works addressing plans. I'd prefer 'functionality'. For if one scheme can be shown to meet the functions used in a current address implementation, then that scheme is a convergence point even if it looks and feels a lot different. Of course this only looking at addressing. When addressing is used to solve routing problems we have to be very careful. For it seems to me that there are many who now say that routing needs to be solved separate to addressing. Thus those that have current needs met by current addressing schemes, need to evaluate the proposals very carefully to ensure that they separate addressing from routing. And that capability word does not engender such a thought process. My two cents anyway. Bob Moskowitz Speaking for Bob, not Chrysler, but colored by my years at Chrysler... From owner-Big-Internet@munnari.OZ.AU Tue May 10 00:06:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18180; Tue, 10 May 1994 00:06:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA13365; Mon, 9 May 1994 23:44:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA13359; Mon, 9 May 1994 23:40:42 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15902; Mon, 9 May 1994 23:17:57 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA07917; Mon, 9 May 94 07:23:21 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB11393; Mon, 9 May 94 06:16:11 PDT Date: Mon, 9 May 94 06:16:11 PDT Message-Id: <9405091316.AB11393@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN), big-internet@munnari.OZ.AU (bigi) From: Greg Minshall Subject: Re: IP Technical Criteria Brian, >Yes, but it provides both *badly*. Route aggregation was not >designed in, and adding it (CIDR) means that hosts may have >to change their EID if the service provider changes. >SIPP addresses as currently defined seem to have some of the same >problem; changing provider changes your address, and there is no EID. >NSAPAs have the locator and ID buried in a single structure. Could you explain a bit more? Why aren't NSAPAs prone to the same problem? Why do you think the 6-byte field meets the (unspecified!) requirements of an EID? Greg From owner-Big-Internet@munnari.OZ.AU Tue May 10 00:08:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18313; Tue, 10 May 1994 00:08:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA13383; Mon, 9 May 1994 23:46:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA13362; Mon, 9 May 1994 23:43:57 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16430; Mon, 9 May 1994 23:35:44 +1000 (from yakov@watson.ibm.com) Message-Id: <9405091335.16430@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1819; Mon, 09 May 94 09:35:40 EDT Date: Mon, 9 May 94 09:35:40 EDT To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU Subject: IP Technical Criteria Ref: Your note of Sat, 7 May 94 21:49:38 -0400 Noel, >I imagine it wouldn't be trivial to get this consensus, but I didn't >hear a big uproad in reply to your message, so mabe it's possible. As I mentioned before, I'll be willing to drop the need for overlaying the EID and routing info and settle with *always* requiring separate EID and routing info in a packet. Since nobody argued strongly in favor of allowing overlay (I don't think I argued stronly), we should perhaps settle on requiring the IPng to always have separate EID and routing info. Yakov. From owner-Big-Internet@munnari.OZ.AU Tue May 10 03:01:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24647; Tue, 10 May 1994 03:01:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA13652; Tue, 10 May 1994 02:39:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA13638; Tue, 10 May 1994 02:22:05 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23958; Tue, 10 May 1994 02:43:47 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Mon, 9 May 1994 09:43:43 -0700 Date: Mon, 9 May 1994 09:43:43 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199405091643.AA13576@zephyr.isi.edu> To: big-internet@munnari.OZ.AU, ses@tipper.oit.unc.edu Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet 1. Wrong mailing list. Big-internet concerns scaling issues (you know, like in "big Internet". This would be better suited to the end2end-interest list. 2. Please see RFC-1379. Bob Braden From owner-Big-Internet@munnari.OZ.AU Tue May 10 03:58:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16262; Mon, 9 May 1994 23:31:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA13307; Mon, 9 May 1994 23:09:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA13293; Mon, 9 May 1994 22:50:13 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05346; Mon, 9 May 1994 18:20:11 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA07387; Mon, 9 May 94 04:19:40 EDT Message-Id: <9405090819.AA07387@tipper.oit.unc.edu> To: big-internet@munnari.OZ.AU Subject: TIME-WAIT vs WWW - Big Servers on the Big Internet Date: Mon, 09 May 94 04:19:40 -0400 From: Simon E Spero Recently I've been working on high-performance servers for HTTP and GOPHER, two quite simple TCP based protocols, whose basic m.o. is to read a short request, then blast out a stream of data, finishing off by dropping the connection to indicate the end of file. In the HTTP case, once a file has been retrieved, several more transations will immediately be initiated, corresponding to automatically retrieved objects referenced in the initally transferred file. This can lead to a high burst rate, and generates a large number of connections within a relatively short time frame, especially when many users are accessing a server. I constructed a test client designed to simulate a variable number of concurrent users (codename: web-killer), and used it to benchmark the high performance server under various levels of simulated load. Initially the server was capable of completing transactions within a few 100ths of a second; however, at higher load levels, this degenerated into times in the 10s of seconds. All of this extra time was spent in the connection estabilishment phase. A quick invocation of netstat on the server showed many hundreds of connections sitting in TIME_WAIT, on the off-chance that an ancient duplicate might turn up. The problem is caused by the duration of the TIME_WAIT period being effectively infinite with respect to the connection duration ("240 seconds? I'll be old by then"). The connections just build up and up, until the system runs out of control blocks. It might be possible to reduce the impact by hacking the implementation to use special case data structures for the TIME_WAIT state, but it does seem strange to have such a huge amount of overhead for a rare worst-case situation. Also, not that it actually makes a difference, but the 240 second wait time does seem a tad excessive. What scenarios in the modern Internet could generate (e.g. the 200 second case). Do any of the the IP-NG contenders handle TIME_WAIT differently? Would longer sequence numbers reduce the need for keeping the old codgers hanging around so they can tell people to go away? Simon p.s. Incidentally, a lot of the original Bezerkley code seems to make assumptions about what a connection should do that are directly hostile to protocols like GOPHER and HTTP. The most obvious example is inetd, which, as distributed, will automatically shut down gopher and HTTP servers at the first hint of popularity, reasoning that since they spawn and exit so quickly, they must be in an infinite loop. From owner-Big-Internet@munnari.OZ.AU Tue May 10 04:30:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18369; Tue, 10 May 1994 00:10:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA13398; Mon, 9 May 1994 23:48:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA13345; Mon, 9 May 1994 23:27:43 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16964; Mon, 9 May 1994 23:49:13 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405091349.16964@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 9 May 1994 14:48:13 +0100 To: Simon E Spero Cc: big-internet@munnari.OZ.AU Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet In-Reply-To: Your message of "Mon, 09 May 94 04:19:40 EDT." <9405090819.AA07387@tipper.oit.unc.edu> Date: Mon, 09 May 94 14:48:09 +0100 From: Jon Crowcroft this certainly is an growth area... >Recently I've been working on high-performance servers for HTTP and GOPHER, >two quite simple TCP based protocols, whose basic m.o. is to read a short >request, then blast out a stream of data, finishing off by dropping the >connection to indicate the end of file. see below why i believe this is not the usually required model >Do any of the the IP-NG contenders handle TIME_WAIT differently? Would longer >sequence numbers reduce the need for keeping the old codgers hanging around >so they can tell people to go away? IP-NG doesnt affect the TIME_WAIT in TCP, unless it abolishes dynamic routing and does layer violation - the internet layer has bounds on packet lifetimes to limit the damage caused by loops, but you want a lifetime bounded by the frequency of connection start/stop/lifetime versus crash/reboot cycle times, and that is application and system specific... >GOPHER and HTTP. The most obvious example is inetd, which, as distributed, >will automatically shut down gopher and HTTP servers at the first hint of >popularity, reasoning that since they spawn and exit so quickly, they must >be in an infinite loop. actually, since most retrievals of apages that transfer a lot of data result in many connections (e.g. the text, and seperate GIFs), the HTTP model is broken - it should batch the data into a single connection, and de-batch at client - otherwise, with the lack of congestio nwindow caching in route tables, every conenction will have to go through slowstart... and get a sort of high level stop&go performance... in really high bandwidth nets, you will probably find that the usage model for WWW traffic will start to resemble file browsing in unix, and you want to actually open a single connection from client to server, and start to barrel the data back from the current page, and from links in the current page (so long as there was a good data distribution model, c.f. caching, this wouldn't cause to much wide area traffic), and a bit like cache lookahead predictions (see the rs6000 instruction bracnh processor for instance) you could get really good user performace (at a net cost, of course, but hey, bandwidth is free isn't it? at least most the WWW servers seem to be designed as if it is, which is all well and good and citizen of the future-ish) some other reasons the www folks should liase as much as possible with the lower level people... cheers jon From owner-Big-Internet@munnari.OZ.AU Tue May 10 04:32:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19274; Tue, 10 May 1994 00:41:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA13461; Tue, 10 May 1994 00:19:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA13370; Mon, 9 May 1994 23:45:29 +1000 From: smb@research.att.com Received: from ninet.research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18247; Tue, 10 May 1994 00:06:56 +1000 (from smb@research.att.com) Message-Id: <9405091406.18247@munnari.oz.au> Received: by gryphon; Mon May 9 10:01:18 EDT 1994 To: Simon E Spero Cc: big-internet@munnari.OZ.AU Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet Date: Mon, 09 May 94 10:01:17 EDT Do any of the the IP-NG contenders handle TIME_WAIT differently? Would longer sequence numbers reduce the need for keeping the old codgers hanging around so they can tell people to go away? Thus far, IPng has been looking at IP and its close friends (ICMP, routing, etc.) only. My suggestion of even as simple a change as widening the sequence number fields did not meet with particularly loud approval. We may be looking at TCP later, but not yet. Incidentally, a lot of the original Bezerkley code seems to make assumptions about what a connection should do that are directly hostile to protocols like GOPHER and HTTP. The most obvious example is inetd, which, as distributed, will automatically shut down gopher and HTTP servers at the first hint of popularity, reasoning that since they spawn and exit so quickly, they must be in an infinite loop. That's an interesting dilemma! The shutdown code in inetd was added as a response to an earlier problem -- that missing servers, especially for UDP, could generate an incredible amount of load on the target machine. But the heuristic now fails. It isn't clear what a better strategy would be. From owner-Big-Internet@munnari.OZ.AU Tue May 10 05:10:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22028; Tue, 10 May 1994 01:51:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA13588; Tue, 10 May 1994 01:29:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA13511; Tue, 10 May 1994 01:03:28 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20982; Tue, 10 May 1994 01:25:07 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405091525.20982@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 9 May 1994 16:23:12 +0100 To: John Hascall Cc: big-internet@munnari.OZ.AU Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet In-Reply-To: Your message of "Mon, 09 May 94 10:03:53 CDT." <9405091503.AA01160@pooh.cc.iastate.edu> Date: Mon, 09 May 94 16:22:53 +0100 From: Jon Crowcroft > ... but, it may actually, be the "right thing to do". As I > understand slowstart (please correct me if I am wrong), it > only happens once at the the start of a connection. nope. the congestion avoidance happesn every time there is congestion (i.e. packet loss indicated by enough losses over a window to cause some nyumber of duplicate acks or timeouts...) > have bursty traffic like HTTP: > while (!bored) { > big xfer > stare a bit > } > it seems to me that if you kept the connection open, you > would slowstart, pause, and then on the next transfer > start "full bore", possibly causing bad congestion. i think it'd work fine...if the user doesn't look at any data, their client will do no reads, and the receive window will close, and cause the sender to slow up... cheers jon From owner-Big-Internet@munnari.OZ.AU Tue May 10 05:14:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27270; Tue, 10 May 1994 04:12:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA13727; Tue, 10 May 1994 03:49:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA13713; Tue, 10 May 1994 03:30:03 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19337; Tue, 10 May 1994 00:43:35 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14847(8)>; Mon, 9 May 1994 07:39:14 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 9 May 1994 07:37:19 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IP Technical Criteria In-Reply-To: jnc's message of Sat, 07 May 94 18:49:38 -0800. <9405080149.AA08958@ginger.lcs.mit.edu> Date: Mon, 9 May 1994 07:37:07 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94May9.073719pdt.12171@skylark.parc.xerox.com> > As I mentioned before, I don't have *very* strong feeling on this. That > is, I'll be willing to drop this if there is enough consensus that we can > live without this space saving, and just require the IPng to have > *separate* EID and routing info. > > I imagine it wouldn't be trivial to get this consensus, but I didn't hear > a big uproar in reply to your message, so maybe it's possible. ROAR!! I don't have time for more at the moment, but if you are going to use a "silence is consent" rule, consider the silence to be broken. Steve From owner-Big-Internet@munnari.OZ.AU Tue May 10 05:15:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28801; Tue, 10 May 1994 04:46:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA13776; Tue, 10 May 1994 04:24:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA13754; Tue, 10 May 1994 04:03:57 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27920; Tue, 10 May 1994 04:24:51 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14485(2)>; Mon, 9 May 1994 11:23:43 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 9 May 1994 11:24:14 -0700 To: smb@research.att.com Cc: Simon E Spero , deering@parc.xerox.com, big-internet@munnari.OZ.AU Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet In-Reply-To: smb's message of Mon, 09 May 94 07:01:17 -0800. <9405091406.18247@munnari.oz.au> Date: Mon, 9 May 1994 11:24:02 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94May9.112414pdt.12171@skylark.parc.xerox.com> > Thus far, IPng has been looking at IP and its close friends (ICMP, routing, > etc.) only. My suggestion of even as simple a change as widening the > sequence number fields did not meet with particularly loud approval. > We may be looking at TCP later, but not yet. I think the important thing to recognize is that TCP changes of this sort can and should be *orthogonal* to the IPng-selection process. However, there is no reason not to pursue both issues concurrently, i.e., TCPng, if that's what's needed, does not have to wait for IPng (or vice versa). Steve From owner-Big-Internet@munnari.OZ.AU Tue May 10 05:15:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28846; Tue, 10 May 1994 04:48:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA13802; Tue, 10 May 1994 04:26:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA13773; Tue, 10 May 1994 04:19:22 +1000 Received: from mailhub.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20154; Tue, 10 May 1994 01:04:58 +1000 (from john@iastate.edu) Received: from pooh.cc.iastate.edu by mailhub.iastate.edu id AA24256; Mon, 9 May 1994 10:04:35 -0500 Received: by pooh.cc.iastate.edu; id AA01160; Mon, 9 May 1994 10:03:54 -0500 Message-Id: <9405091503.AA01160@pooh.cc.iastate.edu> To: Jon Crowcroft Cc: big-internet@munnari.OZ.AU Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet In-Reply-To: Your message of Mon, 09 May 1994 14:48:09 +0100. <9405091349.16964@munnari.oz.au> Date: Mon, 09 May 1994 10:03:53 CDT From: John Hascall SS> == Simon E Spero JC> == Jon Crowcroft SS> Recently I've been working on high-performance servers for HTTP and GOPHER, SS> two quite simple TCP based protocols, whose basic m.o. is to read a short SS> request, then blast out a stream of data, finishing off by dropping the SS> connection to indicate the end of file. JC> see below why i believe this is not the usually required model JC> actually, since most retrievals of apages that transfer a lot of data JC> result in many connections (e.g. the text, and seperate GIFs), the JC> HTTP model is broken - it should batch the data into a single JC> connection, and de-batch at client - otherwise, with the lack of JC> congestio nwindow caching in route tables, every conenction will have JC> to go through slowstart... and get a sort of high level stop&go JC> performance... I'm sure I find the pause while waiting to reconnect to the same HTTP server I just connected to a few seconds ago as annoying as everyone else does... ... but, it may actually, be the "right thing to do". As I understand slowstart (please correct me if I am wrong), it only happens once at the the start of a connection. So if have bursty traffic like HTTP: while (!bored) { big xfer stare a bit } it seems to me that if you kept the connection open, you would slowstart, pause, and then on the next transfer start "full bore", possibly causing bad congestion. John ------------------------------------------------------------------------------- John Hascall ``An ill-chosen word is the fool's messenger.'' Systems Software Engineer Project Vincent Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551 From owner-Big-Internet@munnari.OZ.AU Tue May 10 08:16:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06468; Tue, 10 May 1994 08:16:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA13969; Tue, 10 May 1994 07:54:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA13966; Tue, 10 May 1994 07:46:17 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21881; Tue, 10 May 1994 01:45:05 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA00968; Mon, 9 May 1994 17:42:12 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA05847; Mon, 9 May 1994 17:42:11 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405091542.AA05847@dxcoms.cern.ch> Subject: Re: IP Technical Criteria To: big-internet@munnari.OZ.AU (bigi) Date: Mon, 9 May 1994 17:42:11 +0200 (MET DST) In-Reply-To: <9405091316.AB11393@WC.Novell.COM> from "Greg Minshall" at May 9, 94 06:16:11 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 737 Greg, > > >Yes, but it provides both *badly*. Route aggregation was not > >designed in, and adding it (CIDR) means that hosts may have > >to change their EID if the service provider changes. > > >SIPP addresses as currently defined seem to have some of the same > >problem; changing provider changes your address, and there is no EID. > >NSAPAs have the locator and ID buried in a single structure. > > Could you explain a bit more? Why aren't NSAPAs prone to the same problem? They change when you change provider, but ES-IS should handle it automatically. > Why do you think the 6-byte field meets the (unspecified!) requirements of > an EID? > I'm not sure it does (but we haven't run out of Ethernet addresses yet). Brian From owner-Big-Internet@munnari.OZ.AU Tue May 10 14:06:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18897; Tue, 10 May 1994 14:06:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA14297; Tue, 10 May 1994 13:44:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA14283; Tue, 10 May 1994 13:39:10 +1000 Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18570; Tue, 10 May 1994 14:00:47 +1000 (from martillo@penril.com) Received: from penril.penril.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwpfs12112; Tue, 10 May 94 00:00:33 -0400 Received: from speedo.penril.com by penril.penril.com (4.1/SMI-4.1) id AA11280; Mon, 9 May 94 23:29:10 EDT Date: Mon, 9 May 94 23:29:10 EDT From: martillo@penril.com (Joachim Martillo) Message-Id: <9405100329.AA11280@penril.penril.com> Received: by speedo.penril.com (4.1/SMI-4.1) id AA22226; Mon, 9 May 94 23:57:42 EDT To: pst@cisco.com Cc: big-internet@munnari.OZ.AU, bgpd@merit.edu In-Reply-To: Paul Traina's message of Wed, 06 Apr 1994 10:29:36 -0700 <199404061729.AA22294@cider.cisco.com> Subject: Introducing proxy aggregations? Date: Wed, 06 Apr 1994 10:29:36 -0700 From: Paul Traina > To: Paul Traina > Subject: Re: Introducing proxy aggregations? > Paul: > If we can't get sites to upgrade just one border router and do a minor > configuration change "for the good of the Internet" and "because my vendor > told me so", how will we ever get them to deploy IPng (which will require > host changes before being fully-functional and again provide little tangible > benefit). > Does "Internet Darwinism" predict NAT boxes for IPng? > > ;-) > /John Yes. Paul p.s. no smiley face intended The persistence of internetworking fascism is truly amazing. Any internet which is not a multiprotocol internet is a toy internet. Should IPng ever be finally specified (I won't hold my breath), it will simply be one more networking protocol (and probably not even a very important one) among the networking protocols found running in multiprotocol internets. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main Street Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@pluto.com From owner-Big-Internet@munnari.OZ.AU Tue May 10 14:09:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB18965; Tue, 10 May 1994 14:09:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA14312; Tue, 10 May 1994 13:47:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA14280; Tue, 10 May 1994 13:28:08 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18155; Tue, 10 May 1994 13:49:49 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-26.dialip.mich.net (pm002-26.dialip.mich.net [35.1.48.107]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id XAA05022 for ; Mon, 9 May 1994 23:49:46 -0400 Date: Tue, 10 May 94 03:22:50 GMT From: "William Allen Simpson" Message-Id: <2345.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Separation of Identifier and Locator > From: yakov@watson.ibm.com > Since nobody argued strongly in favor of allowing overlay (I don't > think I argued stronly), we should perhaps settle on requiring the > IPng to always have separate EID and routing info. > What?!? How many arguments do you want? Oh, you mean _after_ you posted, as if your posting is somehow more important? Everybody has to repeat the arguments of two years.... While I strongly believe that _understanding_ the different uses of addressing for identifying as opposed to locating a system, I am strongly opposed to separating them in the common case. The identifier MUST also locate, even if slowly. I do not expect the net to be heirarchical. It is a mesh. That's why we call it a net, not a tree. I do not expect the DNS to hold (assuming only six degrees of freedom maximum) 6! (720) dynamically updated locators, of 120 bytes or more each, for every node. I expect that source routing will be used in special cases where policy or efficiency requires, and through a special flow setup mechanism. I expect that all other packets will be routed based on the identification of the node that comes from its assignment authority, which _is_ administratively heirarchical. I believe that nodes will have multiple identifiers from multiple assignment authorities. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Tue May 10 16:05:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17537; Tue, 10 May 1994 13:32:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA14242; Tue, 10 May 1994 13:09:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA14226; Tue, 10 May 1994 12:58:16 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17104; Tue, 10 May 1994 13:19:46 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 10 May 1994 12:18:53 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id MAA22703; Tue, 10 May 1994 12:18:53 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA29065; Tue, 10 May 94 12:18:53 JST Date: Tue, 10 May 94 12:18:53 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405100318.AA29065@cactus.slab.ntt.jp> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: IP Technical Criteria Cc: big-internet@munnari.OZ.AU > As I mentioned before, I don't have *very* strong feeling on this. That > is, I'll be willing to drop this if there is enough consensus that we can > live without this space saving, and just require the IPng to have > *separate* EID and routing info. > > I imagine it wouldn't be trivial to get this consensus, but I didn't hear > a big uproar in reply to your message, so maybe it's possible. I personally like a separate EID (Pip had one). However, I don't like what I call meta-requirements. That is, requirements that say how something should be done rather than just say what should be done. If there are a list of (direct) requirements, and if it turns out that a protocol can't satisfy them without having a separate EID, then the requirement for the separate EID is implicit through the direct requirements, and doesn't have to be explicitly called out. If, on the other hand, the direct requirements can be accomplished without a separate EID, then the explicit requirement for a separate EID is bad because it unecessarily restricts the solution set. Either way, separate EIDs, or any other meta-requirement, is not useful, and I'd rather not set a precedent for it here.... PF From owner-Big-Internet@munnari.OZ.AU Tue May 10 21:37:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29738; Tue, 10 May 1994 18:46:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA14536; Tue, 10 May 1994 18:24:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA14522; Tue, 10 May 1994 18:05:40 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28755; Tue, 10 May 1994 18:26:55 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA27679; Tue, 10 May 1994 10:26:15 +0200 Message-Id: <199405100826.AA27679@mitsou.inria.fr> To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: IP Technical Criteria In-Reply-To: Your message of "Tue, 10 May 1994 12:18:53 +0200." <9405100318.AA29065@cactus.slab.ntt.jp> Date: Tue, 10 May 1994 10:26:14 +0200 From: Christian Huitema Paul, You are absolutely correct. There sould not be any "requirement" that specifies a solution rather than "a problem to solve." I am personally very hesitant with any "mandatory EID" requirement for at least two reasons: the need to manage yet another name space and the fact that most arguments I have seen seems to belong to the architecture of transport protocols. The administration of a name space is a heavy task. No, I do not believe we can use IEEE-802 addresses to that effect. They tends not to be that much unique in practice (many boards are soft-configured); the 48 bits space is burnt at a fast rate (no recovery of used numbers); they identify interface boards rather than "systems" (change if you change the board). We will have to resort to a managed space and we will have to manage it ourselves; there is no magic pill. We already manage two spaces, names and addresses. Adding a third is dubious. Achieving the same functionality by reusing the uniqueness property of the address space would be IMHO a big win. The classic arguments for EIDs are related to stable identification of connection contexts. I already mentioned that this is really a problem of transport protocol design; doing it with destination specific identifiers has been demonstrated in the case of point to point connections (XTP). Similar solutions could be achieved with group specific identifiers or by passing an explicit EID in the transport packets. There is an old rule which should be applied there: if it is not used for routing, it should not be in the gateways. It should not be in IP either. By the way, won't we ever want to allow process mobility? If you use a station ID to identify your context, you are bound for serious problems there... Fact is that we have to support TCP, mobility and provider selection. This is the strong requirement. "A separate EID" is one solution to the problem. There are others, e.g. the SIPP solution of relying on an "identifying address" + combining it with source routing information if that is needed for mobility or provider selection. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Wed May 11 04:06:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19799; Wed, 11 May 1994 04:06:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA15104; Wed, 11 May 1994 03:44:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA15087; Wed, 11 May 1994 03:28:21 +1000 Received: from LABS-N.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18132; Wed, 11 May 1994 03:23:44 +1000 (from kent@BBN.COM) Message-Id: <9405101723.18132@munnari.oz.au> To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of Mon, 25 Apr 94 16:00:11 -0400. <9404252000.AA28202@ginger.lcs.mit.edu> Date: Tue, 10 May 94 13:22:07 -0400 From: Steve Kent Noel, I thought of another motivation for requiring the dns-security mechanisms algorithm independent. The DoD makes extensive use of TCP/IP and it is a market into which many vendors probably want to be able to continue to sell. However, the crypto algorithms used in DoD networks are often different from those employed in the open Internet. It behooves us to adopt security standards that are algorithm independent whenever we would like the DoD to be able to use the same protocols but with different crypto algorithms. In circumstances where the DoD enclaves are isolated from the open Internet, there is no need for commonality of algorithm, but commonality of protocol still allows for DoD use of COTS products. Steve From owner-Big-Internet@munnari.OZ.AU Wed May 11 04:07:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19813; Wed, 11 May 1994 04:07:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA15119; Wed, 11 May 1994 03:45:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA15090; Wed, 11 May 1994 03:29:57 +1000 Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19133; Wed, 11 May 1994 03:51:36 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.8/8.6.8) id NAA00919; Tue, 10 May 1994 13:51:30 -0400 Date: Tue, 10 May 1994 13:51:30 -0400 From: Vadim Antonov Message-Id: <199405101751.NAA00919@titan.sprintlink.net> To: martillo@penril.com, pst@cisco.com Subject: Re: Introducing proxy aggregations? Cc: bgpd@merit.edu, big-internet@munnari.OZ.AU >The persistence of internetworking fascism is truly amazing. Any >internet which is not a multiprotocol internet is a toy internet. Khe-khe. We have bi-protocol production network. Guess the traffic on a second protocol stack (CLNP OSI/TUBA). 1 packet in 10 seconds is considered an intensive usage. Face it, the "second Internet" will never catch on. Any realistic IPNG proposal should include trivial stateless translation to/from IP v4. (A side note on "internetworking fascism" -- oh, yeah, the power outlet fascizm is truly amazing. All unhappy electrical gizmo manufacturers have absolutely no freedom in inventing their own plugs and sockets. Any power grid which is not a multi-outlet- configuration is a toy power grid. And those 60Hz and 110V are simply horrible.) Also, don't forget of Nazi clause -- any discussion mentioning them is de-facto became a flamewar and should be terminated. Please use arguments instead of name calling. Convergence on a single standard is the sign of mature technology. At some time the benefits of alternative solutions become immaterial compared with massive cost savings of using standards. Sure, in the mature technology non-standards still exist but their usage is confined to unique applications. >Should IPng ever be finally specified (I won't hold my breath), it >will simply be one more networking protocol (and probably not even a >very important one) among the networking protocols found running in >multiprotocol internets. Isn't that what we're trying to get rid of? Everybody's sick of multiprotocol internets. Have you ever tried to configure an enterprise network which does SNA, IPX, Appletalk and IP (plus somebody wants to play with TUBA) over the same wires? Have you ever thought what fraction of cisco's cost is support for non-IP protocols? (I mean *cost* not price w/o options). The datagram level is not the place to play plurality. The very success of Internet is due to the fact that it has the single common denominator -- the IP. --vadim From owner-Big-Internet@munnari.OZ.AU Wed May 11 05:22:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18483; Wed, 11 May 1994 03:32:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA15049; Wed, 11 May 1994 03:09:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA15024; Wed, 11 May 1994 02:38:08 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14542; Wed, 11 May 1994 01:54:42 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA04416; Tue, 10 May 94 08:53:58 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA28717; Tue, 10 May 94 08:53:01 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA09918; Tue, 10 May 1994 08:53:45 -0700 Date: Tue, 10 May 1994 08:53:45 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9405101553.AA09918@jurassic.Eng.Sun.COM> To: big-internet@munnari.OZ.AU Cc: Bob.Hinden@Eng.Sun.COM In-Reply-To: <94May9.073719pdt.12171@skylark.parc.xerox.com> Subject: Re: IP Technical Criteria > As I mentioned before, I don't have *very* strong feeling on this. That > is, I'll be willing to drop this if there is enough consensus that we can > live without this space saving, and just require the IPng to have > *separate* EID and routing info. > > I imagine it wouldn't be trivial to get this consensus, but I didn't hear > a big uproar in reply to your message, so maybe it's possible. I also do not agree that there needs to be a strict separation of EID and routing info. I think the concept of separation of identification and location (routing) is a lot like protocol layering. It provides a good model to "think" about the issues. This, also like layering, does not mean that the information used to specify identification and location needs to be in separate bits in the packet. Bob From owner-Big-Internet@munnari.OZ.AU Wed May 11 05:23:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22272; Wed, 11 May 1994 05:16:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA15188; Wed, 11 May 1994 04:54:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA15163; Wed, 11 May 1994 04:23:28 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20760; Wed, 11 May 1994 04:32:12 +1000 (from kre@munnari.OZ.AU) To: Christian Huitema Cc: big-internet@munnari.OZ.AU Subject: Re: IP Technical Criteria In-Reply-To: Your message of "Tue, 10 May 1994 10:26:14 +0200." <199405100826.AA27679@mitsou.inria.fr> Date: Wed, 11 May 1994 04:32:12 +1000 Message-Id: <17542.768594732@munnari.OZ.AU> From: Robert Elz Christian, I almost agree with everything that you say. Certainly there is absolutely no justification for any IPng criteria doc to start setting out methods, or solutions, only requirements, and assuming that EIDs were mandated, the method by which EIDs are carried is certainly beyond its scope. I also agree that EIDs are mostly (but probably not entirely) a transport issue - and that's one reason why I still like John Curran's TUNE proposal (even if John no longer does). That put the EIDs in a layer between IPng (or IPv4) and transport - which has the advantage of being common for many different transports, and not requiring changes to existing transport protocols. However, I don't agree that that that moves EIDs outside the scope of IPng. One of the requirements for all candidate IPng proposals is that they devise a method by which TCP (etc) are carried over IPng, it could hardly be otherwise, no-one would even half believe an IPng which not only hadn't carried any TCP traffic, but for which the method for so doing was missing, meaning that interoperability was doomed. Of course all current IPng candidates are doing exactly this, and I believe are already happily moving TCP around. That isn't strictly an IPng issue, IPng could be designed with no thought of TCP, and IPng packets could happily be sent around with no defined payload at all, and if you believed in strict layering you'd probably insist on that. Practically it would be useless. The effect is that IPng proposals have to consider transport issues - and that includes the endpoint identifiers for transport connections - in particular TCP connections, as TCP is what the world is using, and will be using after IPng. This doesn't mean that EIDs have to be carried in IPng packet headers, requiring that would be requiring a solution, which is absolutely not what we want to do. Requiring EIDs as a concept though has many advantages, in addition to the disadvantages that you mention. First, its likely I believe that with EIDs there would no longer be a need for locator -> name mappings with all the problems they create, if identification was performed using EIDs, they would be the source of identifier->name mappings. That is, the only thing one would ever use a locator (address) for would be for forwarding packets toward their destination, they would ahve no other uses at all. That would allow extra flexibility in locator field internal boundaries, without the current (and likely continuing at least as bad, and probably worse) DNS textual conventions for locator (address) -> name mappings constraining the places at which boundaries may be conveniently be located. Read that as: with IPv4 its really not practical to delegate admin responsibility to any part of the address space other than at byte boundaries, because of the way the DNS in-addr.arpa delegations are done. That wastes address space. If we could avoid needing any locator->name mapping at all this constraint would vanish, making more effective use of the available bits, and allowing locators to be smaller than they'd otherwise need to be. EID's don't have this problem, as the only semantic meaning they carry is administrative delegation indications, which maps exactly into the DNS - using byte boundaries is no real problem, all 256 values in each byte can be fully used regardless of any other relationships between the systems to which the EIDs are assigned. I also feel its unfair to equate EID assignment with either address (locator) or name assignemnt in terms of its administrative difficulties. Certainly its extra work, but its not nearly as difficult as either of the others. Address assignment has all kinds of semantic rules, systems can't simply be assigned a random address with any real expectation that they will function correctly, that means that assigning addresses (locators) has to be done with care, and that means assigned by someone with knowledge of all of the relevant rules. On the other hand, EIDs are just random numbers, the only rule is that they be unique, that implies that sequential numbers within the assigned range work just fine. That is, the rule for assigning an EID is simply "Is my range full? If so, apply for a new one to my parent organisation. If not, assign the next available number in my range". Its a task that any dumb automaton can handle, and can realistically be automated. On the other hand, while names are easy to assign technically (just check uniqueness), assigning one entails lots of other work (mailer configuration, ...), they're also human visible, very visible, so cause all kinds of emotional and political arguments. EIDs have none of those problems. I said above that EIDs are "mostly" a transport issue. "Mostly" is because if they're going to be used for identification, then there's no reason to stop at transport identification, you're really going to want them everywhere. That includes in ICMP (equivalent) packets, etc, as well as in the more conventional transport. That can clearly be done by always including a TUNE style encapsulation immediately inside the IPng packet, and then putting the payload inside that, or it can be done by including the TUNE type header fields in the IPng header, the difference between those two is a semantic quibble, it simply doesn't matter. One could however make EIDs truly an IPng issue if one wanted by using EIDs at the final stage of packet delivery (as the identifier used in ES-IS or ARP, where hierarchy is no longer needed, just a unique number), in which case the locator "address" specifies a sub-net (area) only, and not a particular node on that subnet (in the area). That doesn't pervert the essence of EIDs at all, while allowing more compact locators, and simplified administration, in that the locator for a whole group of nodes could be supplied from a server for the node to pick up, and large numbers of names in the DNS could be grouped together in the DNS with only one locator needing to be supplied to apply to all, etc. The SIPP approach of "identifying addresses" and routing info is interesting, as long as one can continue using only the identifying address as the routing info, then it has the potential of saving a few header bytes. Once enough systems have moved around that more and more packets have to carry explicit routing info anyway, that advantage is lost, and instead all you have is the disadvantage of EIDs with too many semantics wasting bits. Personally I much prefer to simply admit now that the space is going to be used, and add explicit EIDs initially when they can be done properly, rather than designing a system where they will ooze in through the cracks later. kre From owner-Big-Internet@munnari.OZ.AU Wed May 11 06:26:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24649; Wed, 11 May 1994 06:26:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA15263; Wed, 11 May 1994 06:04:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA15238; Wed, 11 May 1994 05:34:24 +1000 Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21407; Wed, 11 May 1994 04:50:09 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA25368; Tue, 10 May 94 11:41:55 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA25410; Tue, 10 May 1994 14:43:51 -0400 Message-Id: <9405101843.AA25410@skidrow.lkg.dec.com> To: big-internet@munnari.OZ.AU, dns-security@tis.com, sipp@sunroof2.Eng.Sun.COM Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of "Tue, 10 May 94 13:22:07 EDT." <9405101723.AA21814@Sun.COM> Date: Tue, 10 May 94 14:43:51 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Steve, As I have said, the next version of the dnssec-secext draft will have provisions for algorithms versions. From: Steve Kent To: Noel Chiappa Cc: big-internet@munnari.oz.au, dns-security@tis.com, sipp@sunroof2.Eng.Sun.COM In-Reply-To: Your message of Mon, 25 Apr 94 16:00:11 -0400. <9404252000.AA28202@ginger.lcs.mit.edu> Sender: sipp-request@sunroof.Eng.Sun.COM >Noel, > > I thought of another motivation for requiring the dns-security >mechanisms algorithm independent. The DoD makes extensive use of >TCP/IP and it is a market into which many vendors probably want to be >able to continue to sell. However, the crypto algorithms used in >DoD networks are often different from those employed in the open >Internet. It behooves us to adopt security standards that are >algorithm independent whenever we would like the DoD to be able to use >the same protocols but with different crypto algorithms. In The DoD spectre has already been rasied by others. Personally, I really don't care whether the DoD can use the same protocols with different crypto algorithms. The success of the Internet is based on good engineering for the Internet environment, rather than trying for bureaucratic correctness. When Internet standards have followed such outside non-technical forces, such as the adoption of ASN.1 for SNMP, it has been regretted. A clear provision for at least rolling over to future algorithm sets in needed in dns-security because it is good engineering. And once you have an algorithm version field, its trivial to provide a systematic way for private algorithms to be identified. The details of the construction of SIG RRs and their use in authentiction are part of the algorithm set, not part of the protocol. >circumstances where the DoD enclaves are isolated from the open >Internet, there is no need for commonality of algorithm, but >commonality of protocol still allows for DoD use of COTS products. You can't use COTS products with different algorithms unless you add your (for the DoD probably classified secret) algorithms. If you consider proper algorithms to be (1) taking one piece of data and a key and calculating a SIG for it and (2) taking one piece of data, a key, and a SIG and saying if that SIG authenticates the data, then the current protocol is algorithm dependent. However, if you consider an algorithm to be (1) taking a set of data elements and a key and calculating one or more SIGs and (2) taking one or more data elements, a key, and one or more SIGs and saying if those SIG(s) authentic that data, then the current protocol is totally algorithm independent. (Yes, there are some simplicifcations in my descriptions of both points of view, for brevity, such as only considering the minimally compliant server, but I could construct a parallel set of complete descriptions which would demonstrate the same point.) >Steve Donald From owner-Big-Internet@munnari.OZ.AU Wed May 11 12:46:56 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00816; Wed, 11 May 1994 09:34:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA28319 Wed, 11 May 1994 08:49:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA15402; Wed, 11 May 1994 08:24:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA15399; Wed, 11 May 1994 08:12:48 +1000 Received: from LABS-N.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25091; Wed, 11 May 1994 06:39:08 +1000 (from kent@BBN.COM) Message-Id: <9405102039.25091@munnari.oz.au> To: "Donald E. Eastlake 3rd (Beast)" Cc: big-internet@munnari.OZ.AU, dns-security@tis.com, sipp@sunroof2.eng.sun.com Subject: Re: SIPP Routing Header & security & Re: DNS security draft In-Reply-To: Your message of Tue, 10 May 94 14:43:51 -0400. <9405101843.AA25410@skidrow.lkg.dec.com> Date: Tue, 10 May 94 16:34:10 -0400 From: Steve Kent Donald, I'm glad to hear that the next version of the proposal will carry algortihm identifiers, and I hope it will be algorithm independent too. In the case of signatures, algorithm independence would require that we not rely on the reversability of RSA signatures, i.e., the ability to revover the signed data from the signature value. A generic signature validation mechanism begins by (locally) computing the hash on the (purportedly) signed data. That input, the public key and any algorithm parameters of the signer, plus the signature value itself is input to a signature verification routine. The routine then outputs true or false, i.e., the signature is valid or invalid. Steve From owner-Big-Internet@munnari.OZ.AU Wed May 11 17:43:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11043; Wed, 11 May 1994 14:37:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA15698; Wed, 11 May 1994 14:14:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA15684; Wed, 11 May 1994 14:06:54 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10702; Wed, 11 May 1994 14:28:37 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA16766; Tue, 10 May 94 22:33:54 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB22398; Tue, 10 May 94 21:26:39 PDT Date: Tue, 10 May 94 21:26:39 PDT Message-Id: <9405110426.AB22398@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN), big-internet@munnari.OZ.AU (bigi) From: Greg Minshall Subject: Re: IP Technical Criteria Brian, >> Could you explain a bit more? Why aren't NSAPAs prone to the same problem? [as SIPP addresses] >They change when you change provider, but ES-IS should handle it >automatically. I think SIPP can do that? (a statement in the form of a question) Greg From owner-Big-Internet@munnari.OZ.AU Thu May 12 02:05:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00354; Wed, 11 May 1994 23:57:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA16141; Wed, 11 May 1994 23:34:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA16138; Wed, 11 May 1994 23:29:39 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29973; Wed, 11 May 1994 23:51:12 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA28255; Wed, 11 May 94 09:51:04 -0400 Date: Wed, 11 May 94 09:51:04 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: <9405111351.AA28255@rodan.UU.NET> To: big-internet@munnari.OZ.AU Subject: Requirements lists.... Cc: mo@uunet.uu.net one eternal risk for requirements compilers is that the list, unless restrained by designers with exceptional taste and a strong sense of the physically realizable, will eventually approximate the Sears Christmas Catalog: the requirements doc becomes a huge compendium of everything cool anyone can think of wishing for. in the usual process, the "customer" throws in everything imaginable because they know they won't get the whole list, but they do hope that the unpredictable subset they do get will be at least rational and might even solve the original problem. (This happy ending seldom happens in government systems procurements, but is not totally unheard of.) please note that i'm not indicting any particular document or process, but merely pointing out the most common failure mode which arrises in this type of activity. -Mike O'Dell Resident Crank From owner-Big-Internet@munnari.OZ.AU Thu May 12 03:26:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08304; Thu, 12 May 1994 03:26:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA16394; Thu, 12 May 1994 03:04:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA16366; Thu, 12 May 1994 02:39:26 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07214; Thu, 12 May 1994 03:00:50 +1000 (from craig@aland.bbn.com) Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA14079 for big-internet@munnari.oz.au; Wed, 11 May 94 13:00:42 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA03301; Wed, 11 May 1994 09:58:51 -0700 Message-Id: <199405111658.JAA03301@aland.bbn.com> To: "Mike O'Dell" Cc: big-internet@munnari.OZ.AU Subject: Re: Requirements lists.... In-Reply-To: Your message of Wed, 11 May 94 09:51:04 -0400. <9405111351.AA28255@rodan.UU.NET> From: Craig Partridge Date: Wed, 11 May 94 09:58:50 -0700 Sender: craig@aland.bbn.com one eternal risk for requirements compilers is that the list, unless restrained by designers with exceptional taste and a strong sense of the physically realizable, will eventually approximate the Sears Christmas Catalog: the requirements doc becomes a huge compendium of everything cool anyone can think of wishing for. Mike: If you've noticed that Frank or I occasionally sounds grumpy in our e-mail, this is why. Saying "no" to suggestions from bright hardworking volunteers on a regular basis as one tries to keep the requirements document from becoming either (1) a laundry list or (2) too specific (i.e., use EIDS in this way, vs. must have some unique identifier mechanism) tends to make one feel grouchy. Craig From owner-Big-Internet@munnari.OZ.AU Thu May 12 04:33:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06961; Thu, 12 May 1994 02:52:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA16350; Thu, 12 May 1994 02:29:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA16325; Thu, 12 May 1994 02:08:47 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28632; Wed, 11 May 1994 23:18:17 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 11 May 1994 09:18:08 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 11 May 1994 09:18:08 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA21798; Wed, 11 May 94 09:16:47 EDT Date: Wed, 11 May 94 09:16:47 EDT Message-Id: <9405111316.AA21798@mailserv-D.ftp.com> To: dcrocker@mordor.stanford.edu Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: deering@parc.xerox.com, big-internet@munnari.OZ.AU, sob@hsdndev.harvard.edu, mankin@cmf.nrl.navy.mil, jnc@ginger.lcs.mit.edu Content-Length: 2509 Dave, First of all, the mailing list where discussion of the IPng requirements document is supposed to take place is the big-internet list. I've taken the privilege of moving this discussion there. > We are continuing to be in danger of placing requirements on IPng that > pertain more to our long-term fantasies and less to requirements that are > real and understood. The requirements document is meant to be an instrument by which the internet layer is moved forward from the 1970s into the 21'st century. It reflects where Craig and I believe the Internet should be moving. If all we want was more address space, then I'd work for 20 minutes and reformat RFC791, etal to have more address bytes. What we are attempting to do is to set a goal, a direction, which the various IPng developers should be using to direct their own development. These requirements also set a framework within which the proposals can be evaluated. I honestly do not expect that every proposal will meet all of the criteria in the manner I'd like them to. Some will emphasize one criterion over others. By having a framework such as this, the IPng directorate, in their review, and Scott and Allison, in their recommendation, can discuss the proposals with respect to the criteria, things like "foo does criterion #1 real good" and "bar completely ignores criteria #2 and 3". Of course, you are certainly free to ignore the requirements document and do whatever you wish. > Mobility is an example of something that appears not to be. Perhaps by coming right out and stating that mobility is important, it will provide a certain incentive for the mobility people to work harder and deal with the problems. > An absolutely classic occurrence in projects is to start changing the > requirements late in the game. It is also one of the classic ways to fail. Absolutely. But on the other hand, when the IETF decided that an IPng was desired, we first had a whole bunch of people go off and develop packet headers. Only later did some people decide that we should have a 'requirements' document. Developing the answer(s) (such as PIP and TUBA and SIP and IPAE and...) before you start asking the right questions is also a classic way of failing. Should we take the current proposals, discard them because they all started before the requirements were developed, finalize the requirements, and then start doing development? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu May 12 04:33:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08379; Thu, 12 May 1994 03:28:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA16412; Thu, 12 May 1994 03:06:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA16391; Thu, 12 May 1994 03:04:03 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03567; Thu, 12 May 1994 01:18:12 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-07.dialip.mich.net (pm002-07.dialip.mich.net [35.1.48.88]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA11895 for ; Wed, 11 May 1994 11:17:46 -0400 Date: Wed, 11 May 94 14:23:52 GMT From: "William Allen Simpson" Message-Id: <2358.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: More requirements > From: kasten@ftp.com (Frank Kastenholz) > First of all, the mailing list where discussion of the IPng > requirements document is supposed to take place is the big-internet > list. I've taken the privilege of moving this discussion there. > Thanks. But renaming the subject when that happens would be good. It isn't about SIPP EIDs anymore. > > We are continuing to be in danger of placing requirements on IPng that > > pertain more to our long-term fantasies and less to requirements that are > > real and understood. > > The requirements document is meant to be an instrument by which the > internet layer is moved forward from the 1970s into the 21'st > century. It reflects where Craig and I believe the Internet should be > moving. > And it is an excellent document! It's great to have all the filtered requirements in one place, without the religion. > > Mobility is an example of something that appears not to be. > > Perhaps by coming right out and stating that mobility is important, > it will provide a certain incentive for the mobility people to work > harder and deal with the problems. > Mobility is _very_ important. Our (IETF) failure to finalize IP mobility has been a real sore point, and lead to many incompatible methods in use today. We really need to lead here! I'm trying to keep that process moving as best I can. Security is another problem area. That we can't seem to agree on it, doesn't make it unimportant. > > An absolutely classic occurrence in projects is to start changing the > > requirements late in the game. It is also one of the classic ways to fail. > > Absolutely. But on the other hand, when the IETF decided that an IPng > was desired, we first had a whole bunch of people go off and develop > packet headers. Only later did some people decide that we should have > a 'requirements' document. Developing the answer(s) (such as PIP and > TUBA and SIP and IPAE and...) before you start asking the right > questions is also a classic way of failing. Should we take the > current proposals, discard them because they all started before the > requirements were developed, finalize the requirements, and then > start doing development? > Actually, I like the fact that we had a bunch of folks go off and write up different proposals. It gave me a stonger picture of what people really wanted. The subsequent merging was a wonderful example of positive interaction. Having those pictures is what lead to knowing the requirements, not the other way around. But now that we have the requirements, the WGs should be making adjustments to meet the agreed requirements. If the requirements change, they can't. It harder to hit a moving target. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu May 12 04:34:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09323; Thu, 12 May 1994 04:02:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA16468; Thu, 12 May 1994 03:39:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA16402; Thu, 12 May 1994 03:05:28 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01863; Thu, 12 May 1994 00:36:45 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id HAA11937; Wed, 11 May 1994 07:36:31 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 May 1994 07:36:37 -0700 To: kasten@ftp.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators Cc: deering@parc.xerox.com, big-internet@munnari.OZ.AU, sob@hsdndev.harvard.edu, mankin@cmf.nrl.navy.mil, jnc@ginger.lcs.mit.edu Frank, At 6:16 AM, Frank Kastenholz wrote: >First of all, the mailing list where discussion of the IPng >requirements document is supposed to take place is the big-internet >list. I've taken the privilege of moving this discussion there. That's fine, but the big-internet list might want a tad more background, since the trigger to this thread was not my own note, but rather a note that asserted consensus on the requirement for separating EIDs from 'address' bits. My own note was in reaction to making this a technical requirement at this late date. (It's been discussed, but not specified in any detail. Although having said that, I should also note Paul F's observation that the PIP enhancements to SIPP do support EIDs.) >The requirements document is meant to be an instrument by which the >internet layer is moved forward from the 1970s into the 21'st Let's see. First, I'm in favor of the document. Have been all along. So the debate is about constraints on the doc. I assume that there is general agreement that the document should pertain to feasible reality. The question, then, is about feasibility. >we are attempting to do is to set a goal, a direction, which the >various IPng developers should be using to direct their own >development. The word "requirements" is much stronger than "goal" or "direction". I also believe that as a group we don't really have a clue how to look as far forward as a word like "direction" implies. That is, we don't know how to take such long-term vision and apply it to current technical work. We know how to solve current technical problems and we know how to leave some room for problems whose solutions are readily in sight. A very basic requirement for a requirements document like this is to distinguish between immediate, critical requirements, near-term, critical requirements, and everything else. The first is address space and transition; I doubt anything else is there (other than the generic 'no worse than IPv4'.) The second is, for example, delivery guarantees. I believe it does NOT include mobility, for example. One reason is that we don't really have the infrastructure that requires it and the other is that we don't really have a solution in sight. Everyone agrees it is an important problem. But the continuing presence of large numbers of proposals and little trend towards pruning and focusing suggests that this really isn't something the community yet has a solid feel for. It's tough to require a solution in that case. The third category of 'requirements' is for all of the spiffy stuff that we'd like to see but really don't have immediate need for or understanding of. This category is the one that keeps getting us into trouble. We keep getting caught up in idealism and ignore the practical aspects, such as our not really knowing how to solve a given problem. Making something a requirement doesn't get it solved. We are less than two months away from the IPng recommendation. It would be helpful if we viewed the requirements list in that light. > By having a framework such as >this, the IPng directorate, in their review, and Scott and Allison, >in their recommendation, can discuss the proposals with respect to This only works if the criteria, themselves, are partitioned into priorities. > > Mobility is an example of something that appears not to be. > >Perhaps by coming right out and stating that mobility is important, Frank, I think your statement is quite reflective of a popular view. It is also what is getting us into trouble. The mobility work has been going on for something like two years. The participants are all motivated; they want an answer. Having a line in a requirement document does not suddenly make people find a solution to a problem. Rather than being viewed as a forcing function on developers, the requirements doc needs to reflect a pragmatic understanding of what is attainable, e.g., by taking note of development history. The fact about mobility is that we do not yet undertstand the problem well enough to design and choose a solution. We all want a solution, but that simply is not enough. > Only later did some people decide that we should have >a 'requirements' document. Developing the answer(s) (such as PIP and >TUBA and SIP and IPAE and...) before you start asking the right >questions is also a classic way of failing. Frank, please understand if I take some exception to your characterization. We did not have a single, public requirements list; that is true. I wish we had had one. But the various efforts didn't simply go off and play with packet formats. Each group pursued their own list of requirements. IPAE started with transition, for example. Should we take the >current proposals, discard them because they all started before the >requirements were developed, finalize the requirements, and then >start doing development? Since you end with this question, I'll assume that you are serious. That's unfortunate. I believe it accurately reflects some folks' sentiments and I submit that it is exactly the wrong question. This was discussed at the IPng BOF in Seattle and the fairly strong sentiment was that the recommendation in Toronto needs to choose one of the current candidates. Hence, your question is out of scope. We get a choice. The requirements list can attend to the task of evaluating and distinguishing the current candidates or it can delve into fantasies for longer-term pursuit. It is unlikely that the doc can satisfy both agendas. If the doc pursues the former, it will be highly useful. If it pursues the latter, it won't have much to do with IPng. We are already having problems in handing out addresses. We need IPng now. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Thu May 12 05:11:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11818; Thu, 12 May 1994 05:11:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA16571; Thu, 12 May 1994 04:49:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA16568; Thu, 12 May 1994 04:46:35 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11751; Thu, 12 May 1994 05:08:18 +1000 (from craig@aland.bbn.com) Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA12772 for big-internet@munnari.oz.au; Wed, 11 May 94 15:07:47 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id MAA03504; Wed, 11 May 1994 12:05:56 -0700 Message-Id: <199405111905.MAA03504@aland.bbn.com> To: Dave Crocker Cc: kasten@ftp.com, deering@parc.xerox.com, big-internet@munnari.OZ.AU, sob@hsdndev.harvard.edu, mankin@cmf.nrl.navy.mil, jnc@ginger.lcs.mit.edu Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators In-Reply-To: Your message of Wed, 11 May 94 07:36:37 -0700. From: Craig Partridge Date: Wed, 11 May 94 12:05:55 -0700 Sender: craig@aland.bbn.com Dave: I think we need to be very clear about what the requirements document in its current form is trying to do (versus what was originally attempted). Frank and I originally attempted to write a prioritized list of criteria. The joy of this approach was that you could take a proposal and map its success against the criteria and figure out how well it matched our needs in a prioritized way. (I.e., I could say proposal A met criteria 1 thru 8, and then 12 and 14, and could say proposal B met criteria 1 thru 8 and 10 and 11, and have sense that, by the communities standards, proposal B was better). This was in the spirit of Dave Clark's SIGCOMM '88 paper that said one of the ideas behind IP was an informal prioritized list of requirements. The major problem with the prioritized list is that the IP community is now so big and diffuse that prioritization just didn't work. Different folks viewed different requirements as more or less important and we had no mechanism for making priority judgements other than, say, appointing an Internet Architect to make all the hard decisions. So we threw up our hands and stopped the effort. Then the IPng Area Directorate was formed and asked us to have another stab at the problem. The result is a somewhat different document. First, we no longer prioritize. Second, and partly as a result, the document's goal is different. It is intended as a list of the things an IPng proposal must address (so to speak) to be considered a candidate for IPng. Even at this point, some of the decisions are hard. For instance, take mobility. Clearly IPng will be expected to support mobility. At the same time, while the mobility proposals are stabilizing, they are not fully settled. So we tried to write the requirements document to make clear that an IPng proposal has to have at least thought about how it might support mobility -- in the expectation that if the designers have thought about the problem, they are less likely to make fundamental errors that preclude supporting mobility. Sounds wishy-washy, and maybe it is. Yet to not to mention the need to support mobility for a protocol intended to serve us for 15 years would be inexcusable. Craig From owner-Big-Internet@munnari.OZ.AU Thu May 12 07:25:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12053; Thu, 12 May 1994 05:14:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA16586; Thu, 12 May 1994 04:52:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA16525; Thu, 12 May 1994 04:18:55 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10830; Thu, 12 May 1994 04:40:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08073; Wed, 11 May 94 14:40:26 -0400 Date: Wed, 11 May 94 14:40:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405111840.AA08073@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) the trigger to this thread was not my own note, but rather a note that asserted consensus on the requirement for separating EIDs from 'address' bits. Err, pardon me. I assume you're referring to my note, which said: > I imagine it wouldn't be trivial to get this consensus, but I didn't hear > a big uproar in reply to your message, so maybe it's possible. This is not "assert[ing] consensus". A very basic requirement for a requirements document like this is to distinguish between immediate, critical requirements, near-term, critical requirements, and everything else. The first is address space and transition; I doubt anything else is there The differentiation between these classes is so subjective as to be almost impossible. For instance, it is rational to take the position that more address space is, in fact, a less pressing need than better security, or auto-configuration. We'll just spend all our time arguing as to which class a given requirement belongs in, and not without reason, as different groups will see different problems as more pressing to them. The third category of 'requirements' is for all of the spiffy stuff that we'd like to see but really don't have immediate need for or understanding of. ... We keep getting caught up in idealism and ignore the practical aspects, such as our not really knowing how to solve a given problem. Again, your "no immediate need" is someone else's "our business needs this". However, I agree with you that some things we don't have as much practical experience with as we should, to make final decisions. > Should we take the current proposals, discard them because they all > started before the requirements were developed, finalize the > requirements, and then start doing development? I believe it accurately reflects some folks' sentiments and I submit that it is exactly the wrong question. This was discussed at the IPng BOF in Seattle and the fairly strong sentiment was that the recommendation in Toronto needs to choose one of the current candidates. There was a strong push from some people to take that position, but I don't think it reached the level of a rough consensus. I know of many people who don't think that any of the current candidates is acceptable. Anyway, Frank's rhetorical position ("discard all the existing proposals") is not one that anyone I know takes, so let's not discuss rhetorical straw-men. The requirements list can attend to the task of evaluating and distinguishing the current candidates or it can delve into fantasies for longer-term pursuit. I see. So anything that is not a choice among the existing candidates is a "fantasy"? Pretty loaded terminology. When did you stop beating your wife, Dave? Labelling anything outside the current candidates "fantasy" may make for appealing rhetoric, but is hardly helpful. We are already having problems in handing out addresses. We need IPng now. Can you provide more details on this? I've heard two examples quoted, but neither one panned out when I checked into them. We are less than two months away from the IPng recommendation. It would be helpful if we viewed the requirements list in that light. Yup. And one of the allowed responses is "none of the above". If you want to take the position that that's not a plausible response, then why on earth are we bothering with a requirements document anyway? Either it means something, and we ought to pay attention to it (which means saying "none of the above", if that's the correct answer), or let's forget it. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 12 07:25:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13263; Thu, 12 May 1994 05:46:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA16627; Thu, 12 May 1994 05:24:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA16613; Thu, 12 May 1994 05:04:21 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09058; Thu, 12 May 1994 03:54:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07474; Wed, 11 May 94 13:54:20 -0400 Date: Wed, 11 May 94 13:54:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405111754.AA07474@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: More requirements Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" > when the IETF decided that an IPng was desired, we first had a whole > bunch of people go off and develop packet headers. Only later did some > people decide that we should have a 'requirements' document. Developing > the answer(s) ... before you start asking the right questions is also a > classic way of failing. I like the fact that we had a bunch of folks go off and write up different proposals. ... The subsequent merging was a wonderful example of positive interaction. Unfortunately, having a variety of proposals hacked together, without a good vision of what the Internet ought to look like 20 years down the road, has resulted in a lot of time being wasted in politics, trying to decide between several different proposals, none of which is, I think, really any good. Having those pictures is what lead to knowing the requirements, not the other way around. Not so. The requirement document shows no signs of any content that wouldn't have come about in a more general (and less politicized) discussion, and numerous similar previous requirments documents (e.g. RFC-1126) had the same characteristic. But now that we have the requirements, the WGs should be making adjustments to meet the agreed requirements. If the requirements change, they can't. It harder to hit a moving target. True, it's more difficult, but if we discover at a late stage that we have a real requirement for X, leaving X out on the grounds that we need to freeze things is not going to help in the long run either. I'm aware that this can lead to never-ending motion, but this isn't your typical product ship either. If we can make CIDR work, we've got enough time for a careful and evolutionary approach to modifying IPv4, and if we can't make CIDR work, no IPng scheme I know of is going to work anyway. So, if we have a real need for X, let's take our time, understand it, and add it. Trying to throw in whatever you think you might need support X, without really knowing how you're going to do it, has a high probability of being a waste of time; you need only look at the existing IPv4 TOS field to see how far that gets you. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 12 07:27:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14361; Thu, 12 May 1994 06:21:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA16679; Thu, 12 May 1994 05:59:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA16646; Thu, 12 May 1994 05:25:22 +1000 Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09415; Thu, 12 May 1994 04:05:02 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 11 May 1994 14:04:58 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 11 May 1994 14:04:58 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA26262; Wed, 11 May 94 14:03:40 EDT Date: Wed, 11 May 94 14:03:40 EDT Message-Id: <9405111803.AA26262@mailserv-D.ftp.com> To: dcrocker@mordor.stanford.edu Subject: Requirements (was : FORMAL REQUEST : SIPP EIDs and Locators) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 5041 > >The requirements document is meant to be an instrument by which the > >internet layer is moved forward from the 1970s into the 21'st > > Let's see. First, I'm in favor of the document. Have been all along. So > the debate is about constraints on the doc. I assume that there is general > agreement that the document should pertain to feasible reality. The > question, then, is about feasibility. No. The document pertains to what our collective crystal balls tell us the Internet should be in 10-20 years and how to get there. It's hard. I would also mention that by 'our', I mean primarily Craig's and mine, but with a HUGE amount of outside 'kibitzing' in the sense of two BOFs at IETF meetings, separated by about 18 months, well over a dozen white papers from the IPng process, megabytes of big-i email, private discussions with people, and so on. > >we are attempting to do is to set a goal, a direction, which the > >various IPng developers should be using to direct their own > >development. > > The word "requirements" is much stronger than "goal" or "direction". I > also believe that as a group we don't really have a clue how to look as far > forward as a word like "direction" implies. That is, we don't know how to > take such long-term vision and apply it to current technical work. We know > how to solve current technical problems and we know how to leave some room > for problems whose solutions are readily in sight. Here I have a real problem. If the Internet is successful then this will be the last 'easy' change of a protocol as central as IP. We absolutely have to be thinking 10+ years ahead in order to make sure that what we field over the next 2-3 years is at least suitable as a base for what our crystal balls say. Suppose that SITUNIP is chosen as the IPng, but it is network-resource-allocation hostile. Even if we are not 100% sure about doing network resource allocation, did we do the right thing by chosing SITUNIP? We believe that for the Internet to be successful over the next 20 years, something like network resource reservations will be needed. Even if we don't know everything there is to know about this field, we can certainly take what we do know and evaluate proposals based on that knowledge. Most all of the things that we've discussed in the document are things for which some research is happening now - so even if we can not field a production level frotz, we should have some idea of what it takes to make a frotz and how a frotz might work. > > By having a framework such as > >this, the IPng directorate, in their review, and Scott and Allison, > >in their recommendation, can discuss the proposals with respect to > > This only works if the criteria, themselves, are partitioned into priorities. Feel free to assign your own priorities in the development of your proposal. I would point out, though, that an early draft attempted to order things in terms of priorities (with a MUST/SHOULD) split. The community reacted very negatively to this. Partisans of the Foo proposal said that item X should be more important than item Y, while members of the Bar team said that Y was more important than X. Of course, Foo emphasized X over Y, whilst Bar emphasized Y over X. > > Only later did some people decide that we should have > >a 'requirements' document. Developing the answer(s) (such as PIP and > >TUBA and SIP and IPAE and...) before you start asking the right > >questions is also a classic way of failing. > > Frank, please understand if I take some exception to your characterization. > We did not have a single, public requirements list; that is true. I wish > we had had one. But the various efforts didn't simply go off and play with > packet formats. Each group pursued their own list of requirements. IPAE > started with transition, for example. It would be interesting to know what these "internally generated" requirements for SIPP, CATNIP and TUBA are. It might help the IPng directorate, and the community at large, to evaluate the various proposals and see where they are trying to take us. > Should we take the > >current proposals, discard them because they all started before the > >requirements were developed, finalize the requirements, and then > >start doing development? > > Since you end with this question, I'll assume that you are serious. That's > unfortunate. I believe it accurately reflects some folks' sentiments and I > submit that it is exactly the wrong question. This was discussed at the > IPng BOF in Seattle and the fairly strong sentiment was that the > recommendation in Toronto needs to choose one of the current candidates. > Hence, your question is out of scope. You were pointing out a well known method for engineering projects to fail. I pointed out another. If we try to avoid project-failure techniques, avoiding one technique is as valid as avoiding the other. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu May 12 09:44:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17056; Thu, 12 May 1994 07:32:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA16755; Thu, 12 May 1994 07:09:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA16752; Thu, 12 May 1994 07:05:33 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16890; Thu, 12 May 1994 07:27:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09951; Wed, 11 May 94 17:27:05 -0400 Date: Wed, 11 May 94 17:27:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405112127.AA09951@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: More requirements Cc: jncjnc@ginger.lcs.mit.edu > If we can make CIDR work... Folks who are interested in this may look at the data collected by Erik-Jan Bos from SURFNet. For those of us who are too busy to go look, could you possibly summarize the important results? Noel From owner-Big-Internet@munnari.OZ.AU Thu May 12 09:47:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17450; Thu, 12 May 1994 07:41:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA16781; Thu, 12 May 1994 07:18:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA16729; Thu, 12 May 1994 06:42:48 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16188; Thu, 12 May 1994 07:04:32 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA13492; Wed, 11 May 94 15:09:52 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB24401; Wed, 11 May 94 14:02:37 PDT Date: Wed, 11 May 94 14:02:37 PDT Message-Id: <9405112102.AB24401@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Craig Partridge From: Greg Minshall Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators Cc: big-internet@munnari.OZ.AU Craig, >is now so big and diffuse that prioritization just didn't work. Different >folks viewed different requirements as more or less important and we had >no mechanism for making priority judgements other than, say, appointing >an Internet Architect to make all the hard decisions. I tend to think we need an IPng architecture and an IPng architect. Greg From owner-Big-Internet@munnari.OZ.AU Thu May 12 09:47:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17529; Thu, 12 May 1994 07:43:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA16797; Thu, 12 May 1994 07:20:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA16746; Thu, 12 May 1994 07:02:28 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14150; Thu, 12 May 1994 06:16:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09166; Wed, 11 May 94 16:16:16 -0400 Date: Wed, 11 May 94 16:16:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405112016.AA09166@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: IP Technical Criteria Cc: jnc@ginger.lcs.mit.edu I think the concept of separation of identification and location (routing) is a lot like protocol layering. It provides a good model to "think" about the issues. This, also like layering, does not mean that the information used to specify identification and location needs to be in separate bits in the packet. Nonetheless, each layer of protocol does tend to keep its bits in separate places within the packet, even if some implementations (e.g. VJ compression) look at both. If you want to get abstract, you can say that if something provides a good model for thinking about something, that model is probably good for practical things too. Separation of protocols into layers has proven useful in practise, not just in theory; if TCP-1 hadn't been split into IP and TCP layers, NFS couldn't run over UDP... Noel From owner-Big-Internet@munnari.OZ.AU Thu May 12 10:08:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17669; Thu, 12 May 1994 07:46:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA16812; Thu, 12 May 1994 07:23:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA16732; Thu, 12 May 1994 06:44:37 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16231; Thu, 12 May 1994 07:06:16 +1000 (from craig@aland.bbn.com) Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA05783 for big-internet@munnari.oz.au; Wed, 11 May 94 17:05:50 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id OAA03641; Wed, 11 May 1994 14:03:49 -0700 Message-Id: <199405112103.OAA03641@aland.bbn.com> To: Dave Crocker Cc: Craig Partridge , big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators In-Reply-To: Your message of Wed, 11 May 94 13:33:08 -0700. <199405112033.NAA14121@Mordor.Stanford.EDU> From: Craig Partridge Date: Wed, 11 May 94 14:03:48 -0700 Sender: craig@aland.bbn.com For the record, I haven't been criticizing you or Frank. I HAVE been criticizing our effort as a community. We have failed to resolve to pursue this task in a matter that allows producing a usable spec, in this case a spec of requirements. What we are then going to give the IPng directorate, is a document with little applicability in a testing process. Dave: I understand the gist of your concerns. What I'm trying to say is that I don't think it is this simple. In a corporate world, we can develop specifications (a road map of where we want to be) and then if we find we goofed, there's usually a nice procedure for going back and saying "take this off the spec." This very public, open, concensus based system doesn't have such easy error correction mechanisms. So we have seem to have walked into another procedure of the form: * first, figure out roughly what the right shape of the solution is [i.e., eliminate chaff] * second, do a detailed review of the proposals that have roughly the right shape [do a detailed analysis] * third, make the decision The current requirements document is designed to do step (1). Finishing this step gets us away from situations in which folks post proposals as a short e-mail message and suggest we consider it as seriously as a proposal with tens or hundreds of pages of detail (plus working code) available. It also reduces the field to candidates we can live with (more or less comfortably). Step (2) is where we can talk about the sorts of requirements that we might put into corporate specs (like, IPng forwarding should take no more than 35 instructions on a PowerPC and 27 instructions on an Alpha). Or, if the candidate pool is small enough, we can simply do point by point comparisons. Now, if one wants to criticize the process, I agree that it looks rather bad that we're down to about 75 days to the decision, and we're still finishing up stage 1. (I'll take a little blame for that -- I'm currently the squeaky wheel on the requirements document). But that's life in a volunteer organization. Craig From owner-Big-Internet@munnari.OZ.AU Thu May 12 10:08:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17735; Thu, 12 May 1994 07:49:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA16855; Thu, 12 May 1994 07:26:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA16749; Thu, 12 May 1994 07:03:59 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13339; Thu, 12 May 1994 05:50:38 +1000 (from kre@munnari.OZ.AU) To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Cc: big-internet@munnari.OZ.AU, sob@hsdndev.harvard.edu, mankin@cmf.nrl.navy.mil Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators In-Reply-To: Your message of "Wed, 11 May 1994 07:36:37 MST." Date: Thu, 12 May 1994 05:50:37 +1000 Message-Id: <17631.768685837@munnari.OZ.AU> From: Robert Elz Date: Wed, 11 May 1994 07:36:37 -0700 From: dcrocker@mordor.stanford.edu (Dave Crocker) Message-ID: > > Mobility is an example of something that appears not to be. > >Perhaps by coming right out and stating that mobility is important, Frank, I think your statement is quite reflective of a popular view. It is also what is getting us into trouble. The mobility work has been going on for something like two years. The participants are all motivated; they want an answer. Having a line in a requirement document does not suddenly make people find a solution to a problem. We need to look at this requirement in context. Its certainly true that making mobility work is hard, there are a lot of problems, and some of them don't currently seem to have any good solutions. But we're only talking of IPng here, that is the network layer, no-one is asking the IPng candidates to 'solve the mobility problem'. In a perfect world, IP would be unrelated to mobility. After all, IP simply takes a packet, and delivers it to the destination, independant of other packets that may have been transmitted between the peer endpoints. The very concept of "mobility" in this ideal model is meaningless. Questions that mobility raises - how does a host tell its peer it has moved, how does the peer verify such a message once it receives it, how is the directory (DNS) to be updated quickly enough to handle lots of hosts swimming around the oceans, etc, are all irrelevant to IP (and to IPng). There is really just one issue in IP that complicates mobility - that is the incestuous relationship between IP level packet destination and routing information, and transport level connection identifiers. That makes it difficult to send a packet to a new location, yet retain existing connections. This is something that IPng both can and should address. Second, IPng candidates may be considering "flows", and support for them in some form or other. In doing so, they should address the issue of one (or both) of the end points of the flow moving around the net - in order to make sure that their flow proposals don't make flows incompatible with mobility. These requirements don't seem onerous to me (the whole question of flow support may be, it certainly seems much more difficult than any other IPng mobility support could be). kre From owner-Big-Internet@munnari.OZ.AU Thu May 12 10:42:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20715; Thu, 12 May 1994 09:18:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA16968; Thu, 12 May 1994 08:54:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA16942; Thu, 12 May 1994 08:22:39 +1000 From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16729; Thu, 12 May 1994 07:24:15 +1000 (from yakov@watson.ibm.com) Message-Id: <9405112124.16729@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0477; Wed, 11 May 94 17:24:09 EDT Date: Wed, 11 May 94 17:18:15 EDT To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU Subject: More requirements Ref: Your note of Wed, 11 May 94 13:54:20 -0400 Noel, >If we can make CIDR work... Folks who are interested in this may look at the data collected by Erik-Jan Bos from SURFNet. The data is available via anonymous ftp from ftp.nic.surfnet.nl under surfnet/net-management/ip/nets.[ps, gif]. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu May 12 11:25:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18478; Thu, 12 May 1994 08:08:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA16888; Thu, 12 May 1994 07:44:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA16871; Thu, 12 May 1994 07:39:20 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14769; Thu, 12 May 1994 06:33:58 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id NAA14121; Wed, 11 May 1994 13:33:08 -0700 Message-Id: <199405112033.NAA14121@Mordor.Stanford.EDU> To: Craig Partridge Cc: big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 11 May 94 12:05:55 -0700. <199405111905.MAA03504@aland.bbn.com> Date: Wed, 11 May 94 13:33:08 -0700 From: Dave Crocker X-Mts: smtp Craig, ---- Included message: The major problem with the prioritized list is that the IP community is now so big and diffuse that prioritization just didn't work. Different While I certainly agree with your assessment of the strong reactions that occurred, I have to disagree with your conclusion that convergence is impossible. My own guess is that we really didn't try very heard -- as a community. Why should this task be any different from forumulating a spec for multi-media mail or the next version of snmp? We ALWAYS have diverse input and we OFTEN have much heat and fury. This time, we simply gave up trying to do the essential part of the task. Creating lists is easy. Ranking them is not. It is intended as a list of the things an IPng proposal must address (so to speak) to be considered a candidate for IPng. "must address". hmmm. I guess I make a big distinction between requirements that pertain to real and usable functionality, versus the rest of the stuff that can't be fully specified. What is the test for satisfying a "must address" requirement? So we tried to write the requirements document to make clear that an IPng proposal has to have at least thought about how it might support mobility -- in the expectation that if the designers have thought I think it is good and reasonable to list such a thing. But I think it is vastly less useful than a requirement pertaining to something that CAN be fully spec'd now. Making this distinction is what caused me to send my original note. EIDs pertain to various, general goals and little specific detail. As such, they represent a popular tendency to confuse agendas. about the problem, they are less likely to make fundamental errors that preclude supporting mobility. Sounds wishy-washy, and maybe it is. Yet to not to mention the need to support mobility for a protocol intended to serve us for 15 years would be inexcusable. The problem is that I agree with you. The problem is that there is no way to test satisfaction of the requirement. We can test the size of an address space, the steps of a transition plan, and the efficiency required to process a header. But how to we test whether the 'mobility' requirement has been satisfied? Dave P.S. For the record, I haven't been criticizing you or Frank. I HAVE been criticizing our effort as a community. We have failed to resolve to pursue this task in a matter that allows producing a usable spec, in this case a spec of requirements. What we are then going to give the IPng directorate, is a document with little applicability in a testing process. From owner-Big-Internet@munnari.OZ.AU Thu May 12 11:31:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18642; Thu, 12 May 1994 08:12:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA16903; Thu, 12 May 1994 07:49:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA16874; Thu, 12 May 1994 07:39:32 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14047; Thu, 12 May 1994 06:12:40 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id NAA13979; Wed, 11 May 1994 13:12:35 -0700 Message-Id: <199405112012.NAA13979@Mordor.Stanford.EDU> To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Subject: Re: Requirements (was : FORMAL REQUEST : SIPP EIDs and Locators) Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 11 May 94 14:03:40 -0400. <9405111803.AA26262@mailserv-D.ftp.com> Date: Wed, 11 May 94 13:12:34 -0700 From: Dave Crocker X-Mts: smtp Frank, ---- Included message: No. The document pertains to what our collective crystal balls tell us the Internet should be in 10-20 years and how to get there. It's That's not a requirements statement. It is a statement of general desires. We simply do not know how to "require" a current technology to be capable of solving problems 20 years hence. We barely know how to require a technology to solve problems 5 years hence. (Mostly, it depends upon the degree to which the requirement really is immediate but likely to extend.) Statements of long-term desire are useful for vision, but mostly useless for creating or evaluating designs. This tension between use of your doc to evaluate the alternatives versus use as a mission statement is part of the reason its progress has been impeded. Both uses are valid. But trying to merge them isn't. We absolutely have to be thinking 10+ years ahead in order to make sure that what we field over the next 2-3 years is at least suitable as a base for what our crystal balls say. And on this, I agree. We must not field something that is known to cut off an avenue we strongly believe to be required. But neither must we wait to field it until we can figure out the details. To make something a "requirement" is to make it, ahem, required. Supporing mobility -- to continue the use of this example -- means that we need to wait until we understand it well enough to support it. We don't understand it well enough now, so what do we do with the "requirement"? Even if we don't know everything there is to know about this field, we can certainly take what we do know and evaluate proposals based on that knowledge. ... so even if we can not field a production level frotz, we should have some idea of what it takes to make a frotz and how a frotz might work. For some frotz's, yes and for others, no. If we are REAL close to finishing the research, I say yes. Flows, apparently, is in this category. But I strongly believe that your document needs to distinguish the "soon" from the "eventual". It is the only way to keep the document from becoming an overcooked stew. (I like stew, but if it's overcooked, it becomes an undifferentiated mass/mess.) Feel free to assign your own priorities in the development of your proposal. If we each have our own priorities, then we do not have a common base from which to do the analysis. In fact, I claim that this whole debate hinges on the priorities and not on the specifics items on the list. I would point out, though, that an early draft attempted to order things in terms of priorities (with a MUST/SHOULD) split. The community reacted very negatively to this. Partisans of the Foo Yup. Painful and difficult. But I also claim, necessary. This is the hard work. It would be interesting to know what these "internally generated" requirements for SIPP, CATNIP and TUBA are. It might help the IPng directorate, and the community at large, to evaluate the various proposals and see where they are trying to take us. As long as no one tries to take the following as any sort of definitive statement, I'd say that IPAE worried about a larger address space and incremental, comfortable transition for the IPv4 installed base. SIP worried about increasing the address space in a fashion that was highly compatible with IPv4. It also chose to make format optimizations to facilitate processing. (Personally, I believe that moving the options into its own space also was a major enhancement, but Deering has usually viewed it more modestly.) Addition of the flows field was in response to the belief that we are close to being able to use it and that it is essential. Assorted other features are being added, but they are not part of the critical path for definition or deployment of the core service. I'll leave an equivalent summary for the other candidates to others. Dave From owner-Big-Internet@munnari.OZ.AU Thu May 12 15:07:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03451; Thu, 12 May 1994 15:07:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA17278; Thu, 12 May 1994 14:44:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA17253; Thu, 12 May 1994 14:14:47 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02474; Thu, 12 May 1994 14:35:59 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA28619; Wed, 11 May 94 21:31:47 -0700 Received: by xirtlu.zk3.dec.com; id AA05525; Thu, 12 May 1994 00:31:39 -0400 Message-Id: <9405120431.AA05525@xirtlu.zk3.dec.com> To: Dave Crocker Cc: kasten@ftp.com, big-internet@munnari.OZ.AU Subject: Re: Requirements In-Reply-To: Your message of "Wed, 11 May 94 13:12:34 PDT." <199405112012.NAA13979@Mordor.Stanford.EDU> Date: Thu, 12 May 94 00:31:33 -0400 X-Mts: smtp Dave, Good discussion. Just want to state that I am using Craig and Frank's reqs doc as measuring stick to perform "technical review" of each IPng proposal. It works well. Its not the only measuring stick and that will come out at the end of the day. When your sitting in a room with a couple of MBs of very technical and complex specifications from three separate train of thoughts and core assumptions on what is needed for IPng, the requirements document is making it possible to view cross sections technically in a reasonable time frame. Do you have a specific issue with any of the requirments in the document? I could not tell from your mail? On another note we have the opportunity to add technology to the Internet that can support the future. Now is the time to do it before vendors build another TCP/IP product set and core architecture for the Internet. But most of all I BELIEVE ALE AND CIDR will give us to the year 2000 at least. We should be in NO RUSH AT ALL to put out a willy-nilly spec for IPng that lacks the need to support the future. All this will cause is a product set that will have to be done again in 5 years. If that happens it won't matter and the IETF will have lost all credibility because IPng will have screwed up the Super Information Highway for an International public and some other group will figure it out. And all those whose names were attached to IPng will have to go find jobs as Cobol programmers. That being said it does not mean that we can't come to a decision in July at Toronto. What it does mean is that all ideas will be listened to and weighed by lots of folks including this mail list and the people they work with etc. etc. But if folks don't bend in this process I think we will not have a decision because none of the proposals are PERFECT examples of networking. But nothings perfect right? I also KNOW EIDs and Locators are a good idea. Unfortuneately with the IPng real work I have to do which does include writing code and reviewing all these docs I have not had the time to debate the issue, I have proposed. No one should take my silence as I have given up I just can't work 90 hours a week and have set my priorities. I owe responses to Steve, Christian, and Paul on SIPP and that will take me a few hours and has already. p.s. My customers can get an IPv4 Internet address today! There is no problem. take care, /jim From owner-Big-Internet@munnari.OZ.AU Thu May 12 19:14:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12737; Thu, 12 May 1994 19:14:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA17515; Thu, 12 May 1994 18:52:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA17483; Thu, 12 May 1994 18:30:27 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12037; Thu, 12 May 1994 18:51:58 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 12 May 94 17:39:15 +0900 From: Masataka Ohta Message-Id: <9405120839.AA06459@necom830.cc.titech.ac.jp> Subject: Re: IP Technical Criteria To: bound@zk3.dec.com Date: Thu, 12 May 94 17:39:13 JST Cc: Christian.Huitema@sophia.inria.fr, francis%cactus.slab.NTT.JP@CS.TITECH.AC.JP, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <9405120529.AA05905@xirtlu.zk3.dec.com>; from "bound@zk3.dec.com" at May 12, 94 1:29 am X-Mailer: ELM [version 2.3 PL11] > EIDs are not a 3rd space to manage. The third (and may be more) space to manage is a space(s) of IDs which constitutes a locator. It seems to me that it is much simpler to make a locator sequence of EIDs of intermediate systems. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu May 12 20:23:14 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10285; Thu, 12 May 1994 18:06:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19302 Thu, 12 May 1994 18:04:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA17422; Thu, 12 May 1994 17:39:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA17397; Thu, 12 May 1994 17:09:38 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04405; Thu, 12 May 1994 15:31:14 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA02118; Wed, 11 May 94 22:29:51 -0700 Received: by xirtlu.zk3.dec.com; id AA05905; Thu, 12 May 1994 01:29:44 -0400 Message-Id: <9405120529.AA05905@xirtlu.zk3.dec.com> To: Christian Huitema Cc: francis@cactus.slab.ntt.jp (Paul Francis), deering@parc.xerox.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: IP Technical Criteria In-Reply-To: Your message of "Tue, 10 May 94 10:26:14 +0200." <199405100826.AA27679@mitsou.inria.fr> Date: Thu, 12 May 94 01:29:37 -0400 X-Mts: smtp Christian, >Paul, >You are absolutely correct. There sould not be any "requirement" that >specifies a solution rather than "a problem to solve." The problem to be solved is can we structure the routing architecture for the Internet better. This I think is a valid discussion for IPng. >I am personally very hesitant with any "mandatory EID" requirement for at >least two reasons: the need to manage yet another name space and the fact that >most arguments I have seen seems to belong to the architecture of transport >protocols. I don't see this at all. EIDs and Locators just remove the problem from the transport protocols. It creates a distinct set of discrete components to operate the internetwork layer. The transport layer only has to deal with EIDs. I don't care if the EID is within a complete sequence as the SIPP ASEQ record is or within an NSAP if they scale and perform on a host for TCP/IP and lets not get into that discussion I won't participate. >The administration of a name space is a heavy task. No, I do not believe we >can use IEEE-802 addresses to that effect. They tends not to be that much >unique in practice (many boards are soft-configured); the 48 bits space is >burnt at a fast rate (no recovery of used numbers); they identify interface >boards rather than "systems" (change if you change the board). We will have to >resort to a managed space and we will have to manage it ourselves; there is no >magic pill. We already manage two spaces, names and addresses. Adding a third >is dubious. Achieving the same functionality by reusing the uniqueness >property of the address space would be IMHO a big win. EIDs are not a 3rd space to manage. EID = Node ID: New Field ptr to Locator 1 ptr to Locator 2 more ptrs .......as required. The pointers are used by the network layer and for multi-homed hosts. Yes it would require changes to DNS but then so will Autoregistration and I also think this should have been addressed by IPng but its not. >The classic arguments for EIDs are related to stable identification of >connection contexts. I already mentioned that this is really a problem of >transport protocol design; doing it with destination specific identifiers has >been demonstrated in the case of point to point connections (XTP). Similar >solutions could be achieved with group specific identifiers or by passing an >explicit EID in the transport packets. There is an old rule which should be >applied there: if it is not used for routing, it should not be in the >gateways. It should not be in IP either. By the way, won't we ever want to >allow process mobility? If you use a station ID to identify your context, you >are bound for serious problems there... EIDs can go with you where ever you go. You just get an additional locator. No problem. >Fact is that we have to support TCP, mobility and provider selection. This is >the strong requirement. "A separate EID" is one solution to the problem. There >are others, e.g. the SIPP solution of relying on an "identifying address" + >combining it with source routing information if that is needed for mobility or >provider selection. Yes and I think a separate EID is the superior solution. But that doesn't mean it can get through all this very political environment because it is a good idea. Too bad really. /jim From owner-Big-Internet@munnari.OZ.AU Thu May 12 20:24:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12720; Thu, 12 May 1994 19:12:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA17500; Thu, 12 May 1994 18:49:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA17497; Thu, 12 May 1994 18:48:09 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10841; Thu, 12 May 1994 18:18:47 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405120818.10841@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 12 May 1994 09:18:25 +0100 To: Greg Minshall Cc: big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators In-Reply-To: Your message of "Wed, 11 May 94 14:02:37 PDT." <9405112102.AB24401@WC.Novell.COM> Date: Thu, 12 May 94 09:18:24 +0100 From: Jon Crowcroft >I tend to think we need an IPng architecture and an IPng architect. Greg nope what we need is IPng code and specs jon From owner-Big-Internet@munnari.OZ.AU Fri May 13 01:30:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23798; Fri, 13 May 1994 00:28:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA17793; Fri, 13 May 1994 00:05:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA17790; Fri, 13 May 1994 00:04:39 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23610; Fri, 13 May 1994 00:26:21 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id HAA18068; Thu, 12 May 1994 07:26:04 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 May 1994 07:26:07 -0700 To: bound@zk3.dec.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: kasten@ftp.com, big-internet@munnari.OZ.AU Well, Jim, when you push a button, you punch the hell out of it... >But most of all I BELIEVE ALE AND CIDR will give us to the year 2000 at Wrong. Very wrong. Dead wrong. ALE "gives" us nothing. It makes an estimate, based on wholly flawed methodology, frankly inappropriate to the task. It would be "interesting" information if it were part of a repertoire of analyses. On its own, we can't have a clue as to how to interpret it. For example, we could and should distinguish between 'hitting the wall' versus 'falling off the cliff'. For consistency in the image, I'll turn the wall reference into 'slamming into the canyon floor.' When that happens, we are quite literally dead. But falling off the cliff is pretty serious, too. There's a degree of inevitability to what follows. I claim that we fell off the cliff roughly last year. RFC1597 is a symptom of this. We are already turning down legitimate requests for address space. We are, in other words, forcing people into the use of private network numbers. This is bad. It needs to stop. The only way to make it stop is to fix the address space problem. We need IPng now. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri May 13 02:23:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AC20707; Thu, 12 May 1994 23:17:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA17716; Thu, 12 May 1994 22:55:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA17713; Thu, 12 May 1994 22:52:57 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20560; Thu, 12 May 1994 23:14:39 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA27989; Thu, 12 May 94 09:14:36 -0400 Message-Id: <9405121314.AA27989@rodan.UU.NET> To: big-internet@munnari.OZ.AU Subject: EIDs and requirements therefore... Date: Thu, 12 May 1994 09:14:36 -0400 From: "Mike O'Dell" I've been tracking this discussion for a bit now, and have some thoughts on how this is going. When SIP first started, I distrinctly remember being one of the people who lobbied for some support for mobility. What I had in mind was something like XNS has: the "address" used to identify the endpoint is independent of the network topology, but the packet format carries a "network identifier" for routing purposes. In XNS, the "network number" is really a HINT as to where to find the indicated address. Now I admit that this hint damn well better be correct, but changing the network number does NOT change the identity of the endpoint like it does with an IPv4 address. What we have here is a continuum of dynamic binding mechanism. With IPv4 we have minimal (zero?) dynamic behavior, except for the dynamic binding done with ARP, which is not visible from the other end of the path so it doesn't really count. Pure locator, essentially. With XNS - we have a more dynamic mechanism and a hybrid address token. The identity of the host doesn't change when it moves, but the locator part does, and the local router dynamically supplies the missing piece when you go off-net. With just full-blown EIDs, we have moved from pure address to pure name in the packet. Without exogenous machinery to produce the binding the EID is meaningless (even if you successfully administer the namespace). This is what NIMROD is about - supplying this dynamic machinery in the forwarding and routing structure. Please note that some of this is independent of the Packet Format. This is what Noel has been crying in the wilderness about for two years. We can adopt an IPng which is currently specified with some level of address (or some hybrid combination of designator and locator) which we know how to implement, route, and realize TODAY with finite effort, but with the knowledge that as we work through the details of how to deploy this automagic machinery in the routing and forwarding fabric, we can (gracefully) transition to an "address token" which is more and more pure name and less and less locator. Or we can allow both to exist as the engineering realities dictate. So the important question is NOT "Can we do EIDs today?" but "What in the proposed structure would be a show-stopper for the eventual migration to a structure with more "name" and less "locator"??" I now return you to your regularly scheduled discussions. -Mike From owner-Big-Internet@munnari.OZ.AU Fri May 13 03:22:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00391; Fri, 13 May 1994 03:22:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA18003; Fri, 13 May 1994 03:00:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA18000; Fri, 13 May 1994 02:57:35 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00203; Fri, 13 May 1994 03:19:14 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA16731; Thu, 12 May 94 10:11:33 -0700 Received: by xirtlu.zk3.dec.com; id AA26735; Thu, 12 May 1994 13:11:25 -0400 Message-Id: <9405121711.AA26735@xirtlu.zk3.dec.com> To: "Mike O'Dell" Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: EIDs and requirements therefore... In-Reply-To: Your message of "Thu, 12 May 94 09:14:36 EDT." <9405121314.AA27989@rodan.UU.NET> Date: Thu, 12 May 94 13:11:19 -0400 X-Mts: smtp >So the important question is NOT "Can we do EIDs today?" but "What in >the proposed structure would be a show-stopper for the eventual migration to a >structure with more "name" and less "locator"??" I agree. /jim From owner-Big-Internet@munnari.OZ.AU Fri May 13 03:25:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00525; Fri, 13 May 1994 03:25:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA18018; Fri, 13 May 1994 03:04:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA17986; Fri, 13 May 1994 02:53:11 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29901; Fri, 13 May 1994 03:14:53 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA16466; Thu, 12 May 94 10:07:22 -0700 Received: by xirtlu.zk3.dec.com; id AA26616; Thu, 12 May 1994 13:07:15 -0400 Message-Id: <9405121707.AA26616@xirtlu.zk3.dec.com> To: Jon Crowcroft Cc: Greg Minshall , big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: IPng Architecure and an IPng Architect Date: Thu, 12 May 94 13:07:09 -0400 X-Mts: smtp ] In response to Jon's msg May 12, 1994 to Greg and I changed the name of ] the subject title. =>I tend to think we need an IPng architecture and an IPng architect. =>Greg >nope >what we need is IPng code and specs > jon I agree BUT I would like to see a routing and discovery strategy before we do anymore than write toy demo code and test out the ramifications to the host kernels (and not just BSD derived either). Don't get me wrong we are learning a lot doing present IPng code, but the hair on the back of our neck stands up when we start to determine network topology when required and variable transport addresses are very annoying on a host. As an example of an Architectural concern a 16bit length field just seems to small still for the future and it could cause more fragmentation as MTUs grow on the network. I think we were trying to avoid fragmentation and we could run smack into it again tomorrow because of a 16bit payload length field. And if SIPP were the IPng all this burden will now be on the hosts not the routers. But, SIPP headers aligned on 64bit boundaries are a good thing and should not be broken with any enhancements thus offsets and padding would have to be used. But maybe we cannot figure out the routing and discovery strategy for the next 20 years. Maybe its just too hard and complex and we don't have all the variables to the equation and they are still unknown. This is what I like about EIDs and Locators. I believe they can be used as a means to develop an extensible network topology for which we can write code today that can be extended as the network topology becomes extended instead of re-inventing the internetwork layer again for IPng+. In addition if done correctly when the network topology is extended and EIDs are in place it will be transparent to customers using networking for their business ala APPLICATIONS THAT REQUIRE NETWORK CONNECTIVITY. For IPng any applications that want to become IPng capable they will have to add code to become IPng aware. With the proper use of EIDs this should never happen again. UNLESS we change the transport to become TCP/UDP PLUS, and that maybe could be transparent too depending on how the internetwork layer is designed in IPng. The bottom line is code without Architecture thought will produce short sighted goals. But Architecture without code can be fantasy engineering. Walking this fence is a hard thing to do as an Architect or as an Engineer. Its using the Macro and Micro views together that builds great products. One without the other will produce bugs and a product that cannot function long term. /jim From owner-Big-Internet@munnari.OZ.AU Fri May 13 04:32:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02772; Fri, 13 May 1994 04:32:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA18083; Fri, 13 May 1994 04:10:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA18080; Fri, 13 May 1994 04:06:08 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02562; Fri, 13 May 1994 04:27:51 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16789; Thu, 12 May 94 14:27:46 -0400 Date: Thu, 12 May 94 14:27:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405121827.AA16789@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators Cc: jnc@ginger.lcs.mit.edu From: Jon Crowcroft > I tend to think we need an IPng architecture and an IPng architect. nope - what we need is IPng code and specs No. Go read Chapter 4, "Aristocracy, Democracy and System Design", in "The Mythical Man-Month". Pay particular attention to the sections entitled "Conceptual Integrity", and "Achieving Conceptual Integrity". This book is the premier work on software engineering, and managing software engineering projects. The Internet, and the IETF, can be seen as nothing more than a large software engineering project, and all of the painfully learned lessons in the book apply. Noel From owner-Big-Internet@munnari.OZ.AU Fri May 13 05:17:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04018; Fri, 13 May 1994 05:07:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA18180; Fri, 13 May 1994 04:45:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA18125; Fri, 13 May 1994 04:13:21 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02830; Fri, 13 May 1994 04:35:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16832; Thu, 12 May 94 14:35:01 -0400 Date: Thu, 12 May 94 14:35:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405121835.AA16832@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) We are already turning down legitimate requests for address space. Can you provide more details? The ones I heard rumors about (Boeing in particular) turned out not to be correct. We are, in other words, forcing people into the use of private network numbers. This is bad. It needs to stop. The only way to make it stop is to fix the address space problem. People are also using private network numbers to provide security. If use of private network numbers is really so bad, maybe we should focus on security. Perhaps these people think that adding better security is more important than more address space (which is not really that short, whereas security is already a giant disaster area). We need IPng now. We don't need an interim design, which, as Jim Bound points out, leaves out key capabilities, and thus forces us through a redo some years down the road. Noel From owner-Big-Internet@munnari.OZ.AU Fri May 13 08:26:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05141; Fri, 13 May 1994 05:42:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA18239; Fri, 13 May 1994 05:20:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA18225; Fri, 13 May 1994 04:59:43 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01983; Fri, 13 May 1994 04:06:23 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA19753; Thu, 12 May 94 10:55:51 -0700 Received: by xirtlu.zk3.dec.com; id AA28033; Thu, 12 May 1994 13:55:43 -0400 Message-Id: <9405121755.AA28033@xirtlu.zk3.dec.com> To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: bound@zk3.dec.com, kasten@ftp.com, big-internet@munnari.OZ.AU Subject: Re: Requirements In-Reply-To: Your message of "Thu, 12 May 94 07:26:07 PDT." Date: Thu, 12 May 94 13:55:37 -0400 X-Mts: smtp >Well, Jim, when you push a button, you punch the hell out of it... Yep I do this on purpose. It helps avoid a real problem the ancient Greeks had called Sophism (like when Congress holds up a bill with talk that says nothing to the issue or gets one passed based on 'perceived' public emotion or false premises from supposed polls), and annoyed the heck out of philosophers like Plato, Aristotle, and then Socrates. Forced Socrates to end his life I think. =>But most of all I BELIEVE ALE AND CIDR will give us to the year 2000 at >Wrong. Very wrong. Dead wrong. >ALE "gives" us nothing. It makes an estimate, based on wholly flawed >methodology, frankly inappropriate to the task. It would be "interesting" >information if it were part of a repertoire of analyses. On its own, we >can't have a clue as to how to interpret it. ALE is tracking the data we can gather its not perfect but its all we got. What part of the mathematics or statistical analysis don't you like in ALE? Have you told ALE this and participate in the working group meetings and mail? I don't because the updates I get are on track. So if your telling me its not on track specific details would be very helpful. Ditto on CIDR. I trust these folks and the chairs. >For example, we could and should distinguish between 'hitting the wall' >versus 'falling off the cliff'. For consistency in the image, I'll turn >the wall reference into 'slamming into the canyon floor.' When that >happens, we are quite literally dead. This sounds like Sophism because anyone would agree with you. Like saying guns can kill people, but not saying people need to pull the trigger for the gun to kill somone. The issue is to define why you believe we are going to go over the cliff with semi-scientific analysis based on current address use. If we are going to fall of the cliff tomorrow then we had better just use TUBA cause it will take more time to deploy CATNIP or SIPP, for better or worse. And not worry about the other IPng requirements just addressing and routing. Fortuneately we have time I believe to look and test all IPng proposals and get some new technology at the same time I believe the Internet needs. >But falling off the cliff is pretty serious, too. There's a degree of >inevitability to what follows. I see your issue but not any data to back it up? >I claim that we fell off the cliff roughly last year. RFC1597 is a symptom >of this. We are already turning down legitimate requests for address >space. We are, in other words, forcing people into the use of private >network numbers. What? I just had to explain why CIDR was transparent to our tech folks in the field who set up a customers with several Class C addresses. They are not off the cliff. This was about 4 weeks ago. RFC 1597 is an option for customers who WANT TO HAVE their own private IP addresses that will never be used by the Internet. NO ONE IS FORCING ANYONE. You take liberty here with that statement and are wrong about why RFC 1597 has come about. Yes it could conserver IPv4 address space if private networks want to use it. I have no comment as to its goodness or badnesses for this mail. You are telling us the sky is falling and I am saying the global weather forecast for the next three planting seasons for my farm, though not 100% accurate, is telling me what seeds to sow in my soil. By definition engineering has risks and + or - error correction built in when done correctly. I think what your saying about IPng is dangerous because your view will cause us to only fix the address and route aggregation problem and any side benefits we get from an IPng proposals forward thinking through serendipity. Then products will show up and vendors will dig their heels in and it will get more entrenched and before we know it we just have same old IP with larger addresses and new route aggregation. I don't like this strategy and I am against it completely. Its short sighted and will not be extensible for the future. >This is bad. What is bad? What would be good? >It needs to stop. Waht needs to stop? What will replace that which stops? >The only way to make it stop is to fix the address space problem. But changing the address has ramifications to the entire technical domain of TCP/IP (see my BSD Host Implementation Analysis Internet Draft). Then this new domain creates new ranges as a function. This is why IPng must perform a logic check to see what the affect of the range is to the network topology for the next generation 'International' Internet. NOTE )---> the Internet is International now it will be more so with IPng. For example all proposals provide a new scheme because of a new address and new routing concepts for systems discovery. In addition that system discovery has to coexist for sometime with IPv4 system discovery. This right now is just white board engineering and is not being tested on the Internet today. In SIPP as an example there is still disagreement on the final details for system discovery. In TUBA they have just begun to spec out the integration transition issues with the present IPv4 address space. These are hard technical problems to solve and the working groups experts in these areas are working on them. This is just one example of what happens when you change the address space. >We need IPng now. I agree and we need at least 3 years to get it debugged and deployed in the market. If we make a selection in July of 94 then we can get the whole IETF focused on the specs and code implementation and get interoperability suites or bake-offs going to build an IPng product set for the market place. But my reason for wanting a decision in July is different that what I hear you saying. I want it so we can get all the bright people in the IETF and Industry focused and to give confidence to the vendors to begin developing full robust IPng software as opposed to basic prototypes. IPng being selected will get the ISVs porting and doing some analysis to for the applications. This is missing presently and a big void in IPng as input IMHO. /jim From owner-Big-Internet@munnari.OZ.AU Fri May 13 10:29:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12914; Fri, 13 May 1994 08:38:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA18418; Fri, 13 May 1994 08:15:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA18390; Fri, 13 May 1994 07:53:41 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05152; Fri, 13 May 1994 05:42:53 +1000 (from craig@aland.bbn.com) Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06204 for big-internet@munnari.oz.au; Thu, 12 May 94 15:42:40 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id MAA04464; Thu, 12 May 1994 12:40:41 -0700 Message-Id: <199405121940.MAA04464@aland.bbn.com> To: Noel Chiappa Cc: big-internet@munnari.OZ.AU Subject: Re: Requirements In-Reply-To: Your message of Thu, 12 May 94 14:35:01 -0400. <9405121835.AA16832@ginger.lcs.mit.edu> From: Craig Partridge Date: Thu, 12 May 94 12:40:37 -0700 Sender: craig@aland.bbn.com We need IPng now. We don't need an interim design, which, as Jim Bound points out, leaves out key capabilities, and thus forces us through a redo some years down the road. Noel: Since you cited the mythical man month (and thus took us into the realm of management :-)), let me point out that there's a problem with delaying a decision too. IETF has very limited resources. In general, we're probably lucky to get 5% of the average attendees time. Of those, probably less than half the attendees (probably less than a quarter) are working on IPng issues regularly. As long as we continue to delay the IPng decision, we're going to continue to have those IPng folks fragmented. Some are working on CATNIP, some on SIPP, some on TUBA, some on TURNIPP, etc. Often doing similar stuff (i.e., how to put multicasting into each proposal, how to support flows in each proposal, how to do mobility for each proposal). If we are to have any hope of deploying an IPng in the next several years, we need to rapidly focus on one solution, so everyone can pull in roughly the same direction, rather than being distracted by multiple proposals. My view is that the IPng decision this summer is only the first step in a series. We'll decide on the protocol and with it a general philosophy. Then we'll probably burn a test version over the next two years or so, produce a revised spec, and that will be our standard. But if we wait for all the answers, or even 90% of them, before deciding, we'll deliver the product far too late. Dave's right, we need an IPng decision now, if only to make effective use of our manpower, and to allow us to deliver an IPng solution on-time, when it is needed. Craig From owner-Big-Internet@munnari.OZ.AU Fri May 13 10:41:52 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13604; Fri, 13 May 1994 09:03:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03316 Fri, 13 May 1994 08:52:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA18444; Fri, 13 May 1994 08:27:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA18404; Fri, 13 May 1994 08:01:26 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12162; Fri, 13 May 1994 08:23:09 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id PAA20745; Thu, 12 May 1994 15:23:01 -0700 Message-Id: <199405122223.PAA20745@Mordor.Stanford.EDU> To: bound@zk3.dec.com Cc: kasten@ftp.com, big-internet@munnari.OZ.AU Subject: Re: Requirements Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 12 May 94 13:55:37 -0400. <9405121755.AA28033@xirtlu.zk3.dec.com> Date: Thu, 12 May 94 15:23:01 -0700 From: Dave Crocker X-Mts: smtp ---- Included message: ALE is tracking the data we can gather its not perfect but its all we Unfortunately, we are practising medicine without a license. If we were on a desert island and the patient were dying, then we would have no choice. But we are not competent to practise medicine. There are folks who ARE competent in the practise of formulating projections for new and changing markets. They do not use simplistic techniques of projecting from old behaviors in narrow markets. We need their help. Until we get it, it is not correct to say 'what we've got is better than nothing'. In fact, "nothing" would be preferable. At least then we would not have a false sense of comfort. got. What part of the mathematics or statistical analysis don't you like in ALE? Have you told ALE this and participate in the working Thought I'd said all this to the list before. There is strong evidence of emerging user categories that are quite different from past ones. ALE uses 'traffic analysis and projection' techniques. That's fine for charting growth in traffic. It's not fine when trying to account for new categories of use. group meetings and mail? I don't because the updates I get are on track. So if your telling me its not on track specific details would be very helpful. We are already into a process of self-fulfillment. We are turning people down for numbers. We are therefore directly affecting the outcome of the 'projection' process. This sounds like Sophism because anyone would agree with you. Like saying guns can kill people, but not saying people need to pull the trigger for the gun to kill somone. The issue is to define why you believe Nope. I'm saying that we already have a serious problem. We are turning people down for network numbers. That is the reason that RFC1597 was written. One week ago at a BOF in Interop, there was much energy exerted asserting that we already have a serious problem because folks can't get the numbers they need. (Bob M.? You watching this debate??) If we are going to fall of the cliff tomorrow then we had better just use TUBA cause it will take more time to deploy CATNIP or SIPP, While your conclusion sounds reasonable, it is almost certainly wrong. TUBA is easy to deploy in routers but there's no indication it has any sort of edge for hosts. Also the mere fact that some code exists for hosts doesn't mean that it is mature, performant, supportable in scale, etc. The fact that SIPP code is brand new is equally counter-intuitive. The fact that it really does use IPv4 as its base and that it reuses mosts of its terminology etc. means that coding and support well could be MUCH easier than for TUBA. (I realize that this invites debate. For the thread that this message is part of, I'm only trying to point out that a quick hop to an "easy" decision is not all that easy. In fact, that is EXACTLY what we ought to be considering, rather than asking how many new and experimental features we stuff into the requirements doc.) I see your issue but not any data to back it up? c.f., the authors of RFC1597. RFC 1597 is an option for customers who WANT TO HAVE their own private IP addresses that will never be used by the Internet. NO ONE IS FORCING ANYONE. You take liberty here with that statement and are wrong about Wrong. We are turning folks down. THAT is what motivated 1597, according to some of the authors. I think what your saying about IPng is dangerous because your view will cause us to only fix the address and route aggregation problem and any side benefits we get from an IPng proposals forward thinking through serendipity. Then products will show up and vendors will dig their heels We have been discussing features and desires for nearly two years. We have been designing and enhancing the original proposals and specs during that time. This is not pure serendipity. My point is that we are at or past the point of jerking ourselves around by adding yet-more spiffy features to the requirements list. We have to close that down and make some choices and then deploy this stuff. Every clever new idea now is going to serve to defer the deployment and distract us from solving the core, immediate problems we have been attending to for two years. As you and I both know, this is just the sort of situation that keeps a product from being delivered in a reasonable timeframe. This is just one example of what happens when you change the address space. Jim, if I understood this line of comment, you are lobbying for careful analysis of effects and careful design of the details required for the transition. Sounds good to me. Dave From owner-Big-Internet@munnari.OZ.AU Fri May 13 16:34:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23624; Fri, 13 May 1994 13:53:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA18696; Fri, 13 May 1994 13:30:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA18671; Fri, 13 May 1994 12:56:19 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22170; Fri, 13 May 1994 13:17:54 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA02138; Thu, 12 May 94 20:17:38 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by Eng.Sun.COM (4.1/SMI-4.1) id AA24556; Thu, 12 May 94 13:39:52 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA29364; Thu, 12 May 1994 13:40:32 -0700 Date: Thu, 12 May 1994 13:40:32 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9405122040.AA29364@jurassic.Eng.Sun.COM> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9405121827.AA16789@ginger.lcs.mit.edu> Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators Noel, >This book is the premier work on software engineering, and managing software >engineering projects. The Internet, and the IETF, can be seen as nothing more >than a large software engineering project, and all of the painfully learned >lessons in the book apply. The author recently gave a talk at Sun on the "Design of Design". His main point was that great designs are produced by great designers. Not by design committees, requirements committees, etc. Their are many examples of the latter failing. Bob From owner-Big-Internet@munnari.OZ.AU Fri May 13 19:52:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27759; Fri, 13 May 1994 15:38:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA18794; Fri, 13 May 1994 15:15:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA18791; Fri, 13 May 1994 15:12:02 +1000 Received: from brazos.is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21154; Fri, 13 May 1994 12:48:51 +1000 (from bmanning@is.rice.edu) Received: by brazos.is.rice.edu (AA02331); Thu, 12 May 94 21:44:01 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9405130244.AA02331@brazos.is.rice.edu> Subject: Re: Requirements To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Thu, 12 May 1994 21:44:01 -0500 (CDT) Cc: bound@zk3.dec.com, kasten@ftp.com, big-internet@munnari.OZ.AU In-Reply-To: <199405122223.PAA20745@Mordor.Stanford.EDU> from "Dave Crocker" at May 12, 94 03:23:01 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 771 Dave Crocker sez: > We are already into a process of self-fulfillment. We are turning people > down for numbers. > > Nope. I'm saying that we already have a serious problem. We are turning > people down for network numbers. > > Wrong. We are turning folks down. THAT is what motivated 1597, according > to some of the authors. > Three times in this note. Perhaps you are privy to information that the rest of us do not share. I would appreciate a brief list of how many people have been turned down and the size of the blocks they are asking for. This information may be of use by ALE in adjusting growth projections. Simply as a nice, sideline activity. (We don't need to reflect my request for a class A space though.) -- Regards, Bill Manning From owner-Big-Internet@munnari.OZ.AU Fri May 13 20:08:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00656; Fri, 13 May 1994 16:49:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA18860; Fri, 13 May 1994 16:25:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA18844; Fri, 13 May 1994 16:01:31 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23593; Fri, 13 May 1994 13:52:04 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id UAA22162; Thu, 12 May 1994 20:51:22 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 May 1994 20:51:26 -0700 To: bmanning@is.rice.edu (William Manning) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: bound@zk3.dec.com, kasten@ftp.com, big-internet@munnari.OZ.AU >Three times in this note. Perhaps you are privy to information that the rest >of us do not share. I don't think I have special access. I simply heard authors and reviewers of RFC 1597 make the claim. One of the authors was the source of such a request. Other than citing them, I can't speak for them. They have their details. One suspects they read this list... Other than that, I've been hearing the same scuttlebut as everyone else, and treated it with the same lack of concern. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri May 13 20:17:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08141; Fri, 13 May 1994 20:17:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA19043; Fri, 13 May 1994 19:55:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA19035; Fri, 13 May 1994 19:44:38 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29447; Fri, 13 May 1994 16:20:34 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA22196; Fri, 13 May 94 02:20:03 EDT Message-Id: <9405130620.AA22196@tipper.oit.unc.edu> To: Bob.Hinden@eng.sun.com (Bob Hinden) Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators In-Reply-To: Your message of "Thu, 12 May 94 13:40:32 PDT." <9405122040.AA29364@jurassic.Eng.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 May 94 02:20:03 -0400 From: Simon E Spero Bob.Hinden@Eng.Sun.COM (Bob Hinden) writes: >The author recently gave a talk at Sun on the "Design of Design". His >main point was that great designs are produced by great designers. Not >by design committees, requirements committees, etc. Their are many >examples of the latter failing. [He's probably in California more than Chapel Hill] Briefly touching on the topic in the subject line; one famous S.E. saying is "plan to build one to throw away, because you will anyway'. It'd be useful at this point to work under the assumption that there's something horribly wrong in IPNG (whatever we pick), and at some time we're going to have to do this all over again. It'd be interesting to see if it's any easier to transition between the various IPNG candidates than it is to transition from IPV4; it'd also be interesting to see if EID/Locator punning has any effect on this. I think we do need one person to take to role of imperator, with the power to give thumbs up or thumbs down, with the only appeal being the right to five minutes to argue your case. The obvious choice would be to raise Postel to the Purple; failing that, an IAB member without commercial conflicts of interest would be a good choice. At the very least, let the IPNG directors have the right to prioritize the requirements list, and decide whether or not a given proposal satisfies those requirements. Simon "Yet Chiappa says he was ambitious, And Chiappa is an honourable man So are they all honourable men" ---- Tar Heel Information Services - Nothing but Net | Welcome to TCP JAM -------------------------------------------------------------------------------- -I have heard the routers pinging, each to each. | Tel: +1-919-962-9107, I do not think that they will ping to me- | Fax: +1-919-962-5604 From owner-Big-Internet@munnari.OZ.AU Fri May 13 21:27:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10303; Fri, 13 May 1994 21:27:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA19116; Fri, 13 May 1994 21:05:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA19099; Fri, 13 May 1994 20:46:15 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16093; Fri, 13 May 1994 10:22:20 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA21647; Thu, 12 May 1994 17:22:12 -0700 Message-Id: <199405130022.RAA21647@Mordor.Stanford.EDU> To: big-internet@munnari.OZ.AU Subject: IPng Criteria doc Contact: phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Thu, 12 May 94 17:22:11 -0700 From: Dave Crocker X-Mts: smtp Frank and Craig, Having engaged in this recent round of, ummm, discussion, I'm compelled to respond specifically about your current document. Mostly, I like it a very great deal, in terms of style as well as content. The non-goals section is a nice touch. Yeah. Mostly. But in this community, that's pretty good. The change that I suggest, in keeping with my earlier comments, is to create 3 pots for the items. Your 'time frame' text suggests some of the placements. Criteria for Criteria: The first pot is for stuff that is absolutely essential immediately. We drop dead without it. This is survival, not preference or marketing. The second pot is for stuff that is deemed essential for adoption, for additional functionality, etc. But it has the key feature of having general community consensus that we know what we are doing. It might not be here today, but we don't believe there's much risk. In some cases, history suggests that there IS risk, but the community consensus is that we really do believe we know how to get past it (this time). The third pot is the wish-list. Reasonable and maybe important, but possibly research and definitely not critical path to the near-term. Let me suggest that responses wishing to debate this note start by debating my definitions for the pots. If we can stabilize on them, we can quibble the placements later. 1. Absolutely, positively right now (New) Scale Transition (IPv4) Topological flexibility Performance Robust service Media independence Unreliable datagram service Access Multicast addressing Extensibility Unique naming Control protocol Tunneling 2. Mandatory, near-term, engineering-but-no-research Configuration, administration, and operations Network service 3. Would be nice, when we know how; must not knowingly prevent Allow secure operation Mobility Now, I imagine that some of this need explaining: For the first category, I distinguished between those items that are part of the current IPv4 and those which are new. For the second category, config&admin might seem surprising. In fact, I think that chunk really needs to be split into two. There are capabilities which are well-established within the IPv4 context and we certainly don't want to lose them. But the requirement for autoconfig is, in my opinion, a matter of some difficult history within the IETF and we need to recognize that fact. (I want this stuff as much as anyone else; the issue here is whether we can safely believe we have the problem solved. Our history suggests not.) This is something that OUGHT to be solved by direct effort. To date, our direct efforts have produced underwhelming results. The text also seems to add DNS autoregistration to the task, and that makes the requirement even less related to immediately attainable goals. Hence, it needs to be taken out of the immediate, critical path. The secure operation requirement strikes me as the least reasonable of the entire list. We have a very long history of working hard and achieving little in this realm. Making it a direct requirement won't change that. Adding something like non-repudiation seems to me to work primarily as icing on this cake. Do we really know what any of this means and do we really know that it is necessary at the Internet layer? I'm afraid that I don't think so. I've said enough about the fantasy-versus-reality of mobility in previous notes, so I won't repeat the comments here. Dave From owner-Big-Internet@munnari.OZ.AU Fri May 13 21:29:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10356; Fri, 13 May 1994 21:29:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA19131; Fri, 13 May 1994 21:07:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA19102; Fri, 13 May 1994 20:47:07 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16324; Fri, 13 May 1994 10:29:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19304; Thu, 12 May 94 20:29:42 -0400 Date: Thu, 12 May 94 20:29:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405130029.AA19304@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu From: Craig Partridge let me point out that there's a problem with delaying a decision too. ... As long as we continue to delay the IPng decision, we're going to continue to have those IPng folks fragmented. Look, this is the price the IETF pays for being stupid. First, everyone from the Gang of Five in Zurich on down started running around like chickens with their heads cut off, yelling "the sky is falling", bringing us first ROAD, and then IPng. Next, people charged into the appealing and simple task of starting to design packet formats (modulo TUBA, which already had one), without giving a *lot* of thought as to what the darn thing needed to actually do. (IPv4, let's not forget, was an *experiment*; we're trying to design the Global Information Infrastructure here, and it will take a lot more thinking to get right.) I have zero sympathy about the waste. Yes, it is a horrendous waste of time and energy, but then again, so was the Kobe-IPv7 fiasco. I've learned the hard way that when people want to drive a bus off the cliff, you often can't stop them. You just have to sit back and watch. I can't stop the IPng proponents from wasting time; it's easier just to sit back and watch, sad and wasteful as it is. If we are to have any hope of deploying an IPng in the next several years, You say this like it's obviously the right thing. I don't agree. I think deploying IPng on a rush schedule is almost a guarantee we'll have to do it all over again in the not too distant future. I don't think we should be trying to add support for anything we don't have practical experience with. I also don't think we can afford to do an IPng which *doesn't* include support for some of the advanced stuff. What that tells me is that, assuming we've got time, it's too early to do IPng. we need to rapidly focus on one solution, so everyone can pull in roughly the same direction, rather than being distracted by multiple proposals. I think a more profitable course of action is to say that all the proposals are entirely inadequate, and for people to instead turn to getting experience with the things we need to know more about, such as resource allocation, etc, before we can hope to do a good job of IPng. My view is that the IPng decision this summer is only the first step in a series. We'll decide on the protocol and with it a general philosophy. Oh, balderdash. None of the proposal has what I would dignify as a "general philosophy" (unless you count "ISO" and "not-ISO"). For instance, look at SIPP. What are SIPP's thoughts on how routing and forwarding are going to be done in the future? Pretty minimal; it's Somebody Else's Problem. (I.e. OSPF and IDRP, or whatever else somebody else does.) What about resource allocation? Same answer, except when it's "What resource allocation?" And God forbid anyone should think about how the pieces actually fit together in a coherent, as opposed to ad-hoc, way. I challenge you to describe the architectural design philosophy of the internetworking layer of *any* of the proposals (I suppose CLNP is more or less the same at IPv4, i.e. hopelessly dated.) "Making the packets efficient to forward" doesn't count; that's not architecture, that's elementary engineering. But if we wait for all the answers, or even 90% of them, before deciding, we'll deliver the product far too late. It's only going to be "late" because we've created a hysteria that says we need a decision, any decision, soon. Dave's right, we need an IPng decision now, if only to make effective use of our manpower, and to allow us to deliver an IPng solution on-time, when it is needed. Gee, if I take out IPng, and substitute "CMOT/SGMP", or "OSPF/IS-IS", I seem to have heard this line of reasoning before. Noel From owner-Big-Internet@munnari.OZ.AU Fri May 13 22:43:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12524; Fri, 13 May 1994 22:43:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA19224; Fri, 13 May 1994 22:15:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA19191; Fri, 13 May 1994 21:41:08 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02161; Fri, 13 May 1994 17:34:31 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405130734.2161@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 13 May 1994 08:33:52 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators In-Reply-To: Your message of "Thu, 12 May 94 14:27:46 EDT." <9405121827.AA16789@ginger.lcs.mit.edu> Date: Fri, 13 May 94 08:33:43 +0100 From: Jon Crowcroft > From: Jon Crowcroft > > I tend to think we need an IPng architecture and an IPng architect. > nope - what we need is IPng code and specs > >No. Go read Chapter 4, "Aristocracy, Democracy and System Design", in "The >Mythical Man-Month". Pay particular attention to the sections entitled >"Conceptual Integrity", and "Achieving Conceptual Integrity". read it unsderstood it digested it disagree with it:-) (also,m i teach in a computer science dept, so you must expect me to be very suspicous of software engineering) >This book is the premier work on software engineering, and managing software >engineering projects. The Internet, and the IETF, can be seen as nothing more >than a large software engineering project, and all of the painfully learned >lessons in the book apply. my viewpoint is that we already have an architecture. from you, steve deering, scott shenker & dave clark now we need to engineer it.... jon From owner-Big-Internet@munnari.OZ.AU Fri May 13 23:47:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14886; Fri, 13 May 1994 23:47:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA19299; Fri, 13 May 1994 23:25:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA19285; Fri, 13 May 1994 23:24:05 +1000 Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14851; Fri, 13 May 1994 23:45:44 +1000 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA00432); Fri, 13 May 94 08:45:32 CDT Received: by sabine.is.rice.edu (AA04753); Fri, 13 May 94 08:42:54 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9405131342.AA04753@sabine.is.rice.edu> Subject: !! Denied !! To: postel@isi.edu, scottw@internic.net Date: Fri, 13 May 94 8:42:53 CDT Cc: big-internet@munnari.OZ.AU X-Mailer: ELM [version 2.3 PL11] Sorry to bother you, but there have been a number of threads that seem to point out that IPv$ requests have been denied. Some of the claims are intimated as coming from rfc1597 authors, others from consultants to large corporations with "new and unique" plans for IP addressing. (an IP address for each light switch and two in every SEGA(tm) cartridge) In an attempt to get new data points for the ALE effort, can you please document if there have been such requests that have been turned down? A brief list listing the number and the size of the requested block per request would be useful. -- Regards, Bill Manning From owner-Big-Internet@munnari.OZ.AU Sat May 14 00:20:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11438; Fri, 13 May 1994 22:02:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA19183; Fri, 13 May 1994 21:40:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA19158; Fri, 13 May 1994 21:14:52 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16990; Fri, 13 May 1994 10:50:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19401; Thu, 12 May 94 20:48:35 -0400 Date: Thu, 12 May 94 20:48:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405130048.AA19401@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu From: Dave Crocker There are folks who ARE competent in the practise of formulating projections for new and changing markets. They do not use simplistic techniques of projecting from old behaviors in narrow markets. Mmm. I hope they're better than the professionals at Proteon whom I told in the '85 time-frame that the world-wide router market by 2000 would be a billion dollar market. I think they thought I was on drugs. The current Internet is hardly a "narrow market"; the patterns of use of networking technology in large organizations, and groups of large organizations, were amply demostrated years ago, and have changed little as they have spread. There is strong evidence of emerging user categories that are quite different from past ones. ALE uses 'traffic analysis and projection' techniques. That's fine for charting growth in traffic. It's not fine when trying to account for new categories of use. The Internet has *already* jumped into "new categories" several times in the data these guys are working from; i.e. into universities in general (as opposed to just CS departments), into computer companies, into other countries, etc. We are turning people down for numbers. You keep making this statement, without providing any information; could you please provide some background to help us in assessing this? The cases I heard of, and investigated, were not as described. One week ago at a BOF in Interop, there was much energy exerted asserting that we already have a serious problem because folks can't get the numbers they need. For those of us who weren't there, could you please provide details? Every clever new idea now is going to serve to defer the deployment and distract us from solving the core, immediate problems we have been attending to for two years. Oh, like the routing problem? That graph Yakov talked about shows a *drop* in the number of routign table entries (from 20K, to about 18K) over the last month or so. Maybe we should all stop yapping about this stupid, pointess IPng question and go work on the real problems, like security, autoconfiguration, etc, for a while. As you and I both know, this is just the sort of situation that keeps a product from being delivered in a reasonable timeframe. Getting a product out on time is worthless if it's the wrong product. I know all about that one. Noel From owner-Big-Internet@munnari.OZ.AU Sat May 14 01:04:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18082; Sat, 14 May 1994 01:04:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA19433; Sat, 14 May 1994 00:42:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA19390; Sat, 14 May 1994 00:22:47 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14310; Fri, 13 May 1994 23:32:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23338; Fri, 13 May 94 09:32:25 -0400 Date: Fri, 13 May 94 09:32:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405131332.AA23338@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators Cc: jnc@ginger.lcs.mit.edu From: Bob.Hinden@eng.sun.com (Bob Hinden) > This book is the premier work on software engineering, and managing > software engineering projects. His main point was that great designs are produced by great designers. Not by design committees, requirements committees, etc. I couldn't agree more. The Requirements WG isn't trying to produce a design, though... Noel From owner-Big-Internet@munnari.OZ.AU Sat May 14 01:31:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17861; Sat, 14 May 1994 00:57:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA19404; Sat, 14 May 1994 00:35:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA19387; Sat, 14 May 1994 00:19:25 +1000 Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14276; Fri, 13 May 1994 23:31:48 +1000 (from sob@hsdndev.harvard.edu) Date: Fri, 13 May 94 09:31:14 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405131331.AA09958@hsdndev.harvard.edu> To: bmanning@is.rice.edu, dcrocker@mordor.stanford.edu Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com, kasten@ftp.com Is it time to ask the IANA to shed some light on the topic of have we turned down address requests because of the IPv4 address space limit? In general it might help to get specific on a topic that is generating so much fun traffic. Scott From owner-Big-Internet@munnari.OZ.AU Sat May 14 01:32:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16764; Sat, 14 May 1994 00:22:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA19345; Sat, 14 May 1994 00:00:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA19340; Fri, 13 May 1994 23:57:56 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11471; Fri, 13 May 1994 22:03:42 +1000 (from lyman@BBN.COM) Message-Id: <9405131203.11471@munnari.oz.au> From: Lyman Chapin Subject: Re: Requirements To: craig:; Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <199405121940.MAA04464@aland.bbn.com> Date: Fri, 13 May 94 07:13:59 EDT Mail-System-Version: >To: Noel Chiappa >Cc: big-internet@munnari.oz.au >Subject: Re: Requirements >From: Craig Partridge >Date: Thu, 12 May 94 12:40:37 -0700 > > > We need IPng now. > > We don't need an interim design, which, as Jim Bound points out, leaves out > key capabilities, and thus forces us through a redo some years down the > road. > >Noel: > > Since you cited the mythical man month (and thus took us into the realm >of management :-)), let me point out that there's a problem with delaying a >decision too. > > IETF has very limited resources. In general, we're probably lucky to get >5% of the average attendees time. Of those, probably less than half the >attendees (probably less than a quarter) are working on IPng issues regularly. > > As long as we continue to delay the IPng decision, we're going to continue >to have those IPng folks fragmented. Some are working on CATNIP, some on >SIPP, some on TUBA, some on TURNIPP, etc. Often doing similar stuff (i.e., >how to put multicasting into each proposal, how to support flows in each >proposal, how to do mobility for each proposal). > > If we are to have any hope of deploying an IPng in the next several years, >we need to rapidly focus on one solution, so everyone can pull in roughly >the same direction, rather than being distracted by multiple proposals. > > My view is that the IPng decision this summer is only the first step in >a series. We'll decide on the protocol and with it a general philosophy. >Then we'll probably burn a test version over the next two years or so, >produce a revised spec, and that will be our standard. > > But if we wait for all the answers, or even 90% of them, before deciding, >we'll deliver the product far too late. Dave's right, we need an IPng decision >now, if only to make effective use of our manpower, and to allow us to deliver >an IPng solution on-time, when it is needed. > >Craig Craig, Your argument (with which I entirely agree) is so precisely the same as the argument that led to the IAB's abortive attempt two years ago to focus effort on a single IPng that I cannot help asking the obvious question: what is it that has changed during those two years that makes an "IPng decision" more likely to succeed this summer? I'm not trying to be deliberately naive; I can think of any number of possible reasons - - we have spent those two years developing a much better understanding of IPng requirements and how they can be met by proposals that account for transition and installed-base issues, so the decision can be based on "technical" rather than "political" arguments; - two years ago there was only one viable alternative to IPv4, and it did not provide a credible basis for focussing the efforts of the Internet community on a single solution; whereas today there are several alternatives, at least one of which is credible; and/or - the process that has been followed to reach the July 1994 decision point is sufficiently better than the process that was followed to reach the June 1992 decision point that the result will be acceptable to the community at large. There's no question that the process is being managed infinitely better this time around than last, to the extent that many people would say that there's no comparison to be made. I'm concerned not about making comparisons, but about the fact that we've set our expectations awfully high for Toronto. Are you convinced that the world has evolved enough to make those expectations realistic? - Lyman From owner-Big-Internet@munnari.OZ.AU Sat May 14 01:32:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16815; Sat, 14 May 1994 00:24:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA19360; Sat, 14 May 1994 00:02:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA19326; Fri, 13 May 1994 23:44:08 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02813; Fri, 13 May 1994 17:49:52 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14674(6)>; Fri, 13 May 1994 00:49:25 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 13 May 1994 00:49:18 -0700 To: sipp@sunroof2.eng.sun.com, big-internet@munnari.OZ.AU Cc: deering@parc.xerox.com Subject: addressing/locating/identifying models Date: Fri, 13 May 1994 00:49:13 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94May13.004918pdt.12171@skylark.parc.xerox.com> [Warning: if you don't like Noelgrams, you probably won't want to wade through this either.] There seems to have been some miscommunication or ambiguity about some of the possible addressing/locating/identifying models for IPng (and internet datagram protocols in general). I don't know if this will help, but here is my attempt to characterize/categorize the various approaches. I have prosaically labelled the various models Model A, Model B, etc. for now; perhaps adherents of particular models will offer more evocative names (such as Paul's "VANITY") that we can use in future to refer unambiguously to particular models (for example, I'd like to know what model or models people have in mind when they ask for "pure EIDs"). In any case, I would welcome additions/deletions/corrections to this list. In the following, hierarchical addresses are illustrated as a sequence of components, C1, ..., Cn-1, Cn, where C1 is the highest-order (top-level) component. The last component, Cn, is the "host part". The "subnet number" in an IPv4 address or the "area ID" in a TUBA NSAP address would then be component Cn-1. The illustrations are not intended to imply that the components are of fixed size (i.e., they may be of varying widths, and the widths may either be encoded in the addresses themselves, as with IPv4 Class A, B, and C network numbers, or externally by masks or bit counts, as with IPv4 subnet numbers). Nor are the illustrations intended to imply that the components are necessarily contiguous in the packet headers. The intention is to convey the semantics, not the syntax of addresses. An "internet entity" is here defined as an internet-layer source and/or sink of datagrams. Usually an internet-layer corresponds one-to-one with a "host", "node", or "system"; however, it is possible (though uncommon at present) to have more than one internet entity residing in the same physical device (e.g., multiple "logical hosts" in the same "physical host") or for an internet entity to be moved from one physical device to another. In the illustrations below, the parts labeled "locator" are those parts required to route a datagram to its destination internet entity. The parts labeled "identifier" are those that upper-layer protocols (e.g., transport) may treat as an unambiguous identifier of an internet entity. I distinguish between the case where the last component of an address can hold a "device ID" and the case where it cannot. For "device ID", read a number large enough to be globally unique (but which may, in fact, not be globally unique) that is hardwired or hand-configured into a device or an interface. The canonical example is an Ethernet or IEEE 802 address. This does not including addressing/locating/identifying models for multicast, broadcast, source routing, encapsulation, flows, or virtual circuits -- just plain ol' datagram unicast. I also have not listed all possible models, but only those that have, to my knowledge, been implemented or proposed. Here we go.... MODEL A <---------- locator ---------> +------+ +------+------+ | C1 | . . . | Cn-1 | Cn | +------+ +------+------+ <-------- identifier --------> Constraint: the Cn component is too small to hold a device ID. examples: - IPv4 address (n = 2 or more) - Appletalk address (n = 2) - SIPP global 64-bit address (n = 3 or more) MODEL B <---------------- locator ---------------> +------+ +------+------------------+ | C1 | . . . | Cn-1 | Cn | +------+ +------+------------------+ <-------------- identifier --------------> This differs from Model A in that the Cn component can hold a device ID. However, Cn is not required to be globally unique, but only unique within the topological cluster labelled C1, ..., Cn-1. Enables server-less autoconfiguration of addresses by appending device ID to overheard C1, ..., Cn-1 value. examples: - IPX address (n = 2) - TUBA NET, i.e., NSAP address minus SEL (n = 4 or more) MODEL C <---------------- locator ---------------> +------+ +------+------------------+ | C1 | . . . | Cn-1 | Cn | +------+ +------+------------------+ <------ identifier -------> In this model, the identifier is some number of trailing components, more than one but less than n, that form a globally-unique value. Server-less autoconfiguration possible if device ID really is globally unique. example: - SIPP address sequence, where final 64-bit element is a SIPP address containing a subnet number plus a globally- administered IEEE 802 unicast address. MODEL D <-------- locator --------> +------+------------------+ | Cn-1 | Cn | +------+------------------+ <------ identifier -------> Usable for communication only between nodes located in the same C1, ..., Cn-2 cluster, e.g., the same subnetted site. Server-less autoconfiguration possible. example: - SIPP local-use address containing a subnet number plus an IEEE 802 address. MODEL E ("VANITY") <------------------- locator ------------------> +------+ +------+------------------------+ | C1 | . . . | Cn-1 | Cn | +------+ +------+------------------------+ <------ identifier ------> In this model, the identifier is the last component of the address. Server-less autoconfiguration possible if device ID really is globally unique. examples: - XNS address (n = 2) - Pip FTIF chain + ID (n = 2 or more) - SIPP address sequence, where final 64-bit element is a SIPP address containing a globally-administered IEEE 802 unicast address. MODEL F <------- locator --------> +------------------------+ | Cn | +------------------------+ <------ identifier ------> Usable for communication only between nodes located in the same C1, ..., Cn-1 cluster, e.g., the same subnet or area. Server-less autoconfiguration possible. examples: - Pip ID, when used between nodes on the same link - SIPP local-use address containing an IEEE 802 address. MODEL G <---------- locator ---------> <------ identifier ------> +------+ +------+------+ +------------------------+ | C1 | . . . | Cn-1 | Cn | | I | +------+ +------+------+ +------------------------+ In this model, the locator does not include the identifier, and the Cn component is too small to hold a device ID. example: - TUNE over IPv4 or SIPP - SIPP adress sequence, where the elements preceding the last element are sufficient to route to a node - Nimrod? MODEL H <---------------- locator ---------------> <------ identifier ------> +------+ +------+------------------+ +------------------------+ | C1 | . . . | Cn-1 | Cn | | I | +------+ +------+------------------+ +------------------------+ Same as model G, except the Cn component can hold a device ID, so server-less autoconfiguration of the locator is possible. example: - TUNE over IPX, TUBA, or SIPP - SIPP adress sequence, where the elements preceding the last element are sufficient to route to a node - Nimrod? ---------------------------------------------------------------------------- Some observations about SIPP: SIPP supports all of these models, except model B. SIPP constrains the identifier to be exactly 64 bits. SIPP allows interoperation between nodes using any of the different supported models. From owner-Big-Internet@munnari.OZ.AU Sat May 14 02:09:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20905; Sat, 14 May 1994 02:09:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA19611; Sat, 14 May 1994 01:47:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA19571; Sat, 14 May 1994 01:39:38 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20475; Sat, 14 May 1994 02:01:22 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24407; Fri, 13 May 94 12:01:14 -0400 Date: Fri, 13 May 94 12:01:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405131601.AA24407@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators Cc: jnc@ginger.lcs.mit.edu From: Jon Crowcroft my viewpoint is that we already have an architecture. from you, steve deering, scott shenker & dave clark As the English would say, "rubbish"! :-) We have some thoughts on some of what the new architeture would look like, but there are many, many unanswered questions. What does the interaction between routing and resource allocation look like, for instance? Do we aggregate unrelated flows? How do we do real security; i.e. security which does not require each application to be individually secured (an approach that operating systems security work has revealed to be hopeless...)? Etc, etc, etc.... now we need to engineer it.... Lacking agreement on basic questions like "what is the service model that the new internetwork layer provides to its clients", it's hopeless to expect agreement on the engineering details of a design to implement that service model. Noel From owner-Big-Internet@munnari.OZ.AU Sat May 14 02:11:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20950; Sat, 14 May 1994 02:11:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA19626; Sat, 14 May 1994 01:49:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA19585; Sat, 14 May 1994 01:43:54 +1000 Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17099; Sat, 14 May 1994 00:37:37 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com (via wd40.ftp.com) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwpsd19428; Fri, 13 May 94 08:56:25 -0400 Received: from ftp.com by ftp.com ; Fri, 13 May 1994 08:50:10 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 13 May 1994 08:50:10 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA21736; Fri, 13 May 94 08:48:50 EDT Date: Fri, 13 May 94 08:48:50 EDT Message-Id: <9405131248.AA21736@mailserv-D.ftp.com> To: big-internet@munnari.OZ.AU Subject: Re: Requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 1620 One said... >>Three times in this note. Perhaps you are privy to information that the rest >>of us do not share. > >I don't think I have special access. I simply heard authors and reviewers >of RFC 1597 make the claim. One of the authors was the source of such a >request. Other than citing them, I can't speak for them. They have their >details. One suspects they read this list... > >Other than that, I've been hearing the same scuttlebut as everyone else, >and treated it with the same lack of concern. When one hears things as rumor, one should not repeat such rumors as if they were the gospel truth. One should, at the very least, preface one's statements with words to the effect of "Rumors I've heard indicate that..." If one hears a disturbing rumor, one should make every attempt to get authoritative information which will either prove or disprove the rumor. One would do a great disservice to the community if one were to use faulty or incorrect or misleading information to agitate the community into a particular course of action, especially if that action turns out to be detrimental to the community's good in light of the correct information. There have been people on this mailing list making derogatory comments about the ALE work. They make claims that it is based on faulty models and flawed methodology. This may well be true. To use 'scuttlebut' as the basis for making decisions is no better, and no more valid, and no more invalid. Do I need to remind one of the story of Chicken Little? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Sat May 14 02:12:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19225; Sat, 14 May 1994 01:32:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA19474; Sat, 14 May 1994 01:10:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA19460; Sat, 14 May 1994 00:56:31 +1000 From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18595; Sat, 14 May 1994 01:17:40 +1000 (from bound@zk3.dec.com) Received: from inet-gw-3.pa.dec.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27946 Sat, 14 May 1994 01:17:31 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA03097; Fri, 13 May 94 08:12:17 -0700 Received: by xirtlu.zk3.dec.com; id AA17553; Fri, 13 May 1994 11:12:10 -0400 Message-Id: <9405131512.AA17553@xirtlu.zk3.dec.com> To: Jon Crowcroft Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators In-Reply-To: Your message of "Fri, 13 May 94 08:33:43 BST." <9405130734.2161@munnari.oz.au> Date: Fri, 13 May 94 11:12:04 -0400 X-Mts: smtp >my viewpoint is that we already have an architecture. from you, steve >deering, scott shenker & dave clark >now we need to engineer it.... > jon Well said Jon. I agree. Lets just do it. /jim From owner-Big-Internet@munnari.OZ.AU Sat May 14 02:42:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22153; Sat, 14 May 1994 02:42:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19676; Sat, 14 May 1994 02:20:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA19634; Sat, 14 May 1994 01:49:47 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20961; Sat, 14 May 1994 02:11:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24480; Fri, 13 May 94 12:11:29 -0400 Date: Fri, 13 May 94 12:11:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405131611.AA24480@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: IPng Criteria doc Cc: jnc@ginger.lcs.mit.edu From: Dave Crocker The second pot is for stuff that is deemed essential for adoption, for additional functionality, etc. But it has the key feature of having general community consensus that we know what we are doing. ... The third pot is the wish-list. Reasonable and maybe important, but possibly research and definitely not critical path to the near-term. Aren't there intermediate things, though, where we *don't* have the kind of large-scale field experience to be sure we know what we are doing, but will be absolutely necessary within the 20+ year lifetime of this design? Noel From owner-Big-Internet@munnari.OZ.AU Sat May 14 02:44:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22215; Sat, 14 May 1994 02:44:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19691; Sat, 14 May 1994 02:22:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA19593; Sat, 14 May 1994 01:45:54 +1000 From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17840; Sat, 14 May 1994 00:57:05 +1000 (from bound@zk3.dec.com) Received: from [16.1.0.33] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27710 Sat, 14 May 1994 00:56:08 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA01277; Fri, 13 May 94 07:45:32 -0700 Received: by xirtlu.zk3.dec.com; id AA17058; Fri, 13 May 1994 10:45:23 -0400 Message-Id: <9405131445.AA17058@xirtlu.zk3.dec.com> To: bmanning@is.rice.edu (William Manning) Cc: postel@ISI.EDU, scottw@internic.net, big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: !! Denied !! In-Reply-To: Your message of "Fri, 13 May 94 08:42:53 CDT." <9405131342.AA04753@sabine.is.rice.edu> Date: Fri, 13 May 94 10:45:17 -0400 X-Mts: smtp Also......... ================================ Sorry to bother you, but there have been a number of threads that seem to point out that IPv$ requests have been denied. Some of the claims are intimated as coming from rfc1597 authors, others from consultants to large corporations with "new and unique" plans for IP addressing. (an IP address for each light switch and two in every SEGA(tm) cartridge) In an attempt to get new data points for the ALE effort, can you please document if there have been such requests that have been turned down? A brief list listing the number and the size of the requested block per request would be useful. =================================== If they were turned down for a Class A or B, but were given a Class C, then I think we should count that as they were given an IPv4 address. Hence, they were not turned down. thanks /jim From owner-Big-Internet@munnari.OZ.AU Sat May 14 02:45:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22303; Sat, 14 May 1994 02:45:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19706; Sat, 14 May 1994 02:23:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA19662; Sat, 14 May 1994 02:00:37 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21384; Sat, 14 May 1994 02:22:16 +1000 (from postel@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Fri, 13 May 1994 09:22:00 -0700 Date: Fri, 13 May 1994 09:22:00 -0700 From: postel@ISI.EDU (Jon Postel) Message-Id: <199405131622.AA16591@zephyr.isi.edu> To: dcrocker@mordor.stanford.edu Subject: Regarding claims of Address Requests being Denied Cc: big-internet@munnari.OZ.AU, rgmoskowitz-3@clis.chrysler.com, bound@zk3.dec.com, sob@hsdndev.harvard.edu, postel@ISI.EDU, scottw@internic.net, medin@nsipo.nasa.gov Dave: There are not really that many request for very large address blocks. The few requests for very large addresses allocations have been processed quite slowly with substantial back and forth about alternative plans. The requests for very large address blocks generally involve multi-level structured addresses which are very inefficient in actual address usage. Much of the discussion is aimed at increasing the address efficiency by making the allocation size closer to the number of end addresses actually used for computers. I don't think there are any cases where a persistent requestor did not get some address space (though usually less than the initial request). In a few cases the delays may have caused a requestors to give up, but i don't recall any. [Note that the delays are usually my fault, but sometime the requestors fault, and hardly ever the Internic's fault.] --jon. From owner-Big-Internet@munnari.OZ.AU Sat May 14 03:17:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23399; Sat, 14 May 1994 03:17:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19809; Sat, 14 May 1994 02:55:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA19778; Sat, 14 May 1994 02:37:31 +1000 Received: from netcom11.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22982; Sat, 14 May 1994 02:59:11 +1000 (from kck@netcom.com) Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id JAA20371; Fri, 13 May 1994 09:59:13 -0700 Date: Fri, 13 May 1994 09:59:13 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199405131659.JAA20371@netcom.com> To: lyman@BBN.COM Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU >There's no question that the process is being managed infinitely better >this time around than last, to the extent that many people would say >that there's no comparison to be made. I'm concerned not about making >comparisons, but about the fact that we've set our expectations awfully >high for Toronto. Are you convinced that the world has evolved enough >to make those expectations realistic? > >- Lyman This whole argument process sounds very much like the one that took place in deciding a network management architecture for the IETF. Maybe one of the IPng camps will back down so the process can have a chance of really moving on. -rf From owner-Big-Internet@munnari.OZ.AU Sat May 14 04:01:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19374; Sat, 14 May 1994 01:35:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA19489; Sat, 14 May 1994 01:13:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA19429; Sat, 14 May 1994 00:42:10 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18041; Sat, 14 May 1994 01:03:54 +1000 (from dcrocker@mordor.stanford.edu) Received: from Mordor.Stanford.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27598 Sat, 14 May 1994 00:51:25 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id HAA24679; Fri, 13 May 1994 07:46:16 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 May 1994 07:46:20 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU Noel, At 11:35 AM, Noel Chiappa wrote: >We don't need an interim design, which, as Jim Bound points out, leaves out >key capabilities, and thus forces us through a redo some years down the road. A pointed summary of your thread of notes is that a) we don't really have an urgent problem, and b) we should wait to choose/deploy IPng until we get a full list of enhancements done. a) You are very wrong. Further, we already have an agreement to make a decision in Toronto. As with any IETF working group process, your attempt to change that is highly out of order. We are supposed to be focusing on the Toronto milestone, not rehashing general philosophy. b) You are very wrong. We don't work that way in the IETF. You are concerned about the "philosophy" of each IPng candidate? I am particularly concerned about the philosophy of IETF architecture work itself. We do CORE, CLEAN, FUNCTIONAL work and then increment the capabilities. We do NOT wait until we have all the interesting, wonderful pieces done. That's the approach used by various other standards efforts. We have some history indicating which is more productive. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sat May 14 04:33:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26311; Sat, 14 May 1994 04:33:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA19963; Sat, 14 May 1994 04:11:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA19892; Sat, 14 May 1994 03:45:45 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25324; Sat, 14 May 1994 04:07:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25950; Fri, 13 May 94 14:07:26 -0400 Date: Fri, 13 May 94 14:07:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405131807.AA25950@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) > We don't need an interim design, which, as Jim Bound points out, leaves > out key capabilities, and thus forces us through a redo some years down > the road. A pointed summary of your thread of notes is that ... we should wait to choose/deploy IPng until we get a full list of enhancements done. Well, I'd put it "until we know more, including reasonable scale field experience, about some things which are going to be crucial to add to IPng", but you're not far off. we already have an agreement to make a decision in Toronto. As with any IETF working group process, your attempt to change that is highly out of order. Gee, I wasn't aware that the IETF ran on the "democratic centralism" principle. Lenin approves, I'm sure. We are supposed to be focusing on the Toronto milestone, not rehashing general philosophy. Among the choices which is supposed to be allowable is "none of the above". You are trying to make that choice "not acceptable". I disagree, and am stating my reasons for so thinking. I am particularly concerned about the philosophy of IETF architecture work itself. We do CORE, CLEAN, FUNCTIONAL work and then increment the capabilities. We do NOT wait until we have all the interesting, wonderful pieces done. That's the approach used by various other standards efforts. What I would like to see is absolutely not the OSI approach. The key difference I see with the OSI approach is that I claim we shouldn't try to write final specs for anything (be it mobility, resource allocation, or whatever) without having real, useful scale, experience. It is true that I want to see a more complex internetwork service model (and internetwork layer design to provide it), the pieces of which are developed in parallel. That doesn't mean I'm disagreeing with the "core and increment" model. (The whole sense of Nimrod is a simple core, with the complex stuff being "user specific", allowing interoperable experimentation and deployment of new stuff.) However, the core has to have a certain required minimal amount of functionality for this approach to work. May I remind everyone that we're going through this whole effort now since the IPv4 core was *not* the right thing, and could not be turned into the right thing via incremental extension. (If it can, why are we arguing about a new internetwork packet format?) Noel From owner-Big-Internet@munnari.OZ.AU Sat May 14 05:38:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20844; Sat, 14 May 1994 02:07:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA19588; Sat, 14 May 1994 01:45:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA19568; Sat, 14 May 1994 01:38:03 +1000 Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16588; Sat, 14 May 1994 00:18:59 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwpsd19437; Fri, 13 May 94 08:56:27 -0400 Received: from ftp.com by ftp.com ; Fri, 13 May 1994 08:50:11 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 13 May 1994 08:50:11 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA21739; Fri, 13 May 94 08:48:51 EDT Date: Fri, 13 May 94 08:48:51 EDT Message-Id: <9405131248.AA21739@mailserv-D.ftp.com> To: dcrocker@Mordor.Stanford.EDU Subject: Re: IPng Criteria doc From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 837 > The change that I suggest, in keeping with my earlier comments, is > to create 3 pots for the items. Your 'time frame' text suggests some > of the placements. An earlier version of the document divided the criteria into 'MUST' and 'SHOULD' with the 'MUST' stuff meaning that an IPNG has to do all the musts and would not be deployed, even if The Internet has already collapsed. To some degree, this mirrors your own split (though I recall that we had different 'allocations' of criteria). The current format was explicitly requested by the IPng area directors when they asked Craig and I to resurrect the work. I would be loathe to change the format without at least the approval of the IPng area directors, and the IPng directorate. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Sat May 14 05:39:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22421; Sat, 14 May 1994 02:47:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19732; Sat, 14 May 1994 02:25:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA19648; Sat, 14 May 1994 01:51:12 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21000; Sat, 14 May 1994 02:12:56 +1000 (from craig@aland.bbn.com) Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA02734 for big-internet@munnari.oz.au; Fri, 13 May 94 12:12:42 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA04719; Fri, 13 May 1994 09:10:37 -0700 Message-Id: <199405131610.JAA04719@aland.bbn.com> To: Lyman Chapin Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU From: Craig Partridge Date: Fri, 13 May 94 09:10:35 -0700 Sender: craig@aland.bbn.com Lyman: You've got a good question. And I think it is always possible that this summer's decision will unravel as did the one 2 years ago. However, broadly speaking I think all three of the points you make about differences between now and 2 years ago are applicable. So yes, I think there's hope for Toronto. In terms of concerns about Toronto, I have two major ones: * that there's less time than we'd like for the IPng directorate to do the final spit and polish work on its decision -- the process is getting a bit rushed. Deadlines, of course, are intended to have this effect but still... * we'll make the decision, it will be generally accepted, and everyone will go home, secure in the notion that IPng has been decided. Then we'll all wake up two years from now and realize that we didn't push hard enough and IPng has been stalled for two years. Craig From owner-Big-Internet@munnari.OZ.AU Sat May 14 05:39:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22543; Sat, 14 May 1994 02:49:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19747; Sat, 14 May 1994 02:27:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA19596; Sat, 14 May 1994 01:45:58 +1000 Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17217; Sat, 14 May 1994 00:41:46 +1000 (from perk@watson.ibm.com) Received: from watson.ibm.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwpsd18974; Fri, 13 May 94 08:53:54 -0400 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9661; Fri, 13 May 94 08:28:56 EDT Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 6666; Fri, 13 May 1994 08:29:03 EDT Received: from np2.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Fri, 13 May 94 08:29:02 EDT Received: by np2.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA19201; Fri, 13 May 1994 08:28:52 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9405131228.AA19201@np2.watson.ibm.com> To: big-internet@munnari.OZ.AU Subject: Mobility requirement Date: Fri, 13 May 94 08:28:52 -0500 It has been stated without proof that mobility is too hard, and is not a firm requirement for whatever protocol replaces IPv4. I dispute both of those notions. I suspect that the reason that mobility is thought of as "too hard", is that not everyone has already rushed out and bought wireless IP stations yet. However, it is already possible to do so, and the likely model for handling the mobility requirements looks a lot like the most obvious thing to do -- namely, put mobile hosts onto a network and make a router direct packets for that network. Of course, we are still involved with engineering the IETF solution, and thus it's not deployed at all. And, I very carefully emphasize that we don't know yet the _best_ solution -- but everyone seems to agree that we don't have to know the _best_ solution. We do know _a_ solution. But even so, it won't matter much if there isn't a real requirement for mobility out there (i.e, a market). Here, people can reasonably disagree. No one seems to dispute that the market for portable stations is huge. There are people who claim that portability is just about enough -- i.e, that one can be happy by getting IP service wherever you go, as long as you don't move very far once you are there. Since we don't have mobility now, I cannot _prove_ this isn't enough. And, I don't expect that this mailing list is the correct forum to debate the issue. However, if one _does_ believe that mobility will be desired or required by the owners of portable stations, then the projected sales figures that show portable computers dominating the market in the next few years (before 2000) should spark interest in solving the problem! The market is coming, the solutions (for IPv4) are being IETFed right now, there is already commercial software available... I think mobility should be viewed differently than one might surmise from the previous notes to this list. Charlie P. From owner-Big-Internet@munnari.OZ.AU Sat May 14 05:39:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22649; Sat, 14 May 1994 02:51:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19762; Sat, 14 May 1994 02:29:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA19640; Sat, 14 May 1994 01:50:29 +1000 From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18910; Sat, 14 May 1994 01:24:38 +1000 (from bound@zk3.dec.com) Received: from inet-gw-3.pa.dec.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27950 Sat, 14 May 1994 01:17:55 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA02955; Fri, 13 May 94 08:10:15 -0700 Received: by xirtlu.zk3.dec.com; id AA17494; Fri, 13 May 1994 11:10:05 -0400 Message-Id: <9405131510.AA17494@xirtlu.zk3.dec.com> To: Dave Crocker Cc: bound@zk3.dec.com, kasten@ftp.com, big-internet@munnari.OZ.AU Subject: Re: Requirements In-Reply-To: Your message of "Thu, 12 May 94 15:23:01 PDT." <199405122223.PAA20745@Mordor.Stanford.EDU> Date: Fri, 13 May 94 11:09:59 -0400 X-Mts: smtp Dave, A few comments of agreement and then I am off this thread I think we agree on the urgency but not why. Thats OK with me. I think the ALE group can rebutt or agree with you on the patterns they are looking at presently. I am not qualified to enter this discussion on that topic any further. But I am going with what they said with blind faith and work on that which I cannot accept with blind faith for which I do have technical expertise (wasn't blind faith a great band). I definitely will not enter the TUBA vs other IPngs thread. >My point is that we are at or past the point of jerking ourselves around by >adding yet-more spiffy features to the requirements list. We have to >close that down and make some choices and then deploy this stuff. Every >clever new idea now is going to serve to defer the deployment and distract >us from solving the core, immediate problems we have been attending to >for two years. As you and I both know, this is just the sort of situation >that keeps a product from being delivered in a reasonable timeframe. Yes your right on here. I just don't want to see inadequate products delivered to the market or have to build them that way cause the specs are incomplete or not congruent. Also I don't want to ignore the future when I know its going to hit me in the back of the head. Like payload length or fragmentation or translation affects to network topology ... etc. etc.. >Jim, if I understood this line of comment, you are lobbying for careful >analysis of effects and careful design of the details required for the >transition. Sounds good to me. Yes always have been since I got this job. Why? Because 80% of what I say I want is what my customers want. 20% is me maybe loosing control. In everything I say there is a customer from today or the past that drives my beliefs not pure science. Thats why I have worked and provided review to all IPng transition proposals. I think transition is the most important part of IPng. Back to work guy, /jim From owner-Big-Internet@munnari.OZ.AU Sat May 14 05:40:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23511; Sat, 14 May 1994 03:20:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19824; Sat, 14 May 1994 02:58:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA19795; Sat, 14 May 1994 02:46:48 +1000 Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23130; Sat, 14 May 1994 03:08:19 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA03002 (5.65c/IDA-1.4.4nsd for ); Fri, 13 May 1994 10:08:13 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA20169 (5.65c/IDA-1.4.4-910725 for ); Fri, 13 May 1994 10:08:12 -0700 Message-Id: <199405131708.AA20169@remmel.NSD.3Com.COM> To: big-internet@munnari.OZ.AU Subject: Do we have an architecture? In-Reply-To: Your message of "Fri, 13 May 94 08:33:43 BST." <9405130734.2161@munnari.oz.au> Date: Fri, 13 May 94 10:08:11 -0700 From: tracym@NSD.3Com.COM Jon wrote: > my viewpoint is that we already have an architecture. from you, steve > deering, scott shenker & dave clark > > now we need to engineer it.... At the IPng requirements BOF, Dave Clark stood up and very briefly suggested that we haven't gone back far enough in our requirements efforts. He noted one of the requirements of machine-machine interconnection that were chosen as fundamental (e.g. two machines could talk without a server helping them), from which the rest of TCP-IP has depended. Almost noone seemed to pay attention. Should we take his suggestion?: Two machines can talk without a server. Two machines can talk simply by plugging into the same wire (no manual configuration, except possibly for a name, is needed) One machine can talk with another anywhere, starting only from the knowledge of the other's registered name. A new machine can be plugged into an operating network without prior configuration. The previous behavior can be inhibitted so that some form of configuration is required, for control(security, accounting, ??) purposes. New functions can be added to the base protocol without disrupting the existing hosts, infrastructure, and operations. [strict in what you send, liberal in what you receive] (CLNP got this one partly wrong) etc. These are quickly off the top of my head. I've got to get back to work. Have fun. Regards, Tracy From owner-Big-Internet@munnari.OZ.AU Sat May 14 05:40:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23652; Sat, 14 May 1994 03:21:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19839; Sat, 14 May 1994 02:59:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA19792; Sat, 14 May 1994 02:46:17 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23126; Sat, 14 May 1994 03:07:59 +1000 (from craig@aland.bbn.com) Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA14864 for big-internet@munnari.oz.au; Fri, 13 May 94 13:07:47 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA05021; Fri, 13 May 1994 10:05:51 -0700 Message-Id: <199405131705.KAA05021@aland.bbn.com> To: jnc@lcs.mit.edu Cc: big-internet@munnari.OZ.AU Subject: re: Requirements From: Craig Partridge Date: Fri, 13 May 94 10:05:50 -0700 Sender: craig@aland.bbn.com > My view is that the IPng decision this summer is only the first step in > a series. We'll decide on the protocol and with it a general philosophy. > > Oh, balderdash. None of the proposal has what I would dignify as a "general > philosophy" (unless you count "ISO" and "not-ISO"). Noel: I'm afraid I disagree on this point. For instance, I believe it is safe to say that there were three major philosophical points behind SIP: * keep the packet format word-aligned and as minimalist as possible * keep the fast forwarding path fast * the packet header addresses the next entity that has to do something other than fast forwarding (i.e., options are encapsulated, and you send the datagram to the next router/host that actually has to examine the options) * transition from IPv4 should be straightforward Those are enough points that its possible (though not always easy), when faced with the question of how do we support feature X, to determine whether feature X is supported by a header field or option. There are similar architectural ideas behind CLNP (and I assume, CATNIP which I don't remember well enough from my quick read). I happen to think the CLNP architecture leaves one too many choices about how to solve a particular problem but others like that flexibility. There's no routing protocol architecture there, but that's, in my view, right. We've changed routing protocols several times already, and will change them again. We don't want to change the header format each time... Craig From owner-Big-Internet@munnari.OZ.AU Sat May 14 05:41:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26008; Sat, 14 May 1994 04:27:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA19922; Sat, 14 May 1994 04:05:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA19889; Sat, 14 May 1994 03:40:22 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20290; Sat, 14 May 1994 01:55:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24361; Fri, 13 May 94 11:55:06 -0400 Date: Fri, 13 May 94 11:55:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405131555.AA24361@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) >> We are turning people down for numbers. That is the reason that RFC1597 >> was written. ... >> We are turning folks down. THAT is what motivated 1597, according >> to some of the authors. > Perhaps you are privy to information that the rest of us do not share. I simply heard authors and reviewers of RFC 1597 make the claim. One of the authors was the source of such a request. Your claim above interested me, since they didn't seem to match the stated intentions of the authors in the document itself. So, I called several of them up, to ask them what was really the motivation behind RFC-1597. What I heard from them is more complex than you are indicating. It's true that the IANA is more cautious about handing out address space (and perhaps even a little more cautious than warranted; one person I talked to had requests for a total of 5 class B's turned into 4, but 20% savings aren't going to keep us going for long). Getting larger blocks of space does take a certain amount of work. However, it's more complex than simply "we couldn't get space". For example, many sites *don't want* global connectivity, and *want* firewalls. Such sites don't need globally unique numbers, and in fact, *prefer* non-globally unique ones (since private PPP links can't create unguarded "back doors"). I believe that the introductory sections of RFC-1597 give the motivation quite well; it's an attempt to reduce the pressure on the IPv4 address space ("using these methods, significant savings can be made on allocating IP address space"). It is thus similar to the way in which CIDR reduced the pressure on class B network numbers. Noel From owner-Big-Internet@munnari.OZ.AU Sat May 14 05:41:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26277; Sat, 14 May 1994 04:32:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA19948; Sat, 14 May 1994 04:10:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA19895; Sat, 14 May 1994 03:46:56 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25355; Sat, 14 May 1994 04:08:39 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA05923; Fri, 13 May 1994 20:08:24 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA01663; Fri, 13 May 1994 20:08:24 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405131808.AA01663@dxcoms.cern.ch> Subject: Re: Do we have an architecture? To: tracym@NSD.3Com.COM Date: Fri, 13 May 1994 20:08:24 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199405131708.AA20169@remmel.NSD.3Com.COM> from "tracym@NSD.3Com.COM" at May 13, 94 10:08:11 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2249 Tracy, It's dangerous to disagree with Dave Clark of course, but I am very happy that the IPng requirements draft (when last seen) does not require that two systems alone on a wire must be able to talk without a third party. ARP is a bad design; the fact that Ethernet allows trivial broadcast (and multicast) has led to numerous similar bad designs. (This doesn't include IP multicast: multicast applications need multicast.) See my numerous past flames in the IP-ATM archives for rationale. ES-IS is a good design; the RFC 1577 ARP server is a good design. As for plug and play: it's an optional IPng requirement. Many sites won't want plug and play, for managerial or security reasons. Brian >--------- Text sent by tracym@NSD.3Com.COM follows: > > > Jon wrote: > > my viewpoint is that we already have an architecture. from you, steve > > deering, scott shenker & dave clark > > > > now we need to engineer it.... > > At the IPng requirements BOF, Dave Clark stood up and very briefly > suggested that we haven't gone back far enough in our requirements > efforts. He noted one of the requirements of machine-machine > interconnection that were chosen as fundamental (e.g. two machines > could talk without a server helping them), from which the rest of > TCP-IP has depended. Almost noone seemed to pay attention. > > Should we take his suggestion?: > > Two machines can talk without a server. > > Two machines can talk simply by plugging into the same wire (no manual > configuration, except possibly for a name, is needed) > > One machine can talk with another anywhere, starting only from the > knowledge of the other's registered name. > > A new machine can be plugged into an operating network without prior > configuration. > > The previous behavior can be inhibitted so that some form of > configuration is required, for control(security, accounting, ??) > purposes. > > New functions can be added to the base protocol without disrupting > the existing hosts, infrastructure, and operations. > > [strict in what you send, liberal in what you receive] (CLNP got this > one partly wrong) > > etc. > > These are quickly off the top of my head. I've got to get back to > work. Have fun. > > Regards, > > Tracy > From owner-Big-Internet@munnari.OZ.AU Sat May 14 09:01:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29540; Sat, 14 May 1994 06:12:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA20154; Sat, 14 May 1994 05:50:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA20030; Sat, 14 May 1994 05:15:37 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21339; Sat, 14 May 1994 02:19:14 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405131619.21339@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 13 May 1994 17:18:47 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators In-Reply-To: Your message of "Fri, 13 May 94 12:01:14 EDT." <9405131601.AA24407@ginger.lcs.mit.edu> Date: Fri, 13 May 94 17:18:46 +0100 From: Jon Crowcroft > my viewpoint is that we already have an architecture. from you, steve > deering, scott shenker & dave clark >As the English would say, "rubbish"! :-) as we also say, thanks very much for your constructive response >We have some thoughts on some of what the new architeture would look like, but >there are many, many unanswered questions. What does the interaction between >routing and resource allocation look like, for instance? we have answers for that > Do we aggregate unrelated flows? sometimes, some places, other times not. whats the problem if you have the hooks for both? >How do we do real security; i.e. security which does not >require each application to be individually secured (an approach that >operating systems security work has revealed to be hopeless...)? Etc, etc, >etc.... recursive application of multi-level security is not that hard, but i have negative interest in it... >Lacking agreement on basic questions like "what is the service model that the >new internetwork layer provides to its clients", it's hopeless to expect >agreement on the engineering details of a design to implement that service >model. well you may lack agreement, but i havnt seen anyone disagree with the CSZ model effectively. jon From owner-Big-Internet@munnari.OZ.AU Sat May 14 09:06:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29764; Sat, 14 May 1994 06:17:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA20187; Sat, 14 May 1994 05:55:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA20033; Sat, 14 May 1994 05:15:51 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25808; Sat, 14 May 1994 04:18:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26091; Fri, 13 May 94 14:18:36 -0400 Date: Fri, 13 May 94 14:18:36 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405131818.AA26091@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: FORMAL REQUEST : SIPP EIDs and Locators Cc: jnc@ginger.lcs.mit.edu From: Jon Crowcroft >> my viewpoint is that we already have an architecture. from you, steve >> deering, scott shenker & dave clark > We have some thoughts on some of what the new architeture would look > like, but there are many, many unanswered questions. I didn't mean to give an exhaustive list of problems, but to indicate that I thought your statment wasn't accurate (especially since I was one of the authorities you quoted). > What does the interaction between routing and resource allocation look > like, for instance? we have answers for that This is not the place to discuss this, but I doubt the RSVP camp and the Nimrod camp see eye-to-eye on what those answers are, and without field trials, we've yet to see whether those answers actually work. > Do we aggregate unrelated flows? sometimes, some places, other times not. whats the problem if you have the hooks for both? Second-system disease; a.k.a. kitchen sink syndrome. > Lacking agreement on basic questions like "what is the service model > that the new internetwork layer provides to its clients", it's hopeless > to expect agreement on the engineering details of a design to implement > that service model. well you may lack agreement, but i havnt seen anyone disagree with the CSZ model effectively. By service model, I meant something more inclusive than just the Integrated Services QOS stuff, I meant the entire service available (including routing) from the internetwork layer. And, anyway, don't I recall that one of the people who is most against buying into the CSZ model is Steve Deering, the SIPP architect? Doesn't sounds good to me.... Noel From owner-Big-Internet@munnari.OZ.AU Sat May 14 09:35:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01003; Sat, 14 May 1994 06:47:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA20352; Sat, 14 May 1994 06:25:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA20231; Sat, 14 May 1994 05:59:36 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29952; Sat, 14 May 1994 06:21:15 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-28.dialip.mich.net (pm002-28.dialip.mich.net [35.1.48.109]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA12452; Fri, 13 May 1994 16:21:08 -0400 Date: Fri, 13 May 94 15:18:30 GMT From: "William Allen Simpson" Message-Id: <2385.bill.simpson@um.cc.umich.edu> To: sipp@sunroof.eng.sun.com Cc: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: 64K (was tangential to Re: FORMAL REQUEST : SIPP EIDs and Locators ) Gentlefolk, I understand that as the front-runner with the most features, SIPP is now under vigorous scrutiny. But this should be on the big-internet list, not the SIPP list. I have moved it. > From: yakov@watson.ibm.com > >Most packets are still less than 600 bytes. > > I think that expecting a host to pump Gbits/sec - Gbytes/sec > with average packet size of 600 bytes may introduce a bit > of overhead. > > >So that's almost 50 years before you seriously bump into 64K as a ceiling. > > HIPP MTU *today* is 64K. So is Fibre Channel MTU. > > And, by the way, it is limited only by the max size of IPv4 packet. > > Yakov. > I am surprised at the number of you who have forgotten their basic communication theory. I can't say that it was one of my strong points in school, so correct me as to detail, but as I remember it, the length of the packet that can be sent is not governed by the size of some header fields, but by the size of the checksum protecting it. For instance, a CCITT 16-bit CRC can protect a packet of up to 4K bits, assuming no more than 3 bits in error. The 32-bit CRC can protect a packet of up to 11K bits, assuming no more than 3 bits in error. So, for your 64K packets, please detail the 1K-bit CRC that you are using. How is your research coming on the 4K CRCs for bigger packets? Also, the preliminary data that Craig Partridge released to end2end, using small 512 byte packets, shows an undetected (by the AAL5 32-bit CRC) error-rate of 1.6 * 10**-10. That seems small, until you remember that your target speeds are at 10**-9 bps. An undetected error over every ATM link every 10 seconds is a lot of errors! What happens when the packets are 100 times as big, and they aren't within the Hamming distance of the CRC. Catastrophy! Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sat May 14 09:59:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02230; Sat, 14 May 1994 07:22:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA20401; Sat, 14 May 1994 07:00:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA20379; Sat, 14 May 1994 06:42:30 +1000 Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01670; Sat, 14 May 1994 07:04:06 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA11014 (5.65c/IDA-1.4.4nsd for ); Fri, 13 May 1994 14:04:01 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA20693 (5.65c/IDA-1.4.4-910725); Fri, 13 May 1994 14:04:00 -0700 Message-Id: <199405132104.AA20693@remmel.NSD.3Com.COM> To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Cc: big-internet@munnari.OZ.AU Subject: Re: Do we have an architecture? In-Reply-To: Your message of "Fri, 13 May 94 20:08:24 +0200." <9405131808.AA01663@dxcoms.cern.ch> Date: Fri, 13 May 94 14:03:59 -0700 From: tracym@NSD.3Com.COM Brian, [To be fair to Dave, I believe that requirement for no server wasn't concerned with how two machines found out about each other's addresses. I suggested the "two on a wire" version.] > It's dangerous to disagree with Dave Clark of course, but I am very > happy that the IPng requirements draft (when last seen) does not require > that two systems alone on a wire must be able to talk without a third > party. Religion: I am deeply indebted to Apple for allowing me to (almost) plug and play with Macs and a printer at home. I'll be unhappy if I can't do the same thing with the next generation of stuff I play with when I retire. I had to do NOTHING except plug in the printer and choose it (default name of DeskWriter550c on the net). The Macs did require some configuration for file access: I had to say "do it", and list the names of the machines with which sharing was ok. Pretty easy. > ARP is a bad design; the fact that Ethernet allows trivial > broadcast (and multicast) has led to numerous similar bad designs. This is religion. ARP was absolutely the perfect solution when it was designed. Simple, clean, and MULTI-PROTOCOL too! It doesn't scale well. ES-IS is certainly better(I think you can get by without an IS). > As for plug and play: it's an optional IPng requirement. Many sites > won't want plug and play, for managerial or security reasons. No disagreement on the need to turn (some or all of) it off. It may be optional whether to use it, on a site-by-site basis, but I believe it's a MUST requirement for IPng (ref Appletalk above). Perhaps we can get closer toward agreement if we discuss the scope of plug and play. On a local wire there's nothing you can really do to stop two hosts from talking between themselves. If your site forces the use of an address resolution server, or even authentication, for all communication between *properly installed* hosts, then fine. The really interesting case that you would like to prevent is plugging a new unknown host into your network and simply giving it (or allowing it to choose) a name, address, and full access to both internal and external resources. On this we agree completely. I've simply been arguing that the scope of application for IPng must be kept broad: from local to global, slow to fast, secure to free... Regards, Tracy From owner-Big-Internet@munnari.OZ.AU Sat May 14 11:57:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05247; Sat, 14 May 1994 08:32:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA20501; Sat, 14 May 1994 08:10:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA20481; Sat, 14 May 1994 07:56:37 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04604; Sat, 14 May 1994 08:18:17 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA11139; Fri, 13 May 94 16:23:44 MDT Received: from [130.57.64.152] by WC.Novell.COM (4.1/SMI-4.1) id AA00336; Fri, 13 May 94 15:16:23 PDT Date: Fri, 13 May 94 15:16:22 PDT Message-Id: <9405132216.AA00336@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) From: Greg Minshall Subject: Re: Do we have an architecture? Cc: big-internet@munnari.OZ.AU Brian, >It's dangerous to disagree with Dave Clark of course, but I am very >happy that the IPng requirements draft (when last seen) does not require >that two systems alone on a wire must be able to talk without a third >party. ARP is a bad design; the fact that Ethernet allows trivial >broadcast (and multicast) has led to numerous similar bad designs. >(This doesn't include IP multicast: multicast applications need multicast.) >See my numerous past flames in the IP-ATM archives for rationale. >ES-IS is a good design; the RFC 1577 ARP server is a good design. I *think* that ES-IS allows two systems on a wire to talk without a third party. >As for plug and play: it's an optional IPng requirement. Many sites >won't want plug and play, for managerial or security reasons. *I* think plug and play is required, but it is also required that an *infrastructure* be able to turn off plug and play. This may mean "you can plug and play all you want on that wire, but if you want to get off that wire, you're going to have to come and talk to ME first!". Or, there may even be a requirement to keep plug 'n' players from talking to other "configured" hosts on a wire. Greg From owner-Big-Internet@munnari.OZ.AU Sat May 14 11:58:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05395; Sat, 14 May 1994 08:35:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA20516; Sat, 14 May 1994 08:13:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA20487; Sat, 14 May 1994 08:01:19 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04862; Sat, 14 May 1994 08:22:58 +1000 (from craig@aland.bbn.com) Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA19661 for big-internet@munnari.oz.au; Fri, 13 May 94 18:21:34 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id PAA05679; Fri, 13 May 1994 15:19:40 -0700 Message-Id: <199405132219.PAA05679@aland.bbn.com> To: tracym@NSD.3Com.COM Cc: bsimpson@morningstar.com, sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 64K In-Reply-To: Your message of Fri, 13 May 94 15:06:15 -0700. <199405132206.AA20856@remmel.NSD.3Com.COM> From: Craig Partridge Date: Fri, 13 May 94 15:19:39 -0700 Sender: craig@aland.bbn.com > Also, the preliminary data that Craig Partridge released to end2end, > using small 512 byte packets, shows an undetected (by the AAL5 32-bit > CRC) error-rate of 1.6 * 10**-10. That seems small, until you remember > that your target speeds are at 10**-9 bps. An undetected error over > every ATM link every 10 seconds is a lot of errors! [Shouldn't Craig be presenting this, with a little more context.] Very briefly, since the work is preliminary, Jim Hughes and I are looking at AAL5's error behavior in the case of what is called a packet splice. A packet splice is a case in which the right number of cells is lost among two AAL5 packets such that, on quick inspection, the arriving cells appear to be one packet. (Consider two packets of 5 cells each: A1 A2 A3 A4 A5 and B1 B2 B3 B4 B5 and imagine that A3 A4 A5 B1 and B2 are lost. A1 A2 B3 B4 B5 will have the right AAL5 length and a valid IP header). The question is how often will the AAL5 CRC and TCP checksum catch such errors. The number Bill mentions are the chance the AAL5 CRC will fail to catch the splice (given that a splice occurred). The TCP checksum appears to add about two orders of magnitude additional protection. HOWEVER (big warning sign), this is the result of one test run of about 10**12 splices. We're still working on setting up several more test runs. This warning is especially true for the TCP checksum (since the 1 error in 100 let through result is surprising). Keep in mind too, this work only applies to packet splice situations (bit errors, etc., may be another matter entirely). Craig From owner-Big-Internet@munnari.OZ.AU Sat May 14 11:59:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05440; Sat, 14 May 1994 08:37:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA20531; Sat, 14 May 1994 08:15:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA20467; Sat, 14 May 1994 07:44:39 +1000 Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04035; Sat, 14 May 1994 08:06:22 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA12699 (5.65c/IDA-1.4.4nsd for ); Fri, 13 May 1994 15:06:18 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA20856 (5.65c/IDA-1.4.4-910725); Fri, 13 May 1994 15:06:16 -0700 Message-Id: <199405132206.AA20856@remmel.NSD.3Com.COM> To: bsimpson@morningstar.com Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 64K In-Reply-To: Your message of "Fri, 13 May 94 15:18:30 GMT." <2385.bill.simpson@um.cc.umich.edu> Date: Fri, 13 May 94 15:06:15 -0700 From: tracym@NSD.3Com.COM Bill, I think you're mixing the layers, and making assumptions about requirements that are rooted in yesterday/today, rather than today/tomorrow. > I am surprised at the number of you who have forgotten their basic > communication theory. I can't say that it was one of my strong points > in school, so correct me as to detail, but as I remember it, the length > of the packet that can be sent is not governed by the size of some > header fields, but by the size of the checksum protecting it. This makes assumptions about lower layers: perhaps that the packet is sent as a monolithic unit by the underlying transmission service, with a single crc to protect it. Why to you think this will be the only approach for the next 20 years? ATM, like it or not, has already broken the model of the contiguous frame: perhaps AALng will reassemble a bunch of AAL5 frames, each with a relatively strong CRC, below the IPng layer. > Also, the preliminary data that Craig Partridge released to end2end, > using small 512 byte packets, shows an undetected (by the AAL5 32-bit > CRC) error-rate of 1.6 * 10**-10. That seems small, until you remember > that your target speeds are at 10**-9 bps. An undetected error over > every ATM link every 10 seconds is a lot of errors! [Shouldn't Craig be presenting this, with a little more context.] > What happens when the packets are 100 times as big, and they aren't > within the Hamming distance of the CRC. Catastrophy! This assumes AAL5 or similar. Other solutions/mechanisms are likely in the future. The biggest flaw with your concerns is the assumption that all applications want the same degree of error protection. We are barely on the edge of gigabit applications, and have little idea of what may come. Perhaps uncompressed, 24-bit color, HDTV video streams will be convenient to send as 3mbyte packets, 60 times a second. It'll only need ~1.6 gigabits/sec. No problem in 10 years. A couple of errors per frame and a dropped frame every 10 seconds probably might be perfectly acceptable. Cheers, Tracy From owner-Big-Internet@munnari.OZ.AU Sat May 14 12:06:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05471; Sat, 14 May 1994 08:38:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA20546; Sat, 14 May 1994 08:16:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA20484; Sat, 14 May 1994 08:01:09 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04856; Sat, 14 May 1994 08:22:53 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id PAA27259; Fri, 13 May 1994 15:22:36 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 May 1994 15:22:41 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Noel, At 11:07 AM 5/13/94, Noel Chiappa wrote: >Well, I'd put it "until we know more, including reasonable scale field Great. You've just ensured a deadly embrace. No decision until major deployment. No significant deployment until a decision. In case you hadn't noticed, IPng has proved to be too basic for the approach you suggest. We did substantial, multi-implementation demos and the response seemd to be 'so what'? Noel, there is NO intermediate step. We need to choose among the current alternatives, start deploying it with its core capabilities, and then continue down the usual IETF path of incremental enhancement. >Gee, I wasn't aware that the IETF ran on the "democratic centralism" >principle. Lenin approves, I'm sure. You weren't aware of the usual IETF practise of balancing the need for open and fair debate with the need for making forward progress? Curious. I thought you were. > We are supposed to be focusing on the Toronto milestone, not rehashing > general philosophy. > >Among the choices which is supposed to be allowable is "none of the above". Wrong. I pointedly suggested at the IPng open directorate meetin that that was specifically NOT a viable option. My sense was basic agreement among the group, but will pointedly ask this list to comment. What are the acceptable "recommendations" by the IPng area directors/directorate? Bradner outlined a theorectially complete range; i.e., he went through the academic exercise of listing possibilities. >From that, I believe that valid choices for Toronto are: 1. Name a specific choice from the contenders and declare it adequate. 2. Name a specific choice from the contenders and list minor, immediate changes that are needed prior to deployment 3. Name a specific choice from the contenders and maybe list minor, immediate changes that are needed, but also name longer-term enhancements that are required, albeit NOT prior to initial deployment. >May I remind everyone that we're going through this whole effort now since the >IPv4 core was *not* the right thing, and could not be turned into the right Slight misinterpretation, Noel. IPv4 was very much fine for almost 20 years (or at least 12 years of production use. It was NEVER intended for anything close to the use it has gotten. To repeat: We don't do long-term work in this community. We do short-term work that often bears fruit for long-term. If you require us to do really long-term work, you are almost certainly requiring that we deliver nothing useful in the nearterm and probably nothing useful in the longterm. Really. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sat May 14 13:12:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14669; Sat, 14 May 1994 13:12:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA21145; Sat, 14 May 1994 12:50:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21120; Sat, 14 May 1994 12:39:06 +1000 Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07059; Sat, 14 May 1994 09:32:27 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id QAA04270; Fri, 13 May 1994 16:32:17 -0700 Date: Fri, 13 May 1994 16:32:17 -0700 From: Dave Katz Message-Id: <199405132332.QAA04270@feta.cisco.com> To: Greg_Minshall@Novell.COM Cc: brian@dxcoms.cern.ch, big-internet@munnari.OZ.AU In-Reply-To: Greg Minshall's message of Fri, 13 May 94 15:16:22 PDT <9405132216.AA00336@WC.Novell.COM> Subject: Do we have an architecture? I *think* that ES-IS allows two systems on a wire to talk without a third party. Yes, it does. From owner-Big-Internet@munnari.OZ.AU Sat May 14 13:14:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14719; Sat, 14 May 1994 13:14:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA21161; Sat, 14 May 1994 12:52:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21137; Sat, 14 May 1994 12:49:19 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13015; Sat, 14 May 1994 12:33:09 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29030; Fri, 13 May 94 22:33:03 -0400 Date: Fri, 13 May 94 22:33:03 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405140233.AA29030@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Spin control... Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" as the front-runner with the most features Gee, Bill, you're just about ready to go to Washington as a campaign PR type; excellent wrist action on the spin control there. :-) Noel From owner-Big-Internet@munnari.OZ.AU Sat May 14 13:16:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14781; Sat, 14 May 1994 13:16:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA21179; Sat, 14 May 1994 12:54:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21140; Sat, 14 May 1994 12:49:26 +1000 Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13149; Sat, 14 May 1994 12:34:32 +1000 (from sob@hsdndev.harvard.edu) Date: Fri, 13 May 94 22:34:26 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405140234.AA16181@hsdndev.harvard.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements > I pointedly suggested at the IPng open directorate meeting that was > specifically NOT a viable option. My sense was basic agreement among the > group, but will pointedly ask this list to comment. The IPng area directors reserve the right to make the proper choice among the options outlined in our presentation during the Houston IETF meeting. Allison and Scott From owner-Big-Internet@munnari.OZ.AU Sat May 14 13:18:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14817; Sat, 14 May 1994 13:18:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA21205; Sat, 14 May 1994 12:56:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21123; Sat, 14 May 1994 12:39:21 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06785; Sat, 14 May 1994 09:26:20 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA27608; Fri, 13 May 1994 16:25:29 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 May 1994 16:25:36 -0700 To: bound@zk3.dec.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: !! Denied !! Cc: bmanning@is.rice.edu (William Manning), postel@ISI.EDU, scottw@internic.net, big-internet@munnari.OZ.AU, bound@zk3.dec.com At 7:45 AM 5/13/94, bound@zk3.dec.com wrote: >If they were turned down for a Class A or B, but were given a Class C, >then I think we should count that as they were given an IPv4 address. >Hence, they were not turned down. well... There are those that choose to use private (not registered globally) IPv4 addresses. But there are those that feel forced into it because they cannot get enough address space. If they get a Class C but also have to use private address space, they've been turned down. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sat May 14 13:19:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14866; Sat, 14 May 1994 13:19:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA21220; Sat, 14 May 1994 12:57:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21114; Sat, 14 May 1994 12:36:12 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09428; Sat, 14 May 1994 10:42:46 +1000 (from smart@mel.dit.csiro.au) Received: from koel.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA03116 (5.65c/IDA-1.4.4/DIT-1.3 for big-internet@munnari.oz.au); Sat, 14 May 1994 10:42:54 +1000 Message-Id: <199405140042.AA03116@shark.mel.dit.csiro.au> To: big-internet@munnari.OZ.AU Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Fri, 13 May 1994 00:49:13 PDT." <94May13.004918pdt.12171@skylark.parc.xerox.com> Date: Sat, 14 May 1994 10:42:35 +1000 From: Bob Smart Steve Deering wrote: > [Warning: if you don't like Noelgrams, you probably won't want to wade > through this either.] On the contrary everyone should read it. It is comprehensive without being couched in difficult generalities. I hope the responses are done in a similar style. The subject of address allocation requests has come up. It reminded of a recent time when Australia's NSAP allocation people offered to sell us a block of NSAPs. Our organization debated for a while whether to get a block that was insanely large or whether we should pay extra for one of the larger slices that would let us address every atom in the organization :-). Instead we just forgot the whole thing... One advantage of the separate EID approach is that EIDs don't have to be allocated in power-of-2 boundaries and organizations can go back for more without worrying about contiguity. So there is no need for companies to hoard. Then you can do the internal organization addresses (used for routing) with 0s (or equivalent) in the external part of the address. The boundary routers can fill in the external part of the source address of departing packets (based on the provider chosen) without affecting the identifiers used by the transport layer. As the organizations network gets larger it needs to obtain wider address allocations from the providers but since no internal renumbering is needed when this happens there is no need for organizations to preplan large address spaces. It is really nice that SIPP can support this sort of thing (though in a slightly different way to that described above). However I strongly support the intention of SIPP to initially use standard IPv4 style addresses which double as EIDs and do CIDR-style routing. There is no need to do everything new at once. Bob Smart From owner-Big-Internet@munnari.OZ.AU Sat May 14 13:21:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14916; Sat, 14 May 1994 13:21:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA21235; Sat, 14 May 1994 12:59:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21117; Sat, 14 May 1994 12:37:22 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14055; Sat, 14 May 1994 12:59:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29211; Fri, 13 May 94 22:59:04 -0400 Date: Fri, 13 May 94 22:59:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405140259.AA29211@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu > Well, I'd put it "until we know more, including reasonable scale field > experience, about some things which are going to be crucial to add to > IPng", Great. You've just ensured a deadly embrace. No decision until major deployment. No significant deployment until a decision. No, that's not what I'm saying at all. This new stuff (IDPR, RSVP, etc) is all being field trialed in IPv4. > Among the choices which is supposed to be allowable is "none of the > above". Wrong. I pointedly suggested at the IPng open directorate meetin that that was specifically NOT a viable option. Well, in talking to people, what I hear from some quarters is that the IETF, having publicly comitted to making an IPng decision (on the grounds that the sky was about to fall if we didn't), is now going to look foolish, and marginalize itself, if we don't. I hear a variety of suggestion in response to this, including "just pick one, to show we can make a decision, and having done that, we'll go off and fix it up, and make it really work". I want to go off and talk to a variety of people, and sit and think for a bit about what the best way is to proceed in this situation, but my current sense is as follows. Although we might look bad in the short run to say "none of the above", it may be the right thing in the long run. We're in this spot because we were foolish enough to do something ill-advised; try and rush into making a decision we weren't really ready to make. I think that if we respond to this by trying to cover up our misstep with clever footwork, it's just going to hurt worse in the long run. It's obvious to plenty of people right now that that's what we are doing; eventually everyone will figure it out. When they do, the IETF's reputation is going to suffer. It seems to be a general rule of life that when you do something wrong, your best bet is to sit up, admit it, and take your medicine. Trying to evade the pain with clever manoeuvring just makes things worse in the end. We're putting a lot of energy into writing requirements documents. If none of the proposals really meet the requirements, we have an obligation to say just that. Noel From owner-Big-Internet@munnari.OZ.AU Sat May 14 13:39:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15619; Sat, 14 May 1994 13:39:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA21261; Sat, 14 May 1994 13:17:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21143; Sat, 14 May 1994 12:50:16 +1000 From: smb@research.att.com Received: from ninet.research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13364; Sat, 14 May 1994 12:40:33 +1000 (from smb@research.att.com) Message-Id: <9405140240.13364@munnari.oz.au> Received: by gryphon; Fri May 13 22:39:48 EDT 1994 To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: big-Internet@munnari.OZ.AU Subject: Re: IPng security, etc. Date: Fri, 13 May 94 22:39:47 EDT Big Internet folks, >How do we do real security; i.e. security which does not >require each application to be individually secured (an approach tha t >operating systems security work has revealed to be hopeless...)? Etc , etc, >etc.... At least one IPng proposal has specific mechanisms out in Internet Draft form which directly address the above issues. Yes -- but there is very little in those proposals that's SIPP-specific, and couldn't be adapted very easily to TUBA or CATNIP. In fact, that's one of the easier things to agree on, since it's almost orthognal to other IPng issues. For that matter, they could be used, almost unchanged, with IPv4. From owner-Big-Internet@munnari.OZ.AU Sat May 14 14:22:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17164; Sat, 14 May 1994 14:22:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA21329; Sat, 14 May 1994 14:00:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA21315; Sat, 14 May 1994 13:46:52 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16634; Sat, 14 May 1994 14:08:24 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA19966; Fri, 13 May 94 21:02:46 -0700 Received: by xirtlu.zk3.dec.com; id AA07842; Sat, 14 May 1994 00:02:39 -0400 Message-Id: <9405140402.AA07842@xirtlu.zk3.dec.com> To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: Requirements In-Reply-To: Your message of "Fri, 13 May 94 15:22:41 PDT." Date: Sat, 14 May 94 00:02:33 -0400 X-Mts: smtp Hi Dave, Well I am back to reading mail on big-i. And I see your still saying stuff that sounds like MUZAK to my ears and making my fingers bleed as I will be one of the many folks that has to write some code to make IPng work. Need a logic check here especially on the word 'deployment' in your mail. (muzak and fingers bleed are from one of my favorite philosophers the past John Lennon so you don't think I am being nasty). When you say this do you mean we need to start in July? Or We need to get the specs in order so we can start after July? I say the above because none of the IPng proposals can be deployed based on current specs. There are to many areas I personally just don't think are done yet in the MUST HAVE list. Some think there done I don't. Also I have to ask. When you say deploy are you speaking from personal experience of having implemented all the specs as a protoytpe for IPng or someone in your company because I know of NO vendor that has implemented all the specs for any IPng. This will help me understand what you mean by deploy? Thanks... With out knowing this I am going to respond to your mail. If you sense I am annoyed when folks who don't implement keep telling me this is what we should do, I am, and its beginning to bug me. But when someone starts talking deployment it causes me pain in my brain and not just a minor annoyance. =>At 11:07 AM 5/13/94, Noel Chiappa wrote: =>Well, I'd put it "until we know more, including reasonable scale field >Great. You've just ensured a deadly embrace. No decision until major >deployment. No significant deployment until a decision. This is what I need cleared up. No response yet. >In case you hadn't noticed, IPng has proved to be too basic for the >approach you suggest. We did substantial, multi-implementation demos and >the response seemd to be 'so what'? Noel, there is NO intermediate step. >We need to choose among the current alternatives, start deploying it with >its core capabilities, and then continue down the usual IETF path of >incremental enhancement. Thats because the demos were toy code so far not even real prototypes where you depended on the IPng changes like system discovery to find your router as opposed to just tunneling which is what they all did. I know in our prototype work we are now doing the systems discovery but don't have a clue how to do this unless we can do some bakeoffs. This has not even been tested by any IPng. => We are supposed to be focusing on the Toronto milestone, not rehashing => general philosophy. => =>Among the choices which is supposed to be allowable is "none of the above". >Wrong. >I pointedly suggested at the IPng open directorate meetin that that was >specifically NOT a viable option. My sense was basic agreement among the >group, but will pointedly ask this list to comment. You had no consensus in the room I was there and I disagreed with you completely. So did others. At Houston IETF the bullet stated NONE OF THE ABOVE. I was told this could be a decision when I accepted to work on the Directorate. I did make the caveat this was OK if none could solve the problem as long as we did not pick two. >What are the acceptable "recommendations" by the IPng area >directors/directorate? Bradner outlined a theorectially complete range; >i.e., he went through the academic exercise of listing possibilities. And one was NONE of the ABOVE. True it may mean we did not do our job if that is the answer. But it is and can be the answer. You don't have the facts right on this process at all. >From that, I believe that valid choices for Toronto are: >1. Name a specific choice from the contenders and declare it adequate. Yep... >2. Name a specific choice from the contenders and list minor, immediate changes that are needed prior to deployment Yep... This is tweeking... >3. Name a specific choice from the contenders and maybe list minor, immediate > changes that are needed, but also name longer-term enhancements that are > required, albeit NOT prior to initial deployment. This is not written down anywhere and I did not hear this at all. If this is an option I think the Directorate needs to be told so. If it is the bullet needs some serious technical analysis as to what is needed but does not have to be deployed. Try telling this to engineers who build products. Well just make this place holder etc etc.. We want to analyze this and not be handed a list by someone who is not also implementing products. This is when I stop listening to all the pure research people in the IETF who are not building products or the marketing politician types. Give me a spec I will tell YOU if it can be done as an implementor. Don't try to do it the other way around. Thats a part of the IETF that I hope never changes. >To repeat: We don't do long-term work in this community. We do short-term >long-term work, you are almost certainly requiring that we deliver nothing >work that often bears fruit for long-term. If you require us to do really >useful in the nearterm and probably nothing useful in the longterm. Well this community will change and has already. It better and Noel's note to Craig about all the waste for the past 3 years on IPng is a perfect example of what better change. We need to realize our companies are paying for some of us to be here so we can build products based on specifications. If all of it was like IPng we could not afford to participate it would cost to much. /jim From owner-Big-Internet@munnari.OZ.AU Sat May 14 15:21:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11873; Sat, 14 May 1994 12:06:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA21064; Sat, 14 May 1994 11:44:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA21010; Sat, 14 May 1994 11:08:51 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10782; Sat, 14 May 1994 11:30:34 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA18494; Fri, 13 May 94 21:30:29 EDT Date: Fri, 13 May 94 21:30:29 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9405140130.AA18494@itd.nrl.navy.mil> To: big-Internet@munnari.OZ.AU Subject: IPng security, etc. Big Internet folks, >How do we do real security; i.e. security which does not >require each application to be individually secured (an approach that >operating systems security work has revealed to be hopeless...)? Etc, etc, >etc.... At least one IPng proposal has specific mechanisms out in Internet Draft form which directly address the above issues. Use of SIPP ESP will provide confidentiality and integrity without requiring each application to be modified individually. Depending on algorithm and mode, such implementations may also provide authentication. Use of SIPP AH will provide strong authentication without confidentiality (and appears to be easily exportable from most or all countries). The two mechanisms may be combined in several ways to provide mixes of the two security properties. As discussed at length a while back, a scalable key mgmt protocol is important for really widespread use of any IPng security mechanism. The SIPP security mechanisms are deliberately decoupled from key mgmt, permitting them to be used with many different key mgmt approaches. Please read the I-Ds for more detail. Comments specific to those proposals belong on the sipp list, not big-Internet. % recursive application of multi-level security is not that hard, but i % have negative interest in it... Davis, Hale, Kallgren, & Cole of NRL published a paper in the 1989 (1990 ?) IEEE Military Communications Conference proceedings which describes a reasonable MLS networking architecture and approach. Their approach is locally known as a "pink" architecture because it has at least two-layers of cryptography. The upper layer device (e.g. a transport-layer encryptor) provides a red-pink boundary and provides full user-to-user separation of data in a manner that does not require individual modification of applications. The lower layer device (e.g. an IP encryptor or some sort of link encryptor) provides a pink-black boundary and helps provide some protection against traffic flow analysis as well as helping to secure the protocols in the pink boundary from outsider attacks. I don't think there is any serious question that such an architecture can be implemented in a high assurance manner (i.e. A1 or better). It is not at all clear to me that there is much or any commercial interest in such high levels of protection. I believe that the SIPP ESP can be used effectively as a transport-layer mechanism for the above purposes (indeed, that capability was a design intent because I want the SIPP mechanism designs to be suitable for both commercial and governmental use). Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Sat May 14 15:32:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19700; Sat, 14 May 1994 15:32:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA21422; Sat, 14 May 1994 15:10:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA21397; Sat, 14 May 1994 14:48:54 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18768; Sat, 14 May 1994 15:10:24 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA23548; Fri, 13 May 94 22:09:28 -0700 Received: by xirtlu.zk3.dec.com; id AA08262; Sat, 14 May 1994 01:09:21 -0400 Message-Id: <9405140509.AA08262@xirtlu.zk3.dec.com> To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Cc: bound@zk3.dec.com, bmanning@is.rice.edu (William Manning), postel@ISI.EDU, scottw@internic.net, big-internet@munnari.OZ.AU Subject: Re: !! Denied !! In-Reply-To: Your message of "Fri, 13 May 94 16:25:36 PDT." Date: Sat, 14 May 94 01:09:14 -0400 X-Mts: smtp =>If they were turned down for a Class A or B, but were given a Class C, =>then I think we should count that as they were given an IPv4 address. =>Hence, they were not turned down. >well... >There are those that choose to use private (not registered globally) IPv4 >addresses. But there are those that feel forced into it because they >cannot get enough address space. If they get a Class C but also have to >use private address space, they've been turned down. well... They were turned down for a Class A or B address yes. But they were not turned down and cannot use IPv4 addresses any more. I agree its harder I had to think about that poor customer with 3 Class C addresses when I helped the folks in teh field get it figured out. But at the end of the day they are running IPv4 applications and using IPv4 addresses in their transport layers on ours and my competitors Hosts and accessing the Internet. The Sky is getting cloudy but its not falling. I think this is what Tony mean't at Seattle when he said don't Panic (for different reasons maybe than I am saying here). But we have some time to select an IPng get it fine tuned for the MUSTs and even get the new stuff ready when we Most I talk to would rather use 10 Class C addresses than private ones cause they see the benefit of using the Internet for their employees. I admit though most I talk to also do stuff with the Internet even non computer damaged friends who are plumbers, mechanical engineers, whatever. /jim From owner-Big-Internet@munnari.OZ.AU Sat May 14 18:44:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18333; Sat, 14 May 1994 14:57:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA21370; Sat, 14 May 1994 14:35:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA21356; Sat, 14 May 1994 14:19:04 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB17819; Sat, 14 May 1994 14:40:44 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA21895; Fri, 13 May 94 21:39:36 -0700 Received: by xirtlu.zk3.dec.com; id AA08012; Sat, 14 May 1994 00:39:29 -0400 Message-Id: <9405140439.AA08012@xirtlu.zk3.dec.com> To: Steve Deering Cc: sipp@sunroof2.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Fri, 13 May 94 00:49:13 PDT." <94May13.004918pdt.12171@skylark.parc.xerox.com> Date: Sat, 14 May 94 00:39:24 -0400 X-Mts: smtp Steve, First, thanks for doing this its very helpful. I like Model H. And yes SIPP can do Model H. I think SIPP should be Model H only. In this case the Identifier would be the DNS ASEQ record and be the first 64bits (unless someone can convince me 64bits is not big enough for a globally unique identifier). A question: In this case (Model H) the device Cn component would be there every time for any association for that node? Right? Multiple Logical Hosts on one Physical Host comment: In Model H case each logical host would be a different name in the DNS and to an application in my mind to make this really clean. Finally I think Model H provides a clear separation between the transport and intenetwork layer and this will be true from a software engineering implementation strategy too. How about the name JSNIP (pronounded jay-snip) meaning J=John (TUNE - who really got me going bugging you about the transport ID case) S=Steve (you being Mr. SIPP), N=Noel (obviously an EID kind of guy), I = Integrated with P=Paul (because PIP concatented EIDs and 64bits with a routing thought and addressing). Plus JSNIP ryhmes with SIPP. thanks again for doing this, /jim From owner-Big-Internet@munnari.OZ.AU Sat May 14 19:02:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26221; Sat, 14 May 1994 19:02:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA21618; Sat, 14 May 1994 18:40:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA21604; Sat, 14 May 1994 18:37:43 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26168; Sat, 14 May 1994 18:59:27 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 14 May 94 17:52:49 +0859 From: Masataka Ohta Message-Id: <9405140853.AA16514@necom830.cc.titech.ac.jp> Subject: Re: 64K (was tangential to Re: FORMAL REQUEST : SIPP EIDs and Locators ) To: bsimpson@morningstar.com Date: Sat, 14 May 94 17:52:47 JST Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU In-Reply-To: <2385.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at May 13, 94 3:18 pm X-Mailer: ELM [version 2.3 PL11] > Also, the preliminary data that Craig Partridge released to end2end, > using small 512 byte packets, shows an undetected (by the AAL5 32-bit > CRC) error-rate of 1.6 * 10**-10. That seems small, until you remember > that your target speeds are at 10**-9 bps. An undetected error over > every ATM link every 10 seconds is a lot of errors! Bogus. You are assuming that physical layer error rate is 100%. If physical layer error rate is, for example, 10^-6, we will have undetected error, which may later be detectet at network layer, about once a half year. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sat May 14 19:37:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26962; Sat, 14 May 1994 19:37:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA21659; Sat, 14 May 1994 19:15:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA21634; Sat, 14 May 1994 18:53:48 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26466; Sat, 14 May 1994 19:15:28 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 14 May 94 18:08:57 +0859 From: Masataka Ohta Message-Id: <9405140909.AA16565@necom830.cc.titech.ac.jp> Subject: Re: Do we have an architecture? To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Sat, 14 May 94 18:08:56 JST Cc: tracym@NSD.3Com.COM, big-internet@munnari.OZ.AU In-Reply-To: <9405131808.AA01663@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at May 13, 94 8:08 pm X-Mailer: ELM [version 2.3 PL11] > Tracy, > > It's dangerous to disagree with Dave Clark of course, but I am very > happy that the IPng requirements draft (when last seen) does not require > that two systems alone on a wire must be able to talk without a third > party. It seems to me that it is a very good requirement. > ARP is a bad design; the fact that Ethernet allows trivial > broadcast (and multicast) has led to numerous similar bad designs. ARP is a good design. There was some applications or systems which use broadcast in a wrong way. To prevent the effect of them minimal, we should make size of a single datalink layer as small as possible. Doing so is also necessary as a small number of hosts can easily use up the network bandwidth. Today, single datalink with more than 100 hosts is rare. > (This doesn't include IP multicast: multicast applications need multicast.) > See my numerous past flames in the IP-ATM archives for rationale. In the archive, I have seen several complaints on broadcast storm in CERN where 1,000 hosts are connected without routers. The problem is in poor management of CERN, not in broadcast. Anyway, ARP is an issue at datalink, which has little to do with IPng design solely at network layer. If some ARP design have very strange requirement for other layers, the ARP design, not rest of other protocol stacks, is broken. > ES-IS is a good design; the RFC 1577 ARP server is a good design. Having a ARP server, the single point of failure, which must be statically configgured, RFC1577 ARP is the worst design. Use ATM with small datalink and with broadcast as it is easy and straight forward (see draft-ohta-ip-over-atm-00.txt). Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sat May 14 20:15:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22097; Sat, 14 May 1994 16:42:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA21486; Sat, 14 May 1994 16:20:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA21461; Sat, 14 May 1994 15:45:44 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17920; Sat, 14 May 1994 14:45:21 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA22134; Fri, 13 May 94 21:43:18 -0700 Received: by xirtlu.zk3.dec.com; id AA08037; Sat, 14 May 1994 00:43:12 -0400 Message-Id: <9405140443.AA08037@xirtlu.zk3.dec.com> To: Dave Crocker Cc: big-internet@munnari.OZ.AU Subject: Re: IPng Criteria doc In-Reply-To: Your message of "Thu, 12 May 94 17:22:11 PDT." <199405130022.RAA21647@Mordor.Stanford.EDU> Date: Sat, 14 May 94 00:43:06 -0400 X-Mts: smtp Dave, I liked your break down of the pots. Except we are delivering Mobile products today with IPv4? So I guess I would like to see that up with must do. /jim From owner-Big-Internet@munnari.OZ.AU Sat May 14 20:55:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11776; Sat, 14 May 1994 12:02:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA21049; Sat, 14 May 1994 11:40:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA21035; Sat, 14 May 1994 11:38:56 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06174; Sat, 14 May 1994 09:01:28 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Fri, 13 May 1994 19:01:25 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 13 May 1994 19:01:25 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA01482; Fri, 13 May 94 19:00:04 EDT Date: Fri, 13 May 94 19:00:04 EDT Message-Id: <9405132300.AA01482@mailserv-D.ftp.com> To: dcrocker@mordor.stanford.edu Subject: Re: Requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Content-Length: 2241 > >Among the choices which is supposed to be allowable is "none of the above". > > Wrong. > > I pointedly suggested at the IPng open directorate meetin that that was > specifically NOT a viable option. My sense was basic agreement among the > group, but will pointedly ask this list to comment. Depends on what you mean by 'basic agreement'. I STRONGLY disagree with the notion of declaring any possible outcome of the process 'not viable' before the directorate gets down to the business of evaluating the proposals. As an intellectual exercise, suppose that none of the proposals is suitable, even with major modifications, to being used as IPng. Must we still select one of them? Would you have the IPng directorate and area directors make a recommendation for protocol "Q", knowing it to be a bad one? Would you have the IESG select "Q", even if Q was completely unsuited to the task? By ruling out part of the solution space, we may force ourselves into making just such a disasterous decision. We would unnecessarily constrain our possible range of actions. > What are the acceptable "recommendations" by the IPng area > directors/directorate? Bradner outlined a theorectially complete range; > i.e., he went through the academic exercise of listing possibilities. > > >From that, I believe that valid choices for Toronto are: > > 1. Name a specific choice from the contenders and declare it adequate. > > 2. Name a specific choice from the contenders and list minor, immediate > changes that are needed prior to deployment > > 3. Name a specific choice from the contenders and maybe list minor, immediate > changes that are needed, but also name longer-term enhancements that are > required, albeit NOT prior to initial deployment. Let's be complete. 4. Declare that, as a result of the ALE work, IPv4 will last long enough that we do not have to make a decision now (I know you disagree, this is, however, a part of the solution space) 5. Declare that no contender is suitable enough, even with major enhancements, and that we all go back to the drawing board. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Sat May 14 20:56:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15891; Sat, 14 May 1994 13:47:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA21288; Sat, 14 May 1994 13:25:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA21175; Sat, 14 May 1994 12:54:17 +1000 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14775; Sat, 14 May 1994 13:16:02 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA17311; Fri, 13 May 94 20:13:18 -0700 Received: by xirtlu.zk3.dec.com; id AA07515; Fri, 13 May 1994 23:13:11 -0400 Message-Id: <9405140313.AA07515@xirtlu.zk3.dec.com> To: bsimpson@morningstar.com Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 64K (was tangential to Re: FORMAL REQUEST : SIPP EIDs and Locators ) In-Reply-To: Your message of "Fri, 13 May 94 15:18:30 GMT." <2385.bill.simpson@um.cc.umich.edu> Date: Fri, 13 May 94 23:13:05 -0400 X-Mts: smtp Bill, I am getting more confused than ever on this entire issue. I am glad you moved it to big-i. Its not a SIPP issue but a networking issue I hear has had discussion before. I don't care I would like to hear it again. Craig and you have put out some very interesting CRC and error detecting data based on a 64K packet size. This still does not convince me at all. I doubt there is much reason at all for > 64K packets on a wide area network. But on a local area network I really believe this will be possible in the future to push data across an MTU > 64K. Though ATM MTU is pushing that limit is it not? If so are we going to ignore ATM? I also don't buy all the hardware and checksum issues either if folks begin to build MTUs that causes this requirement the error correcting algorithms will come with it. I still believe we need > 16bit packet length for any IPng header. thanks /jim From owner-Big-Internet@munnari.OZ.AU Sat May 14 21:03:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29181; Sat, 14 May 1994 20:47:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA21740; Sat, 14 May 1994 20:25:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA21698; Sat, 14 May 1994 19:54:51 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06775; Sat, 14 May 1994 09:25:56 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA27614; Fri, 13 May 1994 16:25:49 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 May 1994 16:25:53 -0700 To: perk@watson.ibm.com (Charlie Perkins) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re:Mobility requirement Cc: big-internet@munnari.OZ.AU sigh. At 6:28 AM 5/13/94, Charlie Perkins wrote: >It has been stated without proof that mobility is too >hard, and is not a firm requirement for whatever >protocol replaces IPv4. Proving the negative is usually pretty tough. More importantly, it isn't that there is a technical impediment to doing mobility it is that there is no clear indication that the IETF is gravitating toward any particular choice or set of choices and it is also not clear that we are fully certain of the requirements for this functionality. You might be. I might be. But WE aren't. The lack of sufficient field experience with this rather distinctive modality is almost certainly a major part of the reason. The lack of highly pressing, immediate demand is probably the other. In any case, I was observing lengthy IETF work and little IETF convergence. That usually means something. >The market is coming, Yup. And that's great. So what will it take for the related IETF work to comfortably converge on a single proposal? Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sun May 15 00:36:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29240; Sat, 14 May 1994 20:50:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA21755; Sat, 14 May 1994 20:28:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA21712; Sat, 14 May 1994 19:55:33 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06773; Sat, 14 May 1994 09:25:49 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA27611; Fri, 13 May 1994 16:25:41 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 May 1994 16:25:45 -0700 To: kasten@ftp.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU Frank, At 5:48 AM 5/13/94, Frank Kastenholz wrote: > One should, at the very least, preface >one's statements with words to the effect of "Rumors I've heard >indicate that..." If I hadn't just come from the Interop RFC1597 BOF, then I'd energetically agree with you. Whether I'd have been more moderate in my language or would instead have to now apologize for NOT being immoderate, I won't try to guess. (Well, there's a reasonable basis for guessing I'd have to do the latter. sigh.) >There have been people on this mailing list making derogatory >comments about the ALE work. They make claims that it is based on You mean I'm not the only one offering this criticism. Oh, good. Or perhaps you were just being polite?... >To use >'scuttlebut' as the basis for making decisions is no better, and no You're quoting from the second half of my response. You left out the citation of RFC1597, which I now feel like I'm relying on much too heavily. >Do I need to remind one of the story of Chicken Little? Why are you mentioning restaurant franchises in this debate? (Oh, you mean the truth in labeling, about the size of the chicken?) Dave P.S. It's friday. The last comment reflects that. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sun May 15 01:01:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29278; Sat, 14 May 1994 20:52:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA21770; Sat, 14 May 1994 20:30:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA21715; Sat, 14 May 1994 20:00:38 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07412; Sat, 14 May 1994 09:42:26 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA27678; Fri, 13 May 1994 16:42:09 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 May 1994 16:42:15 -0700 To: kasten@ftp.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Frank, At 4:00 PM 5/13/94, Frank Kastenholz wrote: >Depends on what you mean by 'basic agreement'. I STRONGLY disagree >with the notion of declaring any possible outcome of the process 'not >viable' before the directorate gets down to the business of >evaluating the proposals. The directorate isn't working in a vaccuum. Two of the IPng contenders have been around for a couple of years. As a community, we already have a fair idea of what they are about. There is no magic to the meeting of the directorate, so my own assertion of the acceptable outcomes by the directorate is very much based on a belief that that subset is reasonable. Treating this as a black box process which says that we can't say ANYTHING about the decision event until the directorate sends up some white smoke does not seem to me at all appropriate. >As an intellectual exercise, suppose that none of the proposals is Frank, this is not an intellectual exercise. This is an exercise in remodeling and enhancing a technology that is the underpinning of a multi-billion dollar industry, providing communications for many millions of people. You work for one of the organizations responsible for deliverying this stuff. Let me ask you. Would you spend 2 years developing a product and only when it was completely done THEN ask whether is should be scrapped? The usual process is to run continuing evaluations. If all of the contenders are wholly unacceptable, then we need to tell ourselves that now! We bloody well should not be waiting for the annoited directorate to tell us, because we bloody well should be working on something that WILL be acceptable. Do I think that one of the alternatives is vastly better? You bet! Do I think that there will be major problems with the alternatives? You bet! But that is quite different from saying that NONE of the alternatives is acceptable. If the consensus of the community is that it really believes that none of the alternatives is acceptable, then we need to hear that instantly and not wait for Toronto. >Let's be complete. No, Frank. Let's be practical. If you believe either of your two additional alternatives is practical and reasonable, please explain in detail. I've already argued against using the ALE data for making any decisions. Please explain why you think it is valid methodology. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sun May 15 01:27:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07292; Sun, 15 May 1994 01:27:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA22032; Sun, 15 May 1994 01:05:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA22018; Sun, 15 May 1994 00:52:08 +1000 Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02161; Sat, 14 May 1994 23:00:13 +1000 (from sob@hsdndev.harvard.edu) Date: Sat, 14 May 94 08:59:57 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405141259.AA05165@hsdndev.harvard.edu> To: dcrocker@mordor.stanford.edu, kasten@ftp.com Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu > Treating this as a black box process The black box has viewing holes. The IPng directorate mailing list archives are on hsdndev.harvard.edu in pub/ipng/mailing.list. Take a look at the discussions and if anyone has comments on the comments therein they should post them to this list. Scott From owner-Big-Internet@munnari.OZ.AU Sun May 15 03:12:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11301; Sun, 15 May 1994 03:12:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA22130; Sun, 15 May 1994 02:50:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA22116; Sun, 15 May 1994 02:29:46 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06836; Sun, 15 May 1994 01:16:16 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa17647; 14 May 94 11:16 EDT To: Masataka Ohta Cc: Brian Carpenter CERN-CN , tracym@nsd.3com.com, big-internet@munnari.OZ.AU Subject: Re: Do we have an architecture? In-Reply-To: Your message of Sat, 14 May 1994 18:08:56 +0200. <9405140909.AA16565@necom830.cc.titech.ac.jp> Date: Sat, 14 May 1994 11:15:06 -0400 From: John Curran Message-Id: <9405141116.aa17647@nic.near.net> -------- ] From: Masataka Ohta ] Subject: Re: Do we have an architecture? ] Date: Sat, 14 May 94 18:08:56 JST ] ] > ARP is a bad design; the fact that Ethernet allows trivial ] > broadcast (and multicast) has led to numerous similar bad designs. ] ] ARP is a good design. There was some applications or systems which use ] broadcast in a wrong way. To prevent the effect of them minimal, we ] should make size of a single datalink layer as small as possible. ARP is sufficient for many applications, but it _does_ have some characteristics that make it difficult to use in a dynamic environment. This could all be correctly with the addition of lifetime values in the PDUs, and addition of an external autoconfiguration method (such as DHCP) but ES-IS already exists, work well, and has years of experience. ] Doing so is also necessary as a small number of hosts can easily use up ] the network bandwidth. Today, single datalink with more than 100 ] hosts is rare. ] ] In the archive, I have seen several complaints on broadcast storm in ] CERN where 1,000 hosts are connected without routers. ] ] The problem is in poor management of CERN, not in broadcast. If you'd like (and are in New England sometime), I can give you a tour of network reality where literally dozens of sites are running large bridged environments and don't particularly plan on changing in the near future. Please do not extrapolate your views on how "networking should be done" on others without knowing the full ranges of constraints (including technical, political, and financial.) ] Anyway, ARP is an issue at datalink, which has little to do with IPng ] design solely at network layer. If some ARP design have very strange ] requirement for other layers, the ARP design, not rest of other protocol ] stacks, is broken. Correct. ARP performs mapping between two layers and creates bindings which IP may care very much about but has no control over due to lack of functionality in the protocol. Yes, a disfunctional lower-layer protocol can prevent us from doing things in the network layer. /John From owner-Big-Internet@munnari.OZ.AU Sun May 15 03:21:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03520; Sat, 14 May 1994 23:42:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA21914; Sat, 14 May 1994 23:20:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA21900; Sat, 14 May 1994 23:03:31 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16286; Sat, 14 May 1994 13:56:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29567; Fri, 13 May 94 23:56:01 -0400 Date: Fri, 13 May 94 23:56:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405140356.AA29567@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) my own assertion of the acceptable outcomes by the directorate is very much based on a belief that that subset is reasonable. Treating this as a black box process which says that we can't say ANYTHING about the decision event until the directorate sends up some white smoke does not seem to me at all appropriate. This position (that you think that the directorate is only likely to settle on one of the three you mentioned) is rather different from what I thought I heard you saying before (that the other two choices were simply unacceptable). Me, I have no idea what the directorate is likely to agree to. > As an intellectual exercise, suppose that none of the proposals is > suitable, even with major modifications, to being used as IPng. Must > we still select one of them? Frank, this is not an intellectual exercise. This is an exercise in remodeling and enhancing a technology that is the underpinning of a multi-billion dollar industry He never said the IPng choice was an intellectual exercise. He asked you to give him an answer about your choice in a hypothetical situation. (One which is hypothetical only to avoid interminable arguing about whether the hypothesized fact - the suitability of any of the proposals - is true or not.) Would you spend 2 years developing a product and only when it was completely done THEN ask whether is should be scrapped? Hopefully you'd have some sort of marketing decision to tell you what functionality and price you need, before starting work. We're still arguing about what it should do, unfortunately. Not a good sign... If all of the contenders are wholly unacceptable, then we need to tell ourselves that now! We bloody well should not be waiting for the annoited directorate to tell us, because we bloody well should be working on something that WILL be acceptable. I agree completely. If the consensus of the community is that it really believes that none of the alternatives is acceptable, then we need to hear that instantly and not wait for Toronto. Well, the IPng directorate meeting next week should be interesting. I've already argued against using the ALE data for making any decisions. Please explain why you think it is valid methodology. The data we have already contains several cycles of growth into emerging user categories; universities as a whole, production basis in computer and oher high-tech manufacturing companies, etc. So, to some extent, that kind of growth is already factored into the historical data they are using. None of the previous expansions into new categories changed the growth rate substantially. (See the chart "Host Growth (Measured) by SRI-ZONE", from Phill Gross' presentation at the Houston IETF; it's been more or less straight [on a semi-log graph] from the fall of '89, and has slowed down since prior to that.) (As an aside, I don't believe the logistic curves; the leveling off point keeps changing. I think the straight exponential curves aren't too bad, and in any case they are worst case; economic and physical realities mean we will fall behind those curves eventually.) This doubling of size of the user community is starting to use really massive amounts of resources, amounts you just don't sling together in a second. I find it really hard to believe that the growth rate is going to accelerate, given how much training time, etc, it takes to get people on (and the further out you go, the less computer literate the new users are, etc, etc). Many of these suggested new user communities (phone poles, TV set boxes, etc) are unlikely to be directly connected to the Internet *anyway*. This is clear in the case of the the CDPD folks, who picked CLNP. I mean, think it through: using CLNP means they won't be interoperable with the Internet, right? (At least at their basic level; they can always encapsulate.) However, if they were willing to be non-interoperable, a viable alternative was to use IP with a completely private address space. Plus to which, if we don't secure the darn system better, there isn't going to be *any* growth... Noel From owner-Big-Internet@munnari.OZ.AU Sun May 15 03:34:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06172; Sun, 15 May 1994 00:52:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA21991; Sun, 15 May 1994 00:30:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA21964; Sat, 14 May 1994 23:55:46 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05194; Sun, 15 May 1994 00:17:27 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27385; Sat, 14 May 94 10:17:18 EDT Date: Sat, 14 May 94 10:17:18 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9405141417.AA27385@itd.nrl.navy.mil> To: atkinson@itd.nrl.navy.mil, smb@research.att.com Subject: Re: IPng security, etc. Cc: big-Internet@munnari.OZ.AU % At least one IPng proposal has specific mechanisms out in Internet % Draft form which directly address the above issues. % Yes -- but there is very little in those proposals that's SIPP-specific, % and couldn't be adapted very easily to TUBA or CATNIP. In fact, that's % one of the easier things to agree on, since it's almost orthognal to % other IPng issues. For that matter, they could be used, almost unchanged, % with IPv4. Steve, It is in fact startling to me that neither TUBA nor CATNIP have any concrete security proposals since it is so straightforward to do. Instead, I understand that both claim they will reuse the IPv4 Security Protocol. This would be much more reasonable if an IPv4 Security Protocol existed as an Internet Draft. No such draft exists, making claims of reuse not credible. In over 12 months of the IPv4 Security Protocol WG have made remarkably little progress. The IPv4 Security Protocol WG have less list discussion than the CIPSO list did and have no more consensus than the CIPSO folks did, to draw a comparison. Also, the IPv4 Security Protocol is focusing on confidentiality mechanisms and has chosen to avoid creating an authentication-only specification. This is highly unfortunate. Discussions I've had (as a private citizen) with the US export control people indicate that authentication-only mechanisms are almost certain to fall under Commerce Dept rules while mechanisms which specify confidentiality are likely to fall under State Dept rules (which are harder to work with commercially) even if the particular implementation only includes authentication. Thirdly, it is important to understand that several groups (e.g. DEC, NRL, Sun) are independently building prototype implementations of the SIPP security mechanisms (in true IETF fashion). No other IPng proposal has a security specification to implement, let alone prototype implementations in progress. SIPP will include security mechanisms from day 1 and in all implementations rather than leaving them as later-day add-ons that are not part of the base protocol specification. If we are really serious about having a safer Internet, then we need to start building security mechanisms into all the systems. IPng, IMHO, should include security mechanisms (or at least an authentication-without-confidentiality, for export control reasons) in every implementation. Regards, Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Sun May 15 04:22:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13373; Sun, 15 May 1994 04:22:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA22225; Sun, 15 May 1994 04:00:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA22211; Sun, 15 May 1994 03:52:41 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13013; Sun, 15 May 1994 04:14:25 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA00546; Sat, 14 May 1994 11:14:09 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 14 May 1994 11:14:12 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Noel, First, thank you for being willing to pursue the projection discussion in terms of "market" sectors. At 8:56 PM 5/13/94, Noel Chiappa wrote: >None of >the previous expansions into new categories changed the growth rate >substantially. (See the chart "Host Growth (Measured) by SRI-ZONE", I suspect that these do not really reflect different usage markets. In general, the Internet has been used for inter-organization, informal communications. In general, it has not been used for formal communications (of which EDI is a particularly extreme example), mass-market personal use, mass-market device interaction, ... Are those exactly the right additional categories to use? I don't know. That's why I'm hoping we can recruit some strategic market projection folks into this discussion. (Haven't uncovered any volunteers, yet, but still searching.) In other words, I'm suggesting that domain names labels aren't particularly helpful for this exercise. I understand why they are appealing, but believe we need to look at types of use in terms of human communication function, to give better guidance about NEW markets. A year ago, I would have thought that power poles, televisions and light switches would be silly to include. Not anymore. >... massive >amounts of resources, amounts you just don't sling together in a second. I >find it really hard to believe that the growth rate is going to accelerate, >given how much training time, etc, it takes to get people on (and the further Fair point. Certainly our current model of configuration and support effort doesn't seem to scale. (I suspect a contained sub-system, like utility telephone poles, could, but believe that house light switches won't.) But I would also claim that that limit is a problem, not an explanation. I.e., we should take the stance that we need to walk/run/hop down a path that will allow us to satisfy any reasonable user and market request as soon as we can. >Many of these suggested new user communities (phone poles, TV set boxes, etc) >are unlikely to be directly connected to the Internet *anyway*. I'm sympathetic to this reaction, but I don't agree with it. We keep taking various, current opertional constraints and assuming that they are natural requirements or limitations. Firewalls are largely due to our lack of adequate security mechanisms. They are a safe answer, but they have their own problems. If/when we find ways to improve the security features, it is plausible to forsee reduced use of firewalls. Most of the examples of 'natural' private networks seem to extend easily into examples of public ones. For example, each of the four bulleted examples in RFC1597 are reasonable in the scenario they describe but I claim that they are equally reasonable for public access. (Our response to RFC1597 discusses this.) Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sun May 15 05:53:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15291; Sun, 15 May 1994 05:32:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA22305; Sun, 15 May 1994 05:10:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA22291; Sun, 15 May 1994 04:56:49 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14943; Sun, 15 May 1994 05:18:33 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa28564; 14 May 94 15:18 EDT To: Ran Atkinson Cc: smb@research.att.com, big-Internet@munnari.OZ.AU Subject: Re: IPng security, etc. In-Reply-To: Your message of Sat, 14 May 1994 10:17:18 -0400. <9405141417.AA27385@itd.nrl.navy.mil> Date: Sat, 14 May 1994 15:17:28 -0400 From: John Curran Message-Id: <9405141518.aa28564@nic.near.net> -------- ] From: Ran Atkinson ] Subject: Re: IPng security, etc. ] Date: Sat, 14 May 94 10:17:18 EDT ] ... ] It is in fact startling to me that neither TUBA nor CATNIP have any ] concrete security proposals since it is so straightforward to do. What about draft-ietf-tuba-inlsp-00.txt? I'll admit that I have not completed my reading of it (as there's something quite unnerving about the combination of OSI and security jargon in one document... ;-) ] If we are really serious about having a safer ] Internet, then we need to start building security mechanisms into all ] the systems. IPng, IMHO, should include security mechanisms (or at ] least an authentication-without-confidentiality, for export control ] reasons) in every implementation. 100 percent agreement. I'm not confident that we can specify an architecture for security association establishment (which is desperately needed to obtain the benefit of these security mechanisms) but it very likely can be added (and/or improved) independent of IPng deployment. /John From owner-Big-Internet@munnari.OZ.AU Sun May 15 06:36:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12299; Sun, 15 May 1994 03:47:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA22184; Sun, 15 May 1994 03:25:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA22170; Sun, 15 May 1994 03:12:42 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07479; Sun, 15 May 1994 01:35:59 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA29558; Sat, 14 May 1994 08:35:39 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 14 May 1994 08:35:43 -0700 To: bound@zk3.dec.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com At 9:02 PM 5/13/94, bound@zk3.dec.com wrote: >When you say this do you mean we need to start in July? >Or >We need to get the specs in order so we can start after July? Since there are no IPng products, as far as I know, how could we start deploying in July? Since I've been distinguishing between core and near-term, there is a chance that the core specs will be in order by July. If they are, they should be elevated, implemented, etc. > Some think there done I don't. Specifics? Or is your EID submission an example? >Also I have to ask. When you say deploy are you speaking from personal Huh? > it causes me pain in my brain and not just a minor >annoyance. Hmmm. I wonder it it's anything like the reaction one might get to seeing efforts to add a major requirement 2 months before a final deadline, after nearly 2 years of discussion and development? >Thats because the demos were toy code so far not even real prototypes They were not toy code for SIP. I doubt they were toy code for TUBA. They weren't product, either, but they sure weren't toy. >where you depended on the IPng changes like system discovery to find >your router as opposed to just tunneling which is what they all did. Huh? They did NOT all do ONLY tunneling. >You had no consensus in the room I was there and I disagreed with you >completely. So did others. At Houston IETF the bullet stated NONE OF >THE ABOVE. I was told this could be a decision when I accepted to work ********** FOLKS: Jim and I would appreciate some comments from the peanut gallery. Is the community going to be satisfied with a 'none of the above' recommendation by the directorate?? Inquiring minds want to know. ********** > If it >is the bullet needs some serious technical analysis as to what is needed but >does not have to be deployed. Try telling this to engineers who build Happens all the time, Jim. It's just planned product growth. >>To repeat: We don't do long-term work in this community. We do short-term >>long-term work, you are almost certainly requiring that we deliver nothing >>work that often bears fruit for long-term. If you require us to do really >>useful in the nearterm and probably nothing useful in the longterm. > >Well this community will change and has already. It better and Noel's Jim, you missed my point. One does not simply "decide" to become skilled at something one has shown a pointed lack of capability in. We don't do long-term design not because it isn't important but because we don't know how and when we try to pretend that we do, we fail. Other groups often try to design for the long-term and they usually fail. The IETF usually tries for the near-term and usually winds up solving something much longer term. I hope we don't "fix" this limitation. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Sun May 15 07:48:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16268; Sun, 15 May 1994 06:07:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA22346; Sun, 15 May 1994 05:45:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA22321; Sun, 15 May 1994 05:14:43 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15380; Sun, 15 May 1994 05:36:28 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa29357; 14 May 94 15:36 EDT To: Dave Crocker Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Requirements In-Reply-To: Your message of Sat, 14 May 1994 08:35:43 -0700. Date: Sat, 14 May 1994 15:35:24 -0400 From: John Curran Message-Id: <9405141536.aa29357@nic.near.net> -------- ] From: Dave Crocker ] Subject: Re: Requirements ] Date: Sat, 14 May 1994 08:35:43 -0700 ] ... ] >Thats because the demos were toy code so far not even real prototypes ] ] They were not toy code for SIP. I doubt they were toy code for TUBA. ] They weren't product, either, but they sure weren't toy. Please, Dave: the demos may have contained lots of very functional code, but none of the demos that I've seen to date would be called a "complete" (or even "minimal") IPng suite. Autoconfiguration may have been present in some cases, but not autoregistration. Routing varied from production protocols to completely static. Transition support varied from prototype to none-at-all. Security wasn't, mobility (except in the local area) wasn't supported, and multicast wasn't present in most cases. That's not to say that the demos weren't useful (most implementors I spoke with considered them crucial for clarifying the specification details.) There's certainly going to have to be a lot more demos, bake-offs, and testing before any proposal can be used in a high consequence application. I'd like to see some serious "deployment" (among interested parties) right after July, but I presume that vendors will not attempt to ship IPng products until things actually stabilize in the 6 to 18 months that follow. /John From owner-Big-Internet@munnari.OZ.AU Sun May 15 08:27:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20039; Sun, 15 May 1994 08:27:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA22521; Sun, 15 May 1994 08:05:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA22507; Sun, 15 May 1994 07:50:23 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19785; Sun, 15 May 1994 08:12:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07416; Sat, 14 May 94 18:12:05 -0400 Date: Sat, 14 May 94 18:12:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405142212.AA07416@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu I went for a long walk today, and I have some thoughts on this whole IPng situation. I'm not sure anyone is going to like them, but here they are anyway. This whole IPng deal, from its roots in concerns about the IPv4 address space, on through ROAD, and on along through IPng, has been utterly back to front, and so totally and unbelievably amateurish it's incredible. That a standards body with responsibility for a key piece of the world's infrastructure is behaving like this is frightful and infuriating. I simply cannot find the words to express the depth of my professional contempt for what I've watched happen. A responsible and coherent way to procede would have been to go through a process of deciding what functionality we wanted IPng to provide (e.g. "looping packet detection"), and getting agreement on that; then sitting down and deciding what mechanisms we wanted to use to provide that functionality (e.g. "a hop count"), and getting agreement on that; then deciding from that the details of how big the fields are, where they are, etc. At the end, we'd have set of documents that describe the overall functionality of the interwork layer, what service model it provides to clients, and what it assumes or can use of the network layers over which it runs. We'd have had along with outlines of each subsystem, and an explanation of how each one used the fields in the internetwork header. Instead, people have been going off and designing packet formats on the backs of logical envelopes, putting together new ones over the weekend, and mostly doing whatever bits and pieces of the design are either easy or appealing. It's not very productive to go back and try and assign blame for all this; for what it's worth, I come in for my share. While I was one of the first to call attention to the problem of eventual total exhaustion of the the IP addressing system (first at a presentation to the IAB at the Fall '90 Interop, and to the IETF at the Boulder IETF in Nov '90), I was Internet AD from then until the Spring of '92. From the creation of the ROAD show (in the Fall of '91), things got out of control, and I should have done more than I did to try and get them under control. We've gotten to this pass one day at a time, and looking back over old mail, I don't see any day when we decided to have this set of competing IPng designs, or even a day when it became inevitable. We slowly drifted from one thing into another, from running out of class B's, to routing table explosions, to 32 bits being used up, with the TCP/ISO wars mixed in; things just got out of hand, and this is what we wound up with. Maybe that's 20-20 hindsight, but I think it's of some relevance as we ask to what degree the IESG and IAB should try and lead the IETF, as opposed to simply managing things that grow from the grass-roots on up. Anyway, the important question is: what's the best way forward from here? The only rational answer I can see is to admit our failings, admit we all screwed up, put the current IPng efforts to the side, and go back and perform the kind of rational design process you'd hope to see with something this important. We ought to decide on what a new internetwork layer ought to do, and then decide how it's going to do it, and then worry about how the bits look. We need an IPng architect to lead this (and I suggest we get Dave Clark, if we can convince him to do it). When that process is done, there may be some pieces of various IPng efforts that are useful, but until that is done, arguing about SIPP versus TUBA versus CATNIP versus whatever is just the most miserable and third rate waste of time. Let's stop acting like disorganized and incompetent amateurs, and start acting like what we actually really are: a crew of pretty good engineers, designers, and architects. Noel From owner-Big-Internet@munnari.OZ.AU Sun May 15 10:08:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19166; Sun, 15 May 1994 07:52:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA22450; Sun, 15 May 1994 07:30:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA22436; Sun, 15 May 1994 07:24:23 +1000 From: jcjones@MIT.EDU Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18999; Sun, 15 May 1994 07:46:09 +1000 (from jcjones@MIT.EDU) Received: from CARBONARA.MIT.EDU by MIT.EDU with SMTP id AA18806; Sat, 14 May 94 17:46:02 EDT Received: by carbonara.MIT.EDU (5.57/4.7) id AA25787; Sat, 14 May 94 17:45:56 -0400 Message-Id: <9405142145.AA25787@carbonara.MIT.EDU> To: big-internet@munnari.OZ.AU Cc: jcurran@nic.near.net Subject: New Proposal Date: Sat, 14 May 94 17:45:56 EDT As I promised several weeks earlier, a "make-most-people-happy" solution (to be released in July) is on the way featuring: 1. A virtually inexhaustible address space (300 million devices per person) 2. Efficient packet routing and small router tables (less than one meg each) 3. Mobility (truly dynamic, not quasistatic) 4. Simple network management 5. Autoconfiguration Before I release a proposal, I'm requesting input on two concerns: a. With the features above, do you _still_ want complete COMPATIBILITY WITH IPV4? Is a dual stack scheme okay/possible? b. How important is dynamic PROVIDER SELECTION? Can we do without it? If a user wishes to send packets from Boston to Hong Kong, must I include functionality that allows him to specify every carrier in between? *Please say no.* -J.C. Jones- P.S. - Some of you may already know this, but I will say it again anyway. This whole business with IP becomes much clearer if one maintains a panoramic view of the entire OSI stack while attempting to solve problems associated with the Network Layer. Oh, yeah, what's BOF? From owner-Big-Internet@munnari.OZ.AU Sun May 15 10:16:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19242; Sun, 15 May 1994 07:55:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA22465; Sun, 15 May 1994 07:33:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA22433; Sun, 15 May 1994 07:17:09 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18823; Sun, 15 May 1994 07:38:51 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA04919; Sat, 14 May 94 17:38:48 EDT Date: Sat, 14 May 94 17:38:48 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9405142138.AA04919@itd.nrl.navy.mil> To: jcurran@nic.near.net Subject: Re: IPng security, etc. Cc: big-Internet@munnari.OZ.AU % What about draft-ietf-tuba-inlsp-00.txt? I'll admit that I have not % completed my reading of it (as there's something quite unnerving about % the combination of OSI and security jargon in one document... ;-) John, A note to big-Internet within the last month from someone at NIST indicated that TUBA no longer plans to use NLSP. At Seattle, during the Thursday afternoon meeting of the Security Area Advisory Group (SAAG), I was drafted by the AD to outline what SIPP was doing for security. I did so at warp speed without any preparation. Someone from the audience asked about other IPng proposals. I commented that "TUBA apparently plans to use NLSP". I was corrected from the audience with a statement that TUBA did _not_ plan to use NLSP but instead would use the (currently non-existent) IPv4 Security Protocol instead. Friends of mine who work with and like OSI tell me that "NLSP is among the less readable OSI documents". I have a copy of NLSP and it is most assuredly a dense document. I don't claim to understand it. One of the few agreements reached so far in the IPv4 Security Protocol WG is that TLVs won't be used and that we will not just adopt NLSP for the IPv4 Security Protocol (as some other parts of the DoD wanted us to do). % ] If we are really serious about having a safer % ] Internet, then we need to start building security mechanisms into all % ] the systems. IPng, IMHO, should include security mechanisms (or at % ] least an authentication-without-confidentiality, for export control % ] reasons) in every implementation. % % 100 percent agreement. I'm not confident that we can specify an % architecture for security association establishment (which is desperately % needed to obtain the benefit of these security mechanisms) but it very % likely can be added (and/or improved) independent of IPng deployment. I dislike "structured" Security Association Identifiers (SAIDs) because such usage seems vulnerable to analysis by bad guys. I prefer psuedo-random SAID values. SAIDs appear to be necessary but not sufficient to identify a unique security session. It appears that the source identifying address/EID plus the SAID will be sufficient to identify a unique security session. If the key mgmt protocol uses the SAID as its "hook", then we should be able to figure out how to do it in a manner independent of IPng choice or deployment. I like the decoupling very much for several reasons, including but not limited to my employer's desire to be capable of cleanly substituting government key mgmt mechanisms and the long history of key mgmt protocols that weren't as secure as initially believed (e.g. Denning & Sacco's paper in ACM Operating Systems Review circa 1981; work by Cathy Meadows and others into formal verification of crypto protocols). Steve Bellovin is quite right (no surprise since he has forgotten more than I'll ever know on security) that the SIPP security work is largely reusable by any IPng (not to mention IPv4). Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Sun May 15 10:22:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19381; Sun, 15 May 1994 07:57:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA22480; Sun, 15 May 1994 07:34:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA22419; Sun, 15 May 1994 07:04:46 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18498; Sun, 15 May 1994 07:26:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07204; Sat, 14 May 94 17:26:27 -0400 Date: Sat, 14 May 94 17:26:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405142126.AA07204@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: re: Requirements Cc: jnc@ginger.lcs.mit.edu From: Craig Partridge >> My view is that the IPng decision this summer is only the first step in >> a series. We'll decide on the protocol and with it a general >> philosophy. > None of the proposal has what I would dignify as a "general philosophy" I'm afraid I disagree on this point. For instance, I believe it is safe to say that there were three major philosophical points behind SIP: We seem to be using the term "general philosophy" to mean two distinctly different things. The first is what is commonly called a "design philosophy"; i.e. a style of design. I don't consider things like "keep it as simple as possible for the given functionality" and "make it efficient" as real elements of a design philosophy, since any competent engineer will adhere to these. The question of design philosophy comes in more when it comes to tradeoffs like "robustness versus complexity" and "flexibility versus complexity". For example, two independant mechanisms to do something are more robust than one, but is the extra complexity worth it? Here, there's no simple answer, and different applications result in different optimal values for these tradeoffs. I'm usually one for very simple designs (as Dave Clark no doubt remembers from many harangues aof mine at MIT :-), but given the special circumstances inherent in a global communication network (where failure is serious, and change difficult), I've turned the knobs a little further toward flexibility and robustness than I normally might. The second thing that might fall under the rubric of "general philosophy" is the overall "architectural philosophy" of the design. Given the desired functional specification of a system, you have to have some overall scheme for breaking it up into subsystems, some ideas on how the subsystems will work together to provide the desired service, etc. Anyway, with that in hand, let's look at your list: * keep the packet format word-aligned I find it hard to call this anything much more than competent engineering; compilers keep data in structures word-aligned, so it's not that hard. and as minimalist as possible Again, no more complex than is needed is not exactly deep insight.. * keep the fast forwarding path fast Efficiency; again, competent engineering. * the packet header addresses the next entity that has to do something other than fast forwarding (i.e., options are encapsulated, and you send the datagram to the next router/host that actually has to examine the options) Now, this is a clever idea (and one I promptly stole for Nimrod, so you can tell I really do think it's a good idea, imitation being the sincerest form of flattery :-), but it's hardly "general philosophy". * transition from IPv4 should be straightforward Since no scheme without a reasonable transition strategy is even plausible in the real world, this amounts to little more than a recognition of reality. Those are enough points that its possible (though not always easy), when faced with the question of how do we support feature X, to determine whether feature X is supported by a header field or option. This is just about the smallest part of doing the design, and is trivial to answer. Anything used by much less than 1% of the packets gets an option; anything used by much more is a field. These points offer little help in some of the really tricky design questions, such as "for a field which is critical to the correct operation of the protocol, and which is to be fixed length, do we either make it long enough so it can't possibly run out, or define now how to extend it when the evil day comes". (I'm not sure if "just close our eyes and stick out heads in the sand" is a valid option.) Then there are a whole host of architectural questions, such as "what is the interaction between rsource allocation and routing" and "do we aggregate non-related flows" which these points give no help with either. There's no routing protocol architecture there, but that's, in my view, right. We've changed routing protocols several times already, and will change them again. No. We've changed the routing protocol several time, but the overall routing architecture (hop-by-hop, based on addresses in the packet) has remained much the same. The syntax of the addresses has changed somewhat, but the semantics have stayed the same. We don't want to change the header format each time... IPng has to be a lot more than a header format. It has to have some coherent idea for what services it is going to provide, and how. The routing and addressing architecture is a key subsystem(s) in providing those services, and it interacts with other key subsystems, such as resource allocation, access control, etc. Unless you know how it's going to work, there's no way to say for sure you've got the right stuff in the header. Noel From owner-Big-Internet@munnari.OZ.AU Sun May 15 14:17:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00272; Sun, 15 May 1994 14:17:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA22813; Sun, 15 May 1994 13:55:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA22799; Sun, 15 May 1994 13:51:22 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00159; Sun, 15 May 1994 14:13:05 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa25310; 15 May 94 0:12 EDT To: Noel Chiappa Cc: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of Sat, 14 May 1994 23:19:18 -0400. <9405150319.AA08587@ginger.lcs.mit.edu> Date: Sun, 15 May 1994 00:12:03 -0400 From: John Curran Message-Id: <9405150012.aa25310@nic.near.net> -------- ] From: Noel Chiappa ] Subject: Re: Thoughts on the IPng situation... ] Date: Sat, 14 May 94 23:19:18 -0400 Actually, Noel, I agree with almost all of your response, minus one note: ] You're making an argument that you're going to save energy with your path. I ] don't believe it; human nature doesn't work that way. Once a proposal is ] selected, a major political campaign right there, there's going to be all the ] battles (over deployed code, installed base, etc) to change it. Anyone trying to avoid revisions due to their "installed base" of IPng software had best not get involved in IPng in the first place. No matter how we proceed, it's going take several iterative cycles to work out all of the very colorful interactions in IPng. Getting things working right is _very_ important before real users ever see IPng deployment schedules. One way to clearly communicate this to vendors is to simply remind them that prior to "Internet Standard" status, things can still change, and those who put unknowing users on draft standards take their chances of getting burnt. /John From owner-Big-Internet@munnari.OZ.AU Sun May 15 18:00:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02364; Sun, 15 May 1994 15:27:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA22879; Sun, 15 May 1994 15:05:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA22876; Sun, 15 May 1994 15:02:22 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27067; Sun, 15 May 1994 12:40:59 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa19928; 14 May 94 22:40 EDT To: Noel Chiappa Cc: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of Sat, 14 May 1994 18:12:05 -0400. <9405142212.AA07416@ginger.lcs.mit.edu> Date: Sat, 14 May 1994 22:39:53 -0400 From: John Curran Message-Id: <9405142240.aa19928@nic.near.net> -------- Noel, I'm not certain how many folks would actually reply to your musings, but felt that some reply was in order seeing as you called for such a radical change to our current direction. I find myself in general agreement with your assessment of how we _could have_ proceeded, but not in agreement on how we should best proceed from our current situation. ] From: Noel Chiappa ] Subject: Thoughts on the IPng situation... ] Date: Sat, 14 May 94 18:12:05 -0400 ] ... ] A responsible and coherent way to procede would have been to go ] through a process of deciding what functionality we wanted IPng to provide ] (e.g. "looping packet detection"), and getting agreement on that; then ] sitting down and deciding what mechanisms we wanted to use to provide that ] functionality (e.g. "a hop count"), and getting agreement on that; then ] deciding from that the details of how big the fields are, where they are, ] etc. ] At the end, we'd have set of documents that describe the overall ] functionality of the interwork layer, what service model it provides to ] clients, and what it assumes or can use of the network layers over which ] it runs. We'd have had along with outlines of each subsystem, and an ] explanation of how each one used the fields in the internetwork header. Yes, it certainly would have been easier to get agreement on the functionality *first*, and then seek designs from interested teams of developers (with the goal of taking the best "core" and proceeding.) However, it would have required that we all agreed on the desired goal at the start of this task. The current IPng proposals actually started out with fairly different assumptions regarding what problem(s) they were trying to solve, and the extent to which the basic TCP/IP architecture could be changed. (e.g. Can we add flows, security, or mobility? Is this simply a network-layer change or can transport be "improved"? ...) Over time, there has been significant consensus reached on the necessary functionality: the requirements doc has been an attempt to capture that consensus on paper. It's possible that we would have moved faster without IPng proposals on the table; it's also possible that it would have gone slower as everyone tried to get the requirements bent towards unseen agendas. I'm actually quite pleased with the discussion that's occured over the last year or so; as a result, there are a number of requirements that I now understand the desire for even though I personally have no need for them... ] Anyway, the important question is: what's the best way forward from ] here? The only rational answer I can see is to admit our failings, admit we ] all screwed up, put the current IPng efforts to the side, and go back and ] perform the kind of rational design process you'd hope to see with ] something this important. Hmm. I asked a number of the proponents whether or not their proposal would be different if given the chance to "start over". The fact that some said "yes" concerns me, as it reflects a lack of freedom to change due to the investment (WG's, mergers, politics) that's occurred to this point. I wouldn't be so hasty to set aside the current proposals; many folks seem have grown quite fond of one or another, and asking them to set such aside runs contrary to human nature. It has been suggested that once an IPng proposal is selected, it will then be possible to "focus our efforts" and improve the proposal to the quality necessary to actually undertake deployment. In many ways, I hope this is true, as the task of developing a complete IPng quite is daunting, and we're going to need a lot of volunteers to make significant progress. Given the time that will be required till actual deployment, it should even be possible to undertake your "design process" in parallel with IPng experimentation, and to feed results back into the appropriate working group for consideration. If you think of the current IPng proposals as "prototypes", then running a formal design process in parallel makes some sense. ] We ought to decide on what a new internetwork layer ought to do, ] and then decide how it's going to do it, and then worry about how the bits ] look. We need an IPng architect to lead this (and I suggest we get Dave ] Clark, if we can convince him to do it). I agree that you need an IPng architect to undertake such a design process, one might claim that we went through all of these convolutions because we had _too many_ IPng architects... ] When that process is done, there may be some pieces of various IPng ] efforts that are useful, but until that is done, arguing about SIPP versus ] TUBA versus CATNIP versus whatever is just the most miserable and third ] rate waste of time. Hmm. Arguing about the proposals is remarkably inefficient, but I still claim there is value to the extent that all the participants are willing to keep an open mind, and respect the requirements expressed by each proposal. ] Let's stop acting like disorganized and incompetent amateurs, and ] start acting like what we actually really are: a crew of pretty good ] engineers, designers, and architects. Abandoning the current work to date and undertaking your design process is certainly one way to proceed. Starting from a selected proposal (and the requirements document) is another. If one assumes that the selected proposal is to be used "as is", then I find myself in strong agreement with your approach. If, on the other hand, it will be possible to alter the selected proposal (including modifying architectural aspects) then I don't think we can justify abandoning the significant work that has been done already. /John From owner-Big-Internet@munnari.OZ.AU Sun May 15 18:25:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03297; Sun, 15 May 1994 16:02:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA22931; Sun, 15 May 1994 15:40:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA22906; Sun, 15 May 1994 15:22:51 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28389; Sun, 15 May 1994 13:19:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08587; Sat, 14 May 94 23:19:18 -0400 Date: Sat, 14 May 94 23:19:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405150319.AA08587@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, jcurran@nic.near.net Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu From: John Curran I find myself in general agreement with your assessment of how we _could have_ proceeded, but not in agreement on how we should best proceed from our current situation. I understand. I expect that many people will think I am being naive and simplistic. I did think about this for quite a while, though. I really think that trying to craft some tricky path forward, to i) save technical/organizational face, and ii) not waste the investment to date, will in fact i) harm our reputation more than an admission of the true state of affairs (it's no secret to anybody, we just won't admit it, and ii) waste more time and energy going forward, in politics, getting people to agree to change things which are already "done", etc, than we'd save. Yes, it certainly would have been easier to get agreement on the functionality *first*, and then seek designs from interested teams of developers If we'd gotten agreement on functionality, and hopefully even on mechanism (more likely if we didn't have to pick between A's design, and B's), I'd have thought we wouldn't really need to have separate designs; it would be pretty much a slam-dunk from there. We could thus avoid the attendant difficulty of chosing one. Getting those agreements may not have been possible, but it would have been easier than trying to answer these questions through the murk of complete designs. However, it would have required that we all agreed on the desired goal at the start of this task. The current IPng proposals actually started out with fairly different assumptions regarding what problem(s) they were trying to solve Yes, and we should have argued about those technical issues openly, not buried in the politics of chosing A or B. Over time, there has been significant consensus reached on the necessary functionality: the requirements doc has been an attempt to capture that consensus on paper. Well, I get an very "non-full stomach" feeling reading that. There's a lot of generic design guidance, but there's not nearly as much detailed technical content as I'd have liked. This is not to knock Frank and Craig; they've been doing about as best they could, given the situation, but that document isn't what I wish it were. Hmm. I asked a number of the proponents whether or not their proposal would be different if given the chance to "start over". The fact that some said "yes" concerns me, as it reflects a lack of freedom to change due to the investment (WG's, mergers, politics) that's occurred to this point. Yes, and that's only *part* of the bad news. I wouldn't be so hasty to set aside the current proposals; many folks seem have grown quite fond of one or another, and asking them to set such aside runs contrary to human nature. Oh, you don't need to tell me that! However, think about it. If we pick one, the others are going to be losers anyway (modulo such pieces as we salvage for reuse). So, there's going to be a lot of disappointed egos Real Soon anyway. This way, nobody's a winner, but is that so much worse, really? They can all console each other, and they're all in the boat together. Anyway, I'm not saying put them all in the trash; I'm just saying put them to the side, go back and do what we should have done, in an atmosphere free of the "politics of chosing". Then, we can take them back up, if desired, and rework them to retain the good bits. It has been suggested that once an IPng proposal is selected, it will then be possible to "focus our efforts" and improve the proposal to the quality necessary to actually undertake deployment. In many ways, I hope this is true, as the task of developing a complete IPng quite is daunting, and we're going to need a lot of volunteers to make significant progress. Unfortunately, this is the kind of complicated path forward which I think will actually take more effort than the alternative. Picking X, just for the sake of picking something, so we can basically throw it away and start again seems really ludicrous. It's also wasteful of all the time, energy, and politics involved in picking, and then getting the designers of X to agree to make all the changes. It'll just make us look silly. If we want to appear responsible, let's do what we all know is right, no matter how mainful it looks. Given the time that will be required till actual deployment, it should even be possible to undertake your "design process" in parallel with IPng experimentation, Yes, but it's going to be much more difficult to make unbiased technical decisions if picking mechanism X for function Y means protocol Z is going to have to change. The Z proponents are going to be in there arguing not to use X, so they won't have to change their protocol, all their deployed software, installed base, etc, etc. If you think of the current IPng proposals as "prototypes", then running a formal design process in parallel makes some sense. Well, if they're just prototypes, why the hell are we going through this big song and dance to pick one? I always thought a prototype was something you built to learn from... Arguing about the proposals is remarkably inefficient, but I still claim there is value to the extent that all the participants are willing to keep an open mind, and respect the requirements expressed by each proposal. Yeah, there's some value, but the cost/benefit ration is pretty small. Most of the energy goes into ego, etc. You were talking about things which run run contrary to human nature; trying to have a clean, clear, technical debate this way just goes against the grain. Abandoning the current work to date I'm not talking about abandoning everything... Starting from a selected proposal ... is another. If one assumes that the selected proposal is to be used "as is", then I find myself in strong agreement with your approach. If, on the other hand, it will be possible to alter the selected proposal (including modifying architectural aspects) then I don't think we can justify abandoning the significant work that has been done already. You're making an argument that you're going to save energy with your path. I don't believe it; human nature doesn't work that way. Once a proposal is selected, a major political campaign right there, there's going to be all the battles (over deployed code, installed base, etc) to change it. The politics is going to go on, and on, and on, and the techical stuff is going to get stuck in the back seat. Putting on the brakes, and deciding to go about this the right way is really the best way to go. Noel From owner-Big-Internet@munnari.OZ.AU Sun May 15 21:52:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11712; Sun, 15 May 1994 21:52:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA23220; Sun, 15 May 1994 21:30:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA23195; Sun, 15 May 1994 21:03:07 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11229; Sun, 15 May 1994 21:24:52 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 15 May 94 20:18:35 +0900 From: Masataka Ohta Message-Id: <9405151118.AA20450@necom830.cc.titech.ac.jp> Subject: Re: Do we have an architecture? To: jcurran@nic.near.net (John Curran) Date: Sun, 15 May 94 20:18:33 JST Cc: brian@dxcoms.cern.ch, tracym@nsd.3com.com, big-internet@munnari.OZ.AU In-Reply-To: <9405141116.aa17647@nic.near.net>; from "John Curran" at May 14, 94 11:15 am X-Mailer: ELM [version 2.3 PL11] > ARP is sufficient for many applications, but it _does_ have some > characteristics that make it difficult to use in a dynamic environment. Dynamic environment should be taken care of by mobility. Interaction between mobility and ARP is well understood (HR proxy-arps MH). There is no difficulty in it. > ] In the archive, I have seen several complaints on broadcast storm in > ] CERN where 1,000 hosts are connected without routers. > ] > ] The problem is in poor management of CERN, not in broadcast. > > If you'd like (and are in New England sometime), I can give you a tour > of network reality where literally dozens of sites are running large > bridged environments and don't particularly plan on changing in the near > future. No, thank you. I already know there are a lot of poorly managed sites in the world. > Please do not extrapolate your views on how "networking should be > done" on others without knowing the full ranges of constraints (including > technical, political, and financial.) People who can't do things right, because of full ranges of (illusions of) constraints, will suffer no matter what we do. Fools are so creative in configuring systems wrongly. Still , the less configurable parameters (configurable by fools), the better. Thus, broadcasted ARP is a lot better than NBMA ARP. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sun May 15 22:27:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12113; Sun, 15 May 1994 22:27:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA23261; Sun, 15 May 1994 22:05:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA23258; Sun, 15 May 1994 22:02:06 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12041; Sun, 15 May 1994 22:23:51 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa21908; 15 May 94 8:23 EDT To: Masataka Ohta Cc: brian@dxcoms.cern.ch, tracym@nsd.3com.com, big-internet@munnari.OZ.AU Subject: Re: Do we have an architecture? In-Reply-To: Your message of Sun, 15 May 1994 20:18:33 +0200. <9405151118.AA20450@necom830.cc.titech.ac.jp> Date: Sun, 15 May 1994 08:22:52 -0400 From: John Curran Message-Id: <9405150823.aa21908@nic.near.net> -------- ] From: Masataka Ohta ] Subject: Re: Do we have an architecture? ] Date: Sun, 15 May 94 20:18:33 JST ] ] > ARP is sufficient for many applications, but it _does_ have some ] > characteristics that make it difficult to use in a dynamic environment. ] ] Dynamic environment should be taken care of by mobility. Interaction ] between mobility and ARP is well understood (HR proxy-arps MH). There ] is no difficulty in it. It's good to hear that it's so well understood, Masataka. Perhaps we should all ignore the discussion section (Appendix B) of since use of ARP with mobility is so straightforward? One might claim that we're going through quite a bit of additional complexity (gratuitous proxy ARP replies, related security issues, concern over lost messages) simply because ARP is not dynamic... Your original assertion was: ] ARP is a good design. There was some applications or systems which use ] broadcast in a wrong way. To prevent the effect of them minimal, we ] should make size of a single datalink layer as small as possible. I've change my mind; I agree with the above. ARP is a good design FOR A RATHER LIMITED PROBLEM SPACE. Happily, the current suite of IPng proposals all embrace a larger set of requirements, so we may not have to put up with ARP's contraints forever. /John From owner-Big-Internet@munnari.OZ.AU Sun May 15 23:02:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12480; Sun, 15 May 1994 23:02:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA23316; Sun, 15 May 1994 22:40:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA23299; Sun, 15 May 1994 22:26:32 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12314; Sun, 15 May 1994 22:48:18 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14274; Sun, 15 May 1994 14:48:16 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21031; Sun, 15 May 1994 14:48:15 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405151248.AA21031@dxcoms.cern.ch> Subject: Re: Do we have an architecture? To: tracym@NSD.3Com.COM Date: Sun, 15 May 1994 14:48:15 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199405132104.AA20693@remmel.NSD.3Com.COM> from "tracym@NSD.3Com.COM" at May 13, 94 02:03:59 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 572 Tracy. I agree that we can mainly agree. Just: > > ARP is a bad design; the fact that Ethernet allows trivial > > broadcast (and multicast) has led to numerous similar bad designs. > > This is religion. ARP was absolutely the perfect solution when it was > designed. Simple, clean, and MULTI-PROTOCOL too! It doesn't scale > well. ES-IS is certainly better(I think you can get by without an IS). > Not religion: emotion based on traumatic experience. You said it, ARP doesn't scale and some of us have no choice but to run absurdly big bridged networks. Brian From owner-Big-Internet@munnari.OZ.AU Sun May 15 23:04:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12511; Sun, 15 May 1994 23:04:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA23334; Sun, 15 May 1994 22:42:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA23302; Sun, 15 May 1994 22:39:48 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12470; Sun, 15 May 1994 23:01:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10844; Sun, 15 May 94 09:01:29 -0400 Date: Sun, 15 May 94 09:01:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405151301.AA10844@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, jcurran@nic.near.net Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu > You're making an argument that you're going to save energy with your > path. I don't believe it ... Once a proposal is selected, a major > political campaign right there, there's going to be all the battles > (over deployed code, installed base, etc) to change it. No matter how we proceed, it's going take several iterative cycles to work out all of the very colorful interactions in IPng. Getting things working right is _very_ important before real users ever see IPng deployment schedules. True, but I keep hearing people saying "we have to decide on an IPng so major manufacturer X can burn it into their code and ship 17 zillion set-top boxes", or whatever. This leaves us completely without the ability to do the kind of thing you're talking about; get the bugs out of it before everyone goes off and implements it. If they want something that works, and they want it now, then perhaps they really ought to use IPv4; maybe they have to use a private address space if their system is really huge, and have some sort of application gateway to connect up to other systems, but that technique will work. One way to clearly communicate this to vendors is to simply remind them that prior to "Internet Standard" status, things can still change, and those who put unknowing users on draft standards take their chances of getting burnt. Oh, but this never works. It's like RFC's; we keep saying "read the fine print", but everyone thinks and RFC is a standard. I just heard a story about one (major) manufacturer who implemented to an I-D and got really pissed off when something was changed, since they had all this deployed stuff... Noel From owner-Big-Internet@munnari.OZ.AU Sun May 15 23:37:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12747; Sun, 15 May 1994 23:37:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA23372; Sun, 15 May 1994 23:15:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA23321; Sun, 15 May 1994 22:40:51 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12485; Sun, 15 May 1994 23:02:37 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA17065; Sun, 15 May 1994 15:02:34 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21304; Sun, 15 May 1994 15:02:33 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405151302.AA21304@dxcoms.cern.ch> Subject: Re: Do we have an architecture? To: mohta@necom830.cc.titech.ac.jp (Masataka Ohta) Date: Sun, 15 May 1994 15:02:33 +0200 (MET DST) Cc: tracym@NSD.3Com.COM, big-internet@munnari.OZ.AU In-Reply-To: <9405140909.AA16565@necom830.cc.titech.ac.jp> from "Masataka Ohta" at May 14, 94 06:08:56 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1221 >--------- Text sent by Masataka Ohta follows: ... > In the archive, I have seen several complaints on broadcast storm in > CERN where 1,000 hosts are connected without routers. > > The problem is in poor management of CERN, not in broadcast. > Oh, thanks, we'll fix it tomorrow. COME ON! Do you think we run the network the way we do because we are stupid? I don't NEED this sort of comment on public lists, THANK YOU! (Well, that made me feel a little better. Now let me explain why we run a 6000-node bridged Class B network. Because our users need to move equipment every day and DHCP is not implemented by most vendors. Because we need megabytes/sec of throughput and MTU Discovery is not implemented by most vendors. Because we need site-wide LAT which is not routable. Because routers on the market don't support IP multicast and we couldn't afford an extra box on every subnet. Because until we finish migration to DECnet/OSI we can't figure out how to route DECnet cleanly. Because buying enough high performance brouters would annihilate my budget.) BTW the network actually works quite well. It would have been easier to get it that way without ARP, that's all. Needless to say we don't run RIP. Brian From owner-Big-Internet@munnari.OZ.AU Mon May 16 00:12:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13758; Mon, 16 May 1994 00:12:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA23413; Sun, 15 May 1994 23:50:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA23377; Sun, 15 May 1994 23:15:44 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12745; Sun, 15 May 1994 23:37:30 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa25620; 15 May 94 9:37 EDT To: Noel Chiappa Cc: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of Sun, 15 May 1994 09:01:29 -0400. <9405151301.AA10844@ginger.lcs.mit.edu> Date: Sun, 15 May 1994 09:36:32 -0400 From: John Curran Message-Id: <9405150937.aa25620@nic.near.net> -------- ] From: Noel Chiappa ] Subject: Re: Thoughts on the IPng situation... ] Date: Sun, 15 May 94 09:01:29 -0400 ] ] ... ] One way to clearly communicate this to vendors is to simply remind them ] that prior to "Internet Standard" status, things can still change, and ] those who put unknowing users on draft standards take their chances of ] getting burnt. ] ] Oh, but this never works. It's like RFC's; we keep saying "read the fine ] print", but everyone thinks and RFC is a standard. I just heard a story about ] one (major) manufacturer who implemented to an I-D and got really pissed off ] when something was changed, since they had all this deployed stuff... You can't have it both ways: either we're willing to obsolete trial deployments, or we promote technically inferior standards simply because they were deployed before the standardization process was complete. We're not talking about a telnet option here; we're discussing the next network-layer protocol for internetworking. If someone shows up with significant improvements (backed up by running code and rough consensus) during testing and trial deployments, we _change_ IPng. Once we reach Internet Standard, we can acknowledge an installed base and do those "incremental improvements" that IETF has been so good at in the past. /John From owner-Big-Internet@munnari.OZ.AU Mon May 16 00:47:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14268; Mon, 16 May 1994 00:47:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA23473; Mon, 16 May 1994 00:25:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA23459; Mon, 16 May 1994 00:24:34 +1000 Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14259; Mon, 16 May 1994 00:46:21 +1000 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA20725); Sun, 15 May 94 09:46:06 CDT Received: by sabine.is.rice.edu (AA05740); Sun, 15 May 94 09:43:35 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9405151443.AA05740@sabine.is.rice.edu> Subject: Re: Thoughts on the IPng situation... To: jcurran@nic.near.net (John Curran) Date: Sun, 15 May 1994 09:43:34 -0500 (CDT) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <9405150937.aa25620@nic.near.net> from "John Curran" at May 15, 94 09:36:32 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 512 I think that there is a minor point that neither you or Noel has seen. IF (thats a big one) a company can do -planned- obsolesence, then they have a built in migration path. Witness Nintendo/Sega on the 8/16 bit game conversion. Or closer to home, the LattisNet/Synoptics 10bT episode and the current 100M/ethernet and V.fast stuff. Companies -will- build stuff that has a very limited lifetime for a number of reasons. People will buy it -if- they are told upfront the risks. -- Regards, Bill Manning From owner-Big-Internet@munnari.OZ.AU Mon May 16 00:50:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14309; Mon, 16 May 1994 00:50:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA23488; Mon, 16 May 1994 00:28:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA23456; Mon, 16 May 1994 00:11:30 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14099; Mon, 16 May 1994 00:33:12 +1000 (from kre@munnari.OZ.AU) To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: big-internet@munnari.OZ.AU Subject: Re: Requirements In-Reply-To: Your message of "Fri, 13 May 1994 16:42:15 MST." Date: Mon, 16 May 1994 00:33:11 +1000 Message-Id: <18053.769012391@munnari.OZ.AU> From: Robert Elz Date: Fri, 13 May 1994 16:42:15 -0700 From: dcrocker@mordor.stanford.edu (Dave Crocker) Message-ID: Do I think that one of the alternatives is vastly better? You bet! Do I think that there will be major problems with the alternatives? You bet! Dave - I'm quite sure that there are several, perhaps even many people who agree with you. Some of them probably even share your belief as to which of the contenders is better. A problem is that others don't (well that's OK, that's the point of the IPng directorate). A bigger problem is that I suspect that some of those people who disagree with you also see major problems with some of the other protocols, and that some of those problems are with the candidate that you favour. Some of us who aren't in any camp at all see major problems with all of the candidate protocols. But that is quite different from saying that NONE of the alternatives is acceptable. So it turns out it isn't. At the minute if I had a vote I'd vote for "none of the above", because from what I've seen none is suitable as a protocol for the future. If we really were pressed so hard that we couldn't afford another six months, or year, to work on getting the problems out, then I'd probably agree that we should pick one now, simply because we would die if we didn't - but I simply don't believe that. Having said that, if we were forced to pick right now (and July counts as "right now") I think I'd have to (reluctantly) go with TUBA, as it looks to have less serious problems, and perhaps more importantly, looks likely to be able to be deployed a little quicker - recall the only reason for "pick now" is that there is an *urgent* need for immediate deployment. If we can defer things for a while, then I think that SIPP looks to be the best of the contenders for long term viability, but I really don't think its ready yet. For now, "none of the above" is the right solution. The only rational alternative is "X, with major modifications", whose only point being to try to get everyone to work together. With the latter in mind, could I ask those working on the various candidates to reply and let me know what you're going to do when your candidate is rejected? Will you switch to work on the successful candidate? Will you give up in disgust and go do something else entirely? Will you continue working on your favoured protocol despite its being rejected? Note that I'm asking individuals, not for any kind of group response. You can reply to me personally if you'd prefer. If I missed a plausible answer, feel free to specify it. kre Aside: way back in my schooldays my German teacher made it quite clear that I was never to use "alternatives" when there were more than 2 choices. His theory was that we had to learn English or we'd never master German. I didn't do either... From owner-Big-Internet@munnari.OZ.AU Mon May 16 00:51:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14327; Mon, 16 May 1994 00:51:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA23503; Mon, 16 May 1994 00:29:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA23442; Mon, 16 May 1994 00:08:33 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14072; Mon, 16 May 1994 00:30:18 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA20476; Sun, 15 May 94 10:29:31 -0400 Message-Id: <9405151429.AA20476@rodan.UU.NET> To: big-internet@munnari.OZ.AU Subject: Noel's lamentations... Date: Sun, 15 May 1994 10:29:30 -0400 From: "Mike O'Dell" One the one hand, I certainly understand how Noel feels and don't disagree with with the sentiment, in vacuuo, so to speak. However, this ain't a vacuum. Noel argues for tearing off a blank sheet of paper and starting over. That is an interesting thing to do, but rather risky for a number of reasons, the most important being that you have no reason, beyond faith, to believe you will actually get a better answer, and it is certainly much harder to predict *when* you'll have an answer. Rightly or wrongly, when this first started, it was believed, I think, by most of the alternative creators that the problem was relatively bounded and that modest deltas off existing, known-working solutions would be prudent engineering. I cannot fault this approach for an instant given that reasonable belief. What I think has happened here in the requirements process is that the depth of the architectural issues which need addressing for long-term scaling are now understood to a *very* different degree than when this first started. It is true that some visionaries, like Noel, have been trying to get people to think about all these issues in a systems kind of way for a while now, but this effort has brought the issues into a sharper focus for a much broader community of people than ever before. And guess what, providing everything from soup to nuts is a daunting proposition. In fact, providing all of them requires solving problems which are genuine, certifiably-hard RESEARCH problems. One of the saving distinctions between "the IETF way" and "Other Systems Investigations" is that we don't just take the requirements document, transpose the matrix, and call it done. The process of developing these alternatives has revealed much about these problems. True, this insight might have been achieved by other, more contemplative means, but you takes enlightenment where you find it. And further, as "correct" as he might be in the academic abstract, I think Noel's self-flagellation does a disservice to a number of very smart people who have been looking at this. One other point Noel makes is very alluring, but not really true, I don't think. He argues that if we *really* understood the requirements, and maybe settled on the mechanism, then the "packet format" would be "slam-dunk" self-evident. Maybe to Noel, but given the number of ways even good engineers can accomplish "the same thing", ignoring any spin control, I think he materially underestimates the energy required for real closure and the inevitability of some level of ego involvement. I won't deny for an instant that this is the way he feels it *should* happen, and I would love for it to be that way, but my experience tells me otherwise. So given that we are *here* and not somewhere else, no matter how interesting it might be to be somewhere else, what do we do? Noel suggests dropping back 50 and punting. Let me suggest an alternate view. If, in fact, we could identify some concrete fact or cluster of facts which we can say, with a high-degree of certainty, which if known (better) would materially effect the outcome of the decision, and if we can bound the amount of time it will take to develop that cluster of facts, then one could argue pursuasively for waiting while performing the experiment of doing the bit of research which would produce those new facts. If, however, we are in the position that the only way we will know enough to make a knowably *significant* change in the decision is to wait until the future unfolds, either we have to find someone with a Tardis, or we find ourselves in the position of engineers rather than architects. Engineers are paid to make the best decisions they can make given the constraints dictated by the Real World and on time-lines dictated by external reality. Sure, this can sometimes result in delivering the wrong thing on the right schedule, and *sometimes* that is fatal, but usually it is not - otherwise there would be many fewer companies in the world. And "wrong" is a relative measure - what is "wrong" may be the best thing in the marketplace since its surrounded by worse competitors. (furtive glance in the direction of IPv4....) THe point is that you cannot tell the future very far in advance, and the people running around demanding that everything we do here be perfect for the next 20 years are just simply nuts. Yes, IPng will be around in 20 years, as will Fortran, and for the same reasons. But it is safe to assume that *something* which materially shifts the model will happen in 20 years and if you are smart enough to predict that, why are you wasting time on this (oh, right, you are already rich - grin). And maybe we get lucky and it all works out Fine - 20 years and IPng "takes a licking and keeps on ticking." IPv4 certainly has. BUT YOU CAN'T KNOW. AT worst, it's a crap-shoot, and at best, you may manage to load the dice, but you don't even get to know this much. SO you get all the data you can, collect everyone's prognostications and secret wish lists, and then you pick the heading and sail on. Maybe good, maybe bad, maybe we coulda done better if we had done it differently, but only *now* we know that, and it doesn't help now. So next time we listen to Noel, OK? -Mike From owner-Big-Internet@munnari.OZ.AU Mon May 16 01:22:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14553; Mon, 16 May 1994 01:22:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA23547; Mon, 16 May 1994 01:00:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA23519; Mon, 16 May 1994 00:34:59 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14369; Mon, 16 May 1994 00:56:46 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405151456.14369@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 15 May 1994 15:56:21 +0100 To: tracym@NSD.3Com.COM Cc: big-internet@munnari.OZ.AU Subject: Re: Do we have an architecture? In-Reply-To: Your message of "Fri, 13 May 94 10:08:11 PDT." <199405131708.AA20169@remmel.NSD.3Com.COM> Date: Sun, 15 May 94 15:56:18 +0100 From: Jon Crowcroft >Two machines can talk simply by plugging into the same wire (no manual >configuration, except possibly for a name, is needed) persoanlly, there is little about any IPNG proposal that stops you haveing plug&play the main thing that stops it (and for IPv4) is lack of effort by the vendors...which is curious given the user demand (or maybe the user demand is less than people claim....is this lack of product evidence?:-) it'd be easy for them to pre get C blocks (or whatever,) and have a machine plug in with a default net that will allow one time use to dial them up & autoconfigure apporopriately for whetre the m/c is... except for security concerns...and you could use a 1 time kerberos approach... main thing stopping that, of course, is US export and now defunct cocom... jon From owner-Big-Internet@munnari.OZ.AU Mon May 16 01:25:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14579; Mon, 16 May 1994 01:25:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA23562; Mon, 16 May 1994 01:02:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA23544; Mon, 16 May 1994 00:59:16 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14544; Mon, 16 May 1994 01:20:53 +1000 (from kre@munnari.OZ.AU) To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: sipp@sunroof.Eng.Sun.COM, big-internet@munnari.OZ.AU Subject: Re: continuing EID discussion In-Reply-To: Your message of "Thu, 12 May 1994 10:12:05 +0200." <9405120112.AA20949@cactus.slab.ntt.jp> Date: Mon, 16 May 1994 01:20:51 +1000 Message-Id: <18067.769015251@munnari.OZ.AU> From: Robert Elz This is a response to (yet another) message on the SIPP list that clearly really belongs on Big-Internet, so I'm moving this one. While I'm only replying to a small part of this message, I will include all of Paul's message for the benefit of B-I readers not on the SIPP list. Date: Thu, 12 May 94 10:12:05 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405120112.AA20949@cactus.slab.ntt.jp> let me say that I hope nobody is still considering the notion of requiring EIDs for IPng. I certainly am. As I said before, we should specify requirements, not solutions. EIDs are requirements, not solutions. Or, if the acronym invokes bad vibes, then the requirement can be stated as ... IPng must provide a method to transmit location independant identifiers for the use of transport protocols, and others, and the definition the uses of TCP and UCP over IPng must include using this location independant identifier in their pseudo-checksums. To me, that is requiring EIDs (and one specific use for them). There's a reason for this - apart from all the other likely uses of EIDs, defining the transport level to use this location independant (and hence routing useless) identifier enables the IP layer to be upgraded much more seamlessly if (when) needed in the future. Pulling one network level header off, doing address (locator) substitution if needed, and sticking a modified header on as packets flow from one region of the net to another is a possibility. What won't be is fiddling TCP to manipulate its checksum to account for changes in the identifier it uses. That may be possible now, most of the time, but we have to assume that in the future at least some packets will either be encrypted, or signed, above the network level, meaning that modifications are impossible - modifications at the net level have to be permitted to allow things like hop counts to be adjusted, and for manipulation of options, etc. To be precise, let me first say what I'm advocating. I'm arguing for an identifier that 1) is used by transport layer, instead of "locators", to distinguish among different network layers, This I agree with. 2) is used by routers to determine last hop routing (that is, it is the node ID or host ID of a locator), this is a solution, not a requirement, and while I agree with it as a possibility, I wouldn't require it. and 3) is administered by vendors not users (it comes attached to computers out of the box). But this I asbolutely (and totally) disagree with. I require a mapping from EID into name, that is I want EIDs to be *the* binary identifier. To make this mapping plausible, there has to be some kind of administrative relationship between EIDs owned by some administration (company, department, individual, whatever), so they can reasonably be made to fit into the DNS (or any other kind of directory). I do not require EIDs to be fixed for all time, they only need remain while any connection using them remains alive - if all connections die when a host is rebooted, and there is some way to handle dynamic DNS registration, then assigning a new (currently unused, not new for all time) EID to a host at boot time is just fine. I have no problem with a vendor assigned ID being used to acquire the EID from some kind of server, nor, if the organisation can manage it, to using it with some organisation prefix to form the EID, but using a vendor assigned number alone seems unworkable. Using vendor assigned numbers this way also eases the pressure on them to absolutely guarantee global uniqueness - their number only needs to be unique within the organisation in which its used, which means that occasional errors in id assignment by the vendors can almost certainly be tolerated - just as we usually tolerate duplicate IEEE assigned numbers today. kre Paul's message - if you've seen it before, no need to read any further.... Date: Thu, 12 May 94 10:12:05 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405120112.AA20949@cactus.slab.ntt.jp> To: sipp@sunroof.Eng.Sun.COM Subject: continuing EID discussion (was Re: FORMAL REQUEST : SIPP EIDs and Locators) Since the discussion of the Subject Re: FORMAL REQUEST : SIPP EIDs and Locators has degraded to counting angels and slinging mud, I have stopped reading it and am concerned that others have also stopped reading it and therefore didn't look at my reply to Steve and Christian, which I spent a fair amount of time and thought on. So, at the expense of sending the same message to the list twice, I here resubmit my message under the new Subject..... PF --------------------------------------------------------------- I want to rebutt the comments of Steve and Christian regarding the costs/benefits of EIDs. But first let me say that I hope nobody is still considering the notion of requiring EIDs for IPng. As I said before, we should specify requirements, not solutions. To be precise, let me first say what I'm advocating. I'm arguing for an identifier that 1) is used by transport layer, instead of "locators", to distinguish among different network layers, 2) is used by routers to determine last hop routing (that is, it is the node ID or host ID of a locator), and 3) is administered by vendors not users (it comes attached to computers out of the box). To make it clear that this is what I'm talking about, let me call this particular beast a VANITY (Vendor-Assigned Node-Identifying Transport Yodel). (If you're wondering about "Yodel", this is a reference to the ancient practice of Swiss herders identifying each other by their distinctive yodel. Yes, I'm making this up..... :-) In the following I quote Steve's message. I didn't save Christian's message, so I'll paraphrase what I remember him saying. > - EIDs are neither necessary nor sufficient to solve the problems > for which they are usually cited as a solution, e.g., multi-homing, > mobility, dynamic address changing. This is true except for the case of "serverless" host address auto-configuration, which I believe to be a very important requirement, and which I think is the primary benefit of VANITYs. I think this use alone justifies the use of VANITYs. The other uses (Steve mentions) are icing on the cake, but I agree with Steve that these can be done other ways, as shown with SIPP. > - EIDs are yet another name space to be allocated and managed, in addition > to addresses and DNS names. Our experience with our existing name > spaces makes me *very* loath to create another, especially without a > *very* concrete reason. > Christian also mentioned the cost of managing "another" name space. I would like to argue, to the contrary, that the use of VANITYs very significantly *reduces* the cost of name space management--specifically because they allow for host auto-configuration. Let's assume that most of the cost of name space management is human cost. Currently, hundreds and soon (if not already) thousands of people are involved in assigning millions of IP host numbers. Further, those are the people who are the least qualified to be assigning numbers (not because they aren't smart, but because it isn't their primary job, they're not networking gurus, etc.). If you use VANITYs, you move this function to a smallish number of vendors (some hundreds rather than many thousands), where the assignment process can be localized, focused, and probably largely automated. You save countless man-hours. >- It may well turn out that higher-level protocols will end up defining > higher-level IDs at a much finer grain than the EIDs that have been > proposed in this community, for example, globally unique process IDs > in support of fine-grain process migration. (See the VMTP protocol > spec for one example of such an approach.) Such higher-level IDs > are likely to make EIDs redundant. I think this is a wash. Probably a good way for an application to manage such a number space is to take the network layer identifier and append some additional information specific to that application. If the network layer identifier is an address (i.e., combination locator/identifier), then the address also is "redundant". Either way, you are replicating some information. However, if you believe VANITYs to be stable for longer than addresses, perhaps the use of VANITYs to help manage the application EIDs is better than the use of addresses. >- In the most common case, where the locating semantics of either or both ............ > of changing addresses, or whatever), requiring the presence of pure > EIDs would make the packet header significantly larger than it would > otherwise be. True, the price we accept for our connectionless internet Agreed. > model is a large header on every packet. But I think we have a duty as > designers to make relatively efficient use of that header space, since > it is a "tax" imposed on every packet. I am particularly concerned I agree. If all other things are equal, we should favor smaller headers.....but...... > about header size because I see increasing use of encapsulation as a > multi-purpose mechanism in the Internet, such that many packets may > end up carrying multiple SIPP headers on at least some part of their At least some of the reasons for such encapsulations would be eliminated if we had VANITYs (for instance, the use of encapsulation for getting mobility). > journey. I'm also concerned with making it possible to forward SIPP > packets at very high speed, and keeping the basic header size relatively > compact is one part of that (e.g., more likely to fit into a cache line, > when using a general-purpose processor as a packet switch). Mumble. Maybe so. The use of VANITYs doesn't increase the amount of info that has to be examined, though, so perhaps with some care one can manage to funnel only the needed info into the cache line. I don't know for sure, and it probably differs significantly from machine to machine. Another point is that the VANITY might help high speed switching because it can be used as a flow ID, blah blah mumble hand wave. > A common answer to the large header size issue is to suggest using > header compression over slow links. Besides the fact that that > does not address the high-speed forwarding issue, another problem > is that our current strategy for header compression in IPv4 only works > for TCP traffic and relies on certain properties of TCP. However, I > expect much of the high-volume traffic in the future to be UDP, e.g., What? High volume over slow links? If you can solve that one you can become a rich man! :-) If it is high volume (and therefore high speed), you by definition don't need header compression. > real-time audio and video. I don't know what's involved in building > a robust header compression scheme for SIPP/UDP headers (there's a > good project for someone to work on!), but I'd rather not depend on I agree. In fact, SIPP could use this like yesterday.... > it being easy or cheap to do. Another, perhaps unfounded, concern is > that compression spends CPU cycles to save bandwidth, but we may want > to support nodes that are starved for *both* CPU and bandwidth, e.g., > very low-powered wireless devices. I suspect that a machine that is starved for CPU and bandwith will not be exchanging packets simultaneously with a large number of other devices, and therefore compression should work well at low cost (i.e., lots of redundancy from packet to packet). Ok, finally I want to address Christian's comments (and Minshall has also mentioned this) about the non-uniqueness of IEEE 802 numbers. I agree that this is a problem, but I wonder how much. In the context of SIPP, the spec is very specific about requiring the use of "universally administered" 802 numbers. Thus, I *hope* that the "soft" assignments of 802 numbers doesn't apply. As for sloppy practice by vendors resulting in duplicate "universally administered" 802 numbers, at least with SIPP this should rarely cause a real problem (unless I'm missing something). *If* we get SIPP hosts to *always* assign a different flow ID for each route sequence it is using, then duplicate 802 numbers only cause a problem when 1) the hosts with the duplicates are talking to the same machine, 2) the flow IDs are the same, and 3) the other identifiers, such as transport socket, are all the same. I think that the probability of this is small enough that failures caused for this reason will be in the noise compared to failures caused for other reasons. /* start aside */ As an aside, this is *yet another* good reason to have hosts always assign a flow ID. I'm now thoroughly convinced that the cost of doing this is well worth it. Off the top of my head, the benefits are: 1. Hosts receiving packets can use the flow ID to detect a change in route sequence. Thus, they don't have to parse through the route sequence every time. 2. Routers can use the flow ID to identify flows. My gut feeling is that 90% or more of real time could be handled without explicit flow setup. 3. If not 2, then at least routers can use it to aid their caching strategies (I know that there are other issues here, like how to advance ther route header). 4. "Fixes" the blatant distant-snooping security hole introduced by route sequence reversal. (Sorry Ran, but having thought about this more, I remain convinced that this technique is useful for this purpose.) 5. The duplicate VANITY problem. /* end aside */ Actually, this notion that a host can successfully talk to multiple other hosts that have the same VANITY is interesting to me (not that I'm advocating it). Specifically, it makes me ask what the point is to IP header authentications, especially in the absense of higher-layer authentication. As long as packets can successfully get from source to dest and back, what does the network layer care about authentication? The application cares about authentication, but authenticating the network layer for the purpose of authenticating the application seems weak and more expensive than doing it at the application. Maybe I'm just being dense, but can someone please re-iterate for me why we need to authenticate at the network layer? PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 01:57:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14868; Mon, 16 May 1994 01:57:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA23603; Mon, 16 May 1994 01:35:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA23600; Mon, 16 May 1994 01:32:07 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14820; Mon, 16 May 1994 01:53:53 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA03216; Sun, 15 May 1994 08:53:40 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 May 1994 08:53:43 -0700 To: John Curran From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU At 12:35 PM 5/14/94, John Curran wrote: >but none of the demos that I've seen to date would be called a "complete" >(or even "minimal") IPng suite. Autoconfiguration may have been present >in some cases, but not autoregistration. Routing varied from production >protocols to completely static. Transition support varied from prototype >to none-at-all. Security wasn't, mobility (except in the local area) >wasn't supported, and multicast wasn't present in most cases. John, As I said, they weren't product. Also, autoconfiguration, autoregistration, security and mobility were not part of the requirements list at the time. A point people keep missing is that we have heaped a wide range of useful but complicated and new features onto IPng. While these features will be useful they are not really essential to initial deployment. We are, after all, living without them now. Yes, we want to add those features and yes, we need to have a basis for believing they CAN be added. But we are living without them now. By definition, they are not required for inital deployment. Hence, counting them against the validity of the early demos is, in my opinion, itself not valid. Dave Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Mon May 16 03:07:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15402; Mon, 16 May 1994 03:07:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA23678; Mon, 16 May 1994 02:45:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA23675; Mon, 16 May 1994 02:40:30 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15375; Mon, 16 May 1994 03:02:17 +1000 (from kre@munnari.OZ.AU) To: Bob Smart Cc: big-internet@munnari.OZ.AU Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Sat, 14 May 1994 10:42:35 +1000." <199405140042.AA03116@shark.mel.dit.csiro.au> Date: Mon, 16 May 1994 03:02:17 +1000 Message-Id: <18100.769021337@munnari.OZ.AU> From: Robert Elz Date: Sat, 14 May 1994 10:42:35 +1000 From: Bob Smart Message-ID: <199405140042.AA03116@shark.mel.dit.csiro.au> One advantage of the separate EID approach is that EIDs don't have to be allocated in power-of-2 boundaries and organizations can go back for more without worrying about contiguity. So there is no need for companies to hoard. Exactly - though I'd keep to powers of 2 allocations, and in fact, I'd stick to powers of 256 allocations (ie: 8 bit chunks). That's for reverse mapping registration issues. I don't see that as a problem, 64 bits has a very large number of 256 sized blocks, quite enough in fact. And 256 numbers at a time seems like the right allocation unit for EIDs for most reasonable sized organisations - say up to the size of a large university (like this one). I doubt we'd obtain 256 new systems in less than a few months, applying for a new block of numbers every few months doesn't seem onerous. Note: this is new, ie: additional, systems, not counting replacements, for which the old EIDs can be reused - which is another reason I really don't want to be using manufacturer assigned numbers. Very large organisations, like major companies, large research bodies like Bob's organisation, etc, may reasonably request 2^16 (65536) EID's in one request, even then we have 2^48 chunks to give out - equivalent to four times the total available space of IEEE numbers (excluding wastage), which is certainly plenty (I knoww there are some who believe that IEEE numbers would be suitable as EIDs themselves, though I don't believe that myself, 48 bits isn't enough, and the allocation policy is all wrong). kre From owner-Big-Internet@munnari.OZ.AU Mon May 16 04:17:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15914; Mon, 16 May 1994 04:17:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA23756; Mon, 16 May 1994 03:55:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA23717; Mon, 16 May 1994 03:23:45 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15630; Mon, 16 May 1994 03:45:32 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-22.dialip.mich.net (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA23315 for ; Sun, 15 May 1994 13:45:28 -0400 Date: Sun, 15 May 94 16:03:46 GMT From: "William Allen Simpson" Message-Id: <2392.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Pick one, look at the rest > ********** > FOLKS: Jim and I would appreciate some comments from the peanut gallery. > Is the community going to be satisfied with a 'none of the above' > recommendation by the directorate?? Inquiring minds want to know. > ********** > None of the above is not an acceptable choice to me. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon May 16 04:19:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15931; Mon, 16 May 1994 04:19:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA23771; Mon, 16 May 1994 03:58:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA23720; Mon, 16 May 1994 03:23:52 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15635; Mon, 16 May 1994 03:45:39 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-22.dialip.mich.net (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA23324 for ; Sun, 15 May 1994 13:45:36 -0400 Date: Sun, 15 May 94 17:21:59 GMT From: "William Allen Simpson" Message-Id: <2395.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: CDPD > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Many of these suggested new user communities (phone poles, TV set boxes, etc) > are unlikely to be directly connected to the Internet *anyway*. This is clear > in the case of the the CDPD folks, who picked CLNP. I mean, think it through: > using CLNP means they won't be interoperable with the Internet, right? (At > least at their basic level; they can always encapsulate.) However, if they > were willing to be non-interoperable, a viable alternative was to use IP with > a completely private address space. > I keep seeing this stated, but it doesn't jive with the CDPD spec. CDPD allows both IP and CLNP. Only IP is being deployed, unless something drastic has happened, and I didn't get the announcement. Of course, CDPD is 100 users all sharing 16Kbps in each single cell, which is pretty worthless as far as throughput. But it should work for only one user. Why would they ever deploy CLNP? A CLNP header would really kill throughput at those speeds! Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon May 16 04:52:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16190; Mon, 16 May 1994 04:52:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA23817; Mon, 16 May 1994 04:30:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA23787; Mon, 16 May 1994 04:08:45 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16014; Mon, 16 May 1994 04:30:31 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA06132; Sun, 15 May 94 13:31:30 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac03584; 15 May 94 18:22 GMT Date: Sun, 15 May 94 13:28 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Noel Chiappa To: "Tansin A. Darcos & Company" <0005066432@mcimail.com> To: jnc To: yakov Cc: big internet Subject: Re: IP Technical Criteria Message-Id: <33940515182833/0003858921NA5EM@mcimail.com> >So, it is just space savings, right? In that case, I'm not at all sure I >can agree it's a good move to allow this. It's a fairly minor optimization, >with potentially very bad consequences. >For instance, in the perceived push to save space, one might be tempted to >have a single overloaded field with compromise syntax, rather than having >separate EID and locator fields, each with optimal syntax for that purpose. >This will have a negative impact on the flexibility and adaptability, and >thus of the lifetime, of the design. I am running so far behind in mail.... There is another way to save space on slow links. The PPP wg is defining compression algorithms. Granted if you didn't have the bytes there to compress, the compressed packet is smaller. But it ain't all that bad. Yes I use V.42bis on slow links, but I know of the overhead of V.42bis and how a compression scheme in the PPP driver itself would be better. Bob From owner-Big-Internet@munnari.OZ.AU Mon May 16 05:27:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16441; Mon, 16 May 1994 05:27:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA23873; Mon, 16 May 1994 05:05:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA23861; Mon, 16 May 1994 05:01:39 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16393; Mon, 16 May 1994 05:23:26 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa13715; 15 May 94 15:23 EDT To: Dave Crocker Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Requirements In-Reply-To: Your message of Sun, 15 May 1994 08:53:43 -0700. Date: Sun, 15 May 1994 15:22:22 -0400 From: John Curran Message-Id: <9405151523.aa13715@nic.near.net> -------- ] From: Dave Crocker ] Subject: Re: Requirements ] Date: Sun, 15 May 1994 08:53:43 -0700 ] ... ] A point people keep missing is that we have heaped a wide range of useful ] but complicated and new features onto IPng. While these features will be ] useful they are not really essential to initial deployment. Oh, no, not *that* trick again... We tried the "use this, and we'll fix it later" approach with IPv4 TOS bits, with a net result that TOS never reached critical mass. Some of the "useful but complicated" features are actually necessary for continued growth of the Internet, particular to (a phrase you like to use) new communities of users. The fact that we are getting by now without these features does not not mean they're not required for deployment of IPng, it means that there are some things that we'd like to do with the Internet which we simply are not undertaking for lack of capability. Are these necessary for _initial_ deployment? Depends on how you define "initial", and what feature you refer to... I'd certainly be uncomfortable with any IPng production deployment prior to autoconfiguration and mobility specs, since the process of adding these might easily require changes to router discovery/ES-IS (hence invalidating any previously installed base). Don't worry, Dave, they'll be plenty of trials, bakeoffs, and testing of IPng (if that's what you're concerned about). Just don't think that IPng is going to start appearing in production networks until it's gone a few iterations. /John From owner-Big-Internet@munnari.OZ.AU Mon May 16 06:02:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16684; Mon, 16 May 1994 06:02:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA23945; Mon, 16 May 1994 05:40:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA23888; Mon, 16 May 1994 05:07:41 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16456; Mon, 16 May 1994 05:29:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12139; Sun, 15 May 94 15:29:26 -0400 Date: Sun, 15 May 94 15:29:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405151929.AA12139@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bill.simpson@um.cc.umich.edu Subject: Re: Pick one, look at the rest Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" > Is the community going to be satisfied with a 'none of the above' > recommendation by the directorate?? None of the above is not an acceptable choice to me. Could you provide a little bit of your thinking as to why? Noel From owner-Big-Internet@munnari.OZ.AU Mon May 16 06:37:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17029; Mon, 16 May 1994 06:37:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA23988; Mon, 16 May 1994 06:15:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA23985; Mon, 16 May 1994 06:11:46 +1000 Received: from wilbur.nas.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17004; Mon, 16 May 1994 06:33:33 +1000 (from lekash@nas.nasa.gov) Received: (from lekash@localhost) by wilbur.nas.nasa.gov (8.6.8.1/NAS.5.b) id NAA23173; Sun, 15 May 1994 13:33:28 -0700 Date: Sun, 15 May 1994 13:33:28 -0700 From: lekash@nas.nasa.gov (John Lekashman) Message-Id: <199405152033.NAA23173@wilbur.nas.nasa.gov> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU In-Reply-To: Noel Chiappa's message of Sat, 14 May 94 18:12:05 -0400 <9405142212.AA07416@ginger.lcs.mit.edu> Subject: Thoughts on the IPng situation... This whole IPng deal, from its roots in concerns about the IPv4 address space, on through ROAD, and on along through IPng, has been utterly back to front, and so totally and unbelievably amateurish it's incredible. That a standards body with responsibility for a key piece of the world's infrastructure is behaving like this is frightful and infuriating. I simply cannot find the words to express the depth of my professional contempt for what I've watched happen. A responsible and coherent way to procede would have been to go through a process of deciding what functionality we wanted IPng to provide (e.g. "looping packet detection"), and getting agreement on that; . . . Instead, people have been going off and designing packet formats on the backs of logical envelopes, putting together new ones over the weekend, and mostly doing whatever bits and pieces of the design are either easy or appealing. While I agree there are many aspects of pathetic in everything that is happening that is somehow related to IPng, I disagree with the idea that what you lay out is both responsible and coherent. You are just describing the difference between top down versus bottom up engineering process. Both need to happen, and at the same time if one wants to win. In another aspect of my life, I have been involved with the storage standards committee, where only did the first methodology you mention was done. (Ok, mostly its been people who work for me.) The net effect has been: 1. Its not complete. There are gaping holes in the standard, because no one had to be implementing as they go. They decided that certain aspects, (e.g. data and meta-data format) were simply not part of the standard. 2. There is no reference implementation. So, all sorts of people can claim to be compliant, and the net result is none of them interoperate. Its quite annoying to write hundreds of thousands of tapes, and not be able to migrate to another compliant system, because the database and tape format is not open. (Yes, I've avoided it, but few sites have.) 3. We've given up on that process, and simply walked away, as it shows no hope of producing viable results. Anyway, the important question is: what's the best way forward from here? The only rational answer I can see is to admit our failings, admit we all screwed up, put the current IPng efforts to the side, and go back and perform the kind of rational design process you'd hope to see with something this important. Actually, you should save it. Some coherent rapid prototyping along the way is really essential. We ought to decide on what a new internetwork layer ought to do, and then decide how it's going to do it, and then worry about how the bits look. We need an IPng architect to lead this (and I suggest we get Dave Clark, if we can convince him to do it). Yes, an architect would be good. But there are so many people who are psyched to be it. Six architects would not be good. john From owner-Big-Internet@munnari.OZ.AU Mon May 16 07:21:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17618; Mon, 16 May 1994 07:21:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA24097; Mon, 16 May 1994 06:59:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA24083; Mon, 16 May 1994 06:42:38 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17229; Mon, 16 May 1994 07:04:25 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA03868; Sun, 15 May 1994 14:04:13 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 May 1994 14:04:16 -0700 To: John Curran From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU John, At 12:22 PM 5/15/94, John Curran wrote: >Oh, no, not *that* trick again... I beg your pardon? My comment was neither a ploy nor a fantasy. It was, in my opinion, an accurate assessment of the method we use for creating and deploying technology. There is a simple choice: Plan fully and completely before building and deploying, or plan simply and tightly, then build and deploy, and then iterate as incremental functionality is deemed necessary and possible. Necessary AND possible. Most wish lists are reasonable. Most, in fact, are likely to get agreement about their utility and maybe even their necessity. But knowing HOW to solve a problem in a way that will work adequately (efficiency, robustness, scaling, ...) AND gain community consensus is what we find takes so much time. Worse are the cases in which we don't even know HOW to solve the problem. I assume that you don't want us to wait until we solve all those problems before deploying IPng? If you do, it will be 10 years. Maybe more. We have examples of this delay from other standards efforts. The Internet approach is generally deemed superior. >We tried the "use this, and we'll fix it later" approach with IPv4 TOS EXACTLY!! Do not specify something whose near-term utility is not reasonably well understood. "Placeholders" are not a good idea. The SNMPv1 security field is another example. And we keep seeing it. It means that you either design, build and deploy what you DO know now, or you wait for some indeterminate time until a "complete" solution is possible. But like "free beer tomorrow", tomorrow is never today. What is deemed "complete" for today will not be sufficient by the time we can satisfy the original list. Hence, the Internet approach is to prune rather than expand requirements lists, so that we can satisfy the common, clear, immediate core of requirements, while having some sense of the next-round of effort and some sense that it can be added to the core. This sounds ludicrous. No one would ever design a design process like this. It clearly cannot produce successful specs. But it does. >Are these necessary for _initial_ deployment? Depends on how you define >"initial", and what feature you refer to... I'd certainly be uncomfortable >with any IPng production deployment prior to autoconfiguration and mobility >specs, since the process of adding these might easily require changes to Let's see. We have several years of working on autoconfiguration, but no major solution to the requirement. We have more than one year of working on mobility and don't really even have consensus on the statement of the requirement. And you want to wait until these are solved? Just what sort of decision are you expecting in Toronto? Certainly not one of any practical value. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Mon May 16 08:13:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19334; Mon, 16 May 1994 08:13:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24180; Mon, 16 May 1994 07:51:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24152; Mon, 16 May 1994 07:46:30 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18534; Mon, 16 May 1994 07:53:33 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20586; Sun, 15 May 94 14:53:25 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA28710; Sun, 15 May 94 14:52:59 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA16841; Sun, 15 May 1994 14:53:22 -0700 Date: Sun, 15 May 1994 14:53:22 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9405152153.AA16841@jurassic.Eng.Sun.COM> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <2392.bill.simpson@um.cc.umich.edu> Subject: re: Pick one, look at the rest > None of the above is not an acceptable choice to me. "None of the above" is not an acceptable choice for me too. I think that if the IETF does not select an IPng in July there other forces in the industry that will pick for us. As other standards group have found out, if we are not responsive to our customers (user, vendors, etc.) they will find a new supplier. Bob From owner-Big-Internet@munnari.OZ.AU Mon May 16 08:16:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19415; Mon, 16 May 1994 08:16:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24200; Mon, 16 May 1994 07:54:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24155; Mon, 16 May 1994 07:46:37 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18923; Mon, 16 May 1994 08:03:17 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA21181; Sun, 15 May 94 15:03:01 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA28770; Sun, 15 May 94 15:02:34 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA16919; Sun, 15 May 1994 15:02:55 -0700 Date: Sun, 15 May 1994 15:02:55 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9405152202.AA16919@jurassic.Eng.Sun.COM> To: big-internet@munnari.OZ.AU Cc: Bob.Hinden@Eng.Sun.COM Subject: Question about EID / Locators If EID and locators are separate (which means that it is possible to change the locators with out breaking the transport connection), then doesn't the datagram need to be authenticated? I think this the same problem that occurs with source routes. If the transport uses the EID and locator to identify the connection, then it just the same as having and EID and locator in the same field. That is, they are not really separate. Bob From owner-Big-Internet@munnari.OZ.AU Mon May 16 08:21:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19670; Mon, 16 May 1994 08:21:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA24230; Mon, 16 May 1994 07:59:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24227; Mon, 16 May 1994 07:57:44 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19585; Mon, 16 May 1994 08:19:28 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa22875; 15 May 94 18:19 EDT To: Dave Crocker Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Requirements In-Reply-To: Your message of Sun, 15 May 1994 14:04:16 -0700. Date: Sun, 15 May 1994 18:18:24 -0400 From: John Curran Message-Id: <9405151819.aa22875@nic.near.net> -------- ] From: Dave Crocker ] Subject: Re: Requirements ] Date: Sun, 15 May 1994 14:04:16 -0700 ] ... ] Hence, the Internet approach is to prune rather than expand requirements ] lists, so that we can satisfy the common, clear, immediate core of ] requirements, while having some sense of the next-round of effort and some ] sense that it can be added to the core. ] ] This sounds ludicrous. No one would ever design a design process like ] this. It clearly cannot produce successful specs. ] ] But it does. Actually, I agree that the approach above ("the Internet approach"?) does work well, in circumstances where the appropriate facilities are in place to allow easy replacement of the function. Routing protocols are a fine example, since IPv4 functions fine as long as the routing table has correct entries, regardless of origin. As you can tell from my original tirade, I'm rather suspicious of the claim that we can handle _major_ changes (such as IPng) which are not incremental. I can't think of any success stories where we've achieved common deployment of functionality which was not incremental by nature (Subnetting comes to mind, but it was only deployable due to "proxy arp" which allowed the change to be made on an incremental basis.) Do you feel that we will be successful in deploying new functionality once IPng is in widespread use? I'll admit I'm pessimistic regarding our chances of making incremental improvements to the ever-growing Internet, and that causes me to put on rose-colored glasses when it comes to getting to more capabilities into IPng... ] Let's see. We have several years of working on autoconfiguration, but no ] major solution to the requirement. We have more than one year of working ] on mobility and don't really even have consensus on the statement of the ] requirement. You'll note that I said "autoconfiguration" and "mobility", not "resource reservation" or "flows" :-) While there are some outstanding issues, the mobile-ip working group has made remarkable progress in reaching consensus over the past year... I do believe that mobility is well within the reach of IPng. (yes, it may not be in the initial pilots, but that doesn't mean that it won't be ready in time.) Autoconfiguration (as opposed to auto-registration) has been demonstrated by several different mechanisms so far, and the real issue is selecting which one(s) are really needed in IPng. Do you honestly see autoconfiguration being difficult to achieve for IPng? Why? ] And you want to wait until these are solved? Just what sort of decision ] are you expecting in Toronto? Certainly not one of any practical value. Hmm, loaded question. I expect that the IPng directors (with assistance from the directorate) will recommend which (if any ) IPng candidate satisfies the requirements document, or will delineate the minimal changes necessary to make one proposal meet the requirements document. No, I don't expect miracles from the IPng process. I _do_ expect a decision. /John From owner-Big-Internet@munnari.OZ.AU Mon May 16 09:42:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21351; Mon, 16 May 1994 09:21:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA24320; Mon, 16 May 1994 09:21:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA24312; Mon, 16 May 1994 09:13:57 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21121; Mon, 16 May 1994 09:12:59 +1000 (from kre@munnari.OZ.AU) To: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Cc: big-internet@munnari.OZ.AU Subject: Re: Question about EID / Locators In-Reply-To: Your message of "Sun, 15 May 1994 15:02:55 MST." <9405152202.AA16919@jurassic.Eng.Sun.COM> Date: Mon, 16 May 1994 09:12:55 +1000 Message-Id: <18262.769043575@munnari.OZ.AU> From: Robert Elz Date: Sun, 15 May 1994 15:02:55 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-ID: <9405152202.AA16919@jurassic.Eng.Sun.COM> If EID and locators are separate (which means that it is possible to change the locators with out breaking the transport connection), then doesn't the datagram need to be authenticated? No more than with IPv4 - ie: ideally, yes it means exactly that, but we can probably survive without it. I think this the same problem that occurs with source routes. The problem with source routes occurs only because of the requirement to reverse the route when sending replies. There is no such requirement when using EIDs and locators. Hosts should translate the (original) source EID into an address before sending a reply. This sounds like an onerous kernel burden, but really isn't - a reply will (must) come from application mode (eg: you don't ack the syn until an accept has been done), these days, for security, incoming addresses are almost always translated to names anyway - the same translation can produce the address to be used for messages back, and it can all be buried in the API (inside the "accept" routine). UDP applications may need a little more work. Authentication is needed anyway however. kre From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:21:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23709; Mon, 16 May 1994 10:21:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24393; Mon, 16 May 1994 10:21:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24388; Mon, 16 May 1994 10:11:06 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23292; Mon, 16 May 1994 10:10:57 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 09:10:52 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA04351; Mon, 16 May 1994 09:10:52 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15163; Mon, 16 May 94 09:10:52 JST Date: Mon, 16 May 94 09:10:52 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160010.AA15163@cactus.slab.ntt.jp> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: addressing/locating/identifying models Thanks for the taxonomy. I hope that people start using it (or perhaps something with more user-friendly, if not evocative, naming scheme). One point. You mentioned that only one of the models suited VANITY. However, I didn't mean in my description of VANITY to be so restrictive. The main point for me was that the EID be vendor-assigned. That is, that it be useful for serverless auto-configuration. Thus, they can be used in your models C - F. Perhaps I should have simply called them va-EIDs, to indicate how they are assigned. PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:32:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23800; Mon, 16 May 1994 10:25:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24408; Mon, 16 May 1994 10:24:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24371; Mon, 16 May 1994 10:06:51 +1000 Received: from [192.5.216.174] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22417; Mon, 16 May 1994 09:48:39 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 08:48:32 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA04129; Mon, 16 May 1994 08:48:32 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA14929; Mon, 16 May 94 08:48:31 JST Date: Mon, 16 May 94 08:48:31 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405152348.AA14929@cactus.slab.ntt.jp> To: kre@munnari.OZ.AU, smart@mel.dit.csiro.au Subject: Re: addressing/locating/identifying models Cc: big-internet@munnari.OZ.AU > space of IEEE numbers (excluding wastage), which is certainly > plenty (I knoww there are some who believe that IEEE numbers > would be suitable as EIDs themselves, though I don't believe > that myself, 48 bits isn't enough, and the allocation policy is > all wrong). > I seem to be in the minority in thinking that IEEE 802 numbers are usable (for now?) as EIDs. The major objection seems to be that there probability that an 802 number is globally unique is not high enough. I have lately imagined the IANA taking on the role of assigning globally unique identifiers, but I have imagined they would be assigned very much like 802 numbers are (at least the "universally administered" ones). That is, IANA would assign blocks to vendors, who would then hardwire them into their hosts/routers. This allows for nice serverless autoconfiguration. Robert, when you say that the IEEE allocation policy is all wrong, what are you refering to? PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:34:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23834; Mon, 16 May 1994 10:27:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24434; Mon, 16 May 1994 10:26:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24374; Mon, 16 May 1994 10:07:23 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22845; Mon, 16 May 1994 09:57:30 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 08:57:20 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA04204; Mon, 16 May 1994 08:57:20 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15021; Mon, 16 May 94 08:57:19 JST Date: Mon, 16 May 94 08:57:19 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405152357.AA15021@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil > > let me say that I hope nobody is still considering the > notion of requiring EIDs for IPng. > > I certainly am. > > As I said before, we should specify requirements, not > solutions. > > EIDs are requirements, not solutions. Or, if the acronym > invokes bad vibes, then the requirement can be stated as ... > > IPng must provide a method to transmit location independant > identifiers for the use of transport protocols, and others, > and the definition the uses of TCP and UCP over IPng must > include using this location independant identifier in their > pseudo-checksums. > > To me, that is requiring EIDs (and one specific use for them). Yes, this is still requiring EIDs, and I still think it doesn't make sense as a requirement. You are assuming the solution in the above "requirement", that is, you are assuming a "location independant identifier". What if you worded it this way: IPng must provide a method to transmit identifiers for the use of higher-layer protocols. The identifier must remain the same throughout the lifetime of the higher-layer protocol, independent of the location of the identified node, and independent of the route used for the packets. This to me is a requirement. I believe that it captures the functionality that you desire without stating that EIDs are the solution. Do you agree? PF > > There's a reason for this - apart from all the other likely > uses of EIDs, defining the transport level to use this > location independant (and hence routing useless) identifier > enables the IP layer to be upgraded much more seamlessly > if (when) needed in the future. > > Pulling one network level header off, doing address (locator) > substitution if needed, and sticking a modified header on > as packets flow from one region of the net to another is a > possibility. What won't be is fiddling TCP to manipulate its > checksum to account for changes in the identifier it uses. > That may be possible now, most of the time, but we have to assume > that in the future at least some packets will either be > encrypted, or signed, above the network level, meaning that > modifications are impossible - modifications at the net level > have to be permitted to allow things like hop counts to be > adjusted, and for manipulation of options, etc. > > To be precise, let me first say what I'm advocating. I'm > arguing for an identifier that 1) is used by transport layer, > instead of "locators", to distinguish among different > network layers, > > This I agree with. > > 2) is used by routers to determine last hop routing (that is, > it is the node ID or host ID of a locator), > > this is a solution, not a requirement, and while I agree with > it as a possibility, I wouldn't require it. > > and 3) is administered by vendors not users (it comes > attached to computers out of the box). > > But this I asbolutely (and totally) disagree with. I require > a mapping from EID into name, that is I want EIDs to be *the* > binary identifier. To make this mapping plausible, there > has to be some kind of administrative relationship between > EIDs owned by some administration (company, department, > individual, whatever), so they can reasonably be made to > fit into the DNS (or any other kind of directory). I do > not require EIDs to be fixed for all time, they only need > remain while any connection using them remains alive - if all > connections die when a host is rebooted, and there is some > way to handle dynamic DNS registration, then assigning a new > (currently unused, not new for all time) EID to a host at boot > time is just fine. > > I have no problem with a vendor assigned ID being used to > acquire the EID from some kind of server, nor, if the > organisation can manage it, to using it with some organisation > prefix to form the EID, but using a vendor assigned number > alone seems unworkable. Using vendor assigned numbers this > way also eases the pressure on them to absolutely guarantee > global uniqueness - their number only needs to be unique within > the organisation in which its used, which means that occasional > errors in id assignment by the vendors can almost certainly be > tolerated - just as we usually tolerate duplicate IEEE assigned > numbers today. > > kre > > Paul's message - if you've seen it before, no need to read > any further.... > > Date: Thu, 12 May 94 10:12:05 JST > From: francis@cactus.slab.ntt.jp (Paul Francis) > Message-Id: <9405120112.AA20949@cactus.slab.ntt.jp> > To: sipp@sunroof.Eng.Sun.COM > Subject: continuing EID discussion (was Re: FORMAL REQUEST : SIPP EIDs and Locators) > > Since the discussion of the Subject Re: FORMAL REQUEST : SIPP EIDs and Locators > has degraded to counting angels and slinging mud, I have stopped reading > it and am concerned that others have also stopped reading it and therefore > didn't look at my reply to Steve and Christian, which I spent a fair amount > of time and thought on. > > So, at the expense of sending the same message to the list twice, I here > resubmit my message under the new Subject..... > > PF > > --------------------------------------------------------------- > > > I want to rebutt the comments of Steve and Christian regarding > the costs/benefits of EIDs. But first let me say that I hope > nobody is still considering the notion of requiring EIDs for > IPng. As I said before, we should specify requirements, not > solutions. > > To be precise, let me first say what I'm advocating. I'm > arguing for an identifier that 1) is used by transport layer, > instead of "locators", to distinguish among different network layers, > 2) is used by routers to determine last hop routing (that is, > it is the node ID or host ID of a locator), and 3) is > administered by vendors not users (it comes attached to > computers out of the box). To make it clear that this is > what I'm talking about, let me call this particular beast > a VANITY (Vendor-Assigned Node-Identifying Transport Yodel). > > (If you're wondering about "Yodel", this is a reference to the > ancient practice of Swiss herders identifying each other by > their distinctive yodel. Yes, I'm making this up..... :-) > > In the following I quote Steve's message. I didn't save > Christian's message, so I'll paraphrase what I remember > him saying. > > > > - EIDs are neither necessary nor sufficient to solve the problems > > for which they are usually cited as a solution, e.g., multi-homing, > > mobility, dynamic address changing. > > This is true except for the case of "serverless" host address > auto-configuration, which I believe to be a very important > requirement, and which I think is the primary benefit of VANITYs. > I think this use alone justifies the use of VANITYs. The other > uses (Steve mentions) are icing on the cake, but I agree with > Steve that these can be done other ways, as shown with SIPP. > > > - EIDs are yet another name space to be allocated and managed, in addition > > to addresses and DNS names. Our experience with our existing name > > spaces makes me *very* loath to create another, especially without a > > *very* concrete reason. > > > > Christian also mentioned the cost of managing "another" name space. > I would like to argue, to the contrary, that the use of VANITYs very > significantly *reduces* the cost of name space management--specifically > because they allow for host auto-configuration. Let's assume that > most of the cost of name space management is human cost. Currently, > hundreds and soon (if not already) thousands of people are involved > in assigning millions of IP host numbers. Further, > those are the people who are the least qualified to be assigning > numbers (not because they aren't smart, but because it isn't their > primary job, they're not networking gurus, etc.). If you use > VANITYs, you move this function to a smallish number of vendors > (some hundreds rather than many thousands), where the assignment > process can be localized, focused, and probably largely automated. > You save countless man-hours. > > >- It may well turn out that higher-level protocols will end up defining > > higher-level IDs at a much finer grain than the EIDs that have been > > proposed in this community, for example, globally unique process IDs > > in support of fine-grain process migration. (See the VMTP protocol > > spec for one example of such an approach.) Such higher-level IDs > > are likely to make EIDs redundant. > > I think this is a wash. Probably a good way for an application to > manage such a number space is to take the network layer identifier > and append some additional information specific to that application. > If the network layer identifier is an address (i.e., combination > locator/identifier), then the address also is "redundant". Either way, > you are replicating some information. However, if you believe > VANITYs to be stable for longer than addresses, perhaps the use of > VANITYs to help manage the application EIDs is better than the > use of addresses. > > > >- In the most common case, where the locating semantics of either or both > ............ > > of changing addresses, or whatever), requiring the presence of pure > > EIDs would make the packet header significantly larger than it would > > otherwise be. True, the price we accept for our connectionless internet > > Agreed. > > > model is a large header on every packet. But I think we have a duty as > > designers to make relatively efficient use of that header space, since > > it is a "tax" imposed on every packet. I am particularly concerned > > I agree. If all other things are equal, we should favor smaller > headers.....but...... > > > about header size because I see increasing use of encapsulation as a > > multi-purpose mechanism in the Internet, such that many packets may > > end up carrying multiple SIPP headers on at least some part of their > > At least some of the reasons for such encapsulations would be eliminated > if we had VANITYs (for instance, the use of encapsulation for getting > mobility). > > > journey. I'm also concerned with making it possible to forward SIPP > > packets at very high speed, and keeping the basic header size relatively > > compact is one part of that (e.g., more likely to fit into a cache line, > > when using a general-purpose processor as a packet switch). > > Mumble. Maybe so. The use of VANITYs doesn't increase the amount > of info that has to be examined, though, so perhaps with some care > one can manage to funnel only the needed info into the cache line. > I don't know for sure, and it probably differs significantly from > machine to machine. Another point is that the VANITY might help > high speed switching because it can be used as a flow ID, blah blah > mumble hand wave. > > > A common answer to the large header size issue is to suggest using > > header compression over slow links. Besides the fact that that > > does not address the high-speed forwarding issue, another problem > > is that our current strategy for header compression in IPv4 only works > > for TCP traffic and relies on certain properties of TCP. However, I > > expect much of the high-volume traffic in the future to be UDP, e.g., > > What? High volume over slow links? If you can solve that one you > can become a rich man! :-) > > If it is high volume (and therefore high speed), you by definition > don't need header compression. > > > real-time audio and video. I don't know what's involved in building > > a robust header compression scheme for SIPP/UDP headers (there's a > > good project for someone to work on!), but I'd rather not depend on > > I agree. In fact, SIPP could use this like yesterday.... > > > it being easy or cheap to do. Another, perhaps unfounded, concern is > > that compression spends CPU cycles to save bandwidth, but we may want > > to support nodes that are starved for *both* CPU and bandwidth, e.g., > > very low-powered wireless devices. > > I suspect that a machine that is starved for CPU and bandwith will > not be exchanging packets simultaneously with a large number of other > devices, and therefore compression should work well at low cost > (i.e., lots of redundancy from packet to packet). > > > Ok, finally I want to address Christian's comments (and Minshall has > also mentioned this) about the non-uniqueness of IEEE 802 numbers. > I agree that this is a problem, but I wonder how much. In the > context of SIPP, the spec is very specific about requiring the use > of "universally administered" 802 numbers. Thus, I *hope* that > the "soft" assignments of 802 numbers doesn't apply. As for sloppy > practice by vendors resulting in duplicate "universally administered" > 802 numbers, at least with SIPP this should rarely cause a real > problem (unless I'm missing something). *If* we get SIPP hosts to > *always* assign a different flow ID for each route sequence it is > using, then duplicate 802 numbers only cause a problem when > 1) the hosts with the duplicates are talking to the same machine, > 2) the flow IDs are the same, and 3) the other identifiers, such > as transport socket, are all the same. I think that the probability > of this is small enough that failures caused for this reason will > be in the noise compared to failures caused for other reasons. > > /* start aside */ > > As an aside, this is *yet another* good reason to have > hosts always assign a flow ID. I'm now thoroughly > convinced that the cost of doing this is well worth it. > Off the top of my head, the benefits are: > > 1. Hosts receiving packets can use the flow ID to > detect a change in route sequence. Thus, they > don't have to parse through the route sequence > every time. > > 2. Routers can use the flow ID to identify flows. > My gut feeling is that 90% or more of real time > could be handled without explicit flow setup. > > 3. If not 2, then at least routers can use it to > aid their caching strategies (I know that there > are other issues here, like how to advance ther > route header). > > 4. "Fixes" the blatant distant-snooping security hole > introduced by route sequence reversal. (Sorry Ran, > but having thought about this more, I remain > convinced that this technique is useful for this > purpose.) > > 5. The duplicate VANITY problem. > > /* end aside */ > > > Actually, this notion that a host can successfully talk to > multiple other hosts that have the same VANITY is interesting > to me (not that I'm advocating it). Specifically, it makes > me ask what the point is to IP header authentications, especially > in the absense of higher-layer authentication. As long as > packets can successfully get from source to dest and back, what > does the network layer care about authentication? The application > cares about authentication, but authenticating the network layer > for the purpose of authenticating the application seems weak > and more expensive than doing it at the application. > > Maybe I'm just being dense, but can someone please re-iterate > for me why we need to authenticate at the network layer? > > PF > > From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:51:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24470; Mon, 16 May 1994 10:41:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24474; Mon, 16 May 1994 10:41:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA15684; Wed, 11 May 1994 14:06:54 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10702; Wed, 11 May 1994 14:28:37 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA16766; Tue, 10 May 94 22:33:54 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB22398; Tue, 10 May 94 21:26:39 PDT Date: Tue, 10 May 94 21:26:39 PDT Message-Id: <9405110426.AB22398@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN), big-internet@munnari.OZ.AU (bigi) From: Greg Minshall Subject: Re: IP Technical Criteria Brian, >> Could you explain a bit more? Why aren't NSAPAs prone to the same problem? [as SIPP addresses] >They change when you change provider, but ES-IS should handle it >automatically. I think SIPP can do that? (a statement in the form of a question) Greg From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:51:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24561; Mon, 16 May 1994 10:43:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24489; Mon, 16 May 1994 10:43:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24453; Mon, 16 May 1994 10:33:18 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24068; Mon, 16 May 1994 10:32:00 +1000 (from kre@munnari.OZ.AU) To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil Subject: Re: continuing EID discussion In-Reply-To: Your message of "Mon, 16 May 1994 08:57:19 +0200." <9405152357.AA15021@cactus.slab.ntt.jp> Date: Mon, 16 May 1994 10:31:57 +1000 Message-Id: <18310.769048317@munnari.OZ.AU> From: Robert Elz Date: Mon, 16 May 94 08:57:19 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-ID: <9405152357.AA15021@cactus.slab.ntt.jp> You are assuming the solution in the above "requirement", that is, you are assuming a "location independant identifier". No, that's not the solution, its a requirement - the reason is that I don't believe that location dependant identifiers can be allocated in an effecient enough manner that we can reasonably allocated a fixed width field of any reasonable size that we can really be sure is going to last forever. Encoding all that location information simply uses too many bits for no useful purpose in the identifier that's required. For this we have to pick something that will last forever without changing format - forever, not just 50 or 100 years. Maybe 128 bit identifiers encoding location might do, but even there I'd be hesitant, as I know how much wastage there is going to be in those things. 256 bits might be enough. I think I'd prefer to make the things location independant, so the allocation policy can be effecient, and we can stick with a reasonably sized field. kre From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:52:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24606; Mon, 16 May 1994 10:45:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24504; Mon, 16 May 1994 10:44:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24445; Mon, 16 May 1994 10:28:22 +1000 Received: from ADRASTEA.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23856; Mon, 16 May 1994 10:28:16 +1000 (from wollman@adrastea.lcs.mit.edu) Received: by adrastea.lcs.mit.edu; id AA26490; Sun, 15 May 1994 20:28:10 -0400 Date: Sun, 15 May 1994 20:28:10 -0400 From: Garrett Wollman Message-Id: <9405160028.AA26490@adrastea.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, jcurran@nic.near.net Subject: Re: Thoughts on the IPng situation... In-Reply-To: <9405150319.AA08587@ginger.lcs.mit.edu> References: <9405150319.AA08587@ginger.lcs.mit.edu> < If we'd gotten agreement on functionality, and hopefully even on > mechanism (more likely if we didn't have to pick between A's design, > and B's), I'd have thought we wouldn't really need to have separate > designs; it would be pretty much a slam-dunk from there. We could > thus avoid the attendant difficulty of chosing one. Getting those > agreements may not have been possible, but it would have been easier > than trying to answer these questions through the murk of complete > designs. From the Jargon File, version 3.0.0: :creationism: n. The (false) belief that large, innovative software designs can be completely specified in advance and then painlessly magicked out of the void by the normal efforts of a team of normally talented programmers. In fact, experience has shown repeatedly that good designs arise only from evolutionary, exploratory interaction between one (or at most a small handful of) exceptionally able designer(s) and an active user population --- and that the first try at a big new idea is always wrong. Unfortunately, because these truths don't fit the planning models beloved of {management}, they are generally ignored. This applies as well to networking as it does to software in general. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-Big-Internet@munnari.OZ.AU Mon May 16 10:53:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24645; Mon, 16 May 1994 10:47:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA24519; Mon, 16 May 1994 10:47:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24458; Mon, 16 May 1994 10:33:46 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23775; Mon, 16 May 1994 10:24:07 +1000 (from kre@munnari.OZ.AU) To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: smart@mel.dit.csiro.au, big-internet@munnari.OZ.AU Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Mon, 16 May 1994 08:48:31 +0200." <9405152348.AA14929@cactus.slab.ntt.jp> Date: Mon, 16 May 1994 10:24:02 +1000 Message-Id: <18304.769047842@munnari.OZ.AU> From: Robert Elz Date: Mon, 16 May 94 08:48:31 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-ID: <9405152348.AA14929@cactus.slab.ntt.jp> Robert, when you say that the IEEE allocation policy is all wrong, what are you refering to? Firstly that its incredibly wasteful - both because once a vendor assigns a number, they can't, in general, and in theory, ever reuse the number for anything, as they're never likely to know when the physical thing to which they assigned the number has been destroyed, and needs it no longer, and because, of necessity, vendors tend to need large blocks - or they hope they do, but many vanish from the face of the earth perhaps after having assigned only a very small fraction of their block, but probably without leaving any accurate traces as to exactly how many they did assign (they're no longer around to ask), so the whole range must be assumed taken. Secondly, and much more importantly, we need blocks of EIDs associated with owners of systems, so there is an effecient mechanism to use to map EIDs onto the DNS, or any other directory - getting EIDs assigned by vendors is much like having them generated by random number generators, there's no relationship you can discern between the numbers you own, and no rational way at all for them to be entered in the DNS. Thirdly, there's no 1:1 relationship between EIDs and either hosts or interfaces. There's no way your vendor can possibly know how many EIDs the final user is going to need on any particular system, it may be more than one - there's no way for the vendor to know to assign the correct number. EIDs need to be allocated much like we allocate IPv4 addresses today, but in much smaller blocks (well, class C sized, but only in groups of 1 in most cases to end user organisations), taken from larger blocks (perhaps 2^24 EIDs) allocated to local registries - that gives us 2^40 registry sized blocks to be allocated one at a time to suitable organisations that request them for re-allocation purposes, which should be enough for a very long time. Any level or organisation can request another block once they have exausted (nearly exhausted) their previous allocation. Users can reassign EIDs when they dispose of the host on which the EID was used - when its no longer needed there. The EID is not associated with any particular hardware. kre I wish I could learn to write sentences that are shorter than several paragraphs each... From owner-Big-Internet@munnari.OZ.AU Mon May 16 11:07:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25185; Mon, 16 May 1994 11:01:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA24549; Mon, 16 May 1994 11:01:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA24535; Mon, 16 May 1994 10:51:22 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24651; Mon, 16 May 1994 10:47:49 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 09:47:43 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA04662; Mon, 16 May 1994 09:47:43 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15675; Mon, 16 May 94 09:47:42 JST Date: Mon, 16 May 94 09:47:42 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160047.AA15675@cactus.slab.ntt.jp> To: brian@dxcoms.cern.ch, tracym@NSD.3Com.COM Subject: Re: Do we have an architecture? Cc: big-internet@munnari.OZ.AU > > As for plug and play: it's an optional IPng requirement. Many sites > won't want plug and play, for managerial or security reasons. > I'd rather see a requirement that says plug-and-play is required, and that also required is the ability of the net administrator to turn it off...... PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 11:26:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25837; Mon, 16 May 1994 11:21:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA24579; Mon, 16 May 1994 11:21:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA24576; Mon, 16 May 1994 11:14:51 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25504; Mon, 16 May 1994 11:09:48 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 10:09:36 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA04996; Mon, 16 May 1994 10:09:36 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA16153; Mon, 16 May 94 10:09:35 JST Date: Mon, 16 May 94 10:09:35 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160109.AA16153@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: addressing/locating/identifying models Cc: big-internet@munnari.OZ.AU, smart@mel.dit.csiro.au > > Firstly that its incredibly wasteful - both because once a > vendor assigns a number, they can't, in general, and in theory, > ever reuse the number for anything, as they're never likely to > know when the physical thing to which they assigned the number > has been destroyed, and needs it no longer, and because, of If the number is big enough, then this doesn't matter....we can afford the benefits of wastefulness. > Secondly, and much more importantly, we need blocks of EIDs > associated with owners of systems, so there is an effecient > mechanism to use to map EIDs onto the DNS, or any other > directory - getting EIDs assigned by vendors is much like > having them generated by random number generators, there's > no relationship you can discern between the numbers you own, > and no rational way at all for them to be entered in the DNS. Since addresses can be used to reverse map into DNS, I don't think we need EIDs to do it.... > > Thirdly, there's no 1:1 relationship between EIDs and either > hosts or interfaces. There's no way your vendor can possibly > know how many EIDs the final user is going to need on any > particular system, it may be more than one - there's no way > for the vendor to know to assign the correct number. In that case, we need to be able to extend the EID locally on the host machine with a number that it can manage... > > EIDs need to be allocated much like we allocate IPv4 > addresses today, but in much smaller blocks (well, class C > sized, but only in groups of 1 in most cases to end user If this is how EIDs are managed, then I think we may as well use locators as identifiers.... Ok, I want to do some other work. Can we agree to disagree at this point? PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 11:41:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26676; Mon, 16 May 1994 11:41:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA24623; Mon, 16 May 1994 11:41:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA24595; Mon, 16 May 1994 11:24:22 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25934; Mon, 16 May 1994 11:24:10 +1000 (from kre@munnari.OZ.AU) To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: big-internet@munnari.OZ.AU, smart@mel.dit.csiro.au Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Mon, 16 May 1994 10:09:35 +0200." <9405160109.AA16153@cactus.slab.ntt.jp> Date: Mon, 16 May 1994 11:24:05 +1000 Message-Id: <18324.769051445@munnari.OZ.AU> From: Robert Elz Date: Mon, 16 May 94 10:09:35 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-ID: <9405160109.AA16153@cactus.slab.ntt.jp> If the number is big enough, then this doesn't matter....we can afford the benefits of wastefulness. While I'm not a bit counter in general, deliberate wastefulness seems wrong to me. Since addresses can be used to reverse map into DNS, I don't think we need EIDs to do it.... But I don't want addresses to reverse map the DNS - doing that causes too many problems, either you have to confine your internal field boundaries to the defined DNS name mapping boundaries (probably octets), which can waste lots of address space (more wasted bits), or the DNS management problems become truly painful. Because you need internal structure there for two purposes, you're almost guaranteed conflicts. Rather than try and hack out some kind of compromise solution, I prefer to simply define the conflict into oblivion. That is, EIDs identify - and if they identify you have to be able to find a name from them. Locators (addresses if you must) supply routing/forwarding information - they help the packet get to its destination. One solid function each. No compromises. In that case, we need to be able to extend the EID locally on the host machine with a number that it can manage... More waste ... a field (space) there long enough for the worst case (who can guess how big) where more than 0 or 1 bits will rarely be used. Why? If this is how EIDs are managed, then I think we may as well use locators as identifiers.... They're too wasteful, and have the wrong semantics. Ok, I want to do some other work. You mean you can read B-I and do other work, all in the same year. That's a neat trick... Can we agree to disagree at this point? I suppose there is little alternative. kre From owner-Big-Internet@munnari.OZ.AU Mon May 16 11:43:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26727; Mon, 16 May 1994 11:43:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA24638; Mon, 16 May 1994 11:43:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA24609; Mon, 16 May 1994 11:38:03 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26617; Mon, 16 May 1994 11:37:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13321; Sun, 15 May 94 21:37:56 -0400 Date: Sun, 15 May 94 21:37:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405160137.AA13321@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu From: Craig Partridge I think you're being too glib in dismissing the design points (I suspect, in part, because they match your world view ...) I think there's probably some truth to that. I can only note that it's not just my world-view, but it is shared by many other people, whose designs have been very successful. >> keep the packet format word-aligned > I find it hard to call this anything .. more than competent engineering Ah, but the question is what to do when push comes to shove regarding flexibility. E.g., CLNP's approach was to make address sizes variable on a per-byte basis. You have to sit down and decide whether you can make a field i) larger than it could conceivably grow for the life of the design, and ii) whether you can afford the preallocated space to hold it at its maximum size. If not, then you are forced into having variable length stuff. Once you've got any variable length stuff, there are ways to deal with that; e.g. put all the fixed length fields first, use padding, etc. (SIPP effectively uses the former; the ASEQ for source routing, variable length addresses, etc, is stuck behind the fields which are at fixed offsets.) Look, it is something of a tradeoff, sure, but a much simpler one than issues like robustness/simplicity. That one's really hard. >> and as minimalist as possible > Again, no more complex than is needed is not exactly deep insight.. the point is which way do you risk on questions on which you are unsure? SIPP says risk by leaving them out. Frankly, this approach scares the heck out of me. Either a feature really is needed, in which case you'd better add it, since the design will ultimately be a failure if it's not there; or it's not. Taking a general policy of leaving poorly understood ones out is no better, really, than flipping a coin (an approach all would rightly laugh at); you are making a crucial decision in an arbitrary way, without enough data. Noel From owner-Big-Internet@munnari.OZ.AU Mon May 16 13:01:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29535; Mon, 16 May 1994 13:01:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA24734; Mon, 16 May 1994 13:01:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA24731; Mon, 16 May 1994 12:58:26 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29504; Mon, 16 May 1994 12:58:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13659; Sun, 15 May 94 22:58:07 -0400 Date: Sun, 15 May 94 22:58:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405160258.AA13659@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mo@uunet.uu.net Subject: Re: Noel's lamentations... Cc: jnc@ginger.lcs.mit.edu From: "Mike O'Dell" Noel argues for tearing off a blank sheet of paper and starting over. Not quite. I'm suggesting that we do as an explicit process something we're now doing, only obscured by the murk of the politics of chosing design A, B, C or whichever, which is to decide what it is we want IPng to do. At that point, looking over the IPng work to date, we will probably find lots of stuff we can reuse. As to discarding work to date, think about the likely future if we continue on the way we're going. First, the N losing candidates are going to be discarded anyway. So, my suggestion is no worse there. Second, for the winner, what I hear lots of people (Craig, KRE, and others in private) saying is that "we need to make major changes". So, there's likely to be some loss there. Even if I were suggesting "ditch everything", it's not really much worse (practically speaking) than the path we're on now. All I'm saying is: look at the costs of i) making an IPng decision (a decision which isn't really going to give us something we can code up and deploy), and ii) the costs of getting that design changed. Is my alternative really more expensive? you have no reason, beyond faith, to believe you will actually get a better answer I could just as easily say that you have no reason to believe that any of the IPng candidates, if accepted, would actually improve the situation on the ground. Knowing the future, for sure, is hard. I do think it's highly unlikely that this body won't produce a superior design with more *experience* about mobility, resource reservation, etc (based on work which is *already* happening now) to draw on. it is certainly much harder to predict *when* you'll have an answer. True. But I'd rather wait some for the right answer, than rush for the wrong one. I have no doubt we will get a good answer in a not-wholly unreasonable timeframe. The IETF process, messy as it is, does work reasonably well. Look at CIDR; although the path there was really messy, I do believe that it is the optimal solution to getting the most possible out of the IPv4 address space, and it's getting out there. Could we have improved on how we got there? Yeah, but forcing a premature choice between C# and whatever the other contenders were wouldn't have helped... when this first started, it was believed ... by most ... that the problem was relatively bounded and that modest deltas off existing, known-working solutions would be prudent engineering ... the depth of the architectural issues which need addressing for long-term scaling are now understood to a *very* different degree than when this first started. Yes, and I think this shows that the last two years haven't been a total writeoff. The community is now a lot more sophisticated about these issues. The IETF is, like it or not, a non-representative democracy, and in such a system everyone has to understand the issues before we can come to the right answer, so I don't begrudge the time spent in educating. And further, as "correct" as he might be in the academic abstract, I think Noel's self-flagellation does a disservice to a number of very smart people who have been looking at this. In doing some "self-flagellation", I just wanted to make the point that I'm not trying to find the people to blame, or shift the blame to others, or anything like that. How we got here is mildy interesting for lessons for how to avoid it in the future, but otherwise irrelevant. We can't change it now. The only important question is what's the best way forward. He argues that if we *really* understood the requirements, and maybe settled on the mechanism, then the "packet format" would be "slam-dunk" self-evident. ... I think he materially underestimates the energy required for real closure and the inevitability of some level of ego involvement. Oh, it wouldn't be trivial, you're quite right there, but I think it would be a lot easier than either i) trying to chose one IPng design over another, or ii) trying to agree on what functionality an IPng should have. The point is that you cannot tell the future very far in advance, and the people running around demanding that everything we do here be perfect for the next 20 years are just simply nuts. Sure, we might blow it, but there are two things to recognize. First, we should try and do designs that have the kind of flexibility that will allow us to less painfully take up the lessons we're obviously going to learn. An example is retransmission algorithms; we've been able to deploy VJCC without any systemwide changes. We need more designs that have that kind of flexibility (although it's not always easy to know how to put that kind of flavor in, it is possible; Nimrod is shot through with that kind of stuff). Second, IPv4 representted a rather bold step into the future, but one that turned out to have been remarkably right, and it wasn't just by chance. I know the situation now is very different; we're talking about a major piece of the world's communication infrastructure, so boldness seems much riskier. However, I think we owe it to the future, and the future users, to be bold; large enterprises which get too cautious can fail as well; look at IBM's problems. Remember, IPv4's success, radical as it was, was not an accident. it is safe to assume that *something* which materially shifts the model will happen in 20 years Sure, things will be different, but if we see through to the underlying fundamentals, the chances are what we do will still be useful. Unix is still a popular system, and will be for a long time to come, because the architects of that system saw deeply into the fundamentals of how to organize computations on a system. BUT YOU CAN'T KNOW. Sure. I'm not even sure I know what the best way is forward from here; I mean, I've got a strong feeling the current path can be improved on, but the exact details I don't feel I have certainty on. We all need to hear other opinions, out of which we can collectively synthesize a better answer... So next time we listen to Noel, OK? Arrghh! Every time people say things like that you really scare me. I'm human; I make lots of mistakes (and I've made some massive ones). All I ask is that people listen, and think hard to see if what I say makes sense... Noel From owner-Big-Internet@munnari.OZ.AU Mon May 16 14:08:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27406; Mon, 16 May 1994 12:01:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA24668; Mon, 16 May 1994 12:01:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA24654; Mon, 16 May 1994 11:45:49 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26780; Mon, 16 May 1994 11:45:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13393; Sun, 15 May 94 21:45:39 -0400 Date: Sun, 15 May 94 21:45:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405160145.AA13393@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: addressing/locating/identifying models Cc: jnc@ginger.lcs.mit.edu From: francis@cactus.slab.ntt.jp (Paul Francis) If this is how EIDs are managed, then I think we may as well use locators as identifiers.... Sigh. The routing needs names for things which are topologically sensitive; i.e. you move someplace else, you get a new one; i.e. locators. Other applications (e.g. transport connections) need names which are *not* toplogically sensitive; i.e. you move someplace else, you *don't* get a new one. If you can explain to me how one name can simultaneously change (when you move) and not change, then I guess I could see using locators as identifiers. (I'll skip the spiel about how the two different uses have different optimal syntax for now, which is why one namespace is not advisable.) Noel From owner-Big-Internet@munnari.OZ.AU Mon May 16 14:37:47 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00349; Mon, 16 May 1994 14:37:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10383 Mon, 16 May 1994 14:25:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA24837; Mon, 16 May 1994 14:21:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24818; Mon, 16 May 1994 14:07:45 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28210; Mon, 16 May 1994 12:23:57 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA11458; Sun, 15 May 94 22:23:52 -0400 Message-Id: <9405160223.AA11458@rodan.UU.NET> To: big-internet@munnari.OZ.AU Subject: IEEE 802 not unique enough??? Date: Sun, 15 May 1994 22:23:51 -0400 From: "Mike O'Dell" Well, then, we have a serious problem. I submit that except for systems which intentionally spoof the MAC address, the IEEE 802 assignment machinery is the most successful ever fielded to date. If people don't think that job is good enough, then they better have something *very* well-thought-out to offer instead. Not that it probably cannot be improved upon, but it has worked awfully damn well aside from inevitable accidents and botches. But anyone's track record won't be perfect, so what does that say about the basic idea if you gotta do much better than IEEE 802 for it to work????? -Mike From owner-Big-Internet@munnari.OZ.AU Mon May 16 14:38:17 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00396; Mon, 16 May 1994 14:38:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10513 Mon, 16 May 1994 14:31:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA24863; Mon, 16 May 1994 14:31:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24832; Mon, 16 May 1994 14:15:26 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02521; Mon, 16 May 1994 14:15:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14045; Mon, 16 May 94 00:15:15 -0400 Date: Mon, 16 May 94 00:15:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405160415.AA14045@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, lekash@nas.nasa.gov Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu From: lekash@nas.nasa.gov (John Lekashman) You are just describing the difference between top down versus bottom up engineering process. Both need to happen, and at the same time if one wants to win. You've got something of a point. Any design much be checked against reality before being adopted. However, I never said anything about getting rid of the "running code" part of the IETF ideology. In an IPng white paper I can never quite finish (between NomComm, Nimrod, etc) I maintain that the way to proceed involves workign with current field deployments of stuff like Mobility, RSVP, etc to learn what we need, in an incremental deployment process where we put up the IPng in pieces (of which Nimrod, not surprisingly, is one). I guess I need to polish that off... > what's the best way forward from here? ... put the current IPng efforts > to the side Actually, you should save it. Some coherent rapid prototyping along the way is really essential. Again, I'm not saying we should throw all that work down the memory hole. We can use some of it. However, the place where we should be doing prototyping (and where we are going to learn the most) is with extensions to IPv4, like mobility, RSVP, etc... Noel From owner-Big-Internet@munnari.OZ.AU Mon May 16 14:38:25 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00405; Mon, 16 May 1994 14:38:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10612 Mon, 16 May 1994 14:33:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA24878; Mon, 16 May 1994 14:33:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24815; Mon, 16 May 1994 14:04:23 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25690; Mon, 16 May 1994 11:14:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13237; Sun, 15 May 94 21:14:41 -0400 Date: Sun, 15 May 94 21:14:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405160114.AA13237@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu Oh, one point I forgot to make: this opinion does not mean I think Scott and Allison have been doing a bad job. I think they were given a fairly painful and near-impossible task, and are carrying it out about as well as anyone could. Having said that, it's worth noting that we keep falling into the following operating mode (the one that Scott and Allison are trying to deal with), and it's darn painful. A need comes up, and instead of sitting down and trying to agree on what we want the thing to do, we quickly wind up with people going off and doing a number of different designs, which not only represent different design philosophies, and different quality levels, but different answers to the question "what should it do". We then have the incredibly difficult job of deciding on one, since we not only have to decide which design is *better* (an entirely reasonable thing to do), we have to decide which vision of what it ought to do we prefer. Needless to say, if the design which does what we want is also the poorest quality design, we'd be in a real fix. I understand that sometimes it's difficult to really understand what the range of possibilities are before you see some actual designs which give you some concrete ideas, but it just seems so wasteful. I dunno, maybe there isn't a better way, but I wish there were. Noel From owner-Big-Internet@munnari.OZ.AU Mon May 16 14:41:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00541; Mon, 16 May 1994 14:41:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA24923; Mon, 16 May 1994 14:41:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24894; Mon, 16 May 1994 14:37:22 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB00275; Mon, 16 May 1994 14:37:00 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 13:36:50 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id NAA08018; Mon, 16 May 1994 13:36:50 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA19597; Mon, 16 May 94 13:36:49 JST Date: Mon, 16 May 94 13:36:49 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160436.AA19597@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: addressing/locating/identifying models Cc: big-internet@munnari.OZ.AU, smart@mel.dit.csiro.au > > Ok, I want to do some other work. > > You mean you can read B-I and do other work, all in the same > year. That's a neat trick... > No, I can't. That's why we'll have to take up this thread some other time.... Cheers, PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 14:42:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00586; Mon, 16 May 1994 14:42:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA24938; Mon, 16 May 1994 14:42:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24920; Mon, 16 May 1994 14:41:02 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00529; Mon, 16 May 1994 14:40:55 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 13:40:50 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id NAA08113; Mon, 16 May 1994 13:40:50 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA19654; Mon, 16 May 94 13:40:50 JST Date: Mon, 16 May 94 13:40:50 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160440.AA19654@cactus.slab.ntt.jp> To: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: addressing/locating/identifying models > > Sigh. The routing needs names for things which are topologically sensitive; > i.e. you move someplace else, you get a new one; i.e. locators. Other > applications (e.g. transport connections) need names which are *not* > toplogically sensitive; i.e. you move someplace else, you *don't* get a new > one. Guess what Noel? I know that!!! > > If you can explain to me how one name can simultaneously change (when you > move) and not change, then I guess I could see using locators as identifiers. Strictly speaking, they can't. What SIPP does, in the case where it uses its locator as its identifier, is to insert new location information when the original location information becomes invalid (as location information). Thus, the original location information in essence becomes an identifier with no effective location info. > > (I'll skip the spiel about how the two different uses have different optimal > syntax for now, which is why one namespace is not advisable.) > Thanks, I appreciate it :-) PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 14:43:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00659; Mon, 16 May 1994 14:43:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA24953; Mon, 16 May 1994 14:43:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24897; Mon, 16 May 1994 14:37:28 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00311; Mon, 16 May 1994 14:37:21 +1000 (from ses@tipper.oit.unc.edu) Received: from [152.2.22.85] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10417 Mon, 16 May 1994 14:27:19 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA08558; Mon, 16 May 94 00:23:37 EDT Message-Id: <9405160423.AA08558@tipper.oit.unc.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, mo@uunet.uu.net Subject: Re: Noel's lamentations... In-Reply-To: Your message of "Sun, 15 May 94 22:58:07 EDT." <9405160258.AA13659@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 May 94 00:23:37 -0400 From: Simon E Spero jnc@ginger.lcs.mit.edu (Noel Chiappa) writes: > >First, we should try and do designs that have the kind of flexibility that >will allow us to less painfully take up the lessons we're obviously going to Master, what is the true nature of the internet protocol? Is it more than source, destination, and data, and is the data unknowable? If the form of the source and destination eids remain fixed, can different incarnations of the internet protocol be bridged unto each other? > it is safe to assume that *something* which materially shifts the model > will happen in 20 years In 20 years I plan to be sun-bathing on the yacht somewhere close to Cannes, watching TV over a spread-spectrum link to the Huitema Research Institute. If my drink ends up getting warm because the network breaks down in the middle of the game (Dean Smith coaching his way to his 10th NCAA title) I am going to be seriously annoyed. >Arrghh! Every time people say things like that you really scare me. I'm human; >I make lots of mistakes (and I've made some massive ones). All I ask is that >people listen, and think hard to see if what I say makes sense... "Only the true Messiah denies his divinity." Actually, I have this picture in my head of that Nike commercial; "I am not a role model. Just because I can route a packet doesn't mean I should build your network." Hey - even the hairstyles are the same :) From owner-Big-Internet@munnari.OZ.AU Mon May 16 14:45:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00716; Mon, 16 May 1994 14:45:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA24968; Mon, 16 May 1994 14:45:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24900; Mon, 16 May 1994 14:37:56 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00359; Mon, 16 May 1994 14:37:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: from GINGER.LCS.MIT.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10633 Mon, 16 May 1994 14:35:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14126; Mon, 16 May 94 00:34:25 -0400 Date: Mon, 16 May 94 00:34:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405160434.AA14126@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) plan simply and tightly, then build and deploy, and then iterate as incremental functionality is deemed necessary and possible. This iteration can be expensive, depending on how widespread the effects; IPng is an example of such an iteration, and it's painful. I used (some years ago) to be in favor of doing a new IP then, and then, at the IAB architecture retreat in the spring of '90 or so, I heard an argument that made me change my mind. The point was that the underlying transmission technology, etc, is changing so fast that it's wise to delay as long as you can, to learn as much as you can. There is obviously some disagreement as to when "as long as you can" runs out. You think it already has, others don't agree. But knowing HOW to solve a problem in a way that will work adequately (efficiency, robustness, scaling, ...) AND gain community consensus is what we find takes so much time. Yes, but we have to develop that consensus; there's no way to bypass it. I find it's easier to develop that consensus if we can get the politics of chosing group X's design over group Y's out of the way... It means that you either design, build and deploy what you DO know now Right, and that's why I like the approach were we deploy a new internetwork layer in pieces, not all at once; we can try one version of a new piece, and if it's not optimal, we can try another version. Noel From owner-Big-Internet@munnari.OZ.AU Mon May 16 14:57:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00195; Mon, 16 May 1994 13:21:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA24764; Mon, 16 May 1994 13:21:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA24761; Mon, 16 May 1994 13:20:49 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25353; Mon, 16 May 1994 11:04:12 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 10:03:23 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA04877; Mon, 16 May 1994 10:03:23 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA15986; Mon, 16 May 94 10:03:22 JST Date: Mon, 16 May 94 10:03:22 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160103.AA15986@cactus.slab.ntt.jp> To: francis@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU, ipng@cmf.nrl.navy.mil > You are assuming the solution in the above "requirement", > that is, you are assuming a "location independant identifier". > > No, that's not the solution, its a requirement - the reason is > that I don't believe that location dependant identifiers can > be allocated in an effecient enough manner that we can > reasonably allocated a fixed width field of any reasonable > size that we can really be sure is going to last forever. Ok, then add the requirement that said identifier must be less than or equal to whatever number you find appropriate, say 64 bits? Well, even that is specifying a solution. A real requiement would say something like "the identifier must be parsable by a current state of the art computer in xx micro-seconds). Blah. PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 15:01:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01490; Mon, 16 May 1994 15:01:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA25030; Mon, 16 May 1994 15:01:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24984; Mon, 16 May 1994 14:51:12 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29035; Mon, 16 May 1994 12:47:57 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA08252; Sun, 15 May 94 22:47:48 EDT Message-Id: <9405160247.AA08252@tipper.oit.unc.edu> To: Robert Elz Cc: francis@cactus.slab.ntt.jp (Paul Francis), big-internet@munnari.OZ.AU, smart@mel.dit.csiro.au Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Mon, 16 May 94 11:24:05 +1000." <18324.769051445@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 May 94 22:47:47 -0400 From: Simon E Spero Robert Elz writes: > Since addresses can be used to reverse map into DNS, I don't > think we need EIDs to do it.... > >But I don't want addresses to reverse map the DNS - doing >that causes too many problems, either you have to confine >your internal field boundaries to the defined DNS name >mapping boundaries (probably octets), which can waste lots >of address space (more wasted bits), or the DNS management >problems become truly painful. Because you need internal These problems are with the DNS, not with other directory services currently under construction. The more advanced forwarding information in centroid-based services can handle reverse lookups of non-aligned EIDs without the in-addr.arpa hackery. Don't kludge IPng just to work around breaking in DNS-tos. Simon From owner-Big-Internet@munnari.OZ.AU Mon May 16 15:04:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01560; Mon, 16 May 1994 15:04:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA25045; Mon, 16 May 1994 15:04:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA25027; Mon, 16 May 1994 14:58:20 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01800; Mon, 16 May 1994 13:57:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13927; Sun, 15 May 94 23:56:52 -0400 Date: Sun, 15 May 94 23:56:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405160356.AA13927@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) A point people keep missing is that we have heaped a wide range of useful but complicated and new features onto IPng. While these features will be useful they are not really essential to initial deployment. We are, after all, living without them now. ... By definition, they are not required for inital deployment. We may be living without them now, but the need for them is seen as pressing enough that there is considerable effort under way to develop these capabilities within IPv4. The real point to note, however, is that because we have to work within the confines of IPv4, the mechanisms chosen to provide them often aren't the best ones. That's why it is really a good idea to design then in from the start in IPng. Hence, counting them against the validity of the early demos is, in my opinion, itself not valid. This much is certainly true. Noel From owner-Big-Internet@munnari.OZ.AU Mon May 16 15:49:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01642; Mon, 16 May 1994 15:06:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA25062; Mon, 16 May 1994 15:06:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24979; Mon, 16 May 1994 14:49:47 +1000 Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01023; Mon, 16 May 1994 14:49:55 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 16 May 1994 13:49:51 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id NAA08251; Mon, 16 May 1994 13:49:51 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA19743; Mon, 16 May 94 13:49:50 JST Date: Mon, 16 May 94 13:49:50 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405160449.AA19743@cactus.slab.ntt.jp> To: big-internet@munnari.OZ.AU, mo@uunet.uu.net Subject: Re: IEEE 802 not unique enough??? > > Well, then, we have a serious problem. I submit that except for > systems which intentionally spoof the MAC address, the IEEE 802 > assignment machinery is the most successful ever fielded to date. If > people don't think that job is good enough, then they better have something > *very* well-thought-out to offer instead. Not that it probably cannot > be improved upon, but it has worked awfully damn well aside from inevitable > accidents and botches. But anyone's track record won't be perfect, so > what does that say about the basic idea if you gotta do much better > than IEEE 802 for it to work????? > Yeah, this is a good point. I have a hard time believing that an EID assignment hierarchy of: root authority -> regional authority -> private orgs. Is going to work better (ie, result in fewer duplicate assignments) than: root authority -> vendors The reason one can get away with the above strategy for addresses is that the address won't work (globally) unless it follows the hierarchy right. With EIDs, they can be many duplicates, and they will work fine most of the time, and break just occasionally. I can just imagine, with the former strategy, some vendor figuring out that he can really simplify configuration for his customers by pseudo-randomly generating the EIDs. (Of course, maybe that would work just fine with a large EID space and good random number generators !!!) PF From owner-Big-Internet@munnari.OZ.AU Mon May 16 15:59:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01136; Mon, 16 May 1994 14:52:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA25000; Mon, 16 May 1994 14:52:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24906; Mon, 16 May 1994 14:39:31 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00462; Mon, 16 May 1994 14:39:11 +1000 (from deering@parc.xerox.com) Received: from [13.1.64.93] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10332 Mon, 16 May 1994 14:22:52 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14649(6)>; Sun, 15 May 1994 21:20:06 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 15 May 1994 21:19:55 -0700 To: big-internet@munnari.OZ.AU Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), deering@parc.xerox.com Subject: Re: Thoughts on the IPng situation... In-Reply-To: jnc's message of Sat, 14 May 94 15:12:05 -0800. <9405142212.AA07416@ginger.lcs.mit.edu> Date: Sun, 15 May 1994 21:19:53 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94May15.211955pdt.12171@skylark.parc.xerox.com> I think what's going on here is a fundamental disagreement over whether we need a new *architecture* for the internet layer, or a new *instantiation* of the current architecture. By "the current architecture", I am referring to the datagram/connectionless internet design, which uses a common internet protocol layered on top of the services offered by a variety of networks, uses hop-by-hop routing based on globally-unique, hierarchical addresses that are carried in every packet, and offers a best-efforts delivery service for variable-length packets, up to a few hundred to a few thousand bytes in length. The architects of the current architecture were the people who designed IP and Pup. Some other instantiations of that architecture, besides IP and Pup, are XNS's internet protocol and its descendant IPX, Appletalk, and CLNP. Examples of protocols that are *not* instantiations of the current architecture are X.25, ISDN, Frame Replay, and ATM. (And let's not debate whether those all belong to the same architecture -- "connection-oriented" -- or to different architectures -- "reliable, connection-oriented", "cell-based, connection- oriented", etc.) Now if you believe that we need a new architecture, then Noel's comments make perfect sense. Coming up with a new architecture is a major undertaking. It should entail deep re-examination of every decision made in previous architectures, and going back to first principles to decide what services, functions, and concrete realizations should be included in the new architecture. It cannot be rushed or held to any artificial deadline. We should not worry about external perceptions that we are "taking too long", because the job of fully defining a new architecture should be recognized by everyone as one that takes long and careful thought, prototyping, and testing. On the other hand, if you believe that we need a new instantiation of the current architecture, then it is reasonable to ask "why is it taking so long?" The current architecture is well-understood. We have lots of previous experience to draw on, both in IPv4 and in other instantiations of the same architecture. It should just be a matter of competent engineering. If the Internet *Engineering* Task Force cannot manage that task, then it might as well be disbanded, and the job taken up by Novell or cisco or any other bright group of network engineers who will just get the job done. I do not believe the Internet needs a new internet-layer architecture. The current architecture has proven remarkably flexible and robust, due to its minimal requirements from lower layers, its minimal service "promises" to upper layers, and its simple, stateless, datagram routing and forwarding model. As a result, it has survived the introduction of many new lower-layer technologies and many new applications (including real-time applications). Its functionality has been upgraded continuously (e.g., new routing protocols, subnets and CIDR, multicast, MTU discovery, DHCP, ...) *without* changing the architecture. As Yakov has pointed out, almost every feature, function, or capability that has been suggested as desirable for IPng can be provided in IPv4 (an instance of the current architecture), except a bigger address space. For example, the current architecture can support policy-based routing (SDRP), mobility (Mobile IP), auto-configuration (DHCP), and flows (CSZ/RSVP). Acknowledging that kludges are in the eye of the beholder, I do not view the implementation of those functions in IPv4 to be kludges that are corrupting the purity of the original architecture (and therefore evidence that a new architecture is needed), but rather I see the fact that they can be accommodated within the current architecture as validation of the flexibility and potential longevity of that architecture. Granted, the implementation of some of those functions might not be as efficient as they would be in a different protocol than IPv4, but in most cases that's simply a problem with the *instantiation* of the architecture, not the architecture itself. For example, new services or functions that take advantage of the *architected-in* extensibility mechanism of IPv4 -- IP header options -- suffer from the particular instantiation of that mechanism in IPv4 (small bound on option length, need for all routers to parse all options). I *do* believe the Internet needs a new instantiation of the current architecture -- an IPng -- in order to increase the address space, to allow for both more hierarchy and more nodes (i.e., the original ROAD problems). Given the long time it will take to deploy, the unpredictability of the growth of the Internet, and the exploitation of IPv4's perceived limited lifetime by those who wish the Internet to die, I think it is important to come to agreement on IPng as soon as possible. Since I do not see this as a grand architectural undertaking (though it will certainly be a grand implementation, deployment, and transition undertaking), and I do not see that we need a new architecture so desperately that we should risk the demise of the Internet waiting for one to be defined, tested, and agreed upon, I see no reason not to choose an IPng in July. I am not particularly worried about IPng having to be replaced by an IPngng in the near future. (I'm more worried that, if we don't get IPng out there soon, we'll end up with NAT boxes everywhere, which will *break* the current architecture.) If we *engineer* (not *architect*) IPng well, there's a fair chance that it will serve as the final refinement of the current architecture, perhaps serving as a transition target for other instantiations of the architecture, such as IPX, Appletalk, and CLNP. Whatever comes next -- if anything comes next -- will be a completely different architecture, not an IP-anything, and it will be deployed, as ATM is being deployed, oblivious to the internet architecture. When Noel accuses SIP (I can't speak for the other proposals) as lacking its own architectural philosophy, or of being "only another header design", he is exactly right. The architects for SIP were those who designed the datagram internet model (Cerf, Postel, Shoch, et. al.). SIP is simply a new instantiation or engineering of their architecture, taking into account some of the lessons learned from previous instantiations (e.g., the value of good alignment, the value of fixed-length, relatively compact addresses, the need for more efficient and less length-bounded option encoding, the inadvisability of internet-layer fragmentation, etc.) It's "only another header design", because the only problem with IPv4 that makes it worthwhile to undertake the pain of deploying a new version is a header design problem: its address fields are too small to accommodate the projected growth of the Internet. My contention that IPng is *rightly* "just header design" does *not* mean that I think header design is unimportant. True, it is not nearly as important as architecture, but in my opinion, we already have an excellent architecture with lots of life left in it -- if it *is* going to last a long time, we want to have a reasonably good instantiation of it, based on our experience with it so far. That's one of the reasons I was opposed to the IAB's Kobe decree that CLNP be IPng -- I thought (and still think) that CLNP is a poor instantiation of the architecture, and I believed that the Internet community could design something better. We have now had the time to try to do that, and it is time for the community to judge those attempts and make a decision. If the choice is still CLNP, so be it. I should point out that I think Pip was more than "just header design"; it also embodied significant new architecture, and those parts of SIPP that are derived from Pip (generalized use of "source routing" for hierarchical addressing, provider-selection, mobility, address-changing, etc.) are certainly not based on the earlier instances of the internet architecture. And I should also admit that Paul and I disagree sometimes about whether or not those new architectural features should be considered as optional functionality or part of the base design. Certainly, the introduction of a new version of IP gives us a rare chance to introduce promising new architectural features, but my conservative design nature would like to avoid risking the success of the design on the success of those new features. The same is true of features like the Traffic Class and Flow ID fields in the SIPP header. Based on my own architectural work (wearing a different hat than my IPng Engineer's hat) and that of more architectural thinkers with whom I have frequent contact (Zhang, Shenker, Clark, Jacobson, Estrin, Huitema, and others), I have incorporated features into SIPP that seem likely to satisfy their/our vision of how the internet architecture might evolve. However, I have been careful to make those features optional. If they don't pan out (like IPv4 TOS didn't pan out), it won't hurt anything (the space they occupy in the header would have been spent anyway, for alignment reasons). They are basically just mechanisms to improve efficiency of forwarding and/or link utilization -- if they don't work, then we can fall back on our traditional solution: more bandwidth and faster routers. One thing we have learned is that the current architecture does not cleanly support migration to new versions of the internet-layer protocol. This is not too surprising, given that a fundamental feature of the architecture is the use of a single, universal internet-layer protocol. I hope that the current exploration of transition strategies (IPAE, dual-stack, etc.) will lead to architectural insights for the future, whether for transitioning to an IPngng if necessary, or for transitioning other internet protocols to IPng. To bring this rambling message to a close, I suggest that we suspend arguments over the requirements for IPng (and self-flagellation over our mistakes of the past, whatever we perceive them to be) until we have agreed on the meta-requirement: must IPng embody a new internet architecture, or can it simply be a re-engineering of IPv4? If you believe that we need a new architecture, do you think we can do a proper job of designing, testing, agreeing on, and deploying it before the market decides to give up on IPv4 and migrate to a better version of the current architecture (e.g., a new version of IPX) or an alternative architecture (e.g., ATM)? Steve From owner-Big-Internet@munnari.OZ.AU Mon May 16 16:24:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01865; Mon, 16 May 1994 16:24:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA25159; Mon, 16 May 1994 16:24:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA25156; Mon, 16 May 1994 16:10:42 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01345; Mon, 16 May 1994 16:10:32 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 16 May 94 15:04:23 +0900 From: Masataka Ohta Message-Id: <9405160604.AA25491@necom830.cc.titech.ac.jp> Subject: Re: addressing/locating/identifying models To: ses@tipper.oit.unc.edu (Simon E Spero) Date: Mon, 16 May 94 15:04:22 JST Cc: kre@munnari.OZ.AU, francis%cactus.slab.NTT.JP@CS.TITECH.AC.JP, big-internet@munnari.OZ.AU, smart@mel.dit.csiro.au In-Reply-To: <9405160247.AA08252@tipper.oit.unc.edu>; from "Simon E Spero" at May 15, 94 10:47 pm X-Mailer: ELM [version 2.3 PL11] >But I don't want addresses to reverse map the DNS - doing >that causes too many problems, either you have to confine >your internal field boundaries to the defined DNS name >mapping boundaries (probably octets), which can waste lots >of address space (more wasted bits), or the DNS management >problems become truly painful. It has nothing to do with DNS. You shouldn't have a lot of internal fields, or you are force to have unreasonably lengthy (20 octets, for example) EIDs. In our University with a class B address, a unit of 4 subnets each cantaining 62 hosts are delegated to each department without faculty level structure and everything works fine. If a department wants another four subnets, they are allocated. DNS (or any mapping) management problems become truly painful when you have a lot of hierarchies. It seems to me that a lot of people are now complaing about IP and IPng not becase they are bad but because thier local management is bad. Masataka Ohta PS It is easy to construct reverse mapping mechanism of IPng have bit-wise boudaries. From owner-Big-Internet@munnari.OZ.AU Mon May 16 18:59:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01254; Mon, 16 May 1994 16:05:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA25129; Mon, 16 May 1994 16:05:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA25115; Mon, 16 May 1994 15:50:16 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01945; Mon, 16 May 1994 15:15:27 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14649(5)>; Sun, 15 May 1994 22:15:12 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 15 May 1994 22:14:58 -0700 To: Robert Elz Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Requirements In-Reply-To: kre's message of Sun, 15 May 94 07:33:11 -0800. <18053.769012391@munnari.OZ.AU> Date: Sun, 15 May 1994 22:14:46 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94May15.221458pdt.12171@skylark.parc.xerox.com> > With the latter in mind, could I ask those working on the > various candidates to reply and let me know what you're going > to do when your candidate is rejected? If SIPP is rejected in favor of some other protocol in July, I will stop working on SIPP and do what I can to make that other protocol as good as possible. I consider the viability of the Internet to be much more important than which protocol is the "winner". (Let me point out that for several years now I have been trying to help the CLNP designers incorporate a multicast capability, most recently in Seattle last month, where I suggested a solution to their "multi-homed multicast originator" problem. Though I try to help, they usually don't take my advice, which of course is their prerogative. I also tried to contribute positively to Pip, while it was a separate proposal "competing" with SIP.) If *all* the IPng candidates are rejected in July, I will stop working on SIPP and I will probably give up on the IETF in disgust. I consider the viability of the Internet to be more important than my allegiance to the IETF, and I think that failure to decide on a solution to IPv4 address space growth would place the viability of the Internet seriously at risk (in fact, I think it has already done so). I'd probably get back to what I'd really rather be doing than all this IPng crap, that is, working on multicast routing and internet-layer support for connectionless multi-media traffic, and I would look for opportunities to incorporate that work into whatever internet protocol looked best positioned to take over from IP in providing the next-generation Internet (IPX?). Steve From owner-Big-Internet@munnari.OZ.AU Mon May 16 18:59:24 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01014; Mon, 16 May 1994 15:58:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12855 Mon, 16 May 1994 15:31:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA24982; Mon, 16 May 1994 14:51:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA24903; Mon, 16 May 1994 14:38:15 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00377; Mon, 16 May 1994 14:38:05 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: from [131.112.4.4] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10414 Mon, 16 May 1994 14:27:17 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 16 May 94 13:16:50 +0859 From: Masataka Ohta Message-Id: <9405160417.AA24392@necom830.cc.titech.ac.jp> Subject: Re: Do we have an architecture? To: jcurran@nic.near.net (John Curran) Date: Mon, 16 May 94 13:16:49 JST Cc: brian@dxcoms.cern.ch, tracym@nsd.3com.com, big-internet@munnari.oz.au In-Reply-To: <9405150823.aa21908@nic.near.net>; from "John Curran" at May 15, 94 8:22 am X-Mailer: ELM [version 2.3 PL11] John; > ] > ARP is sufficient for many applications, but it _does_ have some > ] > characteristics that make it difficult to use in a dynamic environment. > ] > ] Dynamic environment should be taken care of by mobility. Interaction > ] between mobility and ARP is well understood (HR proxy-arps MH). There > ] is no difficulty in it. > > > > It's good to hear that it's so well understood, Masataka. Perhaps > we should all ignore the discussion section (Appendix B) of > since use of ARP with mobility > is so straightforward? If ARP packets are not lost, the protocol is straightforward. If a packet is lost, we must depend on some time-out and retry mechanism whose detail I'm not interested in. ES-IS is no exception. > One might claim that we're going through quite a bit of additional > complexity (gratuitous proxy ARP replies, related security issues, > concern over lost messages) simply because ARP is not dynamic... Whatever protocol including ES-IS you may use, if important packets are lost, you can't expect much dynamism. BTW, ARP has timeout and is dynamic. > ] ARP is a good design. There was some applications or systems which use > ] broadcast in a wrong way. To prevent the effect of them minimal, we > ] should make size of a single datalink layer as small as possible. > > I've change my mind; I agree with the above. ARP is a good design > FOR A RATHER LIMITED PROBLEM SPACE. Happily, the current suite of > IPng proposals all embrace a larger set of requirements, so we may > not have to put up with ARP's contraints forever. ARP is a good design for a limit number of hosts. We have no reason to expand the size of a single datalink beyond, say, 100. Brian; > > The problem is in poor management of CERN, not in broadcast. > > > Oh, thanks, we'll fix it tomorrow. > > COME ON! Do you think we run the network the way we do because > we are stupid? I don't NEED this sort of comment on public > lists, THANK YOU! > (Well, that made me feel a little better. Now let me explain why > we run a 6000-node bridged Class B network. It's poor management of CERN. I'm not interesteed in why. The reason may be poor budget for networking or fool managers or both. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon May 16 19:20:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08132; Mon, 16 May 1994 19:05:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA25306; Mon, 16 May 1994 19:04:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA25303; Mon, 16 May 1994 19:02:38 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03333; Mon, 16 May 1994 17:02:46 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA28427; Mon, 16 May 1994 09:02:31 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA14814; Mon, 16 May 1994 09:02:31 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405160702.AA14814@dxcoms.cern.ch> Subject: Re: Requirements (was : FORMAL REQUEST : SIPP EIDs and Locators) To: big-internet@munnari.OZ.AU (bigi) Date: Mon, 16 May 1994 09:02:31 +0200 (MET DST) In-Reply-To: <199405112012.NAA13979@Mordor.Stanford.EDU> from "Dave Crocker" at May 11, 94 01:12:34 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 750 Folks, I would just like to say that while reviewing the IPng candidate proposals for the IPng Directorate, I found that the draft requirements doc and a few other requirements mooted by email were largely sufficient to support a review. Obviously, once we are down to one proposal it has to be engineered into its final state using more and more concrete requirements. Right now, couldn't we concentrate on reaching rapid consensus on which proposal to adopt? We have all the information needed to do that. Wouldn't it be nice if Scott and Allison could stand up in Toronto and say "As you all know, the consensus is that IPng will be XYZ."? Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.OZ.AU Mon May 16 19:44:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09594; Mon, 16 May 1994 19:44:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA25387; Mon, 16 May 1994 19:44:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA25373; Mon, 16 May 1994 19:38:25 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09303; Mon, 16 May 1994 19:38:19 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA20608; Mon, 16 May 1994 11:35:48 +0200 Message-Id: <199405160935.AA20608@mitsou.inria.fr> To: Masataka Ohta Cc: bsimpson@morningstar.com, big-internet@munnari.OZ.AU Subject: Re: 64K (was tangential to Re: FORMAL REQUEST : SIPP EIDs and Locators ) In-Reply-To: Your message of "Sat, 14 May 1994 17:52:47 +0200." <9405140853.AA16514@necom830.cc.titech.ac.jp> Date: Mon, 16 May 1994 11:35:47 +0200 From: Christian Huitema => > Also, the preliminary data that Craig Partridge released to end2end, => > using small 512 byte packets, shows an undetected (by the AAL5 32-bit => > CRC) error-rate of 1.6 * 10**-10. That seems small, until you remember => > that your target speeds are at 10**-9 bps. An undetected error over => > every ATM link every 10 seconds is a lot of errors! => => Bogus. => => You are assuming that physical layer error rate is 100%. => => If physical layer error rate is, for example, 10^-6, we will have => undetected error, which may later be detectet at network layer, about => once a half year. => => Masataka Ohta Yes. The more I think of it, the more I believe that real error detection belongs to the application. It is trivially embedded in the unmarshalling functions; it is also a natural side effect of cryptographic signatures. Is the data is going to be MD5 protected, then we effectively have a 128 bits checksum! The probably of having an error pass undetected is then about 1 in 10**38... Christian Huitema From owner-Big-Internet@munnari.OZ.AU Mon May 16 22:24:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13983; Mon, 16 May 1994 22:24:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA25528; Mon, 16 May 1994 22:24:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA25522; Mon, 16 May 1994 22:21:01 +1000 Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12821; Mon, 16 May 1994 21:35:31 +1000 (from perk@watson.ibm.com) Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9389; Mon, 16 May 94 07:35:30 EDT Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 3956; Mon, 16 May 1994 07:35:36 EDT Received: from np2.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Mon, 16 May 94 07:35:35 EDT Received: by np2.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA17509; Mon, 16 May 1994 07:35:26 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9405161135.AA17509@np2.watson.ibm.com> To: big-internet@munnari.OZ.AU Subject: Re: Pick one, look at the rest In-Reply-To: (Your message of Sun, 15 May 94 14:53:22 MST.) <9405152153.AA16841@jurassic.Eng.Sun.COM> Date: Mon, 16 May 94 07:35:26 -0500 If a selection is made in July, what is the likelihood that the successful contender will continue to evolve in order to better meet the "requirements"? I can well imagine that the existing implementations would present inertia, effectively deterring future modifications, unless the project leaders explicitly make it one of their goals to accept a long period of change and experimentation. It could be that a decision in July would be one of the first steps along the path to understanding IPng, not one of the last. Maybe the IP community should try to have an incompletely deployed experimental protocol. This would be our "best bet" IPng, partially deployed, but intentionally not "finished" until we really start to see the immediate need. Hopefully, the operational experience with the experimental protocol would give confidence that it could be put into service when needed. As solutions come along for the requirements that IP does not do well now, those solutions could be put into place in the experimental protocol before it gets universally deployed. Sites deploying the experimental protocol would agree to make changes as they are identified and implemented by the IPng community. One might characterize this approach as "keeping our options open". IF it did happen that IPng finally met all the requirements, then it could be deployed right away. Since this hasn't been done before on such a wide scale, I don't know whether such an approach is feasible. Charlie P. From owner-Big-Internet@munnari.OZ.AU Mon May 16 22:29:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14076; Mon, 16 May 1994 22:29:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA25554; Mon, 16 May 1994 22:28:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA25525; Mon, 16 May 1994 22:21:49 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13152; Mon, 16 May 1994 21:46:12 +1000 (from lyman@BBN.COM) Message-Id: <9405161146.13152@munnari.oz.au> From: Lyman Chapin Subject: Re: IEEE 802 not unique enough??? To: francis@cactus.slab.ntt.jp Cc: big-internet@munnari.OZ.AU, mo@uunet.uu.net In-Reply-To: <9405160449.AA19743@cactus.slab.ntt.jp> Date: Mon, 16 May 94 06:56:57 EDT Mail-System-Version: >Date: Mon, 16 May 94 13:49:50 JST >From: francis@cactus.slab.ntt.jp (Paul Francis) >To: big-internet@munnari.oz.au, mo@uunet.uu.net >Subject: Re: IEEE 802 not unique enough??? > >> >> Well, then, we have a serious problem. I submit that except for >> systems which intentionally spoof the MAC address, the IEEE 802 >> assignment machinery is the most successful ever fielded to date. If >> people don't think that job is good enough, then they better have something >> *very* well-thought-out to offer instead. Not that it probably cannot >> be improved upon, but it has worked awfully damn well aside from inevitable >> accidents and botches. But anyone's track record won't be perfect, so >> what does that say about the basic idea if you gotta do much better >> than IEEE 802 for it to work????? >> > >Yeah, this is a good point. I have a hard time believing that an >EID assignment hierarchy of: > >root authority -> regional authority -> private orgs. > >Is going to work better (ie, result in fewer duplicate assignments) >than: > >root authority -> vendors > >The reason one can get away with the above strategy for addresses is >that the address won't work (globally) unless it follows the hierarchy >right. With EIDs, they can be many duplicates, and they will work fine >most of the time, and break just occasionally. I can just imagine, with >the former strategy, some vendor figuring out that he can really simplify >configuration for his customers by pseudo-randomly generating the EIDs. >(Of course, maybe that would work just fine with a large EID space and >good random number generators !!!) > >PF Paul, At some point during our discussions of addressing in X3S3.3 about ten years ago, Dave Oran pointed out that DEC had done an analysis of a random-number generator scheme for MAC addresses, and determined that the likelihood of a duplicate assignment was substantially lower than it would be for a scheme that relied on a two-level hierarchy (root authority - e.g. IEEE - and one subordinate - e.g. vendors). I don't know what model DEC used to estimate the likelihood of errors in the latter case, but perhaps someone from DEC who is on big-I could dig up this work and see if it's relevant. [I do remember Dave saying that the principal reason DEC abandoned the idea of randomizing the assignment of ethernet address blocks was that they didn't think that customers would ever be confident that it worked as claimed...] - Lyman From owner-Big-Internet@munnari.OZ.AU Mon May 16 23:24:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15756; Mon, 16 May 1994 23:24:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA25608; Mon, 16 May 1994 23:24:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA25605; Mon, 16 May 1994 23:15:50 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15494; Mon, 16 May 1994 23:15:46 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id ab27775; 16 May 94 9:15 EDT To: Steve Deering Cc: big-internet@munnari.OZ.AU, Noel Chiappa Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of Sun, 15 May 1994 21:19:53 -0700. <94May15.211955pdt.12171@skylark.parc.xerox.com> Date: Mon, 16 May 1994 09:14:41 -0400 From: John Curran Message-Id: <9405160915.ab27775@nic.near.net> -------- ] From: Steve Deering ] Subject: Re: Thoughts on the IPng situation... ] Date: Sun, 15 May 1994 21:19:53 PDT ] ] I do not believe the Internet needs a new internet-layer architecture. The ] current architecture has proven remarkably flexible and robust, due to its ] minimal requirements from lower layers, its minimal service "promises" to ] upper layers, and its simple, stateless, datagram routing and forwarding ] model. As a result, it has survived the introduction of many new lower-layer ] technologies and many new applications (including real-time applications). ] Its functionality has been upgraded continuously (e.g., new routing protocols, ] subnets and CIDR, multicast, MTU discovery, DHCP, ...) *without* changing the ] architecture. As Yakov has pointed out, almost every feature, function, or ] capability that has been suggested as desirable for IPng can be provided ] in IPv4 (an instance of the current architecture), except a bigger address ] space. For example, the current architecture can support policy-based ] routing (SDRP), mobility (Mobile IP), auto-configuration (DHCP), and flows ] (CSZ/RSVP). Acknowledging that kludges are in the eye of the beholder, ] I do not view the implementation of those functions in IPv4 to be kludges ] that are corrupting the purity of the original architecture (and therefore ] evidence that a new architecture is needed), but rather I see the fact ] that they can be accommodated within the current architecture as validation ] of the flexibility and potential longevity of that architecture. ] ... We're going to have to "agree to disagree" on this one... While it's really wonderful that we can warp IPv4 into doing all of these things, the lack of architecture to support them becomes clear when you try and predict how any combination of capabilities will interact. I'd hold off praising the flexibility of the existing architecture until we have actual deployment and usage of these new capabilities in the real world. I don't think that we need a brand-new architecture for IPng; I do think that revisiting our existing model in light of the lessons learned from the mobility, resource and security working groups might be a good idea. It may even allow us to make simplying assumptions which will reduce overall complexity and improve robustness of the services provided. /John p.s. Perhaps the current architecture is "remarkably flexible", even to the point of allowing a bigger address space. After all, isn't that the whole point of NAT... ;-) From owner-Big-Internet@munnari.OZ.AU Tue May 17 00:59:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17641; Tue, 17 May 1994 00:05:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA25663; Tue, 17 May 1994 00:04:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA25647; Mon, 16 May 1994 23:45:30 +1000 Received: from OSI.NCSL.NIST.GOV by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14634; Mon, 16 May 1994 22:47:08 +1000 (from colella@osi.ncsl.nist.gov) Received: from emu.ncsl.nist.gov.noname by osi.ncsl.nist.gov (4.1/SMI-4.0-MHS-7.0) id AA16051; Mon, 16 May 94 08:46:47 EDT Date: Mon, 16 May 94 08:46:47 EDT Message-Id: <9405161246.AA16051@osi.ncsl.nist.gov> To: atkinson@itd.nrl.navy.mil Subject: Re: IPng security, etc. Cc: big-Internet@munnari.OZ.AU, jcurran@nic.near.net, colella@nist.gov, ccm-dev@munnari.OZ.AU From: colella@nist.gov Reply-To: colella@nist.gov Ran, > % What about draft-ietf-tuba-inlsp-00.txt? I'll admit that I have not > % completed my reading of it (as there's something quite unnerving about > % the combination of OSI and security jargon in one document... ;-) > > John, > > A note to big-Internet within the last month from someone at NIST > indicated that TUBA no longer plans to use NLSP. > > At Seattle, during the Thursday afternoon meeting of the Security > Area Advisory Group (SAAG), I was drafted by the AD to outline what > SIPP was doing for security. I did so at warp speed without any > preparation. Someone from the audience asked about other IPng > proposals. I commented that "TUBA apparently plans to use NLSP". I > was corrected from the audience with a statement that TUBA did _not_ > plan to use NLSP but instead would use the (currently non-existent) > IPv4 Security Protocol instead. All of these statements about TUBA and security are absolutely correct. Up until the Seattle meeting we were still planning to work within the IPSEC. Immediately after Seattle we concluded that IPSEC was moving much too slowly and decided to do the work under the TUBA WG instead. John is referring to an I-D that was distributed to the TUBA list on Thursday and sent off to be an I-D on Friday (it's in the I-D directory at CNRI as draft-ietf-tuba-inlsp-00.txt in case you're interested -- I'm sure the announcement will come RSN). FYI, I've appended the abstract. --Richard TUBA Working Group K. Robert Glenn (NIST) INTERNET-DRAFT Integrated Network Layer Security Protocol For TUBA (draft-ietf-tuba-inlsp--00.txt) (Posted: May 16, 1994/Expires: November 16, 1994) Abstract This Internet Draft specifies a protocol that may be used by End Sys- tems (ESs) and Intermediate Systems (ISs) in order to provide secu- rity services in support of TUBA. The TUBA deployment and transition plan relies on a dual-stack (i.e., CLNP and IPv4) approach to evolv- ing the Internet to IPng. Thus, to provide secure operation in an TUBA environment this Internet Draft defines a simple Integrated Net- work Layer Security Protocol (I-NLSP) that provides confidentiality and integrity services for both CLNP and IPv4. TUBA systems supporting I-NLSP will be capable of secure operations with: (1) other TUBA/I-NLSP systems using either CLNP or IP, and or (2) exist- ing IPv4 operating behind TUBA/I-NLSP capable secure ISs. From owner-Big-Internet@munnari.OZ.AU Tue May 17 01:04:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19779; Tue, 17 May 1994 01:04:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA25728; Tue, 17 May 1994 01:04:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA25725; Tue, 17 May 1994 00:59:55 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17816; Tue, 17 May 1994 00:07:55 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA23463; Mon, 16 May 94 07:03:18 -0700 Received: by xirtlu.zk3.dec.com; id AA18270; Mon, 16 May 1994 10:03:14 -0400 Message-Id: <9405161403.AA18270@xirtlu.zk3.dec.com> To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: bound@zk3.dec.com, big-internet@munnari.OZ.AU Subject: Re: Requirements In-Reply-To: Your message of "Sat, 14 May 94 08:35:43 PDT." Date: Mon, 16 May 94 10:03:08 -0400 X-Mts: smtp =>When you say this do you mean we need to start in July? =>Or =>We need to get the specs in order so we can start after July? >Since there are no IPng products, as far as I know, how could we start >deploying in July? Since I've been distinguishing between core and >near-term, there is a chance that the core specs will be in order by July. >If they are, they should be elevated, implemented, etc. I agree. => Some think there done I don't. >Specifics? Or is your EID submission an example? Yes thats one example. Here is one for each OK. SIPP: Two different people writing use of unicast address as we speak. This is one of your MUSTS. TUBA: CLNP Multicast ink is still wet and I am aware of no implementations. I recall this is one of your musts and definitely one of mine. CATNIP: No transition specification addressing the ramifications of transition with this proposal. TURNIP / IPING / others - Not valid to me as real proposals. Might be good ideas though TURNIP to me is just CATNIP. => it causes me pain in my brain and not just a minor =>annoyance. >Hmmm. I wonder it it's anything like the reaction one might get to seeing >efforts to add a major requirement 2 months before a final deadline, after >nearly 2 years of discussion and development? I am sure this is similar. Touche ... =>Thats because the demos were toy code so far not even real prototypes >They were not toy code for SIP. I doubt they were toy code for TUBA. >They weren't product, either, but they sure weren't toy. The reference toy code means building blocks to test out key functionality. For example on a BSD system how routes are stored (and for PMTU too) were not used for the demos. From my inquiry they were hard coded. Hard coded software for demos is not testing the entire systems environment per the change. =>where you depended on the IPng changes like system discovery to find =>your router as opposed to just tunneling which is what they all did. >Huh? They did NOT all do ONLY tunneling. To get across the Internet from Amsterdam with an IPng packet they had to be tunneled or translated. I was not commenting on the mirrors on the local machine that may have been implemented to describe the demo. You should have come to the SIPP implementors meeting you would have gotten the real status of where folks stated they were with their prototypes, who showed up. As one example. NIST folks have the same for TUBA. =>You had no consensus in the room I was there and I disagreed with you =>completely. So did others. At Houston IETF the bullet stated NONE OF =>THE ABOVE. I was told this could be a decision when I accepted to work ********** FOLKS: Jim and I would appreciate some comments from the peanut gallery. Is the community going to be satisfied with a 'none of the above' recommendation by the directorate?? Inquiring minds want to know. ********** I am not arguing whether none of the above is right or wrong but that it was stated at Houston as an option and part of the process. You said it was not and that is what I objected to. I am going to respond to Steve Deerings mail (I read ahead) on my preference. This was my point not my decision fyi. => If it =>is the bullet needs some serious technical analysis as to what is needed but =>does not have to be deployed. Try telling this to engineers who build >Happens all the time, Jim. It's just planned product growth. That does not mean it should continue to happen. =>>To repeat: We don't do long-term work in this community. We do short-term =>>long-term work, you are almost certainly requiring that we deliver nothing =>>work that often bears fruit for long-term. If you require us to do really =>>useful in the nearterm and probably nothing useful in the longterm. => =>Well this community will change and has already. It better and Noel's >Jim, you missed my point. One does not simply "decide" to become skilled >at something one has shown a pointed lack of capability in. We don't do >long-term design not because it isn't important but because we don't know >how and when we try to pretend that we do, we fail. Other groups often try >to design for the long-term and they usually fail. The IETF usually tries >for the near-term and usually winds up solving something much longer term. >I hope we don't "fix" this limitation. I did not miss your point I just don't agree with it. I think in the IPng case we are faced with the need to consider the long term and that is at the crux of the disagreement between you and I. Dave trust me this is not like adding subnets, snmp, mobile, or even multicast this is a major overhaul to the code base. For some IPngs its more than the other. With an overhaul like this is the time to add new functionality that will make the Internet better too, for me EIDs is I believe one of the software abstractions I think should be added )---> Steves model H in SIPP works for me fyi which I suggested calling JSNIP. /jim From owner-Big-Internet@munnari.OZ.AU Tue May 17 02:25:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22363; Tue, 17 May 1994 02:25:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25863; Tue, 17 May 1994 02:24:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25857; Tue, 17 May 1994 02:14:20 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21957; Tue, 17 May 1994 02:14:16 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA07625; Mon, 16 May 1994 09:14:06 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 May 1994 09:14:10 -0700 To: Steve Deering From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Thoughts on the IPng situation... Cc: big-internet@munnari.OZ.AU At 9:19 PM 5/15/94, Steve Deering wrote: > must IPng embody a new internet architecture, >or can it simply be a re-engineering of IPv4? > do you think we can do a proper job of designing, >testing, agreeing on, and deploying it before the market decides 1. Re-engineer, not re-architect. 2. We can't do massive reengineering in any reasonable time frame; besides, I don't think it's necessary 3. I sure hope that more folks than just the usual, small group of big-internet junkies answer your query. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Tue May 17 02:28:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22456; Tue, 17 May 1994 02:28:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25892; Tue, 17 May 1994 02:28:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25843; Tue, 17 May 1994 02:05:58 +1000 Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21737; Tue, 17 May 1994 02:05:43 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Mon, 16 May 1994 12:05:08 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 16 May 1994 12:05:08 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA20168; Mon, 16 May 94 12:03:41 EDT Date: Mon, 16 May 94 12:03:41 EDT Message-Id: <9405161603.AA20168@mailserv-D.ftp.com> To: dcrocker@mordor.stanford.edu Subject: Re: Requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: jcurran@nic.near.net, bound@zk3.dec.com, big-internet@munnari.OZ.AU Content-Length: 1008 Dave Crocker Wrote... > At 12:35 PM 5/14/94, John Curran wrote: > >but none of the demos that I've seen to date would be called a "complete" > >(or even "minimal") IPng suite. Autoconfiguration may have been present > >in some cases, but not autoregistration. Routing varied from production > >protocols to completely static. Transition support varied from prototype > >to none-at-all. Security wasn't, mobility (except in the local area) > >wasn't supported, and multicast wasn't present in most cases. > > John, > > As I said, they weren't product. Also, autoconfiguration, > autoregistration, security and mobility were not part of the requirements > list at the time. In late 1992, the document contained requirements for plug-and-play, security, multicast, and mobility. The wording was poor as the document had not been well refined. My archives do not go back any farther than that. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Tue May 17 02:29:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22477; Tue, 17 May 1994 02:29:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25907; Tue, 17 May 1994 02:29:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25860; Tue, 17 May 1994 02:14:30 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21965; Tue, 17 May 1994 02:14:29 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA07641; Mon, 16 May 1994 09:14:21 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 May 1994 09:14:24 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Requirements Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 9:34 PM 5/15/94, Noel Chiappa wrote: > plan simply and tightly, then build and deploy, and then iterate as > incremental functionality is deemed necessary and possible. > >This iteration can be expensive, depending on how widespread the effects; Let's see. You're challenging the basic style of Internet technical development and deployment? Given the lack of any counter-balancing comment you would seem to be making such an assertion. Given the success rate of the Internet approach, I'm surprised that you would hold such a view. > is changing so fast that it's wise to delay as long as you Noel, this is viewed as the classic way to miss a market window. It ahppense all the time, by focusing on the "problems" with deliverying and not on the requirements or benefits of deliverying. For most projects that are late to market, this is at the core of their failure. >Right, and that's why I like the approach were we deploy a new internetwork >layer in pieces, not all at once; we can try one version of a new piece, and >if it's not optimal, we can try another version. Huh? Either you mean deply a core and then add to it or you mean deploy a core and if we don't like it, replace it with a different core. If you mean the former, then we are in complete agreement. If you mean the latter, then I can't imagine what logistical world you live in. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Tue May 17 02:44:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22896; Tue, 17 May 1994 02:44:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25940; Tue, 17 May 1994 02:44:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25923; Tue, 17 May 1994 02:39:49 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22669; Tue, 17 May 1994 02:39:44 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA22630; Mon, 16 May 94 10:44:57 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AD04411; Mon, 16 May 94 09:24:58 PDT Date: Mon, 16 May 94 09:24:58 PDT Message-Id: <9405161624.AD04411@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Simon E Spero From: Greg Minshall Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet Cc: big-internet@munnari.OZ.AU Simon, >It might be possible to reduce the impact by hacking the implementation to >use special case data structures for the TIME_WAIT state, but it does seem >strange to have such a huge amount of overhead for a rare worst-case >situation. Also, not that it actually makes a difference, but the 240 >second wait time does seem a tad excessive. What scenarios in the modern >Internet could generate (e.g. the 200 second case). I would probably hack data structures for TIME_WAIT. TIME_WAIT is quite important for the protocol to operate correctly. 240 seconds is a bit conservative, but probably not incredibly. Greg Minshall From owner-Big-Internet@munnari.OZ.AU Tue May 17 02:45:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22932; Tue, 17 May 1994 02:45:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25955; Tue, 17 May 1994 02:45:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25937; Tue, 17 May 1994 02:44:07 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22888; Tue, 17 May 1994 02:44:00 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA22648; Mon, 16 May 94 10:45:19 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AC04411; Mon, 16 May 94 09:24:32 PDT Date: Mon, 16 May 94 09:24:32 PDT Message-Id: <9405161624.AC04411@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Jon Crowcroft From: Greg Minshall Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet Cc: big-internet@munnari.OZ.AU, Simon E Spero Jon, >IP-NG doesnt affect the TIME_WAIT in TCP, unless it abolishes >dynamic routing and does layer violation - the internet layer has bounds >on packet lifetimes to limit the damage caused by loops, but you want >a lifetime bounded by the frequency of connection start/stop/lifetime >versus crash/reboot cycle times, and that is application and system specific... (Well, of course, SIPP doesn't bound the packet lifetime...:-) >actually, since most retrievals of apages that transfer a lot of data >result in many connections (e.g. the text, and seperate GIFs), the >HTTP model is broken - it should batch the data into a single >connection, and de-batch at client - otherwise, with the lack of >congestio nwindow caching in route tables, every conenction will have >to go through slowstart... and get a sort of high level stop&go >performance... I disagree. If the natural style of the application is to do multiple transfers, the underlying transport and internet layers (and implementations) should be supporting that style. Additionally, if starting off doing slow start every time is a performance problem, then the implementation should (will!) be beaten on to make it cache the congestion stuff. (This is not to say that http/www/etc. shouldn't make some changes; caching, in particular...) Greg From owner-Big-Internet@munnari.OZ.AU Tue May 17 02:47:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22950; Tue, 17 May 1994 02:47:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25970; Tue, 17 May 1994 02:47:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25888; Tue, 17 May 1994 02:28:08 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22403; Tue, 17 May 1994 02:28:01 +1000 (from craig@aland.bbn.com) Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA15191 for big-internet@munnari.oz.au; Mon, 16 May 94 12:27:49 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA06742; Mon, 16 May 1994 09:25:53 -0700 Message-Id: <199405161625.JAA06742@aland.bbn.com> To: big-internet@munnari.OZ.AU Subject: context for Noel's last Requirements note From: Craig Partridge Date: Mon, 16 May 94 09:25:51 -0700 Sender: craig@aland.bbn.com Hi folks: My comments to Noel were actually sent privately, but Noel's emailer apparently automatically cc's Big-I :-) and so his reply to me went to everyone. Here's my original note to Noel. Craig E-mail: craig@aland.bbn.com or craig@bbn.com ------- Forwarded Message To: Noel Chiappa Subject: Re: Requirements In-reply-to: Your message of Sat, 14 May 94 17:26:27 -0400. <9405142126.AA07204@ginger.lcs.mit.edu> From: Craig Partridge Date: Sat, 14 May 94 21:37:29 -0700 Sender: craig Noel: Let me push back some -- I think you're being too glib in dismissing the design points (I suspect, in part, because they match your world view -- the point is, they don't match everyone's). * keep the packet format word-aligned I find it hard to call this anything much more than competent engineering; compilers keep data in structures word-aligned, so it's not that hard. Ah, but the question is what to do when push comes to shove regarding flexibility. E.g., CLNP's approach was to make address sizes variable on a per-byte basis. SIPP's philosophy says don't do that. and as minimalist as possible Again, no more complex than is needed is not exactly deep insight.. Again, I think this is unfair -- the point is which way do you risk on questions on which you are unsure? SIPP says risk by leaving them out. * keep the fast forwarding path fast Efficiency; again, competent engineering. Only if you assume there are no tradeoffs. * the packet header addresses the next entity that has to do something other than fast forwarding (i.e., options are encapsulated, and you send the datagram to the next router/host that actually has to examine the options) Now, this is a clever idea (and one I promptly stole for Nimrod, so you can tell I really do think it's a good idea, imitation being the sincerest form of flattery :-), but it's hardly "general philosophy". * transition from IPv4 should be straightforward Since no scheme without a reasonable transition strategy is even plausible in the real world, this amounts to little more than a recognition of reality. There are folks who differ quite strongly on this point. Craig ------- End of Forwarded Message From owner-Big-Internet@munnari.OZ.AU Tue May 17 03:24:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24101; Tue, 17 May 1994 03:24:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA26015; Tue, 17 May 1994 03:24:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA26012; Tue, 17 May 1994 03:23:46 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24067; Tue, 17 May 1994 03:23:40 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id KAA08172; Mon, 16 May 1994 10:23:29 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 May 1994 10:23:32 -0700 To: Greg Minshall From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet Cc: big-internet@munnari.OZ.AU At 9:24 AM 5/16/94, Greg Minshall wrote: >(This is not to say that http/www/etc. shouldn't make some changes; >caching, in particular...) I also believe that the massive number of short connections made by http needs changing. Connections setup/teardown always has extra overhead. If a collection of objects are being retrieved from the same site, we ought to find a way to do it far more efficiently. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Tue May 17 03:25:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24132; Tue, 17 May 1994 03:25:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA26041; Tue, 17 May 1994 03:25:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25998; Tue, 17 May 1994 03:05:44 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23440; Tue, 17 May 1994 03:05:38 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405161705.23440@munnari.oz.au> Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 16 May 1994 18:02:39 +0100 To: Greg Minshall Cc: big-internet@munnari.OZ.AU, Simon E Spero Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet In-Reply-To: Your message of "Mon, 16 May 94 09:24:32 PDT." <9405161624.AC04411@WC.Novell.COM> Date: Mon, 16 May 94 18:02:35 +0100 From: Jon Crowcroft >I disagree. If the natural style of the application is to do multiple >transfers, the underlying transport and internet layers (and >implementations) should be supporting that style. Additionally, if >starting off doing slow start every time is a performance problem, then the >implementation should (will!) be beaten on to make it cache the congestion >stuff. ok - you purist you! then Bob Braden's transaction TCP will do fine...it caches all the info from the last tcp... but i nthe absence of that, myu approach takes less code (WWWLib usage of TCP just cahces connection on Most Recently Used...) ... its a 3 line hack, and doesnt require kernel changes.. anyhow, this discussion is the 'meat & potatoes' of the end2end list...so as bob said, it should move there.. >(This is not to say that http/www/etc. shouldn't make some changes; >caching, in particular...) cache/touche? cheers jon From owner-Big-Internet@munnari.OZ.AU Tue May 17 03:44:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24745; Tue, 17 May 1994 03:44:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA26077; Tue, 17 May 1994 03:44:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA26060; Tue, 17 May 1994 03:29:11 +1000 Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24267; Tue, 17 May 1994 03:29:08 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA00937 (5.65c/IDA-1.4.4nsd for ); Mon, 16 May 1994 10:29:01 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA27984 (5.65c/IDA-1.4.4-910725 for ); Mon, 16 May 1994 09:45:22 -0700 Message-Id: <199405161645.AA27984@remmel.NSD.3Com.COM> To: big-internet@munnari.OZ.AU Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Mon, 16 May 94 03:02:17 +1000." <18100.769021337@munnari.OZ.AU> Date: Mon, 16 May 94 09:45:03 -0700 From: tracym@NSD.3Com.COM > Very large organisations, like major companies, large research > bodies like Bob's organisation, etc, may reasonably request > 2^16 (65536) EID's in one request, even then we have 2^48 > chunks to give out - equivalent to four times the total available > space of IEEE numbers (excluding wastage), which is certainly > plenty (I knoww there are some who believe that IEEE numbers > would be suitable as EIDs themselves, though I don't believe > that myself, 48 bits isn't enough, and the allocation policy is > all wrong). I like IEEE numbers as a way of identifying particular pieces of hardware in a network. We give 'em to processors as well as all our interface cards. They make a nice place to stick an anchor to build a routing tree (e.g. OSPF, IS-IS, etc.), perform other topological self-discovery functions, or just track pieces of junk in the net. I agree that there are some painful issues when trying to use them for host identifiers at the user-application level. I'd like to see a 64-bit EID space, with a portion given to IEEE(or other) assigned hardware identifiers, and the rest given to a "soft" host id proposal. All existing IEEE numbers get some well-known additional 16 bits up front. You can argue about how much more space might be desirable for additional hardware identifiers (none,,,32k*2^48), but including the hardware and hostware spaces in a single 64-bit scheme may prevent problems down the road. Regards, Tracy From owner-Big-Internet@munnari.OZ.AU Tue May 17 03:59:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24903; Tue, 17 May 1994 03:46:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA26092; Tue, 17 May 1994 03:46:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA26052; Tue, 17 May 1994 03:26:45 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24156; Tue, 17 May 1994 03:26:40 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 3694; Mon, 16 May 94 13:21:30 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 2493; Mon, 16 May 1994 13:21:30 -0400 Date: Mon, 16 May 94 13:10:40 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Requirements To: Dave Crocker Cc: big-internet@munnari.OZ.AU In-Reply-To: Message-Id: <940516.131040.EDT.VALDIS@vtvm1.cc.vt.edu> On Sun, 15 May 1994 14:04:16 -0700 you said: >EXACTLY!! Do not specify something whose near-term utility is not >reasonably well understood. "Placeholders" are not a good idea. The >SNMPv1 security field is another example. And we keep seeing it. > >It means that you either design, build and deploy what you DO know now, or >you wait for some indeterminate time until a "complete" solution is >possible. >But like "free beer tomorrow", tomorrow is never today. What is deemed >"complete" for today will not be sufficient by the time we can satisfy the >original list. Dave: I understand that "security" and "mobility" are as-yet-not-understood fully. However, have we at least progressed to the point where we *can* say for a certainty "We need hooks X, Y, and Z in the packet header in order to implement feature Frobozz"? If so, we aren't in the same situation as the IP4 TOS field, where (at least from my perspective) it was a "well, we will save 8 bits for flags for future use". For instance, for security we already know we need flags for "unsecure", "authenticated", "encrypted", and some way of specifying what scheme was used to authenticate/encrypt. So - for each of "security", "mobility", "flows", and whatever else, *can* we at least make a list of "We need X to do it", even if we're not sure *how* to do it? If so, I think we can still make useful progress even without actually knowing how to do the feature in question. (As an aside, isn't it common practice in many engineering fields to design (for instance) an airframe and a jet engine seperately, where the airframe engineers know only "it has thrust X, needs fuel Y at Z gals/min, and attaches at points alpha, beta, and gamma"?) Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Tue May 17 04:00:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24935; Tue, 17 May 1994 03:47:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA26107; Tue, 17 May 1994 03:47:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA26063; Tue, 17 May 1994 03:38:01 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24587; Tue, 17 May 1994 03:37:51 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA09154; Mon, 16 May 94 10:39:36 -0700 Date: Mon, 16 May 94 10:39:36 -0700 From: Eric Fleischman Message-Id: <9405161739.AA09154@atc.boeing.com> To: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Thoughts on the IPng situation... Dear Noel, Your frustration with the IETF's IPng process is probably universally shared. I am sure that everyone involved would agree that requirements should guide the approaches -- rather than being formalized a few months before the selection is made. However, I would like to remind you that one of the most vexacious aspects of IPng from the start was deciding whether IPng should be an incremental step or a major advance in technology. Since I am a "first class waffler" (i.e., one who changes one's mind frequently), I clearly see the advantages and disadvantages with both approaches. It is not at all clear to me which basic approach is better. Thus, it is not surprising that those with a more binary decision making capability "firmly know" which approach is best -- and unfortunately do not do so with uniform (consensus based) results. My "bottom line" comment to you is that 1) Yes, the IPng process is flawed. 2) I believe that the IPng process is the best the community can do since we lack -- and have consistently lacked -- a consensus on the even most basic questions. And we have been unable to form a consensus despite many heroic and vexacious efforts. The requirements we do have are the very best we could do after 1.5 years effort. 3) I concur that market environment compells us to select the IPng soon -- before an "ideal" candidate can be identified and built. I see toasternet as beginning to become real NOW (with EPRI and CDPD and what we are doing internally on our own nets as my evidence to that assertion). Thus, flawed or not, we are simply doing the best we can. I really believe that. I also believe that the gulf between "our best" and "what we would like to do" is so great largely as a function of the increased importance of our work to the market as a whole -- leading to substantially more participation from more diverse parts within the market. Put another way: formerly the IETF was more uniform in its orientation than it is today. This current diversity has both its positive and negative consequences. You have "fingered" the negative side of the diversity. The positive side is that we have been considering things in the IPng Process which had rarely (if ever) been considered within the IETF before. Sincerely yours, --Eric Fleischman P.S. Sometimes in life "merely surviving" is a major accomplishment. As superchicken said: "You knew the job was dangerous when you took it. Aaaack!" >From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > ... > Anyway, the important question is: what's the best way forward from >here? The only rational answer I can see is to admit our failings, admit we >all screwed up, put the current IPng efforts to the side, and go back and >perform the kind of rational design process you'd hope to see with >something this important. > We ought to decide on what a new internetwork layer ought to do, >and then decide how it's going to do it, and then worry about how the bits >look. We need an IPng architect to lead this (and I suggest we get Dave >Clark, if we can convince him to do it). > When that process is done, there may be some pieces of various IPng >efforts that are useful, but until that is done, arguing about SIPP versus >TUBA versus CATNIP versus whatever is just the most miserable and third >rate waste of time. > Let's stop acting like disorganized and incompetent amateurs, and >start acting like what we actually really are: a crew of pretty good >engineers, designers, and architects. From owner-Big-Internet@munnari.OZ.AU Tue May 17 07:44:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04844; Tue, 17 May 1994 07:44:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA26319; Tue, 17 May 1994 07:44:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA26316; Tue, 17 May 1994 07:44:10 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29028; Tue, 17 May 1994 05:19:06 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from relay2.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29053 Tue, 17 May 1994 05:04:02 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from bridge2.NSD.3Com.COM by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwqed22686; Mon, 16 May 94 14:58:17 -0400 Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA03453 (5.65c/IDA-1.4.4nsd for ); Mon, 16 May 1994 11:52:00 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA28398 (5.65c/IDA-1.4.4-910725 for ); Mon, 16 May 1994 11:51:59 -0700 Message-Id: <199405161851.AA28398@remmel.NSD.3Com.COM> To: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of "Mon, 16 May 94 10:39:36 PDT." <9405161739.AA09154@atc.boeing.com> Date: Mon, 16 May 94 11:51:58 -0700 From: tracym@NSD.3Com.COM > From: Eric Fleischman > Subject: Re: Thoughts on the IPng situation... > > Dear Noel, .... > 3) I concur that market environment compells us to select the IPng soon > -- before an "ideal" candidate can be identified and built. I see > toasternet as beginning to become real NOW (with EPRI and CDPD and what > we are doing internally on our own nets as my evidence to that assertion). .... > Sincerely yours, > > --Eric Fleischman How about the notion that the IPng selected and developed soon be definitively certified as NOT the last IPng. Perhaps we should be focussing on it as the last ES-IS that the average host (of today's basic shape) might need. (some might say that this is IPv4...(or IPX;-)) But seriously, it's not clear how much more host-based intelligence will be needed for the future IF we get enough addressing capacity and service request flexibility into the end-systems this time around. We should expect that in the not-very-far-distant future there WILL be additional functionality be added in the IS(router/network) arena. Perhaps we can define an ICMP message or two this time around that which allows an ES to provide the extra header bits that a host ought to be using to get the most efficient service (suitably authenticated, of course). In the case of NIMROD, or even PIM, it's not clear that most hosts need to understand the gory details, given some basic access mechanisms. Thus the true INTER-networking protocols could be evolved while most hosts remain unchanged. Many in the IETF think we know allllllmost enough to define how end-systems ought to behave for mobility, security, and perhaps even flows. So... [Really, I'm not just trying to get everyone off the hook.] I think we're trying to solve too many problems at once, with the expectation that it will be the last chance. The last-chance issue comes mainly because we expect (we're pretty damn sure!) there will be too many host interfaces won't (perhaps can't) be changed in the future. So divide and conquer. Regards, Tracy From owner-Big-Internet@munnari.OZ.AU Tue May 17 10:27:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00287; Tue, 17 May 1994 10:27:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA00313; Tue, 17 May 1994 09:59:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA00283; Tue, 17 May 1994 09:43:47 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09751; Tue, 17 May 1994 10:11:27 +1000 (from barney@databus.databus.com) Received: from databus.databus.com by shark.mel.dit.csiro.au with SMTP id AA10484 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 17 May 1994 10:10:21 +1000 Date: Mon, 16 May 94 20:09 EDT Message-Id: <9405162014.AA10603@databus.databus.com> From: Barney Wolff To: tracym@NSD.3Com.COM, big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... Content-Length: 2226 Content-Type: text > Date: Mon, 16 May 94 11:51:58 -0700 > From: tracym@NSD.3Com.COM > > But seriously, it's not clear how much more host-based intelligence > will be needed for the future IF we get enough addressing capacity and > service request flexibility into the end-systems this time around. We > should expect that in the not-very-far-distant future there WILL be > additional functionality be added in the IS(router/network) arena. > Perhaps we can define an ICMP message or two this time around that > which allows an ES to provide the extra header bits that a host ought > to be using to get the most efficient service (suitably authenticated, > of course). > > In the case of NIMROD, or even PIM, it's not clear that most hosts > need to understand the gory details, given some basic access > mechanisms. Thus the true INTER-networking protocols could be evolved > while most hosts remain unchanged. Many in the IETF think we know > allllllmost enough to define how end-systems ought to behave for > mobility, security, and perhaps even flows. So... I know this will sound like a child butting into an adult conversation, but isn't the whole IP philosophy (as opposed to how some networks are implemented) that a host is an active participant, especially-but-not-only when it has >1 interface and a simple default route won't cut it? As an old X.25-ite I'm not totally converted, but I sure thought that's what I converted to! If one wants to measure software effort, it is no longer clear, if it ever was, that there are fewer distinct IP router software suites than IP host software suites. So sloughing it off on the routers will not necessarily decrease the total software nut. I am convinced by the argument that we should be re-implementing the IP philosophy, not inventing a brand new one, for IPng. NAT is always there as a safety net (generalized to header translation) but we should not deliberately plan to need the safety net. Barney Wolff, Pres. Voice: 914-591-6572 Databus Inc. Fax: 914-591-5677 15 Victor Drive Internet: barney@databus.com Irvington, NY 10533-1919 USA "At the corner of database & datacomm" From owner-Big-Internet@munnari.OZ.AU Tue May 17 10:46:56 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08784; Tue, 17 May 1994 09:42:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02446 Tue, 17 May 1994 08:59:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA00207; Tue, 17 May 1994 08:28:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA00193; Tue, 17 May 1994 08:20:46 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06040; Tue, 17 May 1994 08:22:11 +1000 (from crawdad@munin.fnal.gov) Received: from fnal.fnal.gov by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01672 Tue, 17 May 1994 08:22:05 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HCEXWUXF1C000KQI@FNAL.FNAL.GOV>; Mon, 16 May 1994 17:16:21 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA21905; Mon, 16 May 94 17:15:20 CDT Date: Mon, 16 May 1994 17:15:20 -0500 From: Matt Crawford Subject: Re: Requirements (was : FORMAL REQUEST : SIPP EIDs and Locators) In-Reply-To: Your message of Mon, 16 May 94 09:02:31 +0100. <9405160702.AA14814@dxcoms.cern.ch> To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Cc: big-internet@munnari.OZ.AU (bigi) Message-Id: <9405162215.AA21905@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > Right now, couldn't we concentrate on reaching rapid consensus on > which proposal to adopt? I read this as "RABID consensus," which may be the only kind we can get. From owner-Big-Internet@munnari.OZ.AU Tue May 17 10:47:25 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00851; Tue, 17 May 1994 10:37:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04724 Tue, 17 May 1994 10:18:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA00287; Tue, 17 May 1994 09:48:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA00281; Tue, 17 May 1994 09:43:39 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09740; Tue, 17 May 1994 10:11:23 +1000 (from barney@databus.databus.com) Received: from databus.databus.com by shark.mel.dit.csiro.au with SMTP id AA10501 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 17 May 1994 10:10:43 +1000 Date: Mon, 16 May 94 20:09 EDT Message-Id: <9405162015.AA10611@databus.databus.com> From: Barney Wolff To: tracym@NSD.3Com.COM, big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... Content-Length: 2226 Content-Type: text > Date: Mon, 16 May 94 11:51:58 -0700 > From: tracym@NSD.3Com.COM > > But seriously, it's not clear how much more host-based intelligence > will be needed for the future IF we get enough addressing capacity and > service request flexibility into the end-systems this time around. We > should expect that in the not-very-far-distant future there WILL be > additional functionality be added in the IS(router/network) arena. > Perhaps we can define an ICMP message or two this time around that > which allows an ES to provide the extra header bits that a host ought > to be using to get the most efficient service (suitably authenticated, > of course). > > In the case of NIMROD, or even PIM, it's not clear that most hosts > need to understand the gory details, given some basic access > mechanisms. Thus the true INTER-networking protocols could be evolved > while most hosts remain unchanged. Many in the IETF think we know > allllllmost enough to define how end-systems ought to behave for > mobility, security, and perhaps even flows. So... I know this will sound like a child butting into an adult conversation, but isn't the whole IP philosophy (as opposed to how some networks are implemented) that a host is an active participant, especially-but-not-only when it has >1 interface and a simple default route won't cut it? As an old X.25-ite I'm not totally converted, but I sure thought that's what I converted to! If one wants to measure software effort, it is no longer clear, if it ever was, that there are fewer distinct IP router software suites than IP host software suites. So sloughing it off on the routers will not necessarily decrease the total software nut. I am convinced by the argument that we should be re-implementing the IP philosophy, not inventing a brand new one, for IPng. NAT is always there as a safety net (generalized to header translation) but we should not deliberately plan to need the safety net. Barney Wolff, Pres. Voice: 914-591-6572 Databus Inc. Fax: 914-591-5677 15 Victor Drive Internet: barney@databus.com Irvington, NY 10533-1919 USA "At the corner of database & datacomm" From owner-Big-Internet@munnari.OZ.AU Tue May 17 11:40:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02424; Tue, 17 May 1994 11:16:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00384; Tue, 17 May 1994 10:48:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00381; Tue, 17 May 1994 10:46:58 +1000 Received: from [192.5.216.174] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02389; Tue, 17 May 1994 11:15:07 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 17 May 1994 10:14:57 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA26360; Tue, 17 May 1994 10:14:57 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA28873; Tue, 17 May 94 10:14:56 JST Date: Tue, 17 May 94 10:14:56 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405170114.AA28873@cactus.slab.ntt.jp> To: francis@BBN.COM, lyman@BBN.COM Subject: Re: IEEE 802 not unique enough??? Cc: big-internet@munnari.OZ.AU, mo@uunet.uu.net > up this work and see if it's relevant. [I do remember Dave saying > that the principal reason DEC abandoned the idea of randomizing > the assignment of ethernet address blocks was that they didn't think > that customers would ever be confident that it worked as claimed...] > I think I remember such a conversation. Dave was saying that the optimal solution was to have the customer literally flip a coin 48 times and assign the address accordingly. Perhaps to make the job easier, DEC could have included 8 die and some software to easily convert dice dots to ethernet numbers.... But I don't know how the auto-configuration would have worked in that case.... PF From owner-Big-Internet@munnari.OZ.AU Tue May 17 13:17:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07377; Tue, 17 May 1994 13:17:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA00541; Tue, 17 May 1994 12:48:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA00535; Tue, 17 May 1994 12:44:40 +1000 From: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07141; Tue, 17 May 1994 13:13:04 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA17438; Mon, 16 May 94 20:06:38 -0700 Received: by xirtlu.zk3.dec.com; id AA04991; Mon, 16 May 1994 23:06:35 -0400 Message-Id: <9405170306.AA04991@xirtlu.zk3.dec.com> To: Steve Deering Cc: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of "Sun, 15 May 94 21:19:53 PDT." <94May15.211955pdt.12171@skylark.parc.xerox.com> Date: Mon, 16 May 94 23:06:29 -0400 X-Mts: smtp Steve, That was a profound message and full of good logic and the reasons why you believe we should select IPng in July. I agree that we need to select an IPng in July. Your comment about deploying IPng is exactly right. It will be a great effort and the transiton I think will be the most difficult and the first question customers will ask us in engineering. How are you going to do this? Not will it support RSVP, Flows, Autoconfig, et al. But how are you going to keep my costs down and let me incrementally move to IPng. They will ask this even before asking for the carrots. p.s. but I still like EIDs in Model H (JSNIP). /jim From owner-Big-Internet@munnari.OZ.AU Tue May 17 13:18:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07412; Tue, 17 May 1994 13:18:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA00556; Tue, 17 May 1994 12:50:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA00538; Tue, 17 May 1994 12:47:05 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07306; Tue, 17 May 1994 13:15:29 +1000 (from kre@munnari.OZ.AU) To: Simon E Spero Cc: big-internet@munnari.OZ.AU Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Sun, 15 May 1994 22:47:47 -0400." <9405160247.AA08252@tipper.oit.unc.edu> Date: Tue, 17 May 1994 13:15:26 +1000 Message-Id: <18567.769144526@munnari.OZ.AU> From: Robert Elz Date: Sun, 15 May 94 22:47:47 -0400 From: Simon E Spero Message-ID: <9405160247.AA08252@tipper.oit.unc.edu> These problems are with the DNS, not with other directory services currently under construction. The more advanced forwarding information in centroid-based services can handle reverse lookups of non-aligned EIDs without the in-addr.arpa hackery. Databases are definitely not my field - so perhaps you could explain, briefly, how this works. At the minute I can't think of any way at all (but that means nothing). The octet aligned stuff is irrelevant, of course, that's just a shorthand for not knowing how the tree structure of a remote part of the tree is constructed - because its not possible to determine that without lots of queries, there needs to be global agreement on what the structure will be. Currently that happens to be octet alignment, so I tend to say "octet alignment" where I mean the real problem. However, if there's a non tree based distributed database scheme that will scale to hundreds of millions of servers (10^12 hosts implies at least 10^8 servers, probably 10^9 or 10^10), and which will work effeciently (single packet query and response measured of the order of a couple of hundred ms from anywhere in the world), then I'd like to hear about it. Unless this is genuine proven technology for which we're sure we can make implementations in the near future, I'm not sure I'd want to rely on it for something basic to the functioning of IPng however. We know the DNS works (if not always its most common implementation), we know how it scales, unless something clearly better, and clearly working is around, and unless the limitations imposed were truly dreadful, I think I'd prefer to stick with what's known to work. kre From owner-Big-Internet@munnari.OZ.AU Tue May 17 13:19:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07461; Tue, 17 May 1994 13:19:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA00571; Tue, 17 May 1994 12:51:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA00521; Tue, 17 May 1994 12:37:42 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06998; Tue, 17 May 1994 13:06:02 +1000 (from kre@munnari.OZ.AU) To: big-internet@munnari.OZ.AU Subject: Re: IEEE 802 not unique enough??? In-Reply-To: Your message of "Mon, 16 May 1994 13:49:50 +0200." <9405160449.AA19743@cactus.slab.ntt.jp> Date: Tue, 17 May 1994 13:05:17 +1000 Message-Id: <18561.769143917@munnari.OZ.AU> From: Robert Elz Date: Mon, 16 May 94 13:49:50 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-ID: <9405160449.AA19743@cactus.slab.ntt.jp> I have a hard time believing that an EID assignment hierarchy of: root authority -> regional authority -> private orgs. Is going to work better (ie, result in fewer duplicate assignments) than: root authority -> vendors This depends what you mean by "work better". I have little doubt that the vendor route will result in less errors initially. The problem is that when an error is made there it's almost impossible to detect. On the other hand, when an error is made locally, detection is much more likely even if the only detection method was when the two particular hosts attempted to talk and discovered they both had the same ID. Hosts in the same administration are much more likely to exchange data than random hosts around the world. I still don't see how vendor assigned id's can be rationally entered in a directory however - whereas its easy to see how locally assigned ones are. Further, when the directory entries are made, any assignment error is immediately obvious. If the existance of a directory entry is made a prerequisite for correct operation, then duplicate identifiers are basically impossible. When uniqueness is important, verification is the key, there has to be a method by which you can be sure that the assigned number is indeed unique, I don't see how the vendor method achieves that. Further, I'm not at all sure how we would get the vendors to assign these new numbers we want - IEEE numbers would do, but they'd need to be assigned to more equipment than they currrently are by vendors who don't currently assign such things. Last I heard (and this isn't my area), your typical generic clone PC doesn't arrive with an IEEE number engraved in it somewhere (if you buy an ethernet or token ring, that probably does, though for manufacturing economies, some vendors seem to make this a soft config option rather than in a prom). PC's without this extra hardware can be connected via PPP to the Internet - where does this number come from? Does anyone believe that the IETF has the muscle to convince clone PC vendors to start assigning numbers to boxes, just for the tiny fraction of their market which actually connects to the internet? kre From owner-Big-Internet@munnari.OZ.AU Tue May 17 13:49:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03204; Tue, 17 May 1994 11:37:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA00417; Tue, 17 May 1994 11:08:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00400; Tue, 17 May 1994 10:51:11 +1000 Received: from yildun.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09892; Tue, 17 May 1994 10:13:57 +1000 (from hughf@cs.anu.edu.au) Received: (from hughf@localhost) by yildun.anu.edu.au (8.6.9/8.6.9) id KAA00973 for big-internet@munnari.OZ.AU; Tue, 17 May 1994 10:13:35 +1000 From: Hugh Fisher Message-Id: <199405170013.KAA00973@yildun.anu.edu.au> Subject: Re: Thoughts on the IPng situation... To: big-internet@munnari.OZ.AU Date: Tue, 17 May 1994 10:13:27 +1000 (EST) X-Face: IzZbOk_&E(oY<6o8_9:zVxVbU&@T&']zY6~vlKeu<%Xnr"f4F?+_bAEjZ4as%{W*pufyaPP AN7-\xfyYr$}N4+_%c.5"P~jpS3c+*Mp'\k5cU1U_yX=OS&'='U>U}\HJXl!Vn(#$q38k~VKU^m|q- JAfcGK(n=ytcde8m9^1NJ X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1449 Dave Crocker wrote: > 3. I sure hope that more folks than just the usual, small group of > big-internet junkies answer your query. Well, I was very impressed by, and fully agreed with, Steve Deerings message. My perspective is that of a (university) system administrator and occasional network programmer. From here, we have IP working over serial, Ethernet, and fibre; on machines from IBM 386s to super computers; and used for everything from telnet to multicasting video. It works, not perfectly, but neither AppleTalk nor DECnet which are also around on campus can do everything that IP does. It ain't broke, why fix it? Before I get deluged with mail, that was a rhetorical question. OK, there is an address space depletion problem (although nobody has any hard evidence of people being turned down), routing tables are overflowing, multicast routing is in a state of flux... To network architects these are vital issues, but not to me - and I'm sorry to say that people like me have the numbers by at least ten to one. (No I am not suggesting that IPNG be picked by popular vote.) My reaction to these problems is "well, upgrade IP with more addresses and better routing, but keep it backwardly compatible and don't change the way it works too much or my software will break." SIPP seems ideal. Hugh Fisher (These opinions are mine alone, do not reflect those of my employer, etc) From owner-Big-Internet@munnari.OZ.AU Tue May 17 19:57:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22875; Tue, 17 May 1994 19:57:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA00909; Tue, 17 May 1994 19:28:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA00892; Tue, 17 May 1994 19:12:13 +1000 Received: from bgate.lut.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22181; Tue, 17 May 1994 19:40:22 +1000 (from J.P.Knight@lut.ac.uk) Received: by suna.lut.ac.uk (4.1/SMI-4.1) id AA23923; Tue, 17 May 94 10:39:02 BST Date: Tue, 17 May 1994 10:26:35 +0100 (BST) From: "Jon P. Knight" Subject: Re: TIME-WAIT vs WWW - Big Servers on the Big Internet To: Dave Crocker Cc: Greg Minshall , big-internet@munnari.OZ.AU In-Reply-To: <1994May16.063937.19747@hpn.lut.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 16 May 1994, Dave Crocker wrote: > At 9:24 AM 5/16/94, Greg Minshall wrote: > >(This is not to say that http/www/etc. shouldn't make some changes; > >caching, in particular...) > > I also believe that the massive number of short connections made by http > needs changing. Connections setup/teardown always has extra overhead. If > a collection of objects are being retrieved from the same site, we ought to > find a way to do it far more efficiently. > [I replied to this personally to Dave last night and he suggested that the list might be interested in my reply. I didn't think it was really a big-internet topic but I'll bow to Dave's request and repost a paraphrasing of my original reply.] The way to do it more efficiently is to use MIME. There is currently some discussion on the www-talk developers mailing list about introducing a new command into HTTP; MGET. A single HTTP request could contain multiple MGETs and the server would reply with a single MIME multipart response. Each part of this response would be the reply to a single one of the MGETs, including all the HTTP headers (status, error codes, etc). Thus TCP connection set up and tear down can be amortized over a larger number of objects that the current one. I know that quite a few people, myself included, think that this is a good idea. I got hit with the need to retrieve a large number of objects for a single on-screen document in an electronic journals project I have been working on. Even over lightly loaded campus Ethernets the connection setup, server launching and header processing takes up an appreciable amount of time and has lead to user complaints about how slow the service is. There is still some work to be done on this (such as what content-type each HTTP response in the multipart would give) but I look forward to seeing it implemented in the (hopefully) not too distant future. Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Research Student in High Performance Networking and Distributed Systems in the Department of _Computer_Studies_ at Loughborough University. * Its not how big your share is, its how much you share that's important. * From owner-Big-Internet@munnari.OZ.AU Tue May 17 22:42:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25599; Tue, 17 May 1994 21:37:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA01013; Tue, 17 May 1994 21:08:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA01010; Tue, 17 May 1994 20:58:24 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25302; Tue, 17 May 1994 21:26:47 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA15717; Tue, 17 May 94 04:26:32 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA12265; Tue, 17 May 94 04:26:22 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA14143; Tue, 17 May 1994 04:26:28 -0700 Date: Tue, 17 May 1994 04:26:28 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9405171126.AA14143@jurassic.Eng.Sun.COM> To: tracym@nsd.3com.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <199405161851.AA28398@remmel.NSD.3Com.COM> Subject: Re: Thoughts on the IPng situation... Tracy, > How about the notion that the IPng selected and developed soon be > definitively certified as NOT the last IPng. Perhaps we should be It should just be declared as the next version of IP. Nothing more, nothing less. Bob From owner-Big-Internet@munnari.OZ.AU Tue May 17 22:44:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22962; Tue, 17 May 1994 20:01:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA00924; Tue, 17 May 1994 19:32:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA00895; Tue, 17 May 1994 19:13:30 +1000 Received: from rx7.ee.lbl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21739; Tue, 17 May 1994 19:21:46 +1000 (from van@ee.lbl.gov) Received: by rx7.ee.lbl.gov for big-internet@munnari.oz.au (5.65/1.44r) id AA04283; Tue, 17 May 94 02:22:49 -0700 Message-Id: <9405170922.AA04283@rx7.ee.lbl.gov> To: John Curran Cc: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of Mon, 16 May 94 09:14:41 EDT. Date: Tue, 17 May 94 02:22:48 PDT From: Van Jacobson I can't add anything to Steve Deering's eloquent message except to say I completely, 100% agree with everything he said (& this is the probably the first time I have ever completely agreed with anyone). But I would like to disagree with John Curran's comment that: > While it's really wonderful that we can warp IPv4 into doing all > of these things, the lack of architecture to support them > becomes clear when you try and predict how any combination of > capabilities will interact. I have worked on resource management (`flows'), reservation protocols and scalable multicast for the past five years. My experience has been that you have this exactly wrong: As you said, architecture is about designing things so that you have some hope of understanding how combinations of capabilities will interact. One touchstone in this effort is to achieve a sort of orthoganality between different mechanisms so that each has a clear idea of what is and is not "its job". (There is a design principle that says if you have two pieces doing the same job then either they produce the same result, in which case one is redundent, or they produce different results, in which case one is wrong. Either way you want one, not two.) There have endless discussions about how some piece of new machinery overlapped the role of some other piece of new machinery (e.g., RSVP's `path' & channel switching machinery duplicating some of the function of multicast routing & pruning). These discussions *are* the process of design -- they're how we arrive at new pieces that are orthogonal & complementary to the existing pieces. If these disagreements bother you then you are lamenting the fact that protocols are designed by poor myopic humans and not the all knowing gods. But, if you look back through all these megabytes of discussion, you might notice that there was no conflict between the new machinery and IP. IP is architecturally very clear about its job and, partly by extremely good design, partly by accident of history, provided exactly the services and information we needed and didn't need to be warped at all. In fact, IP does a rather difficult job so clearly and simply and elegantly (e.g, look at X.75 to see how the telcos tried to deal with the administrative heterogeneity that IP handles effortlessly) my feeling is that it provided a "center" that helped simplify & improve all the other designs -- When you're comparing garbage to garbage all the choices seem pretty much alike; if someone sets a diamond next to the pile, good & bad suddenly get a lot more obvious. - Van From owner-Big-Internet@munnari.OZ.AU Wed May 18 01:17:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03234; Wed, 18 May 1994 01:17:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA01229; Wed, 18 May 1994 00:48:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA01226; Wed, 18 May 1994 00:43:05 +1000 Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03060; Wed, 18 May 1994 01:11:21 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA06335 (5.65c/IDA-1.4.4nsd for ); Tue, 17 May 1994 08:11:14 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA00844 (5.65c/IDA-1.4.4-910725); Tue, 17 May 1994 08:11:11 -0700 Message-Id: <199405171511.AA00844@remmel.NSD.3Com.COM> To: Bob.Hinden@eng.sun.com (Bob Hinden) Cc: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of "Tue, 17 May 94 04:26:28 PDT." <9405171126.AA14143@jurassic.Eng.Sun.COM> Date: Tue, 17 May 94 08:11:10 -0700 From: tracym@NSD.3Com.COM > By the way, the correct terms are hosts and routers. Last time I looked > at your marketing litature it said you were a router vendor. Not an IS > vendor. > > How about the notion that the IPng selected and developed soon be > > definitively certified as NOT the last IPng. Perhaps we should be > > It should just be declared as the next version of IP. Nothing more, > nothing less. Bob, Please: I was NOT, in my previous message, in the word-smithing business. (The typos in the last message should attest to that. Actually, I'm trying desperately to get some poduction code written, but there have been distractions.) (The use of ES/IS had nothing to do with SIPP/TUBA, if that is why you've complained.) There are lots and lots of boxes that are not routers per-se, but without which the inter-network as we know it does not, and will not, function. ARP servers, route-servers, LAN emulation servers, DNS servers, Border Policy servers, network-side LMI, UNI, NNI and ISDN functions, cell-switches, Giga-switches, PPP-FR translators, FR-ATM translators, bridges-with-IP-fragmentation, etc. ALL of these are in the realm of intermediate systems from the perspective I was trying to discuss. Stuff in the middle between two hosts that has some intelligence. MANY, if not most, of these Intermediate Systems will be affected by our selection (and engineering) of IPng, and IPnng (whether or not they are routers), but it will be within the realm of possibility that these can be upgraded On the other hand, we are positing that from this point on there will be hosts *which*require*global*connectivity* (perhaps without new services) that can't/won't be upgraded. So let's make sure we get the host side right for global connectivity and for currently understood requirements. There WILL be new requirements long before 20 years have passed, but hosts that want to use them will get upgraded, and other hosts won't care. Perhaps everyone is completely happy that the host side is fully spec'd, and ready for at least 20 years? Most people are ready to admit that we don't have all the answers that we would like, even for requirements that are reasonably well-understood today. So let's not burden ourselves with pretending that we might get lucky. Let's even accept that the extension mechanisms being designed today might not be enough. Let's try real hard to solve the pieces that will be most difficult to change. 1) a basic packet format that has "enough" stuff in it 2) a clean host interface for address resolution, QOS request and feedback, connection management, etc. and the original issue: 3) addressing itself If we get addressing right then there will likely be no great difficulty in providing IPng-IPnng translation, just as we will almost certainly be using for IP-IPng. If addressing doesn't come out right, then we will need NATng to maintain global connectivity. Tracy From owner-Big-Internet@munnari.OZ.AU Wed May 18 01:51:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00161; Tue, 17 May 1994 23:57:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA01148; Tue, 17 May 1994 23:28:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA01134; Tue, 17 May 1994 23:19:00 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29741; Tue, 17 May 1994 23:47:21 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa24190; 17 May 94 9:47 EDT To: Van Jacobson Cc: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of Tue, 17 May 1994 02:22:48 -0700. <9405170922.AA04283@rx7.ee.lbl.gov> Date: Tue, 17 May 1994 09:46:16 -0400 From: John Curran Message-Id: <9405170947.aa24190@nic.near.net> -------- ] From: Van Jacobson ] Subject: Re: Thoughts on the IPng situation... ] Date: Tue, 17 May 94 02:22:48 PDT ] ] > While it's really wonderful that we can warp IPv4 into doing all ] > of these things, the lack of architecture to support them ] > becomes clear when you try and predict how any combination of ] > capabilities will interact. ] ] I have worked on resource management (`flows'), reservation ] protocols and scalable multicast for the past five years. My ] experience has been that you have this exactly wrong: As you ] said, architecture is about designing things so that you have ] some hope of understanding how combinations of capabilities will ] interact. One touchstone in this effort is to achieve a sort of ] orthoganality between different mechanisms so that each has a ] clear idea of what is and is not "its job". ... There have ] endless discussions about how some piece of new machinery ] overlapped the role of some other piece of new machinery. ] ... These discussions *are* the process of design -- they're how ] we arrive at new pieces that are orthogonal & complementary to the ] existing pieces. If these disagreements bother you then you are ] lamenting the fact that protocols are designed by poor myopic ] humans and not the all knowing gods. ] ] But, if you look back through all these megabytes of discussion, ] you might notice that there was no conflict between the new ] machinery and IP. IP is architecturally very clear about its ] job and, partly by extremely good design, partly by accident of ] history, provided exactly the services and information we needed ] and didn't need to be warped at all. I will defer to your and Steve's judgement on this... It's possible that the IP architecture provides all of the "architecture" that we really need, and all of the capabilities being discussed will settle in a small number of orthogonal & complementary pieces. Looking at the IPv4 capabilities that have made it to internet-draft stage, I am unable to perceive their complementary nature (but it may be too early to tell). /John From owner-Big-Internet@munnari.OZ.AU Wed May 18 02:59:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04712; Wed, 18 May 1994 01:57:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA01282; Wed, 18 May 1994 01:28:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA01268; Wed, 18 May 1994 01:18:39 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00509; Wed, 18 May 1994 00:01:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23625; Tue, 17 May 94 10:01:44 -0400 Date: Tue, 17 May 94 10:01:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405171401.AA23625@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, brian@dxcoms.cern.ch Subject: Re: Requirements (was : FORMAL REQUEST : SIPP EIDs and Locators) Cc: jnc@ginger.lcs.mit.edu Right now, couldn't we concentrate on reaching rapid consensus on which proposal to adopt? ... Wouldn't it be nice if Scott and Allison could stand up in Toronto and say "As you all know, the consensus is that IPng will be XYZ."? My perception is that it is unlikely that we will develop a rough consensus around one of the designs, as is. The question thus is: what's the most efficient way forward; i) to expend the political energy trying to make a choice which isn't really going to be a done solution, and then convincing the people who did that design to make the changes we need, piecemeal, or ii) come at it from another way? I gather Scott and Allison have been thinking about what to do, so I'll wait and see what the IPng Directorate meeting this week comes up with... Noel From owner-Big-Internet@munnari.OZ.AU Wed May 18 03:00:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05443; Wed, 18 May 1994 02:17:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA01312; Wed, 18 May 1994 01:48:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA01298; Wed, 18 May 1994 01:33:28 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27948; Tue, 17 May 1994 22:56:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23271; Tue, 17 May 94 08:56:47 -0400 Date: Tue, 17 May 94 08:56:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405171256.AA23271@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu From: Steve Deering I think what's going on here is a fundamental disagreement over whether we need a new *architecture* for the internet layer, or a new *instantiation* of the current architecture. You have hit the nail on the head; this is certainly the root of our troubles. I do not believe the Internet needs a new internet-layer architecture. The current architecture ... minimal service "promises" to upper layers, and its simple, stateless, datagram routing and forwarding model. This is where we obviously part paths, in part for reasons contained in your next sentence. I believe we need a new architecture for two reasons. First, we are trying to upgrade the service model provided by the internetwork layer, and in a way which requires more state in the network. Any time you radically change the external functionality of some system, you need to go back and rethink the division into fucntional units, since the modularization boundaries you picked before may not longer be appropriate. Second, the existing internetwork architecture was designed for a far smaller scale network than the global one we now envision; it is a truism of system design that system which work fine at one scale simply don't function well at another, much larger scale. IPv4 has scaled better than the original designers ever hoped for, which says something about how good it was, but it is running out of steam. If you look at IPv4 as a system divided into subsystems (or functional modules, if you like the "program" view of life), it contains precisely two major subsystems; route creation, and forwarding. The interface between them is pretty clean and simple; it consists of filling the routing table. I can't think of anything else that counts as an internetwork layer subsystem; DNS is certainly not (you can exchange packets fine without it). You can argue that multicast represents a separate subsystem, but the current design is so inextricably intermingled with the two existing subsystems (to the detriment of all) it's hard to say. When we look at the new service model we are trying to provide, it becomes clear that this division into subsystems is no longer optimal. In adding a new resource reservation subsystem, we need to go to a model where we have separate routing data distribution, path selection, and forwarding subsystems, since path selection and resource reservation need to interact more closely to do their job properly. There are also issue where the network needs to retain more state; state which only makes sense when interpreted across multiple packets. Resource reservation simply does not make sense without more state in the network. I claim that multicast, at least a multicast that can handle groups across a large range of sizes, so that it works well in a system where you have a few really large (10^6 members) groups as well as many (10^6) small groups (4-5 members) also needs to be done as a separate subsystem, or collection of subsystems (such as group membership, spanning tree selection, etc). Also, when you start to add various administrative and billing considerations into routing, the simple two-subsystem model doesn't work well either. So, no, I don't agree that the current architecture needs no changes. Certainly, in many ways, it has aspects that are right on (such as the notion that delivery is not guaranteed, which simplifies things enormously, at little cost), but it was designed for a much smaller network with a simpler service model, and does need to be reworked. As Yakov has pointed out, almost every feature, function, or capability that has been suggested as desirable for IPng can be provided in IPv4 ... the current architecture can support policy-based routing (SDRP), mobility (Mobile IP) ... and flows (CSZ/RSVP). If you look at each of these, they are either handicapped by being forced to work within the current archietcture (e.g. RSVP, with the problems they have interacting with the routing, when the routing changes paths out from under- neath them, or mobility, where they are encapsulating at a base station), or they are effectively changing the architecture (e.g. RSVP, adding state in the routers). I do not view the implementation of those functions in IPv4 to be kludges that are corrupting the purity of the original architecture ... but rather I see the fact that they can be accommodated within the current architecture as validation of the flexibility and potential longevity of that architecture. But they aren't being accomodated cleanly and easily; ask each of them if they'd have come up with the same answer if they have a blank sheet of paper, as opposed to being forced to work with the IPv4 model? Granted, the implementation of some of those functions might not be as efficient as they would be in a different protocol than IPv4, but in most cases that's simply a problem with the *instantiation* of the architecture, In some cases yes, but not in all, by a long shot. Given ... the exploitation of IPv4's perceived limited lifetime by those who wish the Internet to die, I think it is important to come to agreement on IPng as soon as possible. Look, the people who are shooting at TCP/IP are going to keep on doing it, no matter how hard you try and combat their charges in a rational way. Very few of them are motivated by a concern for good technology; they have other axes to grind. Fix X and they'll start attacking Y. In a previous commercial endeavour, I've been on the receiving end of this kind of campaign; reality has nothing to do with it, and I can tell you from hard experience that the defence you're trying doesn't work. I mean, I've just heard about one organization that lost a sale to an IBM APPN solution because the Internet is running out of address space. This is totally bogus; no APPN solution is going to be part of a global internetwork *anyway*, APPN just doesn't have that capability. So, they'd have been just as well off (from that requirement) with a private IP address space, and at least had an open, multi-vendor solution. The salesperson who made that "IP is running out of space" argument either didn't understand very much, or didn't care. It's mendacious marketing bullshit, the world will always be full of lies and marketing bullshit, and doing good engineering isn't any use in combatting it. I do not see that we need a new architecture so desperately that we should risk the demise of the Internet waiting for one to be defined, tested, and agreed upon I've been reading about the imminent death of TCP/IP for 10 years, and it's not going to happen any time soon. The people who are doing the predicting, and the predictions of what's going to take over have changed, but otherwise the song remains the same. I talked to some trade-rag writers I know, and their opinion is that all the users care about is if it works. This stuff works well, and has a large installed user base to communicate with, and neither of those is going to change. That's the bottom line, and that's all most users care about. To use Brian's metaphor, is the sky clear? No. It is falling? No. Is it cloudy? Yes, and we need to work toward something new. However, people who are willing to concoct bogus arguments as to why you shouldn't use TCP/IP, in favor of their proprietary solution, aren't going to stop just because you make some paper decision. I'm not suggesting waiting on a paper exercise. I'm suggested we work on field trials of some new ideas, and figure out how to integrate them cleanly into a new internetwork layer, in parallel. I see no reason not to choose an IPng in July. Look, there is not going to be a rough consesus for any of the existing candidates, in their current form. That's life, and we need to accept that, and figure out how to move on. I'm more worried that, if we don't get IPng out there soon, we'll end up with NAT boxes everywhere, which will *break* the current architecture. No worse than firewalls, which are popping up all over already, due to our lack of any good security. If we *engineer* (not *architect*) IPng well, there's a fair chance that it will serve as the final refinement of the current architecture, perhaps serving as a transition target for other instantiations of the architecture, such as IPX, Appletalk, and CLNP. Whatever comes next ... will be a completely different architecture, not an IP-anything, and it will be deployed, as ATM is being deployed, oblivious to the internet architecture. Exactly. ATM is being pushed precisely because it provides a more advanced service model than the existing internetwork layer. By deploying at IPng with no more complex service model than IPv4, all you're going to do is give a massive marketing leg up to the ATM people. In other words, instead of Novell salesmen pushing IPX "because the IP address space is running out", you'll have ATM salesmen pushing ATM "because IP does not provide service guarantees". the only problem with IPv4 that makes it worthwhile to undertake the pain of deploying a new version is a header design problem: its address fields are too small to accommodate the projected growth of the Internet. If that really were the only problem we could fix it with an "address extension" option, and with a somewhat easier transition strategy. it is time for the community to judge those attempts and make a decision. I repeat, there is not going to be rough consensus for any of the candidates in their current form. That's the reality of it. Certainly, the introduction of a new version of IP gives us a rare chance to introduce promising new architectural features, but my conservative design nature would like to avoid risking the success of the design on the success of those new features. Sucessful large organizations that take risks prosper (Boeing with the 707 and 747; IBM with the 360 architecture). Ones that try and get conservative wind up on the ash-heap (IBM, with their emphasis on mainframes, etc). I simply cannot imagine going through all the pain and agony of doing a new version of IP *without* the gain of introducing new archietctural features. If we don't have enough practical experience with them yet (and I agree that real experience is needed), we need to wait, and all indications are we can afford to wait a couple of years. I suggest that we suspend arguments over the requirements for IPng ... until we have agreed on the meta-requirement: must IPng embody a new internet architecture, or can it simply be a re-engineering of IPv4? Yes. If you believe that we need a new architecture, do you think we can do a proper job of designing, testing, agreeing on, and deploying it before the market decides to give up on IPv4 and migrate to a better version of the current architecture (e.g., a new version of IPX) or an alternative architecture (e.g., ATM)? Fix the address space, and people who want to take potshots will just switch to something else. As far as ATM goes, my interactions with the people working on it give me the impression that the group with the people who have the most experience at building global-scale data networks, and the best chance of doing a new one, are right here. We need to do it, though, not piddle around with minor tweaks. Do that, and ATM *will* be the Internet of the future. Noel From owner-Big-Internet@munnari.OZ.AU Wed May 18 05:17:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11962; Wed, 18 May 1994 05:17:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA01547; Wed, 18 May 1994 04:48:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA01544; Wed, 18 May 1994 04:40:55 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11775; Wed, 18 May 1994 05:09:13 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA04741; Tue, 17 May 94 13:14:40 MDT Received: from [130.57.64.151] by WC.Novell.COM (4.1/SMI-4.1) id AA06368; Tue, 17 May 94 12:07:07 PDT Date: Tue, 17 May 94 12:07:06 PDT Message-Id: <9405171907.AA06368@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: francis@cactus.slab.ntt.jp (Paul Francis), kre@munnari.OZ.AU From: Greg Minshall Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU >Ok, then add the requirement that said identifier must be less >than or equal to whatever number you find appropriate, say 64 bits? > >Well, even that is specifying a solution. A real requiement >would say something like "the identifier must be parsable by a >current state of the art computer in xx micro-seconds). Only end nodes care about EID. So, it isn't *as much* of a performance issue as, possibly, a bandwidth issue. Greg (yours for 128-bit EIDs, the low order 48 bits of which are often IEEE addresses...) From owner-Big-Internet@munnari.OZ.AU Wed May 18 05:33:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11359; Wed, 18 May 1994 04:57:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA01517; Wed, 18 May 1994 04:28:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA01503; Wed, 18 May 1994 04:15:31 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10781; Wed, 18 May 1994 04:43:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25479; Tue, 17 May 94 14:43:50 -0400 Date: Tue, 17 May 94 14:43:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405171843.AA25479@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Another flow question. Cc: jnc@ginger.lcs.mit.edu From: Tony Li Some guesstimates today are that we have 2*10^6 hosts, and that central routers in the Internet see ~10^4 "flows" (i.e., 2*10^4 common endpoints). If this ratio of hosts to flows continues to be 200:1, then 2*10^9 hosts gives 10^7 flows. The bug with this calculation is that it assumes that the ratio of the number of "central routers" to the number of hosts remains constant. I don't think this is likely to be true; if nothing else, it means that the bandwidth into those routers is going to have to go up by the same ration, from T3 (today) to 10^3 times as fast. First, aggregation is probably a misleading word, as combining flows is not at all similar to how things work with route aggregation. We need a better word... "Merged" isn't bad, but it implies that the traffic gets more mixed up that it really does. My thesaurus gives "collect" and "gather" as synonyms for "aggregate", but somehow I don't like them either. In any case, when flows are aggregated (merged?), they would normally be merged at setup time, possibly by something like a sites border router... Well, presumably you want the process to recurse, so that flows A1, A2 and A3 get aggregated together into A, which gets aggregated with B (containing B1, B2, etc) into 1, which gets aggregated together with 2 (containing C and D (containing ...)), etc... Noel From owner-Big-Internet@munnari.OZ.AU Wed May 18 06:17:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14144; Wed, 18 May 1994 06:17:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA01634; Wed, 18 May 1994 05:48:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA01631; Wed, 18 May 1994 05:46:55 +1000 Received: from bgate.lut.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14102; Wed, 18 May 1994 06:15:11 +1000 (from J.P.Knight@lut.ac.uk) Received: by suna.lut.ac.uk (4.1/SMI-4.1) id AA06087; Tue, 17 May 94 21:15:03 BST Date: Tue, 17 May 1994 21:03:22 +0100 (BST) From: "Jon P. Knight" Subject: Re: Thoughts on the IPng situation... To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: <1994May17.055040.28022@hpn.lut.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 17 May 1994, Noel Chiappa wrote: > I do not view the implementation of those functions in IPv4 to be kludges > that are corrupting the purity of the original architecture ... but rather > I see the fact that they can be accommodated within the current > architecture as validation of the flexibility and potential longevity of > that architecture. > > But they aren't being accomodated cleanly and easily; ask each of them if > they'd have come up with the same answer if they have a blank sheet of paper, > as opposed to being forced to work with the IPv4 model? Trouble is that as soon as you give them all blank sheets of paper, they come up with different, often mutually incompatible designs for the whole network layer rather than just their little bit. Its called the IPng design process... ;-) Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Research Student in High Performance Networking and Distributed Systems in the Department of _Computer_Studies_ at Loughborough University. * Its not how big your share is, its how much you share that's important. * From owner-Big-Internet@munnari.OZ.AU Wed May 18 07:29:38 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12824; Wed, 18 May 1994 05:39:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04371 Wed, 18 May 1994 05:39:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA01579; Wed, 18 May 1994 05:08:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA01565; Wed, 18 May 1994 04:52:07 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12184; Wed, 18 May 1994 05:20:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25800; Tue, 17 May 94 15:20:25 -0400 Date: Tue, 17 May 94 15:20:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405171920.AA25800@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, jcurran@nic.near.net Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu From: John Curran > the current architecture can support policy-based routing (SDRP), > mobility (Mobile IP), auto-configuration (DHCP), and flows (CSZ/RSVP). > ... I do not view the implementation of those functions in IPv4 to be > kludges that are corrupting the purity of the original architecture While it's really wonderful that we can warp IPv4 into doing all of these things, the lack of architecture to support them becomes clear when you try and predict how any combination of capabilities will interact. Exactly. The architecture *is* going to change, as the service model the internetwork layer provides (i.e. the external interface specification) changes. The only question is whether those changes are part of a unified design, or whether they are localized (almost ad hoc) changes. You can make an analogy to a large program, which needs some changes. We all know there are two ways to do it, in the cases where what you want is not already provided for in the structure. #1, quick and dirty; you go in and make a local change that does what you want. #2, you sit back and reorganize the program somewhat, to do what you want cleanly. We all also know that over time, choice of path #1 winds up in a large mess of kludges, warts, etc; an unmaintainable, and ungrowable, program. System architectures are exactly the same. We *are* going to change the architecture here, with deployment of new stuff; the only thing we get to decide is whether it is done in a way where the new features (which I agree we need to deploy incrementally) are designed to work together cleanly, as parts of a new overall design, or whether they are kludged on, with as few changes elsewhere as possible. You don't get "clean" and "as few changes elsewhere" at the same time in an architeture, any more than you do in a program. I don't think that we need a brand-new architecture for IPng; I do think that revisiting our existing model ... might be a good idea. It may even allow us to make simplying assumptions which will reduce overall complexity and improve robustness of the services provided. Exactly. It'll be cleaner, more flexible, have greater capabilities, etc, etc, etc, if we do it right. I should take this opportunity to restate that, in saying we need a "new" architecture, I'm not talking about throwing out the old one, lock, stock and barrel. There are many aspects (such as the reliance on unreliable packets) which are just right. Perhaps a better term would be "revised" architecture, but it's all the same thing, really. Noel From owner-Big-Internet@munnari.OZ.AU Wed May 18 07:43:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16108; Wed, 18 May 1994 07:17:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA01707; Wed, 18 May 1994 06:48:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA01704; Wed, 18 May 1994 06:47:36 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16079; Wed, 18 May 1994 07:15:57 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA16272; Tue, 17 May 94 15:20:09 MDT Received: from [130.57.64.151] by WC.Novell.COM (4.1/SMI-4.1) id AA06513; Tue, 17 May 94 14:12:36 PDT Date: Tue, 17 May 94 14:12:35 PDT Message-Id: <9405172112.AA06513@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: big-internet@munnari.OZ.AU From: Greg Minshall Subject: Re: IEEE 802 not unique enough??? I doubt i've ever said this (or, ever will say this :-) clearly enough: IEEE 802 addresses are very good. I like them for autoconfiguration, say. But, to be considered "globally unique", they *NEED* to be prefixed with some other value (from something like the IPv4 address assignment authority). Locally, on a LAN or within a department or even within an organization (corporation, university, etc.), there are two reasons why it is OK to consider IEEE 802 addresses "unique": 1. The odds of getting two the same is low. 2. In the case that the low odds bite you, there is a "common administration" that can deal with the problem (by autocratically kicking one of the offenders off the wire, whatever). Globally, the following happen: 1. The odds go up quite a bit (though, in general, the probability of *noticing* the collision go down). 2. In the case where the higher odds bite you, there is NO "common administration" that can deal with the problem. If you think of using IEEE 802 addresses, maybe called EIDs, to do a pseudo header checksum calculation, none of this matters. However, if your favorite WWW server is using just the IEEE 802 address (and socket numbers) to look up TCP control blocks, then a conflict is going to leave someone very unhappy. Summarizing: IEEE 802 is good all by itself for "local'ish" use. IEEE 802 prefixed by some managed space (like IPv4) is just fine for global use. Greg From owner-Big-Internet@munnari.OZ.AU Wed May 18 08:01:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16840; Wed, 18 May 1994 07:37:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01737; Wed, 18 May 1994 07:08:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA01734; Wed, 18 May 1994 06:59:51 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12992; Wed, 18 May 1994 05:43:03 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 17 May 1994 15:42:51 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 17 May 1994 15:42:51 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA08782; Tue, 17 May 94 15:41:23 EDT Date: Tue, 17 May 94 15:41:23 EDT Message-Id: <9405171941.AA08782@mailserv-D.ftp.com> To: Greg_Minshall@Novell.COM Subject: Re: continuing EID discussion From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: francis@cactus.slab.ntt.jp, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU Content-Length: 920 > >Ok, then add the requirement that said identifier must be less > >than or equal to whatever number you find appropriate, say 64 bits? > > > >Well, even that is specifying a solution. A real requiement > >would say something like "the identifier must be parsable by a > >current state of the art computer in xx micro-seconds). > > Only end nodes care about EID. So, it isn't *as much* of a performance > issue as, possibly, a bandwidth issue. Depends. You might create FLOWIDS (assuming that you are doing flows, of course) by concatenating the source EID and some small number generated at the source (or maybe the destination EID). Then every router that cares about the FLOWID will care about the EID size. EIDs could also be used as a key into a cache of forwarding information that a router maintains. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed May 18 08:17:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18117; Wed, 18 May 1994 08:17:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01801; Wed, 18 May 1994 07:48:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01779; Wed, 18 May 1994 07:30:35 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16859; Wed, 18 May 1994 07:38:31 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA17658; Tue, 17 May 94 15:42:38 MDT Received: from [130.57.64.151] by WC.Novell.COM (4.1/SMI-4.1) id AA06548; Tue, 17 May 94 14:35:05 PDT Date: Tue, 17 May 94 14:35:04 PDT Message-Id: <9405172135.AA06548@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Steve Deering From: Greg Minshall Subject: Re: addressing/locating/identifying models Cc: sipp@sunroof2.eng.sun.com, big-internet@munnari.OZ.AU Steve, First, model A for AppleTalk started off as model B (i.e., Cn *was* large enough to hold the device ID). Similarly, model B for IPX might become model A if, for example, the world moved to 80-bit device IDs. So, model A versus model B depends on the end-net. Another point is that the all-zeros network number of IPX and (conceptually) Appletalk, which imply "host X on *this* net", is different from your models A/B (maybe it's like model F?). Greg From owner-Big-Internet@munnari.OZ.AU Wed May 18 08:18:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18291; Wed, 18 May 1994 08:18:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01816; Wed, 18 May 1994 07:50:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01782; Wed, 18 May 1994 07:32:13 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17742; Wed, 18 May 1994 08:00:37 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA18633; Tue, 17 May 94 16:06:02 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06587; Tue, 17 May 94 14:58:28 PDT Date: Tue, 17 May 94 14:58:28 PDT Message-Id: <9405172158.AB06587@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atkinson@itd.nrl.navy.mil (Ran Atkinson) From: Greg Minshall Subject: Re: IPng security, etc. Cc: big-Internet@munnari.OZ.AU Ran, > It is in fact startling to me that neither TUBA nor CATNIP have any >concrete security proposals since it is so straightforward to do. This is where there has been some disagreement within the IPng directorate, at least. Some of us have the opinion that some things map onto any of the IPng proposals in much the same way. Thus, normally, there seems to be no real reason to go through this mapping N-1 times uselessly. Where i think the mapping should happen up front is where either 1) that proposal is planning on doing that function in a fundamentally different way (CATNIP's multicast, say), or 2) that proposal *needs* that functionality in a more fundamental way (SIPP's desire to "turn around" source routes, say). Greg From owner-Big-Internet@munnari.OZ.AU Wed May 18 08:19:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18333; Wed, 18 May 1994 08:19:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01831; Wed, 18 May 1994 07:51:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01785; Wed, 18 May 1994 07:33:18 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16100; Wed, 18 May 1994 07:16:56 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA04585; Tue, 17 May 94 14:18:41 -0700 Date: Tue, 17 May 94 14:18:41 -0700 From: Eric Fleischman Message-Id: <9405172118.AA04585@atc.boeing.com> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: Thoughts on the IPng situation... Cc: ericf@munnari.OZ.AU Dear Noel, The purpose of this note is to reply to your recent posting. I have come to value your insight into the Internet community's affairs and so it is with a large degree of hesitancy that I find myself disagreeing with important aspects of your latest posting. Specifically, I hope that you consider the following points: I do not think that you understood the dynamics of what the end user was responding to in the following scenario which you described: >I mean, I've just heard about one organization that lost a sale to an IBM APPN >solution because the Internet is running out of address space. This is totally >bogus; no APPN solution is going to be part of a global internetwork *anyway*, >APPN just doesn't have that capability. So, they'd have been just as well off >(from that requirement) with a private IP address space, and at least had an >open, multi-vendor solution. > >The salesperson who made that "IP is running out of space" argument either >didn't understand very much, or didn't care. It's mendacious marketing >bullshit, the world will always be full of lies and marketing bullshit, and >doing good engineering isn't any use in combatting it. The issue the end user was doubtlessly responding to is the widespread perception that to deploy any major NEW deployment of TCP/IP today is short- sighted since such a deployment will be quickly obsoleted by IPng. Thus, for that user to deploy TCP/IP would imply that they will shortly afterwards have to migrate that deployment to IPng. Thus, a TCP/IP deployment means TWO deployments for that user with all of the associated costs and expenses -- with no functionality gain to their business goals. APPN, by contrast, implies one deployment to that user because IBM promises full backwards compatibility from APPN+ to APPN. Similarly, all us end users know that 3270 Data Streams are still viable today despite the fact that IBM tried to kill them off back in the late 1980s via SAA. However, "backwards compatability" won and SAA lost. Thus, a decision to go with APPN is a decision which hopefully carries with it the ensurance that those APPN assets will (at a minimum) be able to fully depreciate before being obsoleted. Ditto for the subsequent argument you made about people preferably choosing NetWare since it also does NOT carry with it any "imminent forced obsolescence". Of course, those of us who have already deployed TCP/IP have a different perspective than that outlined in the previous paragraph -- a perspective which I have more fully detailed in my "Large Users' View of IPng" documents. In our case, we hope to leverage our investment in TCP/IP by emphatically NOT migrating to IPng until business reasons compel us to do so (e.g., unsurpassed performance/functionality in IPng). Thus, IPng is an unattractive, hard sell for us and our probable response to IPng will be to deploy NAT-like application-layer gateways on our firewalls -- and continue buying IPv4. In any case, while I recognize the existence of bigots, most of the so-called anti-TCP/IP people in your note aren't really anti-TCP/IP. They just have other fish to fry than Internet connectivity. That is, while a growing groundswell of people in my company are keenly excited about Internet connectivity, I suspect that a significant percentage of real end users in other corporations are largely unaware of what they are missing by not being connected to the Internet. Thus, they may not even understand why they might want to eventually connect some day. Thus, your reference to APPN/NetWare not providing Internet access may not be viewed by them as a relevant business issue. [Again, this point was well covered in my documents.] >I've been reading about the imminent death of TCP/IP for 10 years, and it's >not going to happen any time soon. The people who are doing the predicting, >and the predictions of what's going to take over have changed, but otherwise >the song remains the same. I talked to some trade-rag writers I know, and >their opinion is that all the users care about is if it works. This stuff >works well, and has a large installed user base to communicate with, and >neither of those is going to change. That's the bottom line, and that's all >most users care about. From the above, you can see that we as a corporation are strategically interested in TCP/IP remaining very viable for many years to come since we have already deployed 80,000 TCP/IP end systems and roughly 450 TCP/IP routers. However, it is my opinion that the Internet community can NOT afford to "bide its time" on making the IPng decision despite my/our selfish interests that make IPng a "hard sell" to us. This is, as toasternet becomes real, the toasternet applications will need a technology which can scale to choose as their infrastructual basis -- and IPv4 demonstrably can't. Thus, they likely will be making business decisions based on your APPN example above (except choosing OSI) just so they won't have to redeploy their infrastructure twice. Let's get real: if TCP/IP-based Internet connectivity is already an impossibility for them from the get-go, then the best they can do is to select the best available alternative technology which MAY be eventually deployed over the Internet. Are you willing to categorically state that OSI won't become widely supported over the Internet if IPng doesn't become real soon? It seems to me that they really have no other option than to choose OSI if they have to choose today -- unless, of course, they have already widely invested in TCP/IP (or some other technology?). What am I saying? I am saying that we aren't doing IPng for Boeing. We aren't doing it for router vendors, researchers or for anybody else within the Internet community today. We are doing IPng for those people NOT in our community today so that they may be able to join us some day. That is, unless TCP/IP can be made to scale (IPng), what large deployment will be willing to deploy TCP/IP unless they can be assured that they won't have their investment quickly obsoleted? But YOU or I can't assure them of that because we know that we must deploy IPng to "save" the Internet (as the number of Internet users continue to approach a critical threshold). Thus, unless we have IPng defined and deployable then they can not choose TCP/IPng and thus must choose the best of the available alternatives: They must choose something that works and scales and is available within THEIR deployment timeframe window. The bottom line issue (in my opinion) is "when will toasternet become real?" Our window for IPng requires that IPng must be deployable BEFORE toasternet arrives. I personally believe we are missing that window. I believe that toasternet is becoming real today (e.g., CDPD, EPRI, Boeing's doors and elevators -- and soon thermostats? -- are TCP/IP devices today, etc.). However, we will need a minimum of 4 years after selecting IPng to make it deployable. Thus, we are a minimum of 4 years out to solve a problem which is beginning to become manifested today. This worries me. I therefore do not share your belief that we can afford to wait in defining a scalable TCP/IP (i.e., IPng). I believe that we can not afford to dilly-dally despite the demonstrably true observation of yours that we have not achieved consensus as a community on the preferable IPng alternative. I believe that we must proceed full speed ahead despite the torpedos. Politics simply must be met by a willingness to compromise on a workable solution. The future of the Internet is at stake. Sincerely yours, --Eric Fleischman BCS Network Architect From owner-Big-Internet@munnari.OZ.AU Wed May 18 09:33:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20805; Wed, 18 May 1994 09:31:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA01949; Wed, 18 May 1994 09:02:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA01941; Wed, 18 May 1994 08:55:48 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19870; Wed, 18 May 1994 09:10:06 +1000 (from G.Michaelson@cc.uq.oz.au) Received: from [130.102.128.5] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07729 Wed, 18 May 1994 09:08:33 +1000 (from G.Michaelson@cc.uq.oz.au) Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Wed, 18 May 1994 09:07:05 +1000 To: Robert Elz Cc: Simon E Spero , big-internet@munnari.OZ.AU Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Tue, 17 May 1994 13:15:26 +1000." <18567.769144526@munnari.OZ.AU> X-Mailer: exmh version 1.3 4/7/94 Date: Wed, 18 May 1994 09:06:59 +1000 Message-Id: <4423.769216019@brolga.cc.uq.oz.au> From: George Michaelson I'd just like to echo Robert Elz's sentiment. PLEASE don't put a dependency on X.500 into IPnG. I don't think the deployed X.500 systems are viable for name/address lookup events at anything like the response time of the DNS. If you want that top-heavy OSI kind of behaviour (call setup, verification, validation, BER decode, finally a DBMS lookup (with distribution embedded? oh dear. better recurse...) re-encode into BER, call reply, local cache then you can forget datagram-like short delay exchanges. Fast implementation and deployment of an IPnG attuned name/address lookup would do better to leverage off the DNS. I can't think of anything X.500 has going for it beyond a good housekeeping seal of approval, and Betty Crocker is not Dave Crockers mother... -George From owner-Big-Internet@munnari.OZ.AU Wed May 18 09:37:24 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20946; Wed, 18 May 1994 09:37:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08060 Wed, 18 May 1994 09:19:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA01914; Wed, 18 May 1994 08:48:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA01900; Wed, 18 May 1994 08:36:44 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18464; Wed, 18 May 1994 08:24:30 +1000 (from kre@munnari.OZ.AU) To: "Jon P. Knight" Cc: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of "Tue, 17 May 1994 21:03:22 +0100." Date: Wed, 18 May 1994 08:24:28 +1000 Message-Id: <18704.769213468@munnari.OZ.AU> From: Robert Elz Date: Tue, 17 May 1994 21:03:22 +0100 (BST) From: "Jon P. Knight" Message-ID: Trouble is that as soon as you give them all blank sheets of paper, they come up with different, often mutually incompatible designs for the whole network layer rather than just their little bit. This is a feature, not a bug. Upon getting designs done that way a few good net architects can look at them, and distil the basic principles, extract what's really needed by the various proposals, and produce a design that will do what is needed, but is still clean. The problem is that the customers of the net level are mostly off attempting to shoehorn their applications into IPv4, with varying degrees of success (from excellent, indicating that IPv4 is a good design for the application, towards absurd). That is often a much harder problem than starting afresh - the installed base needs to be considered amongst other things. This generates something of a dilemma, these applications (mobility, etc) are needed soon, which is what's prompting the work to put them in IPv4. That work has meant that there's been much less talent available to work on fresh designs, and much of what there is has already been biased by having worked on an IPv4 solution - they tend to see things in those terms. However, if we were to say "stop all that, you're wasting time, work on a design for IPng where you have a free hand", then we delay IPng while everyone decides what they need. Personally I don't see that as a problem for IPng, though others do, but it is a problem for the applications - they want something that can work next year, or even this year, not with a guaranteed delay of 4 or 5 years while IPng is first designed, then prototyped, implemented, and most importantly, deployed widely enough to have any impact. kre From owner-Big-Internet@munnari.OZ.AU Wed May 18 09:56:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21871; Wed, 18 May 1994 09:56:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02055; Wed, 18 May 1994 09:27:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02003; Wed, 18 May 1994 09:19:13 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20416; Wed, 18 May 1994 09:22:57 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08114 Wed, 18 May 1994 09:20:40 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA19949; Tue, 17 May 94 19:17:58 EDT Message-Id: <9405172317.AA19949@tipper.oit.unc.edu> To: George Michaelson Cc: Robert Elz , big-internet@munnari.OZ.AU Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Wed, 18 May 94 09:06:59 +1000." <4423.769216019@brolga.cc.uq.oz.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 May 94 19:17:58 -0400 From: Simon E Spero George Michaelson writes: > >If you want that top-heavy OSI kind of behaviour (call setup, verification, >validation, BER decode, finally a DBMS lookup (with distribution embedded? >oh dear. better recurse...) re-encode into BER, call reply, local cache then >you can forget datagram-like short delay exchanges. The systems that I mentioned, in particular SID, are UDP based. SID uses the PER, and happens to use only a half to a third of the overhead of DNS, when performing DNS style lookups. This may not seem important to some, but if you're trying to ship around certificates along with the data, it can make a lot of difference. From owner-Big-Internet@munnari.OZ.AU Wed May 18 09:56:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21872; Wed, 18 May 1994 09:56:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02049; Wed, 18 May 1994 09:27:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA01997; Wed, 18 May 1994 09:15:31 +1000 Received: from brolga.cc.uq.oz.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21335; Wed, 18 May 1994 09:43:49 +1000 (from G.Michaelson@cc.uq.oz.au) Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Wed, 18 May 1994 09:43:30 +1000 To: Simon E Spero Cc: Robert Elz , big-internet@munnari.OZ.AU Subject: Re: addressing/locating/identifying models In-Reply-To: Your message of "Tue, 17 May 1994 19:17:58 -0400." <9405172317.AA19949@tipper.oit.unc.edu> X-Mailer: exmh version 1.3 4/7/94 Date: Wed, 18 May 1994 09:43:26 +1000 Message-Id: <5798.769218206@brolga.cc.uq.oz.au> From: George Michaelson Fine. If you have a deployable method that can support your needs I have no gripe. In fact, if its faster than the DNS perhaps the DNS should be re-mapped onto it... -George From owner-Big-Internet@munnari.OZ.AU Wed May 18 09:57:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21926; Wed, 18 May 1994 09:57:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02066; Wed, 18 May 1994 09:28:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02009; Wed, 18 May 1994 09:21:09 +1000 Received: from csn.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19181; Wed, 18 May 1994 08:47:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from murtoa.cs.mu.OZ.AU by csn.org with SMTP id AA12603 (5.67b/IDA-1.5 for big-internet@munnari.oz.au); Tue, 17 May 1994 16:47:20 -0600 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01804; Wed, 18 May 1994 07:48:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01779; Wed, 18 May 1994 07:30:35 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16859; Wed, 18 May 1994 07:38:31 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA17658; Tue, 17 May 94 15:42:38 MDT Received: from [130.57.64.151] by WC.Novell.COM (4.1/SMI-4.1) id AA06548; Tue, 17 May 94 14:35:05 PDT Date: Tue, 17 May 94 14:35:04 PDT Message-Id: <9405172135.AA06548@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Steve Deering From: Greg Minshall Subject: Re: addressing/locating/identifying models Cc: sipp@sunroof2.eng.sun.com, big-internet@munnari.OZ.AU Steve, First, model A for AppleTalk started off as model B (i.e., Cn *was* large enough to hold the device ID). Similarly, model B for IPX might become model A if, for example, the world moved to 80-bit device IDs. So, model A versus model B depends on the end-net. Another point is that the all-zeros network number of IPX and (conceptually) Appletalk, which imply "host X on *this* net", is different from your models A/B (maybe it's like model F?). Greg From owner-Big-Internet@munnari.OZ.AU Wed May 18 09:58:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21944; Wed, 18 May 1994 09:58:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02089; Wed, 18 May 1994 09:29:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02015; Wed, 18 May 1994 09:21:29 +1000 Received: from csn.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19324; Wed, 18 May 1994 08:51:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from murtoa.cs.mu.OZ.AU by csn.org with SMTP id AA13453 (5.67b/IDA-1.5 for big-internet@munnari.oz.au); Tue, 17 May 1994 16:51:25 -0600 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01804; Wed, 18 May 1994 07:48:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01779; Wed, 18 May 1994 07:30:35 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16859; Wed, 18 May 1994 07:38:31 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA17658; Tue, 17 May 94 15:42:38 MDT Received: from [130.57.64.151] by WC.Novell.COM (4.1/SMI-4.1) id AA06548; Tue, 17 May 94 14:35:05 PDT Date: Tue, 17 May 94 14:35:04 PDT Message-Id: <9405172135.AA06548@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Steve Deering From: Greg Minshall Subject: Re: addressing/locating/identifying models Cc: sipp@sunroof2.eng.sun.com, big-internet@munnari.OZ.AU Steve, First, model A for AppleTalk started off as model B (i.e., Cn *was* large enough to hold the device ID). Similarly, model B for IPX might become model A if, for example, the world moved to 80-bit device IDs. So, model A versus model B depends on the end-net. Another point is that the all-zeros network number of IPX and (conceptually) Appletalk, which imply "host X on *this* net", is different from your models A/B (maybe it's like model F?). Greg From owner-Big-Internet@munnari.OZ.AU Wed May 18 09:59:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21975; Wed, 18 May 1994 09:59:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02101; Wed, 18 May 1994 09:30:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02006; Wed, 18 May 1994 09:20:49 +1000 Received: from csn.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18969; Wed, 18 May 1994 08:39:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from murtoa.cs.mu.OZ.AU by csn.org with SMTP id AA10929 (5.67b/IDA-1.5 for big-Internet@munnari.oz.au); Tue, 17 May 1994 16:39:26 -0600 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01819; Wed, 18 May 1994 07:50:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01782; Wed, 18 May 1994 07:32:13 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17742; Wed, 18 May 1994 08:00:37 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA18633; Tue, 17 May 94 16:06:02 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06587; Tue, 17 May 94 14:58:28 PDT Date: Tue, 17 May 94 14:58:28 PDT Message-Id: <9405172158.AB06587@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atkinson@itd.nrl.navy.mil (Ran Atkinson) From: Greg Minshall Subject: Re: IPng security, etc. Cc: big-Internet@munnari.OZ.AU Ran, > It is in fact startling to me that neither TUBA nor CATNIP have any >concrete security proposals since it is so straightforward to do. This is where there has been some disagreement within the IPng directorate, at least. Some of us have the opinion that some things map onto any of the IPng proposals in much the same way. Thus, normally, there seems to be no real reason to go through this mapping N-1 times uselessly. Where i think the mapping should happen up front is where either 1) that proposal is planning on doing that function in a fundamentally different way (CATNIP's multicast, say), or 2) that proposal *needs* that functionality in a more fundamental way (SIPP's desire to "turn around" source routes, say). Greg From owner-Big-Internet@munnari.OZ.AU Wed May 18 10:24:35 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22942; Wed, 18 May 1994 10:24:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10578 Wed, 18 May 1994 10:23:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02159; Wed, 18 May 1994 09:50:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02018; Wed, 18 May 1994 09:22:21 +1000 Received: from csn.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19492; Wed, 18 May 1994 08:58:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from murtoa.cs.mu.OZ.AU by csn.org with SMTP id AA14640 (5.67b/IDA-1.5); Tue, 17 May 1994 16:56:10 -0600 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01834; Wed, 18 May 1994 07:51:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01785; Wed, 18 May 1994 07:33:18 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16100; Wed, 18 May 1994 07:16:56 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA04585; Tue, 17 May 94 14:18:41 -0700 Date: Tue, 17 May 94 14:18:41 -0700 From: Eric Fleischman Message-Id: <9405172118.AA04585@atc.boeing.com> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: Thoughts on the IPng situation... Cc: ericf@munnari.OZ.AU Dear Noel, The purpose of this note is to reply to your recent posting. I have come to value your insight into the Internet community's affairs and so it is with a large degree of hesitancy that I find myself disagreeing with important aspects of your latest posting. Specifically, I hope that you consider the following points: I do not think that you understood the dynamics of what the end user was responding to in the following scenario which you described: >I mean, I've just heard about one organization that lost a sale to an IBM APPN >solution because the Internet is running out of address space. This is totally >bogus; no APPN solution is going to be part of a global internetwork *anyway*, >APPN just doesn't have that capability. So, they'd have been just as well off >(from that requirement) with a private IP address space, and at least had an >open, multi-vendor solution. > >The salesperson who made that "IP is running out of space" argument either >didn't understand very much, or didn't care. It's mendacious marketing >bullshit, the world will always be full of lies and marketing bullshit, and >doing good engineering isn't any use in combatting it. The issue the end user was doubtlessly responding to is the widespread perception that to deploy any major NEW deployment of TCP/IP today is short- sighted since such a deployment will be quickly obsoleted by IPng. Thus, for that user to deploy TCP/IP would imply that they will shortly afterwards have to migrate that deployment to IPng. Thus, a TCP/IP deployment means TWO deployments for that user with all of the associated costs and expenses -- with no functionality gain to their business goals. APPN, by contrast, implies one deployment to that user because IBM promises full backwards compatibility from APPN+ to APPN. Similarly, all us end users know that 3270 Data Streams are still viable today despite the fact that IBM tried to kill them off back in the late 1980s via SAA. However, "backwards compatability" won and SAA lost. Thus, a decision to go with APPN is a decision which hopefully carries with it the ensurance that those APPN assets will (at a minimum) be able to fully depreciate before being obsoleted. Ditto for the subsequent argument you made about people preferably choosing NetWare since it also does NOT carry with it any "imminent forced obsolescence". Of course, those of us who have already deployed TCP/IP have a different perspective than that outlined in the previous paragraph -- a perspective which I have more fully detailed in my "Large Users' View of IPng" documents. In our case, we hope to leverage our investment in TCP/IP by emphatically NOT migrating to IPng until business reasons compel us to do so (e.g., unsurpassed performance/functionality in IPng). Thus, IPng is an unattractive, hard sell for us and our probable response to IPng will be to deploy NAT-like application-layer gateways on our firewalls -- and continue buying IPv4. In any case, while I recognize the existence of bigots, most of the so-called anti-TCP/IP people in your note aren't really anti-TCP/IP. They just have other fish to fry than Internet connectivity. That is, while a growing groundswell of people in my company are keenly excited about Internet connectivity, I suspect that a significant percentage of real end users in other corporations are largely unaware of what they are missing by not being connected to the Internet. Thus, they may not even understand why they might want to eventually connect some day. Thus, your reference to APPN/NetWare not providing Internet access may not be viewed by them as a relevant business issue. [Again, this point was well covered in my documents.] >I've been reading about the imminent death of TCP/IP for 10 years, and it's >not going to happen any time soon. The people who are doing the predicting, >and the predictions of what's going to take over have changed, but otherwise >the song remains the same. I talked to some trade-rag writers I know, and >their opinion is that all the users care about is if it works. This stuff >works well, and has a large installed user base to communicate with, and >neither of those is going to change. That's the bottom line, and that's all >most users care about. From the above, you can see that we as a corporation are strategically interested in TCP/IP remaining very viable for many years to come since we have already deployed 80,000 TCP/IP end systems and roughly 450 TCP/IP routers. However, it is my opinion that the Internet community can NOT afford to "bide its time" on making the IPng decision despite my/our selfish interests that make IPng a "hard sell" to us. This is, as toasternet becomes real, the toasternet applications will need a technology which can scale to choose as their infrastructual basis -- and IPv4 demonstrably can't. Thus, they likely will be making business decisions based on your APPN example above (except choosing OSI) just so they won't have to redeploy their infrastructure twice. Let's get real: if TCP/IP-based Internet connectivity is already an impossibility for them from the get-go, then the best they can do is to select the best available alternative technology which MAY be eventually deployed over the Internet. Are you willing to categorically state that OSI won't become widely supported over the Internet if IPng doesn't become real soon? It seems to me that they really have no other option than to choose OSI if they have to choose today -- unless, of course, they have already widely invested in TCP/IP (or some other technology?). What am I saying? I am saying that we aren't doing IPng for Boeing. We aren't doing it for router vendors, researchers or for anybody else within the Internet community today. We are doing IPng for those people NOT in our community today so that they may be able to join us some day. That is, unless TCP/IP can be made to scale (IPng), what large deployment will be willing to deploy TCP/IP unless they can be assured that they won't have their investment quickly obsoleted? But YOU or I can't assure them of that because we know that we must deploy IPng to "save" the Internet (as the number of Internet users continue to approach a critical threshold). Thus, unless we have IPng defined and deployable then they can not choose TCP/IPng and thus must choose the best of the available alternatives: They must choose something that works and scales and is available within THEIR deployment timeframe window. The bottom line issue (in my opinion) is "when will toasternet become real?" Our window for IPng requires that IPng must be deployable BEFORE toasternet arrives. I personally believe we are missing that window. I believe that toasternet is becoming real today (e.g., CDPD, EPRI, Boeing's doors and elevators -- and soon thermostats? -- are TCP/IP devices today, etc.). However, we will need a minimum of 4 years after selecting IPng to make it deployable. Thus, we are a minimum of 4 years out to solve a problem which is beginning to become manifested today. This worries me. I therefore do not share your belief that we can afford to wait in defining a scalable TCP/IP (i.e., IPng). I believe that we can not afford to dilly-dally despite the demonstrably true observation of yours that we have not achieved consensus as a community on the preferable IPng alternative. I believe that we must proceed full speed ahead despite the torpedos. Politics simply must be met by a willingness to compromise on a workable solution. The future of the Internet is at stake. Sincerely yours, --Eric Fleischman BCS Network Architect From owner-Big-Internet@munnari.OZ.AU Wed May 18 10:47:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22060; Wed, 18 May 1994 10:01:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02124; Wed, 18 May 1994 09:32:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02012; Wed, 18 May 1994 09:21:19 +1000 Received: from csn.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19109; Wed, 18 May 1994 08:44:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from murtoa.cs.mu.OZ.AU by csn.org with SMTP id AA11980 (5.67b/IDA-1.5 for big-Internet@munnari.oz.au); Tue, 17 May 1994 16:44:36 -0600 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01819; Wed, 18 May 1994 07:50:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01782; Wed, 18 May 1994 07:32:13 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17742; Wed, 18 May 1994 08:00:37 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA18633; Tue, 17 May 94 16:06:02 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06587; Tue, 17 May 94 14:58:28 PDT Date: Tue, 17 May 94 14:58:28 PDT Message-Id: <9405172158.AB06587@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atkinson@itd.nrl.navy.mil (Ran Atkinson) From: Greg Minshall Subject: Re: IPng security, etc. Cc: big-Internet@munnari.OZ.AU Ran, > It is in fact startling to me that neither TUBA nor CATNIP have any >concrete security proposals since it is so straightforward to do. This is where there has been some disagreement within the IPng directorate, at least. Some of us have the opinion that some things map onto any of the IPng proposals in much the same way. Thus, normally, there seems to be no real reason to go through this mapping N-1 times uselessly. Where i think the mapping should happen up front is where either 1) that proposal is planning on doing that function in a fundamentally different way (CATNIP's multicast, say), or 2) that proposal *needs* that functionality in a more fundamental way (SIPP's desire to "turn around" source routes, say). Greg From owner-Big-Internet@munnari.OZ.AU Wed May 18 10:48:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23183; Wed, 18 May 1994 10:26:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02124; Wed, 18 May 1994 09:32:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02012; Wed, 18 May 1994 09:21:19 +1000 Received: from csn.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19109; Wed, 18 May 1994 08:44:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from murtoa.cs.mu.OZ.AU by csn.org with SMTP id AA11980 (5.67b/IDA-1.5 for big-Internet@munnari.oz.au); Tue, 17 May 1994 16:44:36 -0600 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01819; Wed, 18 May 1994 07:50:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01782; Wed, 18 May 1994 07:32:13 +1000 Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17742; Wed, 18 May 1994 08:00:37 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA18633; Tue, 17 May 94 16:06:02 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06587; Tue, 17 May 94 14:58:28 PDT Date: Tue, 17 May 94 14:58:28 PDT Message-Id: <9405172158.AB06587@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atkinson@itd.nrl.navy.mil (Ran Atkinson) From: Greg Minshall Subject: Re: IPng security, etc. Cc: big-Internet@munnari.oz.au Ran, > It is in fact startling to me that neither TUBA nor CATNIP have any >concrete security proposals since it is so straightforward to do. This is where there has been some disagreement within the IPng directorate, at least. Some of us have the opinion that some things map onto any of the IPng proposals in much the same way. Thus, normally, there seems to be no real reason to go through this mapping N-1 times uselessly. Where i think the mapping should happen up front is where either 1) that proposal is planning on doing that function in a fundamentally different way (CATNIP's multicast, say), or 2) that proposal *needs* that functionality in a more fundamental way (SIPP's desire to "turn around" source routes, say). Greg From owner-Big-Internet@munnari.OZ.AU Wed May 18 11:01:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24174; Wed, 18 May 1994 10:50:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA02267; Wed, 18 May 1994 10:20:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA02261; Wed, 18 May 1994 10:19:40 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23473; Wed, 18 May 1994 10:34:59 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Big-Internet@munnari.OZ.AU Cc: sipp@sunroof2.eng.sun.com Subject: Apologies for the mail loop Date: Wed, 18 May 1994 10:34:57 +1000 Message-Id: <18781.769221297@munnari.OZ.AU> Sender: kre@munnari.OZ.AU We appear to have had a mail loop, with one of the addresses on the Big-Inteernet list sending articles back to the list, and (apparently) to the SIPP list as well. I have deleted what I believe was the bad address on the list, and it won't be coming back. If its any consolation, B-I (and SIPP) haven't been the only lists to suffer from a loop at the same site, as any of you on namedroppers will have seen... kre From owner-Big-Internet@munnari.OZ.AU Wed May 18 12:42:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29251; Wed, 18 May 1994 12:42:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA02408; Wed, 18 May 1994 12:11:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA02401; Wed, 18 May 1994 12:11:18 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24628; Wed, 18 May 1994 11:02:09 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA20488; Tue, 17 May 94 21:01:59 EDT Message-Id: <9405180101.AA20488@tipper.oit.unc.edu> To: "Jon P. Knight" , big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of "Wed, 18 May 94 08:24:28 +1000." <18704.769213468@munnari.OZ.AU> Date: Tue, 17 May 94 21:01:58 -0400 From: Simon E Spero Date: Tue, 17 May 1994 21:03:22 +0100 (BST) From: "Jon P. Knight" Message-ID: Trouble is that as soon as you give them all blank sheets of paper, they come up with different, often mutually incompatible designs for the whole network layer rather than just their little bit. I think blank pieces of paper are maybe a bit too much for the IETF. What would be a better idea would be for The Great Architect of the Internet (i.e. Dave Clark or Noel) to sketch a line drawing, and then hand that out to the working groups for them to colour in. There could be big thick lines like "can be routed", "more hosts than you can shake a stick at", and "can transition to from IPV4". Then there could be slightly thinner lines like "guaranteed bandwidth and latency", "scalable multicasting", "supports accounting and charging", and "works on gigabit and faster networks". The groups could then sit down with their pencils, and then colour in between the lines. At the end, the playgroup leader Great Architect could look at all the pictures, and then decide which one is the prettiest. Everybody then gets together to work on the chosen picture, so it finishes up as a class project. After that, everybody gets a gold star (Joyce has a large stock of gold stars, so this shouldn't be a problem). Simon // but who gets to be milk monitor? ---- Available for hire after July 31st | ses@unc.edu ------------------------------------------------------------------------------- -I have heard the routers pinging, IS to IS. | Tel: +1-919-962-9107, I do not think that they will ping to me - | Fax: +1-919-962-5604 From owner-Big-Internet@munnari.OZ.AU Wed May 18 17:11:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10879; Wed, 18 May 1994 17:11:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA02459; Wed, 18 May 1994 16:42:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA02456; Wed, 18 May 1994 16:36:45 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10676; Wed, 18 May 1994 17:05:00 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405180705.10676@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 18 May 1994 08:04:29 +0100 To: Simon E Spero Cc: "Jon P. Knight" , big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of "Tue, 17 May 94 21:01:58 EDT." <9405180101.AA20488@tipper.oit.unc.edu> Date: Wed, 18 May 94 08:04:22 +0100 From: Jon Crowcroft >Great Architect could look at all the pictures i think it took dave clark tl 1991 to write the requirements spec of ipv4 i'm quite happy if we desing ipng now, and he (or someone) writes the requirements in 2016, just as the net hits 8 billion end systems... jon From owner-Big-Internet@munnari.OZ.AU Wed May 18 19:33:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16694; Wed, 18 May 1994 19:33:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA02484; Wed, 18 May 1994 19:02:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA02481; Wed, 18 May 1994 18:51:53 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12370; Wed, 18 May 1994 17:52:09 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA04586; Wed, 18 May 94 00:51:52 PDT Received: from jurassic.Eng.Sun.COM (jurassic-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA03120; Wed, 18 May 94 00:51:50 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA29597; Wed, 18 May 1994 00:51:47 -0700 Date: Wed, 18 May 1994 00:51:47 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9405180751.AA29597@jurassic.Eng.Sun.COM> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9405171401.AA23625@ginger.lcs.mit.edu> Subject: Re: Requirements (was : FORMAL REQUEST : SIPP EIDs and Locators) Noel, > My perception is that it is unlikely that we will develop a rough consensus > around one of the designs, as is. The question thus is: what's the most I think you are wrong. I have a lot of faith in the IETF process to do the right thing. I think there will be a rough consensus on an IPng in July. In some ways I don't think the current proposals are that far apart. Bob From owner-Big-Internet@munnari.OZ.AU Thu May 19 00:32:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27152; Thu, 19 May 1994 00:32:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02535; Thu, 19 May 1994 00:02:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA02532; Wed, 18 May 1994 23:55:46 +1000 From: BillDupont@aol.com Received: from mail02.prod.aol.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26936; Thu, 19 May 1994 00:24:04 +1000 (from BillDupont@aol.com) Received: by mail02.prod.aol.net (1.38.193.5/16.2) id AA09235; Wed, 18 May 1994 10:24:01 -0400 X-Mailer: America Online Mailer Sender: "BillDupont" Message-Id: <9405181024.tn236497@aol.com> To: big-internet@munnari.OZ.AU Date: Wed, 18 May 94 10:24:00 EDT Subject: Unsubscribe UNSUBSCRIBE billdupont@aol.com From owner-Big-Internet@munnari.OZ.AU Thu May 19 00:35:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26534; Thu, 19 May 1994 00:12:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA02516; Wed, 18 May 1994 23:42:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA02513; Wed, 18 May 1994 23:35:47 +1000 Received: from xap.xyplex.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26382; Thu, 19 May 1994 00:04:06 +1000 (from milan@mjm.xyplex.com) Received: from mjm.xyplex.com by xap.xyplex.com id ; Wed, 18 May 94 09:49:01 -0500 Received: by xyplex.com (4.1/SMI-4.1) id AA22825; Wed, 18 May 94 10:05:32 EDT Date: Wed, 18 May 94 10:05:32 EDT From: milan@mjm.xyplex.com (Milan Merhar) Message-Id: <9405181405.AA22825@xyplex.com> To: big-internet@munnari.OZ.AU In-Reply-To: Greg Minshall's message of Tue, 17 May 94 14:12:35 PDT <9405172112.AA06513@WC.Novell.COM> Subject: IEEE 802 not unique enough??? Sad to say, IEEE 802 addresses, even if obtained from an "official" source, can't be considered "globally" unique if the possibility exists that an organization's network may be attached in multiple places to the external network. The current practice of some vendors is to use the same 802 address on each interface of multi-interface devices, on the theory that they are attached to "different networks" and therefore isolated. If these networks should find themselves attached to the same external realm, the duplicated addresses may both be visible to an external observer. This is of course a common issue with DECnet routers, which use the same "locally administered" address on each interface. Lately, I've heard of devices that do the same thing but with "globally administered" (i.e. second bit cleared) 802 addresses. A similar condition may occur during flooding with any MAC-layer bridge. It will propagate all the MAC addresses from "over there" to appear to be "over here". This is good, unless (again) there is some observer that can see both networks at the same time. So, how many added bits are need to make 802 addresses acceptable? What implementation rules are necessary to insure that they remain unique? (In other words, how do we define "unique"?) Can we set up the necessary (probably hierachical) prefix assignment mechanism without setting ourselves up for another round of "running out of addresses" in the future? By the way, I understand from some folks that are IEEE regulars that they have a defacto prohibition on any scheme that requires the creation and management of ANOTHER set of globally unique numbers; one is enough trouble to manage for them, I guess... Milan J. Merhar, Xyplex, Inc. 295 Foster St. Littleton, MA 01460 USA Internet: milan@xyplex.com Phone:(508)952-4713 Fax:(508)952-4887 From owner-Big-Internet@munnari.OZ.AU Thu May 19 01:13:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28970; Thu, 19 May 1994 01:13:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02643; Thu, 19 May 1994 00:42:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02640; Thu, 19 May 1994 00:33:35 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28558; Thu, 19 May 1994 01:01:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00882; Wed, 18 May 94 11:01:56 -0400 Date: Wed, 18 May 94 11:01:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405181501.AA00882@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, milan@mjm.xyplex.com Subject: Re: IEEE 802 not unique enough??? Cc: jnc@ginger.lcs.mit.edu From: milan@mjm.xyplex.com (Milan Merhar) IEEE 802 addresses ... can't be considered "globally" unique if the possibility exists that an organization's network may be attached in multiple places to the external network. ... some vendors is to use the same 802 address on each interface of multi-interface devices This is not a problem. If used as parts of locators, they will be prefixed, and made unique, by the locator of the network. If they are used to create an EID, the IED refers to the machine, not the interface, so agains you're OK. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 19 01:32:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB29833; Thu, 19 May 1994 01:32:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA02665; Thu, 19 May 1994 01:02:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02659; Thu, 19 May 1994 00:45:06 +1000 From: root@estbc8.estec.esa.nl Received: from bcserver.estec.esa.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28973; Thu, 19 May 1994 01:13:15 +1000 (from root@estbc8.estec.esa.nl) Received: from estbc8.estec.esa.nl by bcserver.estec.esa.nl (AIX 3.2/UCB 5.64/4.03) id AA16994; Wed, 18 May 1994 17:12:39 +0100 Received: by estbc8.estec.esa.nl (AIX 3.2/UCB 5.64/4.03) id AA13220; Wed, 18 May 1994 17:11:44 +0200 Date: Wed, 18 May 1994 17:11:44 +0200 Message-Id: <9405181511.AA13220@estbc8.estec.esa.nl> To: big-internet@munnari.OZ.AU Subject: Unsubscribe Unsubscribe root@estbc8.estec.esa.nl From owner-Big-Internet@munnari.OZ.AU Thu May 19 01:34:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29870; Thu, 19 May 1994 01:34:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA02680; Thu, 19 May 1994 01:05:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02662; Thu, 19 May 1994 00:57:29 +1000 Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29496; Thu, 19 May 1994 01:25:54 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA27176; Wed, 18 May 94 11:25:45 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA08230; Wed, 18 May 94 11:22:28 EDT Date: Wed, 18 May 94 11:22:28 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9405181522.AA08230@pobox.wellfleet> To: Greg_Minshall@Novell.COM Subject: Re: continuing EID discussion Cc: big-internet@munnari.OZ.AU Only end nodes care about EID. So, it isn't *as much* of a performance issue as, possibly, a bandwidth issue. This is only precisely true if the locator gets you to the destination host. If the locator gets you only to the destination subnet, or to the destination area, or to the last-hop router (or switch, as in ATM), then the last router (or every router in the destination area) will need to look at the EID. On the other hand this does not seem to be a problem, since 64 bits should be enough for a global EID (even if it is not enough for the entire address), and looking at 64 bits is not going to be a significant problem for routers (at least, is trivial compared to other things that routers have to do quickly). Ross From owner-Big-Internet@munnari.OZ.AU Thu May 19 02:20:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28189; Thu, 19 May 1994 00:52:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02609; Thu, 19 May 1994 00:22:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02554; Thu, 19 May 1994 00:07:17 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27352; Thu, 19 May 1994 00:35:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00645; Wed, 18 May 94 10:34:33 -0400 Date: Wed, 18 May 94 10:34:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405181434.AA00645@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu From: Jon Crowcroft i think it took dave clark tl 1991 to write the requirements spec of ipv4 i'm quite happy if we desing ipng now, and he (or someone) writes the requirements in 2016, just as the net hits 8 billion end systems... It may not have gotten written down until later, but the underlying architectural model, with fate-sharing and all that, existed much earlier; I have old slide presentations from the late 70's with fatesharing in them. I see no such coherent architectural model for our new, extended functionality internetwork layer. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 19 02:24:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28224; Thu, 19 May 1994 00:54:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02624; Thu, 19 May 1994 00:24:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02551; Thu, 19 May 1994 00:04:58 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27192; Thu, 19 May 1994 00:33:23 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14539(4)>; Wed, 18 May 1994 07:32:59 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 18 May 1994 07:32:50 -0700 To: milan@mjm.xyplex.com (Milan Merhar) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: IEEE 802 not unique enough??? In-Reply-To: milan's message of Wed, 18 May 94 07:05:32 -0800. <9405181405.AA22825@xyplex.com> Date: Wed, 18 May 1994 07:32:35 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94May18.073250pdt.12171@skylark.parc.xerox.com> > The current practice of some vendors is to use the same > 802 address on each interface of multi-interface devices, > on the theory that they are attached to "different networks" > and therefore isolated. If these networks should find themselves > attached to the same external realm, the duplicated addresses > may both be visible to an external observer. Milan, That practice does not violate global-uniqueness of the 802 address as an identifier for the *device*; it does violate global-uniqueness of the 802 address as an identifier for an *interface*. For the purposes being discussed here, unique *device* (i.e., host or node) identification is what is desired. Steve From owner-Big-Internet@munnari.OZ.AU Thu May 19 03:52:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05158; Thu, 19 May 1994 03:52:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02761; Thu, 19 May 1994 03:22:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02758; Thu, 19 May 1994 03:18:34 +1000 Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05002; Thu, 19 May 1994 03:46:57 +1000 (from estrin@ISI.EDU) Received: from josh.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 18 May 1994 10:45:49 -0700 Date: Wed, 18 May 1994 10:48:37 -0700 Posted-Date: Wed, 18 May 1994 10:48:37 -0700 Message-Id: <199405181748.AA00789@josh.isi.edu> Received: by josh.isi.edu (5.65c/4.0.3-4) id ; Wed, 18 May 1994 10:48:37 -0700 From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: big-internet@munnari.OZ.AU Subject: [tli@cisco.com: Another flow question.] Reply-To: estrin@usc.edu Tony said that he thought it most important to aggregate at the leaves... but the leaves might have the most need to manage flows individually and to apply specific policy constraints. whereas the center of the net would rather tradeoff less state for maybe a bit more bw usage and more generic controls I sent this response to him privately and he responded with the following: "True. So the aggregator reserves sufficient bandwidth for the aggregate of all flows, possibly adjusting to match the aggregate... If the new policy constraints fall outside of the aggregated flow, well, that's life, it gets set up separately. Tony From owner-Big-Internet@munnari.OZ.AU Thu May 19 04:12:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05847; Thu, 19 May 1994 04:12:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02780; Thu, 19 May 1994 03:42:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02777; Thu, 19 May 1994 03:30:06 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05446; Thu, 19 May 1994 03:58:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02271; Wed, 18 May 94 13:58:26 -0400 Date: Wed, 18 May 94 13:58:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405181758.AA02271@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, van@ee.lbl.gov Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu > I do not believe the Internet needs a new internet-layer architecture. I can't add anything to Steve Deering's eloquent message except to say I completely, 100% agree with everything he said We're going to get a new (i.e. revised) architecture, as the services provided by the internetwork layer get upgraded (requiring storage of state about traffic streams in the network, etc). The only question this community gets to answer is "do we do this in a planned way, or not?" When you have a number of different teams working on radically upgrading the functionality (i.e external interface) of a large program, there are two ways to go. i) You can have a rethink of the structure of the program, so that all the new pieces are fitted in cleanly. ii) You can just add them piecemeal, making local changes to tack them on. We all know what happens when you take path ii); you get a disorganized, complex, unreliable, hard-to-modify, inflexible, mess. Exactly the same thing is true of a large, distributed system; i.e. the internetwork layer. As we upgrade the functionality, we are *by definition* going to get a new architecture. Anyone who thinks otherwise is deceiving themselves. All we get to decide is whether we do it by accident, or by design. One touchstone in this effort is to achieve a sort of orthoganality between different mechanisms so that each has a clear idea of what is and is not "its job". It's ironic you should mention this (it's a principle I deeply agree with), since I think SIPP violates this a lot, in ways that bother me. E.g., the use of the ASEQ for both extended addresses and source routes... but I digress. There have endless discussions about how some piece of new machinery overlapped the role of some other piece of new machinery ... These discussions *are* the process of design -- they're how we arrive at new pieces that are orthogonal & complementary to the existing pieces. Now I really feel like I've fallen through the hole into Wonderland. This process of trying to figure out what the functional units should be, and how they interact, is *precisely* "defining the architecture". In the process you mention, you're doing nothing more than trying to define a clean architecture; i.e. exactly what I'm arguing for. But, if you look back through all these megabytes of discussion, you might notice that there was no conflict between the new machinery and IP. IP is architecturally very clear about its job, and, partly by extremely good design, partly by accident of history, provided exactly the services and information we needed and didn't need to be warped at all. I don't see that. For example, there are a number of places where the interaction between RSVP and the routing is not what it could be; the route pinning issue is an example. If what you mean is there is no conflict between these new mechanisms and the fundamental idea of IP, which is that the internetwork layer provides unreliable, end-end packet service, I agree, but nobdoy is talking about changing that aspect of IP. In fact, IP does a rather difficult job so clearly and simply and elegantly I see an interesting analogy here between IP and Unix. Unix Version 6 was a thing of beauty; an incredible amount of power, very clearly, simply and elegantly done. Unfortunately, it didn't have quite the functionality people needed, so they set out to "improve" it (without feeling that the basic model was wrong). When the process was completed, we had a system which could not be described as clear and elegant. The reasons are not hard to find; in large part because the changes were added in piecemeal fashion, without sitting back and reorganizing the system. If we proceed to upgrade the internetwork layer in a similar piecemeal fashion, as we are trying hard to do, we're going to wind up with the same situation. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 19 04:32:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06720; Thu, 19 May 1994 04:32:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA02799; Thu, 19 May 1994 04:02:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02796; Thu, 19 May 1994 03:45:50 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05875; Thu, 19 May 1994 04:14:12 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02421; Wed, 18 May 94 14:14:10 -0400 Date: Wed, 18 May 94 14:14:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405181814.AA02421@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, jcurran@nic.near.net Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu From: John Curran I will defer to your and Steve's judgement on this... Deferring to the experts is not a realistic option here. I don't recall exactly Dave Clark's remarks at the IPng Requirement BoF, but I don't think they agreed with Van and Steve's position here. (I'll let Dave state his exact position, but his position that day was taken in an open forum...) So, you've got Chiappa and Clark (among others) on one side, and Deering and Jacobsen (among others) on the other. Everybody out there is going to have to listen to both sides of this, and make up their own mind. It's possible that the IP architecture provides all of the "architecture" that we really need, and all of the capabilities being discussed will settle in a small number of orthogonal & complementary pieces. Not from my perception, at least not in a clean and flexible way. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 19 04:40:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00643; Thu, 19 May 1994 01:52:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA02701; Thu, 19 May 1994 01:22:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02696; Thu, 19 May 1994 01:09:29 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29958; Thu, 19 May 1994 01:37:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01187; Wed, 18 May 94 11:37:52 -0400 Date: Wed, 18 May 94 11:37:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405181537.AA01187@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, ericf@atc.boeing.com Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu From: Eric Fleischman I am sure that everyone involved would agree that requirements should guide the approaches ... one of the most vexacious aspects of IPng from the start was deciding whether IPng should be an incremental step or a major advance in technology. I'm particularly incensed at the way we sort of drifted into assuming we were going to have a new packet format. As near as I can tell, this came about when some CLNP backers saw in the 32-bit limitation a way to get CLNP adopted, and people who didn't like CLNP went off to do alternatives. Hardly a rational plan for the best evolution path... I believe that the IPng process is the best the community can do since we lack -- and have consistently lacked -- a consensus on the even most basic questions. You've just outlined a recipe for disaster. You think we're going to agree on the answer when we can't even agree on the question? And we have been unable to form a consensus despite many heroic and vexacious efforts. I think the situation is improving; there has been some progress over the last two years. I find a much greater level of sophistication in the community at large over some of these technical issues. We are making progress, albeit painfully, but this is not surprising in a community as large and diverse as the IETF has become. I concur that market environment compells us to select the IPng soon -- before an "ideal" candidate can be identified and built. In other words, it's a political decision, not a technical one. So, don't be surprised if and when, measured on technical axes, the result turns out to be a loser. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 19 04:55:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03664; Thu, 19 May 1994 03:12:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA02723; Thu, 19 May 1994 02:42:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02720; Thu, 19 May 1994 02:25:46 +1000 Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03012; Thu, 19 May 1994 02:54:03 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27547; Wed, 18 May 94 12:53:54 EDT Date: Wed, 18 May 94 12:53:54 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9405181653.AA27547@itd.nrl.navy.mil> To: big-Internet@munnari.OZ.AU Subject: IEEE 802 addresses Cc: sipp@sunroof2.eng.sun.com Note that the implicit assumption of some folks that a single box is the level of granularity for identification is invalid. Counter examples include all commercially available multi-level secure (sic) workstations (e.g. Sun CMW). MLS systems will need to have multiple EIDs, probably about 1 per vertical sensitivity level, even though they might only have a single Ethernet interface. 802 addresses have other problems cited at length by me and others earlier, this is Yet Another Counterexample. Ran atkinson@itd.nrl.navy.mil PS Please edit the headers appropriately if you reply to this note. From owner-Big-Internet@munnari.OZ.AU Thu May 19 05:00:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04380; Thu, 19 May 1994 03:32:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02742; Thu, 19 May 1994 03:02:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02739; Thu, 19 May 1994 02:55:44 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04079; Thu, 19 May 1994 03:24:05 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Big-Internet@munnari.OZ.AU Subject: Admin: Unsubscribing from lists Date: Thu, 19 May 1994 03:24:02 +1000 Message-Id: <18940.769281842@munnari.OZ.AU> Sender: kre@munnari.OZ.AU I know that 99% of you reading this know this already, but two half-brains in the space of a couple of hours is just too much. You simply CANNOT get unsubscribed by sending to Big-Internet@munnari.oz.au - all you will ever achieve by that is to bother everyone else on the list, and just possibly have every message on the list sent to you twice or more.... The correct way to unsubscribe is specified, quite clearly, in the message that everyone gets when they join the list (no-none has any excuse for not knowing the method). Further to join the list in the first place you had to know the correct method of sending administrative messages. The right way is to send to Big-Internet-Request@munnari.OZ.AU This is a standard internet convention for mailing lists, you should always try that first, another possibility is to use listserv@host - its never correct to send to the list itself. Nor is it correct to reply to messages on the list and ask to be removed - that will almost always send to the wrong address, always compose a new message from scratch. kre From owner-Big-Internet@munnari.OZ.AU Thu May 19 06:25:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07564; Thu, 19 May 1994 04:52:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA02818; Thu, 19 May 1994 04:22:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA02815; Thu, 19 May 1994 04:21:59 +1000 Received: from hp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04250; Thu, 19 May 1994 03:28:41 +1000 (from scanlan@waterloo.hp.com) Received: from hppadan.waterloo.hp.com by hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA08562; Wed, 18 May 1994 10:27:31 -0700 Received: by hppadan.waterloo.hp.com (1.37.109.4/15.5+IOS 3.22) id AA02746; Wed, 18 May 94 13:27:08 -0400 From: "Bruce D. Scanlan" Message-Id: <9405181727.AA02746@hppadan.waterloo.hp.com> Subject: unsubscribe To: big-internet@munnari.OZ.AU Date: Wed, 18 May 1994 13:27:07 EDT X-Mailer: Elm [revision: 109.13h] unsubscribe scanlan@waterloo.hp.com From owner-Big-Internet@munnari.OZ.AU Thu May 19 06:25:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08273; Thu, 19 May 1994 05:13:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA02840; Thu, 19 May 1994 04:42:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA02834; Thu, 19 May 1994 04:34:29 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07902; Thu, 19 May 1994 05:02:54 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA10538; Wed, 18 May 94 12:04:39 -0700 Date: Wed, 18 May 94 12:04:39 -0700 From: Eric Fleischman Message-Id: <9405181904.AA10538@atc.boeing.com> To: big-internet@munnari.OZ.AU, ericf@atc.boeing.com, jnc@ginger.lcs.mit.edu Subject: Re: Thoughts on the IPng situation... > I concur that market environment compells us to select the IPng soon -- > before an "ideal" candidate can be identified and built. > >In other words, it's a political decision, not a technical one. So, don't be >surprised if and when, measured on technical axes, the result turns out to be >a loser. > > Noel I actually think that the IPng Decision is an engineering decision as opposed to a political or technical decision. That is, basic engineering (as I understand it) is how to design the best solution to resolve a real world problem given constraints. This is different from deciding to do something due to "the boss' desires" or "majority rules" and it is different from proposing the absolutely best design had we been in a constraintless environment. Of course, the best process approach is to agree on the requirements and goals up front. We did not adequately do that. Thus, our task is to compensate for this inherent process weakness to the fullest extent possible and still satisfy the recently formed rough-consensus goals within the constraints. I wish that I could claim that I had never before been involved in such a "contrary" design process. However, such a claim would be less than honest. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Thu May 19 06:26:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08854; Thu, 19 May 1994 05:33:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA02874; Thu, 19 May 1994 05:02:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA02871; Thu, 19 May 1994 04:55:38 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08522; Thu, 19 May 1994 05:23:42 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14682(8)>; Wed, 18 May 1994 12:23:19 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 18 May 1994 12:23:09 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Thoughts on the IPng situation... In-Reply-To: jnc's message of Wed, 18 May 94 11:14:10 -0800. <9405181814.AA02421@ginger.lcs.mit.edu> Date: Wed, 18 May 1994 12:23:05 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94May18.122309pdt.12171@skylark.parc.xerox.com> Noel, It's rather a leap from: > I don't recall exactly Dave Clark's remarks at the IPng Requirement BoF, > but I don't think they agreed with Van and Steve's position here. to: > So, you've got Chiappa and Clark (among others) on one side, ... Disagreement with Van or me does not necessarily imply agreement with you. If you want to play that game, I could observe that Dave is a member of the IPng Directorate and "I don't recall exactly" but I don't think he has ever suggested that the ADs' timetable for choosing an IPng should be scrapped. I suggest that you follow your own advice: > (I'll let Dave state his exact position, ... before concluding what that position is. > Everybody out there is going to have to listen to both sides of this, > and make up their own mind. This I agree with, except for the polarizing implication that there are only two sides. Steve From owner-Big-Internet@munnari.OZ.AU Thu May 19 06:26:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08380; Thu, 19 May 1994 05:17:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA02855; Thu, 19 May 1994 04:47:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA02837; Thu, 19 May 1994 04:35:23 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03424; Thu, 19 May 1994 03:06:56 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14670(5)>; Wed, 18 May 1994 10:06:30 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 18 May 1994 10:06:20 -0700 To: big-internet@munnari.OZ.AU Cc: deering@parc.xerox.com Subject: serverless autoconfiguration of host addresses Date: Wed, 18 May 1994 10:06:07 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94May18.100620pdt.12171@skylark.parc.xerox.com> I'd like to hear peoples' opinions about the value and/or hazards of serverless autoconfiguration. By "serverless autoconfiguration", I am referring to the mechanism available in IPX or CLNP/ES-IS for a host to automatically generate a globally-unique internet address for itself by appending its own IEEE 802/Ethernet address to a network or area prefix that is obtained by listening to multicast or broadcast messages from neighboring routers. I am *not* referring to the scheme used by Appletalk on LocalTalk LANs, in which a host generates a random host number for itself and then broadcasts a query on the LAN to find out if that number is already in use -- the hazards of that scheme are well understood. I use the qualifier "serverless" to distinguish the IPX or CLNP/ES-IS style of autoconfiguration from the use of a server like a BOOTP or DHCP server to configure a host's address I was surprised to come across the internet draft by Dave Katz (draft-ietf- tuba-addr-assign-00.txt), proposing a mechanism for *preventing* serverless autoconfig of CLNP/TUBA systems, that is, requiring them to get their addresses from a server. (He proposes that the choice of server-based vs. serverless autoconfig be a local administrative decision.) This suggests that there is a demand in some environments for greater adminstrative control over address acquisition by hosts; Dave gives a couple of possible reasons in his draft. For SIP (before it became SIPP), we proposed an approach in which a host could autoconfigure a "local-use" address for itself without the aid of a server. The local-use address was a 64-bit address containing a 48-bit host ID field (i.e., big enough to hold an IEEE 802 address) plus a 12-bit subnet ID (learnable by listening to Router Advertisements). It was intended to allow communication only among a set of subnets belonging to a single site or organization. In order to communicate outside that set of subnets, a host would have to obtain a globally-routable 64-bit address, either by manual configuration or by querying a server, such as a DHCP server. The globally- routable addresses would be administered the same way IPv4 address are administered now, e.g., for every host that required global communication, an administrator or a DHCP-style address allocation algorithm would have to assign it a globally-unique, hierarchical address with a smallish (i.e., much shorter than 48-bits) host ID part. After SIP became SIPP, an alternative approach became possible, in which a host could autoconfigure a globally unique address *sequence* for itself, by appending its autoconfigured local-use address to a globally-routable 64-bit cluster address that identified the site and that was learnable by listening to Router Advertisements. Under this approach, hosts would end up using 128-bit addresses (two 64-bit components) for all off-site communication, and those addresses would be autoconfigured without the aid of a server. Now, I was particularly fond of the SIP (with one "P") approach in that it seemed to have just the right balance between plug-and-play and administrative control: a host installed within a site, organization, or household could come up and communicate with other hosts in the same site/org/house without any administrative address assignment, but in order to communicate with the outside world, there was an administrative step to go through (either manual address assignment or querying a server to get an address, where the server could enforce administrative controls over global address assignment). That seemed a good match to one of the security concerns of most organizations (only "trusted", well-managed hosts should be allowed to talk to the outside world) and the anticipated concerns of household internets (not every appliance, control, and meter should necessarily be accessible from the outside world). To prevent delivery of traffic between the outside world and unauthorized hosts, the site-boundary routers would be expected to filter out packets containing local-use addresses in either the SIP header or the optional SIP Source Route header. Anyway, I'd like to hear what other people think. In particular, I'd like to know whether you think serverless autoconfiguration of globally-routable host addresses is: - an essential capability - nice to have as an option - something you could live without - something too insecure to allow - something else If you have an opinion, it would be particularly helpful if you could respond today (that is "today", local time, whatever your timezone might be), because this topic will be up for discussion at an IPng Directorate meeting tomorrow ("tomorrow", Chicago time). Thanks, Steve From owner-Big-Internet@munnari.OZ.AU Thu May 19 06:53:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11771; Thu, 19 May 1994 06:53:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA02898; Thu, 19 May 1994 06:22:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA02895; Thu, 19 May 1994 06:20:58 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11582; Thu, 19 May 1994 06:49:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03539; Wed, 18 May 94 16:49:16 -0400 Date: Wed, 18 May 94 16:49:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405182049.AA03539@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu From: Steve Deering I could observe that Dave is a member of the IPng Directorate and "I don't recall exactly" but I don't think he has ever suggested that the ADs' timetable for choosing an IPng should be scrapped. Did you ever ask him what his position was on the question of whether now is a good time to chose and IPng, or if he likes any of the choices? I mentioned his comments at the IPng Requirement BoF since someone reminded me about them this morning; my memory of what he said was really hazy, but the person who reminded me, and I, both recall that he did talk directly about the question of a new architectural vision for the internetworking layer. > Everybody out there is going to have to listen to both sides of this, > and make up their own mind. This I agree with, except for the polarizing implication that there are only two sides. Well, the IPng question as a whole has about 17 different factions, yes. I'm talking specifically about the issue of whether or not we need to plan a new (or updated, or revised, or whatever term you want) architecture for the internetwork level, as opposed to have one grow by happenstance as we add functionality. There are obviously subtle variations there too, but you, after all, were the one who said we didn't need a new architecture, whereas I think we do; sounds pretty binary to me. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 19 07:40:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12386; Thu, 19 May 1994 07:13:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA02920; Thu, 19 May 1994 06:43:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA02900; Thu, 19 May 1994 06:23:06 +1000 Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29656; Thu, 19 May 1994 01:29:38 +1000 (from ihanson@pcs.dec.com) Received: from cssec4.pcs.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA28197; Wed, 18 May 94 08:21:05 -0700 Received: by cssec4.pcs.dec.com (5.57/jmh-inet-gw-v1.05); id AA08915; Wed, 18 May 94 17:20:47 +0200 Message-Id: <9405181520.AA08915@cssec4.pcs.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com, ihanson@cssec4.pcs.dec.com Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of "Tue, 17 May 94 08:56:47 EDT." <9405171256.AA23271@ginger.lcs.mit.edu> Date: Wed, 18 May 94 17:20:47 +0200 From: "Iain K. Hanson" X-Mts: smtp jnc@ginger.lcs.mit.edu (Noel Chiappa) wrote: >I believe we need a new architecture for two reasons. I find myself torn between the devil and the deep blue sea. I can see the reasons why a new architecture would be attractive. However, I personally do not beleive that there is time for that in this IPng process for two reasons. 1) I beleive that toaster net, if not already here, will arrive real soon now. For instance, in the United Kinkdom, thew BBC has become an Internet provider. If they start to strongly market this service then the growth in home use of the Internet could easily vector. Also, the Cable TV companies, in addition to becoming PTTs ( telcos ) are talking of providing interactive games playing. 2) I also believe that it is likely that there are users who are installing NATs in preference to the possibliity of having non-contigous class C addresses. If users lives are in any way affected detrimentally as a result of the depletion of IPv4 address space then IMO this represents an effective 'denial of service' >If that really were the only problem we could fix it with an "address >extension" option, and with a somewhat easier transition strategy. Perhaps I am being naive Is this a realistic option? Then follow it with a new architecture ? /ikh From owner-Big-Internet@munnari.OZ.AU Thu May 19 07:40:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12926; Thu, 19 May 1994 07:33:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA02958; Thu, 19 May 1994 07:03:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA02922; Thu, 19 May 1994 06:42:59 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12207; Thu, 19 May 1994 07:11:23 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA04460; Wed, 18 May 94 14:00:39 -0700 Received: by xirtlu.zk3.dec.com; id AA20788; Wed, 18 May 1994 17:00:34 -0400 Message-Id: <9405182100.AA20788@xirtlu.zk3.dec.com> To: Steve Deering Cc: big-internet@munnari.OZ.AU Subject: Re: serverless autoconfiguration of host addresses In-Reply-To: Your message of "Wed, 18 May 94 10:06:07 PDT." <94May18.100620pdt.12171@skylark.parc.xerox.com> Date: Wed, 18 May 94 17:00:28 -0400 X-Mts: smtp Steve, I pretty much concur with Sue Thomson's SIPP Autoconfig draft. But to answer your question: I think its fine to autoconfigure a local use EID. I think global unqiue EIDs and/or locators should be retrieved from a server. Once we have the time to spend on re-architecting the routing paradigm beyond IPv4 then I think we may be able to do this realistically not without a server but with a new distributed network services model. I have serveral ideas I am thinking of that are too premature to share but none of them would work without EIDs and Locators. So for now instead of forcing autoconfiguration into stone in a serverless environment, let the it be done with servers so the technology is more extensible for now. I think Sue has done this in her draft IMHO. /jim /jim From owner-Big-Internet@munnari.OZ.AU Thu May 19 07:40:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12471; Thu, 19 May 1994 07:16:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA02938; Thu, 19 May 1994 06:45:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA02917; Thu, 19 May 1994 06:31:50 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11879; Thu, 19 May 1994 07:00:08 +1000 (from kre@munnari.OZ.AU) To: Steve Deering Cc: big-internet@munnari.OZ.AU Subject: Re: serverless autoconfiguration of host addresses In-Reply-To: Your message of "Wed, 18 May 1994 10:06:07 PDT." <94May18.100620pdt.12171@skylark.parc.xerox.com> Date: Thu, 19 May 1994 07:00:06 +1000 Message-Id: <18974.769294806@munnari.OZ.AU> From: Robert Elz Date: Wed, 18 May 1994 10:06:07 PDT From: Steve Deering Message-ID: <94May18.100620pdt.12171@skylark.parc.xerox.com> In particular, I'd like to know whether you think serverless autoconfiguration of globally-routable host addresses is: - an essential capability Yes (probably) - nice to have as an option Yes - something you could live without Yes - something too insecure to allow Yes - something else All of the above. Its clearly nice for many uses that full auto-config be possible, in many applications that will avoid all kinds of problems, assuming automatic DNS registration goes along with it of course. I'm not certain that an automatic server wouldn't work just as well, but I'm also not sure how to handle the hard cases with a server - server could still avoid all manual configuration, but somehow the server has to know to run at all, and cope with partitioned nets, etc. Servers would probably need to be replicated, with all of those problems. Probably serverless is safe way to go. But its also certain that I don't want a bar of any kind of automatic configuration, serverless or using a server. So while it would be nice to have, it has to be as an option. I can certainly live without it. Its certainly too insecure for me to allow, its also too inconvenient - on a net that's managed, with systems positioned so as to balance load, etc, I want to make sure its impossible for a random user to plug in a system and have it work, they can cause way too much disruption to the (local) net by doing that. If they have to consult the people who run the local net for any reason at all (getting an address is a very fundamental need) then the planners get to decide how the system should be connected so as to fit best. On the other hand, other nets aren't managed at all, there is no-one who cares, nor often any need to care, and no-one with any idea what this numeric magic is, nor why its needed. They just want he thing to work - in those environments autoconfig is clearly a win. I don't see much advantage going half way - eith the autoconfig doesn't happen at all, or it does everything that's necessary. Doing half of it is the worst of both worlds. kre From owner-Big-Internet@munnari.OZ.AU Thu May 19 08:13:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14725; Thu, 19 May 1994 08:13:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA02997; Thu, 19 May 1994 07:43:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA02994; Thu, 19 May 1994 07:37:59 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07309; Thu, 19 May 1994 04:48:37 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA27434; Wed, 18 May 1994 11:48:27 -0700 Message-Id: <199405181848.LAA27434@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, van@ee.lbl.gov Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: Thoughts on the IPng situation... Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 18 May 94 13:58:26 -0400. <9405181758.AA02271@ginger.lcs.mit.edu> Date: Wed, 18 May 94 11:48:27 -0700 From: Dave Crocker X-Mts: smtp Folks, Some might say that all this diversity in discussion is evidence that we have no consensus. It occurs to me that the real problem is that we continue to run this effort in a fashion that is different than the way we run working groups. We know how to run working groups: we have a chair, whose job it is to make sure that the group functions in a fashion that balances open and fair discussion against the need to make forward progress. (And the wg, itself, provides feedback to the chair to keep them in line.) The problem with trying to make forward progress is that whoever loses a particular battle -- and this is true of ALL of us -- has a tendency to try to re-fight the battle. Even with a good wg chair, we've all seen some people continue to rehash material, often in the disguise of a challenge to the fairness or competence of the process. Ultimately, we as a community need to decide whether we are going to make the IPng process succeed or whether we are going to let the various factions make it fail. The issue is not whether anyone is nefarious -- in fact part of the problem is that I don't think we can dismiss any of us who are contentious and vocal for lack of conviction -- but rather that we have a need to make forward progress. We are roughly two months from decision time, folks. Do we want this to succeed? ---- Included message: When you have a number of different teams working on radically upgrading th e functionality (i.e external interface) of a large program, there are two wa ys to go. i) You can have a rethink of the structure of the program, so that a ll the new pieces are fitted in cleanly. ii) You can just add them piecemeal, making local changes to tack them on. We all know what happens when you tak e path ii); you get a disorganized, complex, unreliable, hard-to-modify, inflexible, mess. Since you brought up this line of concern, Noel, I went back over an article that I wrote for an ACM publication ("Making Standards the IETF Way" in StandardsView) noting that your comments have strong surface validity but, in my opinion, do not fit the IETF experience. Forgive me for burdening everyone with the following, but I'm hoping it attends to the question of IPng process and decision-making "Most standards efforts seek to solve a problem in the most general manner and for the longest-term possible. Such intentions cannot be criticized. They are well-meant. Unfortunately, the goal of extreme generality requires very long and careful analysis and requires attending to a very broad range of require ments, which further adds to the design and analysis burden. Hence, it usually takes a very long time to produce these general solutions. Hence, these solutions often have missed their window of opportunity. Worse, they often have become cumbersome, difficult to implement, resulting in very large software modules. "IETF work occasionally suffers from these problems, too. In fact, the IETF is not very successful at fixing working groups that make the mistake of walking down the seductive path of long- term, general design. Fortunately, most IETF working groups operate within a narrow scope, trying to solve immediate problems. The wide range of views that contribute to the work usually make painfully clear what features a specification is lacking. As a result, designs often include hooks for later ex tensions, so that those who did not get their favorite feature into the current draft, can separately specify enhancements. If the community decides that one or another enhancement is valu able, it gets adopted. But the evaluation process for the addi tional features does not impede development and adoption of the functional core. "By rights, the narrow focus and near-term goals of the IETF work should make its specifications rigid and short-lived. Real-world experience shows a different performance record. The specifications are comprehensible to a broad range of implementers. The software operates on the complete range of platforms and is useful in most data communication contexts. Better still, its utility continues after more than ten years of production use. "As the Internet technology is applied to a wider range of environments, various deficiencies are identified. Security and accounting are the ones most commonly cited, though support for guaranteed levels of service, such as for real-time traffic, also are noted. To date, the IETF has shown an astonishing ability to add capabilities to the core technology, and there is little indication that it has reached a limit in that ability. "Over the last five years, work from the Internet community has shown vastly greater market acceptance and use than the work of the OSI community. It's puzzling to try to determine the engineering rule of thumb that explains this. One possibility is the OSI community's desire for functional completeness and accommodation of all interests leads to the philosophy of including as much as possible in a design. In contrast, successful IETF working groups are driven by near-term needs and consequently try to produce designs that remove as much as possible. At first blush, this should produce highly limited designs. The trick in the process appears to be the group consensus requirement. As one would expect, each participant contributes their list of desired features, but the short time-fuse on the work requires that the group reach consensus quickly. This can only be done by removing features, since only a small core of features will be clearly acceptable to most participants. (The alternative approach of including all of everyone's preferences requires too much group debate and results in a design that is too-obviously unacceptable.) However, the process of removing features also requires some assurance that some of those features can be added later. Hence, the design usually permits extensibility which is itself, designed with an approximate sense of the sorts of extensions that are likely to be made." From owner-Big-Internet@munnari.OZ.AU Thu May 19 09:29:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13038; Thu, 19 May 1994 07:36:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA02973; Thu, 19 May 1994 07:05:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA02946; Thu, 19 May 1994 06:47:59 +1000 Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09808; Thu, 19 May 1994 06:02:33 +1000 (from jdemarco@ftp.com) Received: by ftp.com ; Wed, 18 May 1994 16:02:24 -0400 Received: by ftp.com ; Wed, 18 May 1994 16:02:24 -0400 Date: Wed, 18 May 1994 16:02:24 -0400 From: jdemarco@ftp.com (Jim DeMarco) Message-Id: <9405182002.AA18878@ftp.com> To: deering@parc.xerox.com Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Wed, 18 May 1994 10:06:07 PDT <94May18.100620pdt.12171@skylark.parc.xerox.com> Subject: serverless autoconfiguration of host addresses Reply-To: jdemarco@ftp.com >Anyway, I'd like to hear what other people think. In particular, I'd like >to know whether you think serverless autoconfiguration of globally-routable >host addresses is: > > - an essential capability > - nice to have as an option > - something you could live without > - something too insecure to allow > - something else There's something about serverless autoconfiguration of globally- routable host addresses (SAOGRHA) is not clear to me. I certainly follow how a host can "self-configure" itself (i.e. a host can generate a unique EID for itself without having a server assign it such an EID). But if you allow this (SAOGRHA), how would two such hosts communicate with each other? It seems to me that a "self-configured" host would be limited to communicate only with "registered" hosts (since those are the only hosts whose EIDs are available via a DNS or whatever). If a host doesn't actually need to register itself with a central authority, how would its EID become known to other hosts? --Jim From owner-Big-Internet@munnari.OZ.AU Thu May 19 09:31:32 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17187; Thu, 19 May 1994 09:18:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12745 Thu, 19 May 1994 09:16:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA03018; Thu, 19 May 1994 08:43:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA03015; Thu, 19 May 1994 08:39:39 +1000 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13278; Thu, 19 May 1994 07:45:46 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA07024; Wed, 18 May 94 14:40:00 -0700 Received: by xirtlu.zk3.dec.com; id AA21962; Wed, 18 May 1994 17:39:42 -0400 Message-Id: <9405182139.AA21962@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of "Wed, 18 May 94 16:49:16 EDT." <9405182049.AA03539@ginger.lcs.mit.edu> Date: Wed, 18 May 94 17:39:36 -0400 X-Mts: smtp I recall one of the questions Dave asked which got shut down at the IPng Reqs BOF(whatever). Do we believe servers are integral to the network? It was shut down fast enough (I am not saying this negatively just that it was cause there was lots of stuff to do). But if I could have responded I would have put both arms and legs in the air and yelled YES. /jim From owner-Big-Internet@munnari.OZ.AU Thu May 19 10:52:05 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18148; Thu, 19 May 1994 09:57:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14338 Thu, 19 May 1994 09:56:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA03038; Thu, 19 May 1994 09:23:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA03035; Thu, 19 May 1994 09:17:47 +1000 Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13473; Thu, 19 May 1994 07:48:51 +1000 (from barney@databus.databus.com) Date: Wed, 18 May 94 17:53 EDT Message-Id: <9405181753.AA18198@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... Content-Length: 873 Content-Type: text > Date: Wed, 18 May 94 11:37:52 -0400 > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > > In other words, it's a political decision, not a technical one. So, don't be > surprised if and when, measured on technical axes, the result turns out to be > a loser. If it only loses as badly as qwerty, I think we'll be content. Yet another adage comes to mind - the best is the enemy of the good. Of course, that can be read both ways ... I would put in a plea that this discussion be brought down to a more concrete plane. If there is good reason not to make a choice in July, it ought to be possible to make the following sort of argument: Here is what is wrong with all the current proposals: Here is why we cannot, right now, make a proposal that fixes these defects: Here is the schedule on which the issues just above can be solved: Barney Wolff From owner-Big-Internet@munnari.OZ.AU Thu May 19 14:23:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21533; Thu, 19 May 1994 11:33:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA03065; Thu, 19 May 1994 11:03:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA03062; Thu, 19 May 1994 11:02:46 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29259; Thu, 19 May 1994 01:19:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00978; Wed, 18 May 94 11:19:23 -0400 Date: Wed, 18 May 94 11:19:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405181519.AA00978@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: Requirements Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) > This iteration can be expensive, depending on how widespread the effects; You're challenging the basic style of Internet technical development and deployment? No, I'm not; I'm simply pointing out that the costs of iteration get larger as the thing you're iterating touches more and more stuff. Iterating routing protocols is a lot less expensive than iterating the whole internetwork layer. > is changing so fast that it's wise to delay as long as you Noel, this is viewed as the classic way to miss a market window. It ahppense all the time, by focusing on the "problems" with deliverying and not on the requirements or benefits of deliverying. OK, let's focus on the things that are broken today, i.e. the things we really need, and what the benefits of the current IPng candidates are. Security is a lot more pressing than address space, and IPng doesn't help with that. As to the benefits, we could get extra address space with an "address extension" IP option (as Brian Carpenter suggests), without as massive a modification to all hosts. If you want to look at it in a marketing framework, playing "catch-up" marketing (i.e. following your competition) never wins; you have to leap-frog. We're deploying a new internetwork layer with no benefits other than more address space, something the "competition" already has. We need to look for "products" that are more advanced than the competition. > I like the approach were we deploy a new internetwork layer in pieces, > not all at once; we can try one version of a new piece, and if it's not > optimal, we can try another version. Either you mean deply a core and then add to it or you mean deploy a core and if we don't like it, replace it with a different core. Neither. You keep talking about a "core", but I think that's the wrong model. The internetwork layer consists of a number of interacting subsystems, such as "route calculation" and "user traffic forwarding". (Both of these would be part of what you call the "core"). What I think we should be doing is developing a new picture of how all these pieces will fit together. We can then build pieces to the outline of this new model, and we can deploy them one at a time. They won't work too well when first deployed as part of IPv4, but as we get more bits done, the result will become incrementally closer to the "complete" design (I say complete since we will need to tune the picture as we learn more from experience). At some point we may decide the IPv4 packet format is too compromised to keep changing, and change that, but it will be done in the context of the new picture of what the internetwork layer will do. Noel From owner-Big-Internet@munnari.OZ.AU Thu May 19 14:40:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23645; Thu, 19 May 1994 12:33:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA03086; Thu, 19 May 1994 12:03:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA03083; Thu, 19 May 1994 11:47:38 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23082; Thu, 19 May 1994 12:15:49 +1000 (from bill.simpson@um.cc.umich.edu) Received: from merit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19036 Thu, 19 May 1994 12:15:43 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm012-13.dialip.mich.net (pm012-13.dialip.mich.net [35.1.48.214]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA04384 for ; Wed, 18 May 1994 22:14:24 -0400 Date: Thu, 19 May 94 01:20:23 GMT From: "William Allen Simpson" Message-Id: <2431.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: serverless autoconfiguration of host addresses > From: Steve Deering > Anyway, I'd like to hear what other people think. In particular, I'd like > to know whether you think serverless autoconfiguration of globally-routable > host addresses is: > > - an essential capability > - nice to have as an option > - something you could live without > - something too insecure to allow > - something else > Steve, we've talked about this before, but here's my twist: Similarly to you, I like "serverless" for local use only, in order to reach a server, or other local nodes. After all, the address is only good beyond the local net if others can find it, which means you need to get to some server anyway. So, I would use the local serverless address to either register an address (DHCP), or to find out the proper global address (DNS). I don't think that a global serverless address is of much use. And I definitely like the idea of turning it off for security (which is more a border router filter configuration issue than addressing per se). But, unlike you, I like the SIPP 128-bit sequence for the local traffic. It's only for a short time, or for "dentist office" scenarios, where the traffic is least likely to be significant. And the 48+12 takes 1/16 the SIPP number space, whereas the 48 alone would take only 1/65,000. A good tradeoff. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu May 19 14:51:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28623; Thu, 19 May 1994 14:51:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA03111; Thu, 19 May 1994 14:23:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA03108; Thu, 19 May 1994 14:21:24 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25628; Thu, 19 May 1994 13:31:52 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-28.dialip.mich.net (pm002-28.dialip.mich.net [35.1.48.109]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id XAA08611 for ; Wed, 18 May 1994 23:31:41 -0400 Date: Thu, 19 May 94 02:24:04 GMT From: "William Allen Simpson" Message-Id: <2433.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Thoughts on the IPng situation... > From: Dave Crocker > designs. The trick in the process appears to be the group consensus > requirement. As one would expect, each participant contributes their > list of desired features, but the short time-fuse on the work requires > that the group reach consensus quickly. This can only be done by > removing features, since only a small core of features will be clearly > acceptable to most participants. (The alternative approach of > including all of everyone's preferences requires too much group debate > and results in a design that is too-obviously unacceptable.) However, > the process of removing features also requires some assurance that some > of those features can be added later. Hence, the design usually > permits extensibility which is itself, designed with an approximate > sense of the sorts of extensions that are likely to be made." > > Nicely written, Dave. This matches my experiences in the IETF. So, have we removed enough IPng features? ;-> (I know we disagree on this.) Are we as extensible as possible? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu May 19 17:12:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03619; Thu, 19 May 1994 17:12:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA03141; Thu, 19 May 1994 16:43:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA03135; Thu, 19 May 1994 16:26:58 +1000 From: root@estbc8.estec.esa.nl Received: from bcserver.estec.esa.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02948; Thu, 19 May 1994 16:55:14 +1000 (from root@estbc8.estec.esa.nl) Received: from estbc8.estec.esa.nl by bcserver.estec.esa.nl (AIX 3.2/UCB 5.64/4.03) id AA15702; Thu, 19 May 1994 08:55:26 +0100 Received: by estbc8.estec.esa.nl (AIX 3.2/UCB 5.64/4.03) id AA16219; Thu, 19 May 1994 08:54:32 +0200 Date: Thu, 19 May 1994 08:54:32 +0200 Message-Id: <9405190654.AA16219@estbc8.estec.esa.nl> To: big-internet@munnari.OZ.AU Subject: unsubscribe unsubscribe root@estbc8.estec.esa.nl From owner-Big-Internet@munnari.OZ.AU Thu May 19 17:14:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03678; Thu, 19 May 1994 17:14:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA03156; Thu, 19 May 1994 16:46:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA03138; Thu, 19 May 1994 16:31:54 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01562; Thu, 19 May 1994 16:21:06 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24091; Thu, 19 May 1994 08:20:31 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13857; Thu, 19 May 1994 08:20:28 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405190620.AA13857@dxcoms.cern.ch> Subject: Re: serverless autoconfiguration of host addresses To: deering@parc.xerox.com (Steve Deering) Date: Thu, 19 May 1994 08:20:28 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: <94May18.100620pdt.12171@skylark.parc.xerox.com> from "Steve Deering" at May 18, 94 10:06:07 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 819 Steve, It's today today, so is it still OK for me to reply? Depends on whether the red-eye flight has Internet access, I suppose. My view has always been that a site network manager must have the option to control (in the strong sense) the network-level addresses in use on his/her site, iff s/he wants to. That means that serverless autoconfig is a perfectly useful feature but that it MUST be possible to disable it globally for a site. Manual config by the user is a very dangerous thing however, and leads to frequent accidental spoofing. My goal is always to have an up to date database relating hardware address, network-level address, DNS name, physical location, and human user name. Any mechanism that achieves that without broadcast storms is good. Today we can only do it by manual allocation. Brian From owner-Big-Internet@munnari.OZ.AU Fri May 20 02:52:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24123; Fri, 20 May 1994 02:52:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA03256; Fri, 20 May 1994 02:23:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA03253; Fri, 20 May 1994 02:08:34 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23493; Fri, 20 May 1994 02:37:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09516; Thu, 19 May 94 12:36:58 -0400 Date: Thu, 19 May 94 12:36:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405191636.AA09516@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, ses@tipper.oit.unc.edu Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu What would be a better idea would be for The Great Architect of the Internet (i.e. Dave Clark or Noel) to sketch a line drawing I think, based on talking to him, that we could probably convince Dave to take this on. (I doubt I'd be acceptable... :-) Noel From owner-Big-Internet@munnari.OZ.AU Fri May 20 03:12:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24913; Fri, 20 May 1994 03:12:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA03275; Fri, 20 May 1994 02:43:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA03272; Fri, 20 May 1994 02:40:30 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21195; Fri, 20 May 1994 01:40:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09162; Thu, 19 May 94 11:40:07 -0400 Date: Thu, 19 May 94 11:40:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405191540.AA09162@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, ericf@atc.boeing.com Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu it is with a large degree of hesitancy that I find myself disagreeing with important aspects of your latest posting. Well, we can't both be right, and I doubt either one of us is 100% correct, so let's see if we can figure out who's got which bits, eh? :-) > one organization that lost a sale to an IBM APPN solution because the > Internet is running out of address space. The issue the end user was doubtlessly responding to is the widespread perception that to deploy any major NEW deployment of TCP/IP today is short-sighted since such a deployment will be quickly obsoleted by IPng. Now I'm *really* impressed. We're damned if we do, and damned if we don't. If we pick an IPng, people will stop buying TCP/IP because it's going to be obsolete. (It will take years for a full suite of IPng products to become available from all vendors.) But if we *don't* pick an IPng, people will stop buying TCP/IP because it's going to run out of address space. Brilliant. Great planning, everyone. Thus, for that user to deploy TCP/IP would imply that they will shortly afterwards have to migrate that deployment to IPng. Thus, a TCP/IP deployment means TWO deployments for that user with all of the associated costs and expenses If this is really a major concern for a lot of users, then maybe we should be looking for ways to patch IPv4 into continuing to work, such as Brian's IP Option idea. APPN, by contrast, implies one deployment to that user because IBM promises full backwards compatibility from APPN+ to APPN ... a decision to go with APPN is a decision which hopefully carries with it the ensurance that those APPN assets will ... be able to fully depreciate before being obsoleted. But isn't current TCP/IP plant going to be equally backward compatible? most of the so-called anti-TCP/IP people in your note aren't really anti-TCP/IP. They just have other fish to fry than Internet connectivity. Oh, I understand that. They have their own proprietary solutions to sell, and before they can sell them, they have to get people not to jump on the Internet bandwagon. we as a corporation are strategically interested in TCP/IP remaining very viable for many years to come since we have already deployed 80,000 TCP/IP end systems and roughly 450 TCP/IP routers. Don't you think picking an IPng is going to be a factor in how networking companies weigh investing their product development dollars? Sure, in the end what the users want will drive these decisions; if they want more IPv4, they'll get it. However, you can't have it both ways, can you? Either the users will ask for IPng, and IPv4 will stop being invested in, or they'll keep asking for IPv4, and IPng won't happen. Is there some sort of intermediate position (a slow shift in development dollars, as user demand changes, say) that seems reasonable? However, it is my opinion that the Internet community can NOT afford to "bide its time" on making the IPng decision ... as toasternet becomes real, the toasternet applications will need a technology which can scale to choose as their infrastructual basis ... they likely will be making business decisions ... just so they won't have to redeploy their infrastructure twice. ... That would make sense, as you point out below, if there is some alternate, available now, that is going to be the eventual world-wide network. However, I'm not sure there is such a choice available today. Am I missing something? If there is no such option, than *any* system they pick is destined to be obsoleted by whatever technology turns into WorldNet. At least with IPv4 they know they will have an upward interoperabilty path to one of the prime contendors. About the only other strategy that makes sense is for organization X to think that they can drive the creation of that WorldNet technology faster as an internal efffort, than any other exernal alternative. I gather some companies do think they can, but I'm not convinced; building very large data networks is a tricky art. the best they can do is to select the best available alternative technology which MAY be eventually deployed over the Internet. ... It seems to me that they really have no other option than to choose OSI if they have to choose today That would make sense if they think OSI technology is going to turn into WorldNet. I'm not sure that makes more sense, than, say, thinking ATM will be WorldNet. (Not that ATM doesn't also have problems, but let's not get into that.) We are doing IPng for those people NOT in our community today so that they may be able to join us some day. Understood. That is, unless TCP/IP can be made to scale (IPng), what large deployment will be willing to deploy TCP/IP unless they can be assured that they won't have their investment quickly obsoleted? ... They must choose something that works and scales and is available within THEIR deployment timeframe window. But, by your analysis of the APPN case, people won't deploy TCP/IP since it's not IPng, and let's be real, even if we picked CATUBIPP tomorrow, and made all the documents PS's on the spot, we're over two years away from wide product availability. Sure, some people will be out in 6 months from spec freeze, but to be realistic, even that point is some ways off. The bottom line issue (in my opinion) is "when will toasternet become real?" Our window for IPng requires that IPng must be deployable BEFORE toasternet arrives. I dunno, I think we're committing "standards body hubris", thinking that we can have that much effect on the way things work. Toasternet will get kludged into existence the same way the rail, phone, etc, nets got kludged into existence... I therefore do not share your belief that we can afford to wait in defining a scalable TCP/IP (i.e., IPng). I believe that we can not afford to dilly-dally ... I believe that we must proceed full speed ahead despite the torpedos. Politics simply must be met by a willingness to compromise on a workable solution. Ah, there's the rub. What constitutes a "workable solution"? Maybe I'm hopelessly naive, but I see most of the actors in this IPng debacle as motivated by a desire to get a good design, not by a desire to, say, make $$$ by having their solution picked. We're having trouble *precisely* because we can't agree on what's a "workable solution". I get the feeling that what's happening is that we're possibly going to see is a recommendation for one, but with major changes. However, if you're opening up the door to major changes, the proposals are all pretty much equivalent. At that point, whether you pick TUBA or SIPP or whatever is more of a political statement, than a technical one. :-( Noel From owner-Big-Internet@munnari.OZ.AU Fri May 20 03:52:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26163; Fri, 20 May 1994 03:52:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA03313; Fri, 20 May 1994 03:23:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA03302; Fri, 20 May 1994 03:04:56 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23937; Fri, 20 May 1994 02:48:41 +1000 (from lyman@BBN.COM) Message-Id: <9405191648.23937@munnari.oz.au> From: Lyman Chapin Subject: Re: Thoughts on the IPng situation... To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU, ericf@atc.boeing.com In-Reply-To: <9405181537.AA01187@ginger.lcs.mit.edu> Date: Thu, 19 May 94 11:48:14 EDT Mail-System-Version: >Date: Wed, 18 May 94 11:37:52 -0400 >From: jnc@ginger.lcs.mit.edu (Noel Chiappa) >To: big-internet@munnari.oz.au, ericf@atc.boeing.com >Subject: Re: Thoughts on the IPng situation... >Cc: jnc@ginger.lcs.mit.edu > > From: Eric Fleischman > > I am sure that everyone involved would agree that requirements should guide > the approaches ... one of the most vexacious aspects of IPng from the > start was deciding whether IPng should be an incremental step or a major > advance in technology. > >I'm particularly incensed at the way we sort of drifted into assuming we were >going to have a new packet format. As near as I can tell, this came about when >some CLNP backers saw in the 32-bit limitation a way to get CLNP adopted, and >people who didn't like CLNP went off to do alternatives. Hardly a rational >plan for the best evolution path... > > > I believe that the IPng process is the best the community can do since we > lack -- and have consistently lacked -- a consensus on the even most basic > questions. > >You've just outlined a recipe for disaster. You think we're going to agree on >the answer when we can't even agree on the question? Noel, Actually, this is exactly what we're going to do, whether it's the right thing or not. It is *much* easier to get "rough consensus" on an answer than on the question - the motivation is so much stronger (after all, once you've agreed on an answer, the issue of what the question was is no longer relevant). Whether or not this will lead to disaster remains to be seen. Certainly the basic pattern has been followed many times before, in many fields. - Lyman From owner-Big-Internet@munnari.OZ.AU Fri May 20 05:48:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25623; Fri, 20 May 1994 03:32:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA03294; Fri, 20 May 1994 03:03:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA03291; Fri, 20 May 1994 02:52:14 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25203; Fri, 20 May 1994 03:20:36 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 2708; Thu, 19 May 94 12:56:32 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 9916; Thu, 19 May 1994 12:56:32 -0400 Date: Thu, 19 May 94 12:46:25 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: serverless autoconfiguration of host addresses To: Steve Deering , big-internet@munnari.OZ.AU In-Reply-To: <94May18.100620pdt.12171@skylark.parc.xerox.com> Message-Id: <940519.124625.EDT.VALDIS@vtvm1.cc.vt.edu> On Wed, 18 May 1994 10:06:07 PDT you said: >Anyway, I'd like to hear what other people think. In particular, I'd like >to know whether you think serverless autoconfiguration of globally-routable >host addresses is: > > - an essential capability For some sites, yes. They will need a 'plug-and-play' solution to deal with the lack of an administrator. Most 'HomeNet' sites will fall into this category. > - something too insecure to allow At other sites (such as ours), we have both administrative and security reasons for not wanting to allow people to tap in without our knowledge. First off, we bill $$/month per connection, so being able to plug-and-play without telling us will be frowned upon (we currently send a hit squad out if we catch an IP address that isn't in the nameserver). Secondly, although some sites are worried about off-site attacks and are willing to deal with insecure local configs, at our site we are our own worst enemy. At the other end of our FDDI ring are student dorms that are traditionally hotbeds of underground BBS systems and the like. > - something else Yes. I think what is needed is some way to codify it so that those sites that want "plug and play" can do so, but those administrative realms that don't want to are able to inject some flavor of "killer packet" and Terminate With Extreme Predjudice. Perhaps what is needed is something similar to the current PEM stuff - you can sign your packets yourself, or have a certifying authority do it. Then the target system can decide whether to accept a self-signed packet or not. Unfortunately, this gets back into the security morass. Bottom line - my professional opinion is that 'serverless plug-and-play' not be included unless there is also a mechanism for the system that receives a connection from a 'plug-and-play' to know that fact, and to make a decision based on it. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Fri May 20 07:25:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29688; Fri, 20 May 1994 05:32:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA03337; Fri, 20 May 1994 05:03:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03334; Fri, 20 May 1994 04:51:00 +1000 Received: from CARAWAY.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25756; Fri, 20 May 1994 03:38:11 +1000 (from ddc@caraway.lcs.mit.edu) Received: by caraway.lcs.mit.edu id AA25845; Thu, 19 May 94 13:38:00 -0400 Message-Id: <9405191738.AA25845@caraway.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, ses@tipper.oit.unc.edu Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of Thu, 19 May 94 12:36:58 -0400. <9405191636.AA09516@ginger.lcs.mit.edu> From: David Clark Date: Thu, 19 May 94 13:37:59 -0400 Sender: ddc@caraway.lcs.mit.edu X-Mts: smtp Noel, You are out there making trouble again. I have a mild problem with being nominated in that way for whatever role you are contemplating..... Dave From owner-Big-Internet@munnari.OZ.AU Fri May 20 11:39:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06725; Fri, 20 May 1994 08:32:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA03365; Fri, 20 May 1994 08:03:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA03362; Fri, 20 May 1994 07:43:49 +1000 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05703; Fri, 20 May 1994 08:12:15 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-06.dialip.mich.net (pm002-06.dialip.mich.net [35.1.48.87]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA17590 for ; Thu, 19 May 1994 18:12:10 -0400 Date: Thu, 19 May 94 22:00:02 GMT From: "William Allen Simpson" Message-Id: <2452.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: standards for IPng Just had an interesting observation from the SIPP list, which I thought I'd share here: > Date: Thu, 19 May 94 15:50:01 EDT > From: jkrawczy@pobox.wellfleet.com (John Krawczyk) > Repeat after me, SIPP is being held to a higher standard than BGP, an > IETF deployed standard. > > In addition, SIPP is being held to a higher standard than IPX in IP > (RFC-1234), an IETF deployed standard which uses a configured mapping > table, usually distributed by FTP. > > Like I said, this is not the issue I was responding to. I just wanted > to clear up the misunderstandings about BGP. I do want to repeat your > statement, however, but a little more strongly: > > How about "All IPng candidates must be held to a higher standard than > _______." Fill in the blank with anything done previously in the > IETF. I'd be very worried if this were _not_ true. I hope I there is > no need to explain why. > With this sentiment (whether it's right or wrong), we will never have an IPng. Is that what we want? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri May 20 11:41:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13417; Fri, 20 May 1994 11:41:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA03392; Fri, 20 May 1994 11:12:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA03389; Fri, 20 May 1994 11:03:25 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07324; Fri, 20 May 1994 08:48:51 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12301; Thu, 19 May 94 18:48:49 -0400 Date: Thu, 19 May 94 18:48:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405192248.AA12301@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Interesting numbers from the US phone system... Cc: jnc@ginger.lcs.mit.edu I was recently told that "the US phone system" had switched from heirarchical routing (with exception tables, for optimization), based on a two-level (area code, exchange) hierarchy, to flat routing (where the area code and exchange are considered as a unit). In finding out more about what the various parts of the US phone system are doing for routing these days, and why, I came across some interesting numbers. (These numbers are from someone's memory, and are a bit old, so they may not be 100% accurate.) They might prove interesting, so here they are. It turns out the largest inter-exchange carrier, AT&T, has about 200 switches (and the number is shrinking), and the two main secondary ones, MCI and Sprint, have less than 100 each. There are about 10,000 central offices, handling something around 80,000 exchange codes (160 area codes times a guess of an average of 500 active exchanges per area code). There are also about 180 LATA's (I think, my memory is hazy on that one), with the largest ones containing over 100 central offices. Noel From owner-Big-Internet@munnari.OZ.AU Fri May 20 12:52:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16670; Fri, 20 May 1994 12:52:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA03418; Fri, 20 May 1994 12:23:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA03415; Fri, 20 May 1994 12:22:36 +1000 From: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16644; Fri, 20 May 1994 12:50:59 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA24195; Thu, 19 May 94 19:45:59 -0700 Received: by xirtlu.zk3.dec.com; id AA03838; Thu, 19 May 1994 22:45:57 -0400 Message-Id: <9405200245.AA03838@xirtlu.zk3.dec.com> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Subject: Re: standards for IPng In-Reply-To: Your message of "Thu, 19 May 94 22:00:02 GMT." <2452.bill.simpson@um.cc.umich.edu> Date: Thu, 19 May 94 22:45:51 -0400 X-Mts: smtp Bill, I hate to say this. But being new its my impression this whole effort is a bit helter skelter with the IPng Area trying to regroup from many past mistakes in process. Whats really bad is that recovering from a bad process is interfering now with technical excellence. I feel sometimes we are now not doing any engineering but only architectural self-serving analysis. Noel's assessment was right from Eric's message that we could be damnned if we do and dammned if we don't. I have come to the conclusion personally we need to go for it here and look for some internal fortitude to make a decision and get all of us working on the same solution. If we pick the right address template, routing hierarchy, and performance metrics for hosts and routers we can probably do what the original Internet folks did which was build the worlds greatest network ever known. And I believe we can still evolve the architecture, but right now I wish we could do a bit more engineering. /jim From owner-Big-Internet@munnari.OZ.AU Fri May 20 14:52:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21421; Fri, 20 May 1994 14:52:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA03442; Fri, 20 May 1994 14:23:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA03439; Fri, 20 May 1994 14:04:19 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20586; Fri, 20 May 1994 14:32:43 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 20 May 94 13:25:48 +0859 From: Masataka Ohta Message-Id: <9405200426.AA22193@necom830.cc.titech.ac.jp> Subject: Re: Interesting numbers from the US phone system... To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 20 May 94 13:25:47 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9405192248.AA12301@ginger.lcs.mit.edu>; from "Noel Chiappa" at May 19, 94 6:48 pm X-Mailer: ELM [version 2.3 PL11] > I was recently told that "the US phone system" had switched from > heirarchical routing (with exception tables, for optimization), based on a > two-level (area code, exchange) hierarchy, to flat routing (where the area > code and exchange are considered as a unit). Quite interesting. > It turns out the largest inter-exchange carrier, AT&T, has about 200 > switches (and the number is shrinking), As long as most of the people are using audio phones which requires merely 64Kbps, the number of central switches decrease as the capacity of them increases. So, let's try to scale it. In the futue when most of the people using 640Mbps equipments with swithces 100 times faster than the current ones, AT&T will need 20,000 switches (which means ttl of sqrt(20,000)=141), won't it? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri May 20 17:27:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25347; Fri, 20 May 1994 16:32:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA03465; Fri, 20 May 1994 16:03:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA03462; Fri, 20 May 1994 15:47:32 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24514; Fri, 20 May 1994 16:15:56 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA07666; Fri, 20 May 1994 08:15:49 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA26290; Fri, 20 May 1994 08:15:48 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405200615.AA26290@dxcoms.cern.ch> Subject: Re: Thoughts on the IPng situation... To: big-internet@munnari.OZ.AU (bigi) Date: Fri, 20 May 1994 08:15:47 +0200 (MET DST) In-Reply-To: <9405191540.AA09162@ginger.lcs.mit.edu> from "Noel Chiappa" at May 19, 94 11:40:07 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 765 Noel, > > Now I'm *really* impressed. We're damned if we do, and damned if we don't. If > we pick an IPng, people will stop buying TCP/IP because it's going to be > obsolete. (It will take years for a full suite of IPng products to become > available from all vendors.) But if we *don't* pick an IPng, people will stop > buying TCP/IP because it's going to run out of address space. Brilliant. > Great planning, everyone. > We can do better than that. Once we have selected an IPng it is our collective job to make it look like just the next release of IPv4 to the end user. That's product engineering and transition engineering. It's been done with various proprietary protocols with varying success. It's a challenge to do it in a multivendor world. Brian From owner-Big-Internet@munnari.OZ.AU Fri May 20 22:56:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06414; Fri, 20 May 1994 21:32:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA03505; Fri, 20 May 1994 21:03:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA03502; Fri, 20 May 1994 20:59:56 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04019; Fri, 20 May 1994 20:12:37 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA23048; Fri, 20 May 94 03:12:22 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA09265; Fri, 20 May 94 03:12:43 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA11248; Fri, 20 May 1994 03:11:27 -0700 Date: Fri, 20 May 1994 03:11:27 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9405201011.AA11248@jurassic.Eng.Sun.COM> To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU (bigi) In-Reply-To: <9405200615.AA26290@dxcoms.cern.ch> Subject: Re: Thoughts on the IPng situation... Brian, > We can do better than that. Once we have selected an IPng it is > our collective job to make it look like just the next release of > IPv4 to the end user. That's product engineering and transition > engineering. It's been done with various proprietary protocols with > varying success. It's a challenge to do it in a multivendor > world. Just right! We need to make IPng appear as a normal software upgrade to the users. It should start working as it is deployed, no flag days, no negative impact on the users, etc. Bob From owner-Big-Internet@munnari.OZ.AU Fri May 20 23:33:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07021; Fri, 20 May 1994 21:52:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA03539; Fri, 20 May 1994 21:23:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA03536; Fri, 20 May 1994 21:13:49 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05616; Fri, 20 May 1994 20:56:54 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA13833; Fri, 20 May 94 06:00:05 -0500 Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA07018; Fri, 20 May 94 05:56:38 CDT Date: Fri, 20 May 94 05:56:38 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9405201056.AA07018@anubis.network.com> To: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Interesting numbers from the US phone system... I may be wrong, but I think that phone switches solve the basic problems with very poor scaling of their network by throwing enormous amounts of hardware at it. ATT may use only 200 switches on it's 'backbone', but each of those is a multi-million dollar box the size of a house. Shoot, I could make IP scale pretty well with that kind of hardware, a team of thousands of engineers, and a good bullwhip ;) Andrew Molitor From owner-Big-Internet@munnari.OZ.AU Fri May 20 23:34:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06610; Fri, 20 May 1994 21:38:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA03520; Fri, 20 May 1994 21:09:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA03499; Fri, 20 May 1994 20:56:57 +1000 Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06172; Fri, 20 May 1994 21:25:18 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA00957; Fri, 20 May 94 06:25:58 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ar05319; 20 May 94 11:15 GMT Date: Fri, 20 May 94 06:21 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Noel Chiappa To: big internet Subject: Re: Thoughts on the IPng situation... Message-Id: <20940520112102/0003858921NA2EM@mcimail.com> >At that point, whether you pick TUBA or SIPP or whatever is more of a >political statement, than a technical one. :-( For the most part, I am too busy making TCP/IP happen at Chrysler in a BIG way to participate in these conversations. But.... There is one VERY big criteria for us corporate folks that will drive us to an IPng, given a business need. That is the DOS/Windows migration plan. Forget your UNIX work, it does not represent a significant number of install machines in the corporate world (yes I help set Chrysler Finance up with 3,000+ NeXtstep systems). Now all too many DOS/Windows systems are already running dual stack, IP and IPX. It might actually happen later this year that Novell will really get NWIP to the point that it can be used large scale, but my colleagues that do IPX are not holding their breath. This tends to lead me, personally, to be very much concerned about a dual stack transition. I want to REPLACE the IP kernel in DOS with an IPng kernel. Yes I have worked with DLL implementations and found them lacking. Perhaps we will soon have VxD implementations, but that is VERY hard and I would doubt if an IPng would do that out the door. The next big criteria is address migration. I would want a clean port of my IP addresses to IPng addresses. In the past year, the corporate side of our network (still waiting on numbers from engineering) went from 3,000 IP interfaces to 8,800 interfaces (according to our HP OpenView). Dreaming up a new addressing scheme is not all that much fun. As it is we are fighting a DNS/X.500/NDS naming fight... So from where I stand today (and granted I have only scanned the drafts), SIPP looks good to me and I would recommend it to my colleagues. But then if I am shown how easy the same items are with TUBA or CATNIP, or TURNIPP, I could end up needing to reconsider. My voice carries some weight here. But this is not Chrysler's position, yet. Bob Moskowitz Chrysler Corp From owner-Big-Internet@munnari.OZ.AU Sat May 21 01:47:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08853; Fri, 20 May 1994 22:52:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA03560; Fri, 20 May 1994 22:23:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA03557; Fri, 20 May 1994 22:07:58 +1000 Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08348; Fri, 20 May 1994 22:36:18 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA00431; Fri, 20 May 94 05:30:52 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA08370; Fri, 20 May 1994 08:32:51 -0400 Message-Id: <9405201232.AA08370@skidrow.lkg.dec.com> To: big-internet@munnari.OZ.AU Subject: Re: Interesting numbers from the US phone system... In-Reply-To: Your message of "Fri, 20 May 94 13:25:47 +0200." <9405200426.AA22193@necom830.cc.titech.ac.jp> Date: Fri, 20 May 94 08:32:51 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: Masataka Ohta To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9405192248.AA12301@ginger.lcs.mit.edu>; from "Noel Chiappa" at May 19, 94 6:48 pm X-Mailer: ELM [version 2.3 PL11] >> I was recently told that "the US phone system" had switched from >> heirarchical routing (with exception tables, for optimization), based on a >> two-level (area code, exchange) hierarchy, to flat routing (where the area >> code and exchange are considered as a unit). The long distance AT&T switches have done 6 digit lookups for at least 20 years. I don't know what technology they use now but it used to be punched metal cards with edge tabs encoding digits resting on rods. The rods would be raised/lowered based on the six digits (usually area code plus exchange but there are also other posibilties) causing some cards to drop and other not to. Lights were shone through the resulting deck and photocells used to read the results. Of course, if all the routing from a place for a particular area code were the same, there would be no need to vary the output based on any digits after the first three. I assume this is all done electonically in ESS offices or something these days. >... > Masataka Ohta Donald From owner-Big-Internet@munnari.OZ.AU Sat May 21 02:32:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17565; Sat, 21 May 1994 02:32:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA03641; Sat, 21 May 1994 02:03:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA03638; Sat, 21 May 1994 01:58:34 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15537; Sat, 21 May 1994 01:40:52 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Fri, 20 May 1994 08:33:13 -0700 Date: Fri, 20 May 1994 08:33:13 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199405201533.AA28836@zephyr.isi.edu> To: bound@zk3.dec.com Subject: Re: standards for IPng Cc: big-internet@munnari.OZ.AU *> same solution. If we pick the right address template, routing *> hierarchy, and performance metrics for hosts and routers we can probably *> do what the original Internet folks did which was build the worlds *> greatest network ever known. (Errr... thanks, but the original Internet folks had no such intent. It just worked out that way... Some of our peers were pushing X.25, which was expected to become the world's greatest network ever known...) Bob Braden From owner-Big-Internet@munnari.OZ.AU Sat May 21 18:23:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17251; Sat, 21 May 1994 16:53:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA03712; Sat, 21 May 1994 16:24:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA03709; Sat, 21 May 1994 16:05:24 +1000 From: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12468; Sat, 21 May 1994 14:35:37 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA06521; Fri, 20 May 94 21:34:06 -0700 Received: by xirtlu.zk3.dec.com; id AA19814; Sat, 21 May 1994 00:33:05 -0400 Message-Id: <9405210433.AA19814@xirtlu.zk3.dec.com> To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: big internet Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of "Fri, 20 May 94 06:21:00 EST." <20940520112102/0003858921NA2EM@mcimail.com> Date: Sat, 21 May 94 00:32:59 -0400 X-Mts: smtp Bob, Some questions if you can find the time )---> thanks. =>At that point, whether you pick TUBA or SIPP or whatever is more of a =>political statement, than a technical one. :-( >For the most part, I am too busy making TCP/IP happen at Chrysler in a BIG >way to participate in these conversations. But.... Thanks we need to hear from those living with it too and we need more input like this as a wake up call to reality. >There is one VERY big criteria for us corporate folks that will drive us to >an IPng, given a business need. >That is the DOS/Windows migration plan. Forget your UNIX work, it does not >represent a significant number of install machines in the corporate world >(yes I help set Chrysler Finance up with 3,000+ NeXtstep systems). I have always believed this is more than just a network layer problem as I have stated in mail and an IPng White Paper. Is this what your pointing at for DOS/Windows migration plan? Is this an API issue too. One argument I am developing which brings new light into the need for an API is that any transition 'effector' needs to be understood and then acted upon by the IPng transition technical plan. Moving applications to IPng are a clear transition issue because we have changed the core component of TCP/IP. I agree with you but can you give us a few more high level details regarding what needs to be done in your professional opinion as an individual of course. >Now all too many DOS/Windows systems are already running dual stack, IP and >IPX. It might actually happen later this year that Novell will really get >NWIP to the point that it can be used large scale, but my colleagues that do >IPX are not holding their breath. So are you saying that you can see some transition where companies could say just put IPng on the machine and no other stack? I personally can see this as a customer network strategy and why I really believe we need to be prepared for the non-dual-stack transition case. Would you want network software that would let the IPng machines that become IPng only interoperate with old IPv4 machines during the transition to avoid a flag day? >This tends to lead me, personally, to be very much concerned about a dual >stack transition. I want to REPLACE the IP kernel in DOS with an IPng >kernel. Yes I have worked with DLL implementations and found them lacking. >Perhaps we will soon have VxD implementations, but that is VERY hard and I >would doubt if an IPng would do that out the door. I have many concerns technically that assumes a dual stack ONLY transition too. Where we can avoid it, why, and how, are questions I am beginning to ask my self too. Can you expound a bit more on the above? >The next big criteria is address migration. I would want a clean port of my >IP addresses to IPng addresses. In the past year, the corporate side of our >network (still waiting on numbers from engineering) went from 3,000 IP >interfaces to 8,800 interfaces (according to our HP OpenView). Dreaming up >a new addressing scheme is not all that much fun. As it is we are fighting >a DNS/X.500/NDS naming fight... Would a clean port be using the IPv4 address as the low order bits of the IPng address for transition and continued IPng/IPv4 interoperation as proposed by SIPP Transition be a valid approach to review? What do you expect the vendor community to do once IPv4 addresses run out and you can't get anymore from IANA or whoever will be passing them out? This right now is the transition cut-off right now? It won't be the same as a proprietary protocol being maintained for compatibility because its owned by a standards body and right now there are no plans in anyones proposal for the IETF standards to support IPv4 in a multivendor manner after IPv4 runs out. >So from where I stand today (and granted I have only scanned the drafts), >SIPP looks good to me and I would recommend it to my colleagues. But then >if I am shown how easy the same items are with TUBA or CATNIP, or TURNIPP, I >could end up needing to reconsider. My voice carries some weight here. But >this is not Chrysler's position, yet. From what you have seen of the networking mixed bag of tricks to get interoperation working what do you see as the top 5 most critical must do's for IPng Transition (if you want to give 10 then thats good too)? thanks /jim From owner-Big-Internet@munnari.OZ.AU Sun May 22 11:33:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19723; Sun, 22 May 1994 11:13:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA03818; Sun, 22 May 1994 10:44:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA03799; Sun, 22 May 1994 10:24:42 +1000 Received: from brazos.is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18713; Sun, 22 May 1994 10:37:03 +1000 (from bmanning@is.rice.edu) Received: by brazos.is.rice.edu (AA23550); Sat, 21 May 94 19:36:41 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9405220036.AA23550@brazos.is.rice.edu> Subject: Missing In Action To: martillo@penril.com (Joachim Martillo) Date: Sat, 21 May 1994 19:36:40 -0500 (CDT) Cc: avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@penril.com In-Reply-To: <9405212207.AA17145@penril.penril.com> from "Joachim Martillo" at May 21, 94 06:07:16 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 779 Joachim Martillo sez: > DARPA IP, DECNET, AppleTalk and Novell Netware. > Eventually when some internetworking provider transcends DARPA IP DARPA IP, Digital DECNET, Apple Appletalk, and Novell Netware. If you insist on putting developers names in the conversation, Use Them All. Besides, what other versions of IP are being run? I know of DARPA IPv4 and DARPA IPv5. Is there another varient of IP? Perhaps Martillo IP? > I think Henry Ford made the same observation. "You can buy any Model A > you want as long as its black." It was not a successful strategy or > reasonable appraisal of reality. Of course Mr. Ford died destitute and forgotten. He and his company are only remembered as an object lesson in the annals of Business Theory. -- Regards, Bill Manning From owner-Big-Internet@munnari.OZ.AU Sun May 22 11:35:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19114; Sun, 22 May 1994 10:54:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA03802; Sun, 22 May 1994 10:24:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA03796; Sun, 22 May 1994 10:16:03 +1000 Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15719; Sun, 22 May 1994 08:39:55 +1000 (from martillo@penril.com) Received: from penril.penril.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwqxe20366; Sat, 21 May 94 18:39:47 -0400 Received: from speedo.penril.com by penril.penril.com (4.1/SMI-4.1) id AA17145; Sat, 21 May 94 18:07:16 EDT Date: Sat, 21 May 94 18:07:16 EDT From: martillo@penril.com (Joachim Martillo) Message-Id: <9405212207.AA17145@penril.penril.com> Received: by speedo.penril.com (4.1/SMI-4.1) id AA17726; Sat, 21 May 94 18:36:49 EDT To: avg@sprint.net Cc: pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@penril.com In-Reply-To: Vadim Antonov's message of Tue, 10 May 1994 13:51:30 -0400 <199405101751.NAA00919@titan.sprintlink.net> Subject: Introducing proxy aggregations? Date: Tue, 10 May 1994 13:51:30 -0400 From: Vadim Antonov >The persistence of internetworking fascism is truly amazing. Any >internet which is not a multiprotocol internet is a toy internet. Khe-khe. We have bi-protocol production network. Guess the traffic on a second protocol stack (CLNP OSI/TUBA). 1 packet in 10 seconds is considered an intensive usage. You are confusing internetworking with the Internet. There are internets all over the world which are probably in large part multiprotocol. Face it, the "second Internet" will never catch on. Any realistic IPNG proposal should include trivial stateless translation to/from IP v4. Penril Datability Networks has three networked locations in Maryland, New Jersey and Massachusetts. All locations have multiprotocol internetworks supporting DARPA IP, DECNET, AppleTalk and Novell Netware. Because no internetworking provider can offer the kind of multiprotocol internetworking services which we require, we build our own internal wide-area multiprotocol communications subnet. Eventually when some internetworking provider transcends DARPA IP blinders, that provider will make a lot of money in offering a useful service. (A side note on "internetworking fascism" -- oh, yeah, the power outlet fascizm is truly amazing. All unhappy electrical gizmo manufacturers have absolutely no freedom in inventing their own plugs and sockets. The accurate analogy would be using a single LAN technology which is common practice in many organizations. Of course just as the electrical technology is not used in the same way by all devices attached to electrical outlets, not all LAN technology is used in the same way by all devices attaching to LANs. Any power grid which is not a multi-outlet- configuration is a toy power grid. And those 60Hz and 110V are simply horrible.) Also, don't forget of Nazi clause -- any discussion mentioning them is de-facto became a flamewar and should be terminated. Please use arguments instead of name calling. Convergence on a single standard is the sign of mature technology. At some time the benefits of alternative solutions become immaterial compared with massive cost savings of using standards. Sure, in the mature technology non-standards still exist but their usage is confined to unique applications. I think Henry Ford made the same observation. "You can buy any Model A you want as long as its black." It was not a successful strategy or reasonable appraisal of reality. >Should IPng ever be finally specified (I won't hold my breath), it >will simply be one more networking protocol (and probably not even a >very important one) among the networking protocols found running in >multiprotocol internets. Isn't that what we're trying to get rid of? Everybody's sick of multiprotocol internets. Have you ever tried to configure an enterprise network which does SNA, IPX, Appletalk and IP (plus somebody wants to play with TUBA) over the same wires? Have you ever thought what fraction of cisco's cost is support for non-IP protocols? (I mean *cost* not price w/o options). The datagram level is not the place to play plurality. The very success of Internet is due to the fact that it has the single common denominator -- the IP. Ethernet technology is so successful to a large extent because it plays plurality so well at the datagram level. On the other hand Prime Token Ring technology which supported but one type of datagram is barely a memory. --vadim Joachim Martillo Manager of Internetworking Research Penril Datability Networks Datability Advanced Communications Research Center 251 West Central Street Natick, MA 01761 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com From owner-Big-Internet@munnari.OZ.AU Sun May 22 14:29:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24703; Sun, 22 May 1994 13:52:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA03871; Sun, 22 May 1994 13:23:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA03868; Sun, 22 May 1994 13:22:40 +1000 Precedence: list Received: from mail.aero.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24308; Sun, 22 May 1994 13:39:25 +1000 (from obrien@antares.aero.org) Received: from antares.aero.org ([130.221.192.46]) by mail.aero.org with SMTP id <111153-2>; Sat, 21 May 1994 20:39:13 -0700 Received: from altair.aero.org by antares.aero.org (4.1/AMS-1.0) id AA12536 for dcrocker@mordor.stanford.edu; Sat, 21 May 94 20:39:07 PDT To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: Steve Deering , big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... In-Reply-To: Your message of "Mon, 16 May 1994 09:14:10 PDT." Date: Sat, 21 May 1994 20:39:03 -0700 From: "Mike O'Brien" Message-Id: <94May21.203913pdt.111153-2@mail.aero.org> Steve Deering says: >> must IPng embody a new internet architecture, >>or can it simply be a re-engineering of IPv4? >> do you think we can do a proper job of designing, >>testing, agreeing on, and deploying it before the market decides Dave Crocker says: > 3. I sure hope that more folks than just the usual, small group of > big-internet junkies answer your query. Ok, I'm certainly not a usual big-internet junkie, so I'll answer. I think the IETF, in the current time frame and under the current stresses, cannot re-architect IP and come up with something with the same "legs" as IPv4. I think other players, not tied to the IETF and using technologies not yet on the horizon, will wind up deploying other low-level protocols on the same net for the same purposes. CLNP/OSI is the tip of the iceberg in this regard. The driving forces will be economic, not technical. You asked. Mike O'Brien From owner-Big-Internet@munnari.OZ.AU Sun May 22 23:33:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09532; Sun, 22 May 1994 23:33:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA03931; Sun, 22 May 1994 23:04:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA03928; Sun, 22 May 1994 22:56:15 +1000 Precedence: list Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09247; Sun, 22 May 1994 23:24:40 +1000 (from martillo@penril.com) Received: from penril.penril.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwqzl03541; Sun, 22 May 94 09:24:30 -0400 Received: from speedo.penril.com by penril.penril.com (4.1/SMI-4.1) id AA17197; Sun, 22 May 94 07:38:43 EDT Date: Sun, 22 May 94 07:38:43 EDT From: martillo@penril.com (Joachim Martillo) Message-Id: <9405221138.AA17197@penril.penril.com> Received: by speedo.penril.com (4.1/SMI-4.1) id AA09926; Sun, 22 May 94 08:08:18 EDT To: bmanning@is.rice.edu Cc: avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@thurifer.harvard.edu In-Reply-To: William Manning's message of Sat, 21 May 1994 19:36:40 -0500 (CDT) <9405220036.AA23550@brazos.is.rice.edu> Subject: Missing In Action From: bmanning@is.rice.edu (William Manning) Date: Sat, 21 May 1994 19:36:40 -0500 (CDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 779 Joachim Martillo sez: > DARPA IP, DECNET, AppleTalk and Novell Netware. > Eventually when some internetworking provider transcends DARPA IP DARPA IP, Digital DECNET, Apple Appletalk, and Novell Netware. If you insist on putting developers names in the conversation, Use Them All. Besides, what other versions of IP are being run? I know of DARPA IPv4 and DARPA IPv5. Is there another varient of IP? Perhaps Martillo IP? I was trying to distinguish DARPA IP and OSI IP. > I think Henry Ford made the same observation. "You can buy any Model A > you want as long as its black." It was not a successful strategy or > reasonable appraisal of reality. Of course Mr. Ford died destitute and forgotten. He and his company are only remembered as an object lesson in the annals of Business Theory. Henry Ford sometimes learned from his errors and did not bankrupt his company as the Model A fiasco came very close to doing. Internetworking providers probably would not do badly in heeding his example. By the way the need to build an inexpensive car which even his employees could purchase was a great insight. In the packet switching world, the equivalent would be building faster cheaper smaller packet switches selling for about $400-500. The internetworking providers should be modeling themselves on MacDonalds. And as for internetworking itself, my Mom has a small extremely lucrative accounting firm with several locations in NJ and NY. She has a multiprotocol internet whose protocols are Novell IPX and Appletalk which do not suffer from the historical complexity of DARPA IP or from the increasing complexity associated with general stupidity of IETF specifications (especially SNMP, PPP and OSPF). My mom needs a MacDonald's eqivalent internetworking provider who could provide her with her own multiprotocol IPX/Appletalk wide-area backbone. I don't think her firm is atypical of the trend, and the real money lies in servicing the masses of such clients. -- Regards, Bill Manning Joachim Martillo Manager of Internetworking Research Penril Datability Networks Datability Advanced Communications Research Center 251 West Central Street Natick, MA 01761 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com From owner-Big-Internet@munnari.OZ.AU Mon May 23 00:12:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11306; Mon, 23 May 1994 00:12:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA03954; Sun, 22 May 1994 23:44:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA03951; Sun, 22 May 1994 23:42:50 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11284; Mon, 23 May 1994 00:11:17 +1000 (from pvm@ISI.EDU) Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Sun, 22 May 1994 07:10:40 -0700 Message-Id: <199405221410.AA25777@zephyr.isi.edu> To: martillo@penril.com (Joachim Martillo) Cc: bmanning@is.rice.edu, avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@thurifer.harvard.edu Reply-To: pvm@isi.edu Subject: Re: Missing In Action In-Reply-To: Your message of Sun, 22 May 1994 07:38:43 -0400. <9405221138.AA17197@penril.penril.com> Date: Sun, 22 May 94 07:10:39 PDT From: Paul Mockapetris > > DARPA IP, DECNET, AppleTalk and Novell Netware. > > Eventually when some internetworking provider transcends DARPA IP > > DARPA IP, Digital DECNET, Apple Appletalk, and Novell Netware. If you > insist on putting developers names in the conversation, Use Them All. > Besides, what other versions of IP are being run? I know of DARPA IPv4 > and DARPA IPv5. Is there another varient of IP? Perhaps Martillo IP? This is a bit off. DEC, Apple, and Novell all have programmers. ARPA doesn't. ARPA isn't a lab. ARPA sponsors research. IP, TCP et al were the result of work at Stanford, MIT, UCLA, Berkeley, ... yes even DEC, Apple, and probably Novell as well. Sure, guys at ARPA helped make it happen, but I belive there are almost too many contributions to name. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From owner-Big-Internet@munnari.OZ.AU Mon May 23 00:52:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12279; Mon, 23 May 1994 00:52:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA03976; Mon, 23 May 1994 00:24:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA03973; Mon, 23 May 1994 00:14:47 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12099; Mon, 23 May 1994 00:43:15 +1000 (from roll@Stupi.SE) Received: from Bsd.Stupi.SE by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14285 Mon, 23 May 1994 00:41:33 +1000 (from roll@Stupi.SE) Received: by bsd.stupi.se (5.67/1.37) id AA02667; Sun, 22 May 94 16:38:25 +0200 Date: Sun, 22 May 94 16:38:24 MET DST From: Peter Lothberg To: martillo@penril.com (Joachim Martillo) Cc: bmanning@is.rice.edu, avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@thurifer.harvard.edu Subject: Re: Missing In Action In-Reply-To: Your message of Sun, 22 May 94 07:38:43 EDT Message-Id: > Joachim Martillo > Manager of Internetworking Research > Penril Datability Networks > Datability Advanced Communications Research Center > 251 West Central Street > Natick, MA 01761 > VOICE 508-653-5313 > FAX 508-653-6415 > EMAIL martillo@dss.com > > My mom needs a MacDonald's eqivalent internetworking provider who > could provide her with her own multiprotocol IPX/Appletalk wide-area > backbone. I don't think her firm is atypical of the trend, and the > real money lies in servicing the masses of such clients. Ahh, your mom needs a 'MRN' Managed Router Network, wich is something very different from the 'Public Internet'. If you look in the YP on long-distance-carriers, I knew that atleast one that would be happy to sell you that service. Another way of doing it is to view 'dod-ip' as a replacement for the wire and encapsulate whatever you want ontop of that, alteast routers from one major vendor can do this for you right now. ----peter From owner-Big-Internet@munnari.OZ.AU Mon May 23 03:54:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17544; Mon, 23 May 1994 03:54:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA04005; Mon, 23 May 1994 03:24:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA04002; Mon, 23 May 1994 03:09:19 +1000 Precedence: list Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17295; Mon, 23 May 1994 03:37:47 +1000 (from pst@cisco.com) Received: from localhost.cisco.com by cider.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id KAA29183; Sun, 22 May 1994 10:36:21 -0700 Message-Id: <199405221736.KAA29183@cider.cisco.com> X-Authentication-Warning: cider.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: martillo@penril.com (Joachim Martillo) Cc: bmanning@is.rice.edu, avg@sprint.net, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@thurifer.harvard.edu Subject: Re: Missing In Action In-Reply-To: Your message of "Sun, 22 May 1994 07:38:43 EDT." <9405221138.AA17197@penril.penril.com> Date: Sun, 22 May 1994 10:36:21 -0700 From: Paul Traina > DARPA IP, Digital DECNET, Apple Appletalk, and Novell Netware. If you > insist on putting developers names in the conversation, Use Them All. > Besides, what other versions of IP are being run? I know of DARPA IPv4 > and DARPA IPv5. Is there another varient of IP? Perhaps Martillo IP? > > I was trying to distinguish DARPA IP and OSI IP. It's called CLNP. > Henry Ford sometimes learned from his errors and did not bankrupt his > company as the Model A fiasco came very close to doing. ^^^^^^^ Model T > And as for internetworking itself, my Mom has a small extremely > lucrative accounting firm with several locations in NJ and NY. She > has a multiprotocol internet whose protocols are Novell IPX and > Appletalk which do not suffer from the historical complexity of DARPA > IP or from the increasing complexity associated with general stupidity > of IETF specifications (especially SNMP, PPP and OSPF). Have you tried to scale Appletalk, DECnet IV, and IPX? > My mom needs a MacDonald's eqivalent internetworking provider who > could provide her with her own multiprotocol IPX/Appletalk wide-area > backbone. I don't think her firm is atypical of the trend, and the > real money lies in servicing the masses of such clients. VPN > Joachim Martillo > Manager of Internetworking Research > Penril Datability Networks > Datability Advanced Communications Research Center > 251 West Central Street > Natick, MA 01761 > VOICE 508-653-5313 > FAX 508-653-6415 > EMAIL martillo@dss.com Yeah. From owner-Big-Internet@munnari.OZ.AU Mon May 23 04:12:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18058; Mon, 23 May 1994 04:12:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA04026; Mon, 23 May 1994 03:44:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA04021; Mon, 23 May 1994 03:38:18 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17854; Mon, 23 May 1994 04:06:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27117; Sun, 22 May 94 14:06:41 -0400 Date: Sun, 22 May 94 14:06:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405221806.AA27117@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu From: "Mike O'Brien" I think the IETF, in the current time frame and under the current stresses, cannot re-architect IP and come up with something with the same "legs" as IPv4. This is a bit of a tangent on your point here, but, on thinking it over, I'm a bit puzzled as to what exactly the people are saying IP doesn't need a new (or revised) architecture mean by the term "architecture". As far as I'm concerned, if you think there needs to be separate endpoint identification (EID's) and topological location identification (locators), you think we need a new architecture. Likewise, if you think the internetwork layer needs to explicity recognize flows, you think we need a new architecture (albeit a more radical revision than that needed for an EID/locator split). Since I'd guess that a majority of the IETF agrees with one or other of these, I'm left very confused as to why people think there's any validity, or broad support, to the viewpoint that we don't need a new architecture. However, I'm about ready to give up hope that people will see the light on this anytime soon. Your complete assertion ("in the current time frame and under the current stresses") could well be true. Which leads to the question: in what forum is successsor technology going to be developed? I think other players, not tied to the IETF and using technologies not yet on the horizon, will wind up deploying other low-level protocols on the same net for the same purposes. Could be. Perhaps TCP/IP is going to be the X.25 of the '90's; fatally flawed, and impossible to change. Noel From owner-Big-Internet@munnari.OZ.AU Mon May 23 12:42:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02299; Mon, 23 May 1994 11:35:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA04068; Mon, 23 May 1994 11:04:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA04065; Mon, 23 May 1994 10:55:44 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00896; Mon, 23 May 1994 10:50:34 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA18878; Sun, 22 May 1994 17:49:55 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 22 May 1994 17:49:58 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Thoughts on the IPng situation... Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 11:06 AM 5/22/94, Noel Chiappa wrote: >Since I'd guess that a majority of the IETF agrees with one or other of these, >I'm left very confused as to why people think there's any validity, or broad >support, to the viewpoint that we don't need a new architecture. However, I'm To put words into, perhaps, into Mike O'Brien's mouth, I'll hazard the guess that what the view being expressed means is there is a core style of doing inter-hold exchanges, as modeled by IPv4, e.g., minimizing header fields and required functionality, which is working just find thankyouverymuch but which needs some tweaking. "Tweaking" doesn't mean triviality but it means we don't mess with it any more than we really think we must. >about ready to give up hope that people will see the light on this anytime >soon. Or, perhaps, they already HAVE seen the light. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Mon May 23 20:13:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19262; Mon, 23 May 1994 20:13:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA04117; Mon, 23 May 1994 19:44:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA04114; Mon, 23 May 1994 19:40:27 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19153; Mon, 23 May 1994 20:08:49 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405231008.19153@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 23 May 1994 08:37:08 +0100 To: big-internet@munnari.OZ.AU Subject: NSAPs, etc Date: Mon, 23 May 94 08:37:07 +0100 From: Jon Crowcroft For about 15 years we have been trying to do protocol relaying, translation, tunneling, munging, and so forth to permit a multiprotocol world to live at peace with itself one lesson is that where there are a number of claimants for Universal schemes, you have to take a position. My position is one of simplicity. SO for instanced, faced with trying to Unify NSAPs (which subsume E.163 and E.164), IPv4 (which doesn't) and IPng, I would advocate that the higherst level of addressing do _not_ subsume all the others. i.e. do _not_ embed any or all kitchen sink addresses in IPng, except as some exceptional hack... reasons include: unbounded recursive address growth precedence ambiguity parsing but then, I'm not so sure... jon From owner-Big-Internet@munnari.OZ.AU Tue May 24 00:54:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29937; Tue, 24 May 1994 00:54:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA04151; Tue, 24 May 1994 00:24:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA04148; Tue, 24 May 1994 00:18:24 +1000 Precedence: list Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29653; Tue, 24 May 1994 00:46:31 +1000 (from curtis@ans.net) Received: by interlock.ans.net id AA04960 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 23 May 1994 10:46:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 23 May 1994 10:46:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 23 May 1994 10:46:04 -0400 From: Curtis Villamizar Message-Id: <199405231442.AA43070@foo.ans.net> To: martillo@penril.com (Joachim Martillo) Cc: avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, curtis@ans.net Subject: Re: Introducing proxy aggregations? In-Reply-To: (Your message of Sat, 21 May 94 18:07:16 EDT.) <9405212207.AA17145@penril.penril.com> Date: Mon, 23 May 94 10:42:47 -0500 > Penril Datability Networks has three networked locations in Maryland, > New Jersey and Massachusetts. All locations have multiprotocol > internetworks supporting DARPA IP, DECNET, AppleTalk and Novell > Netware. Because no internetworking provider can offer the kind of > multiprotocol internetworking services which we require, we build our > own internal wide-area multiprotocol communications subnet. > > Eventually when some internetworking provider transcends DARPA IP > blinders, that provider will make a lot of money in offering a useful > service. The Internet does carry CLNP and IPX and Appletalk and SNA. All are encapsulated in IP. Generally IPX, SNA, and Appletalk users want a virtual private network so there has been little attempt to provide anything but (some people claim that there is a market for an IPX Internet or SNA Internet). There is a connected OSI NSFNET service, but the traffic levels are patheticly low (generally << 10^-5 of IP, some months < 10^-6), so there has been very little incentive to provide native CLNP. We have exceeded 10^+9 IP packets per day avergaed over a month. How much OSI traffic do you see on the Penril networks? How much IP traffic? BTW - traffic stats for NSFNET can be ftp'd from merit.edu. Curtis From owner-Big-Internet@munnari.OZ.AU Tue May 24 06:39:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05028; Tue, 24 May 1994 02:53:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA04249; Tue, 24 May 1994 02:24:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA04244; Tue, 24 May 1994 02:06:45 +1000 Precedence: list Received: from funet.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04224; Tue, 24 May 1994 02:35:06 +1000 (from Juha.Heinanen@funet.fi) Message-Id: <9405231635.4224@munnari.oz.au> Received: from funet.fi by funet.fi id <08739-0@funet.fi>; Mon, 23 May 1994 19:34:23 +0300 To: martillo@penril.com Cc: bmanning@is.rice.edu, avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@thurifer.harvard.edu In-Reply-To: Joachim Martillo's message of Sun, 22 May 94 07:38:43 EDT <9405221138.AA17197@penril.penril.com> Subject: Missing In Action Date: Mon, 23 May 1994 19:34:23 +0300 From: Juha Heinanen Sender: jh@funet.fi bill, i would suggest frame relay for your mom. it supports efficiently all layer 3 protocols and the prices are nowadays very competitive. -- juha From owner-Big-Internet@munnari.OZ.AU Tue May 24 06:40:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03270; Tue, 24 May 1994 02:13:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA04227; Tue, 24 May 1994 01:44:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA04224; Tue, 24 May 1994 01:29:04 +1000 Precedence: list From: hinden@Eng.Sun.COM Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02653; Tue, 24 May 1994 01:57:18 +1000 (from hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10865; Mon, 23 May 94 08:56:57 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA12890; Mon, 23 May 94 08:57:51 PDT Received: from [129.144.52.38] (chestnut2) by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA02124; Mon, 23 May 1994 08:55:58 -0700 Message-Id: <9405231555.AA02124@jurassic.Eng.Sun.COM> X-Sender: hinden@playground.sun.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 May 1994 08:57:22 -0800 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: Thoughts on the IPng situation... Cc: big-internet@munnari.OZ.AU Noel, At 1:58 PM 5/18/94 -0400, Noel Chiappa wrote: > > I do not believe the Internet needs a new internet-layer architecture. > > I can't add anything to Steve Deering's eloquent message except > to say I completely, 100% agree with everything he said > >We're going to get a new (i.e. revised) architecture, as the services provided >by the internetwork layer get upgraded (requiring storage of state about >traffic streams in the network, etc). The only question this community gets to >answer is "do we do this in a planned way, or not?" >..... I think the issues you raise here are very similar to what you are doing in the routing area. Correct me if I have this wrong, but you do not believe the current routing protocols used in the internet (BGP, IDRP, RIP, OSPF, ISIS, etc.) are adequate and a new routing architecture is needed. In this case you started the NIMROD effort. When NIMROD is completed it will be evaluated and if there is significant agreement (consensus) it will be standardized and deployed on the Internet. However, while this is happening, the IETF did not stop all work on routing protocols while this new routing architecture is developed. New architecture's are difficult things, take a long time to develop, and come with considerable risk. For comparison the extension of BGP3 to BGP4 was a much more limited undertaking with a resulting lower risk. I think most people would agree it would not have been a good idea to delay fixing the routing problems addressed by CIDR and wait for NIMROD to be developed even though they both started around the same time. I believe the issue is the same for IPng. All of the IPng candidates fall within the existing Internet architecture. As Steve Deering points out they are all implementations of the same architecture. As a result I think they all can work and are valid candidates for a new version of IP. They differ in many details (address size, address type, header layout, new features, etc.) but from an architectural sense they are not very different. From an implementation sense they are, of course, very different. Implementation issues are very important, but that is another topic. Based on this I think it is very reasonable for the IETF to select one of the IPng candidates to replace IPv4. The basic problem they all target (routing and addressing) will work fine. With time we will find out if some of the new features that are introduced (for example SIPP flow ID, CATNIP address compressions, etc.) work as expected, but the key problem which is being addressed is well in hand. We still have to work out implementation issues (address size, header formats, etc.) inorder to select one, but these issues are not architectural in nature. If you believe that a new Internet architecture needs to be developed, then I think you should develop one. This is the IETF approach. When it is done, we can all evaluate it and if the IETF thinks it is an improvement over the current Internet architecture, it will be adopted. The way to make a new architecture happen in the IETF is to build it! There are, of course, considerable risks in undertaking the development of a new architecture. "Pandora's box" comes to mind. It would be hard to predict when it would be done and sufficiently proven to risk moving the Internet to it. I think a much better approach for the IETF is to select one of the IPng candidates instead of waiting for a new internet architecture to be developed. Bob From owner-Big-Internet@munnari.OZ.AU Tue May 24 06:40:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11874; Tue, 24 May 1994 05:54:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA04278; Tue, 24 May 1994 05:24:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA04275; Tue, 24 May 1994 05:11:39 +1000 Precedence: list Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27826; Tue, 24 May 1994 00:03:03 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa06849; 23 May 94 10:02 EDT To: Jon Crowcroft Cc: big-internet@munnari.OZ.AU Subject: Re: NSAPs, etc In-Reply-To: Your message of Mon, 23 May 1994 08:37:07 +0100. <9405231008.19153@munnari.oz.au> Date: Mon, 23 May 1994 10:01:25 -0400 From: John Curran Message-Id: <9405231002.aa06849@nic.near.net> -------- From: Jon Crowcroft Subject: NSAPs, etc Date: Mon, 23 May 94 08:37:07 +0100 ... reasons include: unbounded recursive address growth ... Just curious, Jon: Do you see recursive address growth as a desirable feature to be sought after or do you see it as a significant hazard to be avoided? /John From owner-Big-Internet@munnari.OZ.AU Tue May 24 07:42:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14962; Tue, 24 May 1994 07:33:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA04323; Tue, 24 May 1994 07:04:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA04320; Tue, 24 May 1994 07:03:09 +1000 Precedence: list Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00399; Tue, 24 May 1994 01:00:28 +1000 (from curtis@ans.net) Received: by interlock.ans.net id AA23363 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 23 May 1994 11:00:12 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 23 May 1994 11:00:12 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 23 May 1994 11:00:12 -0400 From: Curtis Villamizar Message-Id: <199405231456.AA33854@foo.ans.net> To: martillo@penril.com (Joachim Martillo) Cc: bmanning@is.rice.edu, avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@thurifer.harvard.edu, curtis@ans.net Subject: Re: Missing In Action In-Reply-To: (Your message of Sun, 22 May 94 07:38:43 EDT.) <9405221138.AA17197@penril.penril.com> Date: Mon, 23 May 94 10:56:56 -0500 > And as for internetworking itself, my Mom has a small extremely > lucrative accounting firm with several locations in NJ and NY. She > has a multiprotocol internet whose protocols are Novell IPX and > Appletalk which do not suffer from the historical complexity of DARPA > IP or from the increasing complexity associated with general stupidity > of IETF specifications (especially SNMP, PPP and OSPF). I seriously doubt that you mother wants to see the server broadcasts from every IPX server in NY and NJ, let alone a globally connected internet. What she might be able to benefit from is an IP connection so she could set up an encapsulated tunnel between sites. The economics may not be on her side for a few offices in NY and NJ. If it was NY and CA or NY and London, then it certainly would be. In any case, I seriously doubt that the bgpd and big-internet lists are not terribly interested in your mother's internet. The are some who beleive that this IP complexity that you complaining about is what makes IP scale to the size of the global Internet rather than just the size of you mother's internet. Curtis From owner-Big-Internet@munnari.OZ.AU Tue May 24 08:54:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17463; Tue, 24 May 1994 08:54:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA04369; Tue, 24 May 1994 08:24:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA04366; Tue, 24 May 1994 08:15:37 +1000 Precedence: list Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17181; Tue, 24 May 1994 08:43:50 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 24 May 1994 07:43:23 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id HAA15511; Tue, 24 May 1994 07:43:22 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA26531; Tue, 24 May 94 07:43:21 JST Date: Tue, 24 May 94 07:43:21 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405232243.AA26531@cactus.slab.ntt.jp> To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: NSAPs, etc > > For about 15 years we have been trying to do protocol relaying, > translation, tunneling, munging, and so forth to permit a > multiprotocol world to live at peace with itself > > one lesson is that where there are a number of claimants for Universal > schemes, you have to take a position. My position is one of > simplicity. SO for instanced, faced with trying to Unify NSAPs (which > subsume E.163 and E.164), IPv4 (which doesn't) and IPng, I would > advocate that the higherst level of addressing do _not_ subsume all > the others. i.e. do _not_ embed any or all kitchen sink addresses in > IPng, except as some exceptional hack... > I can't agree more. The only addresses that make sense in a given architecture are those that have some resemblance to the topology. Anything else in the address only serves to complicate matters.... PF From owner-Big-Internet@munnari.OZ.AU Tue May 24 09:54:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19818; Tue, 24 May 1994 09:54:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA04404; Tue, 24 May 1994 09:24:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA04401; Tue, 24 May 1994 09:22:19 +1000 Precedence: list Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19649; Tue, 24 May 1994 09:50:45 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.7/8.6.4) with SMTP id RAA20036; Mon, 23 May 1994 17:49:32 -0600 From: "Peter S. Ford" Message-Id: <199405232349.RAA20036@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: NSAPs, etc In-Reply-To: Your message of Tue, 24 May 94 07:43:21 +0200. <9405232243.AA26531@cactus.slab.ntt.jp> Date: Mon, 23 May 94 17:49:32 MST While I agree that aligning addresses with the topology is a good thing, it is not the ONLY thing that needs to be built into the requirements for addressing. We need addresses that are easy to assign, manage and easy to maintain in light of topological changes. These sort of requirements at first blush may appear to complicate matters, but in fact, by simplifying the ability to number/renumber systems and networks they become enablers. Delegated allocation of addresses where each delegation allows independent routing and addressing plans are a good thing and I believe a requirement. It is also the case that not everyone is going to agree on the best match of their internetwork topology and hierarchical routing. By allowing people to build their own hierarchy and enabling them to glue their systems together at the upper levels of the global Internet you can accommodate the diversity and still get a routable system using an interdomain protocol such as BGP/IDPR. Reserving high order bits in an addressing plan for future use is not much different from establishing a code point. They both accommodate new addressing plans as they come about in the future. As Jon has pointed out this capability allows taking an old addressing and routing plan recursively catenating it to a new addressing and routing plan which is still usable for hierarchical routing. cheers, peter From owner-Big-Internet@munnari.OZ.AU Tue May 24 10:14:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20765; Tue, 24 May 1994 10:14:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA04425; Tue, 24 May 1994 09:44:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA04420; Tue, 24 May 1994 09:31:16 +1000 Precedence: list Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20015; Tue, 24 May 1994 09:58:34 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 24 May 1994 08:57:48 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA16119; Tue, 24 May 1994 08:57:47 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA27359; Tue, 24 May 94 08:57:47 JST Date: Tue, 24 May 94 08:57:47 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405232357.AA27359@cactus.slab.ntt.jp> To: francis@goshawk.lanl.gov, peter@goshawk.lanl.gov Subject: Re: NSAPs, etc Cc: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU > > While I agree that aligning addresses with the topology is a good > thing, it is not the ONLY thing that needs to be built into the > requirements for addressing. We need addresses that are easy to > assign, manage and easy to maintain in light of topological changes. > These sort of requirements at first blush may appear to complicate > matters, but in fact, by simplifying the ability to number/renumber > systems and networks they become enablers. Delegated allocation of > addresses where each delegation allows independent routing and > addressing plans are a good thing and I believe a requirement. I agree with this last sentence. However, I feel it is possible and perferable to allow such independent plans without explicitly encoding ownership of the delegation in the address....ie, give them blocks that they can play with, but don't feel you need to makes those blocks part of the addressing plan per se. Case in point is CIDR allocation. Jon gives a block to APNIC. He says nothing to APNIC about how to sub-allocate from that block. Thus, APNIC has some freedom about how to do its routing and addressing plans. However, there is no field in the IP CIDR address that says "which NIC". Peter, I think we are in agreement about requirements, and in disagreement about how best to go about acheiving them. I think the bit we disagree on is subtle but important.... PF From owner-Big-Internet@munnari.OZ.AU Tue May 24 10:46:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16230; Tue, 24 May 1994 08:13:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA04345; Tue, 24 May 1994 07:44:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA04342; Tue, 24 May 1994 07:37:55 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10413; Tue, 24 May 1994 05:11:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03574; Mon, 23 May 94 15:11:23 -0400 Date: Mon, 23 May 94 15:11:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9405231911.AA03574@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, hinden@eng.sun.com Subject: Re: Thoughts on the IPng situation... Cc: jnc@ginger.lcs.mit.edu From: hinden@eng.sun.com > We're going to get a new (i.e. revised) architecture, as the services > provided by the internetwork layer get upgraded ... The only question > this community gets to answer is "do we do this in a planned way, or > not?" ..... Correct me if I have this wrong, but you do not believe the current routing protocols used in the internet ... are adequate and a new routing architecture is needed. ... When NIMROD is completed it will be evaluated ... while this is happening, the IETF did not stop all work on routing protocols while this new routing architecture is developed. Yes, and as you no doubt also recall, I was one of the people who pushed for adopting BGP as an interim solution (when there was some resistance, some time ago)! :-) I do understand both the need for, and the the value of, interim solutions. I think most people would agree it would not have been a good idea to delay fixing the routing problems addressed by CIDR and wait for NIMROD to be developed even though they both started around the same time. I believe the issue is the same for IPng. Ah, but note that CIDR is a patch to existing stuff; a pretty elegant patch, mind you, but a patch. It also has a limited impact; routers will be affected, but not hosts. With interim solutions, you have to go through a cost/benfit analysis to see if the cost of the patch is worth what it buys you. My sense was that it was worth it for BGP, and CIDR. I don't have the same sense with the current IPng proposals. I think it is very reasonable for the IETF to select one of the IPng candidates to replace IPv4. But, if a reasonably long-lasting fix to address depletion were the issue, I'd have looked at patches which were less costly and obtrusive than a whole new internetworking layer for all the hosts; say an "extended address" IP option, or something like the original IPAE design; maybe NAT boxes, with a new addressing/routing architecture to tie them together, and some minor fixes to protocols like FTP that want to include addresses. There are, of course, considerable risks in undertaking the development of a new architecture. ... It would be hard to predict when it would be done and sufficiently proven to risk moving the Internet to it. True. I think a much better approach for the IETF is to select one of the IPng candidates instead of waiting for a new internet architecture to be developed. Well, I guess we aren't going to agree on this, so it's not worth arguing this point. Noel From owner-Big-Internet@munnari.OZ.AU Tue May 24 10:56:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21485; Tue, 24 May 1994 10:34:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA04455; Tue, 24 May 1994 10:04:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA04430; Tue, 24 May 1994 09:46:17 +1000 Precedence: list Received: from goshawk.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20767; Tue, 24 May 1994 10:14:19 +1000 (from peter@goshawk.lanl.gov) Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.7/8.6.4) with SMTP id SAA20253; Mon, 23 May 1994 18:13:30 -0600 From: "Peter S. Ford" Message-Id: <199405240013.SAA20253@goshawk.lanl.gov> X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: big-internet@munnari.OZ.AU Subject: Re: NSAPs, etc In-Reply-To: Your message of Tue, 24 May 94 08:57:47 +0200. <9405232357.AA27359@cactus.slab.ntt.jp> Date: Mon, 23 May 94 18:13:30 MST Paul, At present it is trivial to look at the recent IP CIDR allocation and determine who the high level addressing authority is. For example: 193/8 is well understood to be the RIPE NCC. Most operators like having this degree of address assignment coding in their addresses. We might disagree whether this is a fixed width field (8 bits) or a variable length field with a prefix length of 8. Are we simply disagreeing on fixed width vrs variable width fields for encoding this information? I suspect I am on the side of the simplicity of fixed, known widths of top level assignments with tons of room for future growth of addressing plans and also to reserve address space for future growth. cheers, peter From owner-Big-Internet@munnari.OZ.AU Tue May 24 14:52:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28810; Tue, 24 May 1994 13:35:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA04489; Tue, 24 May 1994 13:04:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA04486; Tue, 24 May 1994 12:59:30 +1000 Precedence: list Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22128; Tue, 24 May 1994 10:46:04 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA06352; Mon, 23 May 94 20:45:26 EDT Message-Id: <9405240045.AA06352@tipper.oit.unc.edu> To: "Peter S. Ford" Cc: francis@cactus.slab.ntt.jp (Paul Francis), J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: NSAPs, etc In-Reply-To: Your message of "Mon, 23 May 94 17:49:32 MST." <199405232349.RAA20036@goshawk.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 May 94 20:45:26 -0400 From: Simon E Spero If we do end up with 64bit EIDs which don't have to always double as locators, then there is a good case to be made for grandfathering at least two schemes. Allocating 2^32 values to subsume the existing IP address space would make transitioning a little easier, especially if IPNG is deployable before IPV4 Judgment Day. Allocating 2^48 values to correspond to IEEE addresses would also make sense, as if the numbers are already out there, it makes sense to use them. Simon From owner-Big-Internet@munnari.OZ.AU Tue May 24 14:53:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02458; Tue, 24 May 1994 14:53:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA04517; Tue, 24 May 1994 14:24:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA04514; Tue, 24 May 1994 14:21:06 +1000 Precedence: list Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28499; Tue, 24 May 1994 13:28:14 +1000 (from jcurran@nic.near.net) Received: from platinum.near.net by nic.near.net id aa20791; 23 May 94 23:27 EDT To: Paul Francis Cc: francis@goshawk.lanl.gov, peter@goshawk.lanl.gov, J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: NSAPs, etc In-Reply-To: Your message of Tue, 24 May 1994 08:57:47 +0200. <9405232357.AA27359@cactus.slab.ntt.jp> Date: Mon, 23 May 1994 23:26:54 -0400 From: John Curran Message-Id: <9405232327.aa20791@nic.near.net> -------- ] From: Paul Francis ] Subject: Re: NSAPs, etc ] Date: Tue, 24 May 94 08:57:47 JST ] ... ] I agree with this last sentence. However, I feel it is possible ] and perferable to allow such independent plans without explicitly ] encoding ownership of the delegation in the address....ie, give ] them blocks that they can play with, but don't feel you need to ] makes those blocks part of the addressing plan per se. ] ] Case in point is CIDR allocation. Jon gives a block to APNIC. He ] says nothing to APNIC about how to sub-allocate from that block. ] Thus, APNIC has some freedom about how to do its routing and ] addressing plans. However, there is no field in the IP CIDR ] address that says "which NIC". Right. An indication of the assignment authority may not be necessary, but I do see a requirement for encoding the size of the address into the address itself for those schemes which are advocating variable size addresses. This was the essence of my question to Jon Crowcroft: variable addresses which do not explicitely encode the particular address family in the assignment allow for downward recursive expansion, even if not desired. /John From owner-Big-Internet@munnari.OZ.AU Tue May 24 17:02:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13017; Tue, 24 May 1994 06:33:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA04300; Tue, 24 May 1994 06:04:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA04297; Tue, 24 May 1994 06:01:10 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29367; Tue, 24 May 1994 00:38:18 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405231438.29367@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 23 May 1994 15:38:01 +0100 To: John Curran Cc: big-internet@munnari.OZ.AU Subject: Re: NSAPs, etc In-Reply-To: Your message of "Mon, 23 May 94 10:01:25 EDT." <9405231002.aa06849@nic.near.net> Date: Mon, 23 May 94 15:37:58 +0100 From: Jon Crowcroft > reasons include: > unbounded recursive address growth >Just curious, Jon: Do you see recursive address growth as a >desirable feature to be sought after or do you see it as a >significant hazard to be avoided? John where the recursion is mutual between a number of different assigning authorities, it is a bad thing within a given protocol domain, and within a given management domain, it is constructive... jon From owner-Big-Internet@munnari.OZ.AU Tue May 24 19:33:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13114; Tue, 24 May 1994 19:33:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA04558; Tue, 24 May 1994 19:04:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA04555; Tue, 24 May 1994 19:03:30 +1000 Precedence: list Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13057; Tue, 24 May 1994 19:31:51 +1000 (from martillo@penril.com) Received: from penril.penril.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwrgg21094; Tue, 24 May 94 05:31:17 -0400 Received: from speedo.penril.com by penril.penril.com (4.1/SMI-4.1) id AA18128; Tue, 24 May 94 04:58:39 EDT Date: Tue, 24 May 94 04:58:39 EDT From: martillo@penril.com (Joachim Martillo) Message-Id: <9405240858.AA18128@penril.penril.com> Received: by speedo.penril.com (4.1/SMI-4.1) id AA24718; Tue, 24 May 94 05:28:24 EDT To: curtis@ans.net Cc: avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, curtis@ans.net, martillo@penril.com In-Reply-To: Curtis Villamizar's message of Mon, 23 May 94 10:42:47 -0500 <199405231442.AA43070@foo.ans.net> Subject: Introducing proxy aggregations? From: Curtis Villamizar Date: Mon, 23 May 94 10:42:47 -0500 > Penril Datability Networks has three networked locations in Maryland, > New Jersey and Massachusetts. All locations have multiprotocol > internetworks supporting DARPA IP, DECNET, AppleTalk and Novell > Netware. Because no internetworking provider can offer the kind of > multiprotocol internetworking services which we require, we build our > own internal wide-area multiprotocol communications subnet. > Eventually when some internetworking provider transcends DARPA IP > blinders, that provider will make a lot of money in offering a useful > service. The Internet does carry CLNP and IPX and Appletalk and SNA. All are encapsulated in IP. This approach is completely retro and is simply a holdover from days gone by when multiprotocol routers and multiprotocol comms subnets were far less common. Just consider how stupid it is to go through all the trouble of resolving an IPX, Appletalk or SNA address to some IP/TCP or IP/UDP address/port pair and then ship it through an IP internet when you could just ship it directly through a multiprotocol internet. Certainly with most local area technologies the multiprotocol comms subnet approach has won out as most reasonable. Certainly, debugging topological problems is easier in the multiprotocol approach. (In the encapsulated approach -- an apparent IPX problem might really be a problem in the underlying IP layer). Protocol specific optimization is obviously easier in the multiprotocol internet approach. The encapsulation approach also makes satisfying the requirements of non-IP protocols practically impossible in many cases. Just consider the infamous IPX RIP/SAP gap requirement. The persistence of the encapsulation approach despite a better more modern technology and formalism suggests that some vendors are simply unable to produce a high perfromance multiprotocol router perhaps because the code base is so misdesigned that adding new protocols is extremely hard or requires a major performance hit. Faced with such a situation the smart vendor does some heavy powered high quality marketing to present an attrocious architecture as God's gift to computer networking. Generally IPX, SNA, and Appletalk users want a virtual private network so there has been little attempt to provide anything but (some people claim that there is a market for an IPX Internet or SNA Internet). I think IPX and Appletalk users want essentially the same things that IP users want: remote login, E-Mail, file transfer, remote file systems and EBBSes. I am puzzled that people somehow think this makes sense in the IP arena but not in the IPX and Appletalk arena. There is a connected OSI NSFNET service, but the traffic levels are patheticly low (generally << 10^-5 of IP, some months < 10^-6), so there has been very little incentive to provide native CLNP. We have exceeded 10^+9 IP packets per day avergaed over a month. How much OSI traffic do you see on the Penril networks? How much IP traffic? BTW - traffic stats for NSFNET can be ftp'd from merit.edu. Actually, we don't see any ISO OSI traffic, and I rather wish there was no requirement to support the stuff. But on the other hand we have a tremendous amount of IPX, Appletalk and DECNET traffic in addition to the IP traffic. At times the non-IP traffic overwhelms the IP traffic, in which situation the non-IP traffic should be processed as quickly and with as high a performance as possible. Curtis Joachim Martillo Manager of Internetworking Research Penril Datability Networks Datability Advanced Communications Research Center 251 West Central Street Natick, MA 01761 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com From owner-Big-Internet@munnari.OZ.AU Tue May 24 20:13:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14515; Tue, 24 May 1994 20:13:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA04605; Tue, 24 May 1994 19:44:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA04599; Tue, 24 May 1994 19:39:04 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14311; Tue, 24 May 1994 20:07:25 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9405241007.14311@munnari.oz.au> Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 24 May 1994 11:02:18 +0100 To: martillo@penril.com (Joachim Martillo) Cc: farrache@ccpnxt5.in2p3.fr, jh@funet.fi, bmanning@edu.rice.is, avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Missing In Action In-Reply-To: Your message of "Tue, 24 May 94 05:14:08 EDT." <9405240914.AA18131@penril.penril.com> Date: Tue, 24 May 94 11:02:12 +0100 From: Jon Crowcroft >Unfortunately, the router vendors have done such an exceptional >marketing job that they have developed a chorus of router groupies >whose activities in ridiculous organizations like the IETF practically >kill any possibility of high-quality engineering in the computer >networking arena. If the IETF is rediculous, how could it kil lthe possibility of high quality engineering? does not compute. noone in the IETF is suggesting replacing PDH or SDH (pace, SONET) muxes with routers.....yet... jon From owner-Big-Internet@munnari.OZ.AU Tue May 24 20:15:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14565; Tue, 24 May 1994 20:15:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA04620; Tue, 24 May 1994 19:46:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA04602; Tue, 24 May 1994 19:42:22 +1000 Precedence: list Received: from ncc.ripe.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14349; Tue, 24 May 1994 20:10:48 +1000 (from marten@ripe.net) Received: from rijp.ripe.net by ncc.ripe.net with SMTP id AA03266 (5.65a/NCC-2.2); Tue, 24 May 1994 12:09:34 +0200 Received: from localhost.ripe.net by rijp.ripe.net with SMTP id AA08884 (5.65a/NCC-2.2); Tue, 24 May 1994 12:09:33 +0200 Message-Id: <9405241009.AA08884@rijp.ripe.net> To: martillo@penril.com (Joachim Martillo) Cc: bgpd@merit.edu, big-internet@munnari.OZ.AU Subject: Re: Missing In Action In-Reply-To: Your message of Tue, 24 May 1994 05:14:08 EDT. <9405240914.AA18131@penril.penril.com> From: Marten Terpstra X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5064 X-Fax: +31 20 592 5090 Date: Tue, 24 May 1994 12:09:32 +0200 Sender: Marten.Terpstra@ripe.net martillo@penril.com (Joachim Martillo) writes * Unfortunately, the router vendors have done such an exceptional * marketing job that they have developed a chorus of router groupies * whose activities in ridiculous organizations like the IETF practically * kill any possibility of high-quality engineering in the computer * networking arena. Nice speech. You should go into politics. However, I fail to see the relation to the BGPD list in all this. Could you please move this discussion to a list where this is relevant and people may be more interested in these things? -Marten From owner-Big-Internet@munnari.OZ.AU Tue May 24 20:49:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13852; Tue, 24 May 1994 19:53:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA04579; Tue, 24 May 1994 19:24:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA04574; Tue, 24 May 1994 19:19:35 +1000 Precedence: list Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13618; Tue, 24 May 1994 19:48:02 +1000 (from martillo@penril.com) Received: from penril.penril.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwrgh22358; Tue, 24 May 94 05:46:47 -0400 Received: from speedo.penril.com by penril.penril.com (4.1/SMI-4.1) id AA18131; Tue, 24 May 94 05:14:08 EDT Date: Tue, 24 May 94 05:14:08 EDT From: martillo@penril.com (Joachim Martillo) Message-Id: <9405240914.AA18131@penril.penril.com> Received: by speedo.penril.com (4.1/SMI-4.1) id AA25098; Tue, 24 May 94 05:43:53 EDT To: farrache@ccpnxt5.in2p3.fr Cc: jh@funet.fi, bmanning@is.rice.edu, avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@penril.com In-Reply-To: Gilles Farrache's message of Tue, 24 May 94 11:29:19 MET DST <9405240929.AA01865@ccpnxt5.in2p3.fr.> Subject: Missing In Action Date: Tue, 24 May 94 11:29:19 MET DST From: farrache@ccpnxt5.in2p3.fr (Gilles Farrache) >Penril Datability Networks is actually just finishing up a product >which could be used to provide such functionality. It is a modular Thank you for the advertisement ... What you have to know is that now in Europe the problem is not related to routers but to leased line prices to give you mom what she wants..... Actually, it was not an advertisement because the device is not released yet and won't be for a while. But it is an example of what I believe is a necessary component in a well-designed wide area backbone. And this belief has nothing to do with Penril. When I was a Clearpoint and when I was a Prime, I could not but view this mania for building wide-area backbones with routers as anything but some sort of weird lemming-like aberration. For years now, I have been building wide-area backbones with devices that are essentially multiprotocol IMPs (and which were not manufactured by Penril). It is a simple straightforward, relatively inexpensive, easily debuggable approach. Unfortunately, the router vendors have done such an exceptional marketing job that they have developed a chorus of router groupies whose activities in ridiculous organizations like the IETF practically kill any possibility of high-quality engineering in the computer networking arena. Gilles Farrache Joachim Martillo Manager of Internetworking Research Penril Datability Networks Datability Advanced Communications Research Center 251 West Central Street Natick, MA 01761 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com From owner-Big-Internet@munnari.OZ.AU Tue May 24 20:50:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15161; Tue, 24 May 1994 20:33:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA04645; Tue, 24 May 1994 20:05:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA04636; Tue, 24 May 1994 19:49:23 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06805; Tue, 24 May 1994 03:31:44 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA00283; Mon, 23 May 94 12:32:37 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ar04889; 23 May 94 17:29 GMT Date: Mon, 23 May 94 11:40 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Cc: bound Subject: Re: Thoughts on the IPng situation... Message-Id: <60940523164006/0003858921NA5EM@mcimail.com> >Some questions if you can find the time )---> thanks. And I should make more time for this subject... >>That is the DOS/Windows migration plan. Forget your UNIX work, it does >>not represent a significant number of install machines in the corporate >>world (yes I help set Chrysler Finance up with 3,000+ NeXtstep systems). >I have always believed this is more than just a network layer problem as >I have stated in mail and an IPng White Paper. Is this what your >pointing at for DOS/Windows migration plan? Is this an API issue too. Yes, API is important. There is an emerging API for Windows, WinSock (oddly enough :). I have recently learned of some issues I need to take to the 2.0 people (what do you mean, no DNS TXT record support?). But given an IPng, the WinSock people can do some good work. >One argument I am developing which brings new light into the need for >an API is that any transition 'effector' needs to be understood and then >acted upon by the IPng transition technical plan. Moving applications >to IPng are a clear transition issue because we have changed the core >component of TCP/IP. I agree with you but can you give us a few more >high level details regarding what needs to be done in your professional >opinion as an individual of course. An IPng will add new calls to an API and break some old calls, almost no matter how hard we try. But an API consortium, like the WinSock group, if kept on track and not becoming a balloon, can make the transition happen faster. We are fortunate in the Windows world on how well WinSock is catching on. >>Now all too many DOS/Windows systems are already running dual stack, IP >>and IPX. It might actually happen later this year that Novell will really >>get NWIP to the point that it can be used large scale, but my colleagues >>that do IPX are not holding their breath. >So are you saying that you can see some transition where companies could >say just put IPng on the machine and no other stack? I personally can >see this as a customer network strategy and why I really believe we need >to be prepared for the non-dual-stack transition case. YES! IP -> IPng or forget it. More on this a little further down... >Would you want network software that would let the IPng machines that >become IPng only interoperate with old IPv4 machines during the >transition to avoid a flag day? Yes we work in 'workgroups'. Yes we worship the 80/20 rule. But that 20% can be very important. So the transition says that SERVERS could be made dual stack if we must (and only servers). Then workgroups are reprovisioned with IPng along with some other niceties that justify the work (and this will vary by workgroup). Of course there will always be some server that will lag behind and this is where some good work on a IPng->IP NAT type box will be needed. This might be a firewall box completely internal with no security, just taking advantage of all of the firewall proxy smarts. I might note that DUAL stack even on servers will not go over too well. This is a manageablity issue. One more source of user calls of something wrong. Even servers should keep the number of stacks down. >>This tends to lead me, personally, to be very much concerned about a dual >>stack transition. I want to REPLACE the IP kernel in DOS with an IPng >>kernel. Yes I have worked with DLL implementations and found them >>lacking. Perhaps we will soon have VxD implementations, but that is VERY >>hard and I would doubt if an IPng would do that out the door. >I have many concerns technically that assumes a dual stack ONLY >transition too. Where we can avoid it, why, and how, are questions I am >beginning to ask my self too. Can you expound a bit more on the above? We already have 2 stacks on DOS/Windows. Don't expect 3. And as I said, if NWIP works, noone will want to go back to 2 stacks. And don't you DARE base it on Chicago saving your *(*&*&*(&. Or I will scream bloody murder on every IETF list! To few organizations will change an OS just to get the latest networking on the workstation. Chicago will or will not make it on its own. It is SUPPOSED to be a transparent addition to our workgroups (too bad IPng won't feel the same :). So it will start slow and then become, perhaps the OS for new units. And then the retrofit. But with IPng, we will want to download software to the workstations and let them reboot into IPng. We are doing this today in moving groups of users from NETX to VLMs (changing NET.CFG, WIN.INI, SYSTEM.INI, CONFIG.SYS, and AUTOEXEC.BAT along the way) So you may wonder, then why SIPP over TUBA, just skip the TUBA dual stack transition except on servers. More on this later (I hope, lunch time is almost over :). >>The next big criteria is address migration. I would want a clean port of >>my IP addresses to IPng addresses. In the past year, the corporate side >>of our network (still waiting on numbers from engineering) went from 3,000 >>IP interfaces to 8,800 interfaces (according to our HP OpenView). >>Dreaming up a new addressing scheme is not all that much fun. As it is we >>are fighting a DNS/X.500/NDS naming fight... >Would a clean port be using the IPv4 address as the low order bits of >the IPng address for transition and continued IPng/IPv4 interoperation >as proposed by SIPP Transition be a valid approach to review? YES! There is one thing creaping up on us here that I am the cuase of. Uses are learning that they have an FTPD for Windows and are telling their colleagues in other areas just to FTP directly to them for the files instead of trying to get security access to the right server. So the IPng/IPv4 interoperation will be important by the time we get to it. >What do you expect the vendor community to do once IPv4 addresses run >out and you can't get anymore from IANA or whoever will be passing them >out? This right now is the transition cut-off right now? It won't be >the same as a proprietary protocol being maintained for compatibility >because its owned by a standards body and right now there are no plans >in anyones proposal for the IETF standards to support IPv4 in a >multivendor manner after IPv4 runs out. I've already done something about it for Chrysler, 1597. We are already using addresses designated by it. As far as Chrysler is concerned, IANA ran out of addresses; the pain for requesting addresses to meet internal goals exceed the value. 1597 created a framework, more acceptable to management so that we could 'do what ya gotta do'. If you people continue to bury us in delayed futures, the new lore of the INTERNET will be, get your CIDR block, set up your firewall and go! Yes MBONE might be a problem for some firewalls, and not others; and the list goes on. The INTERNET is balkinizing. The force at work is security. The hidden fear is addresses. Ramble, ramble, ramble... >>So from where I stand today (and granted I have only scanned the drafts), >>SIPP looks good to me and I would recommend it to my colleagues. But then >>if I am shown how easy the same items are with TUBA or CATNIP, or TURNIPP, >>I could end up needing to reconsider. My voice carries some weight here. >>But this is not Chrysler's position, yet. >From what you have seen of the networking mixed bag of tricks to get >interoperation working what do you see as the top 5 most critical must >do's for IPng Transition (if you want to give 10 then thats good too)? Out of time. I hope to address this tomorrow or the next day... Bob From owner-Big-Internet@munnari.OZ.AU Tue May 24 21:13:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16148; Tue, 24 May 1994 21:13:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA04676; Tue, 24 May 1994 20:44:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA04671; Tue, 24 May 1994 20:41:23 +1000 Precedence: list Received: from ccpngw.in2p3.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13017; Tue, 24 May 1994 19:29:25 +1000 (from farrache@ccpnxt5.in2p3.fr) Received: by ccpngw.in2p3.fr (5.57/Ultrix2.4-C-3) id AA07892; Tue, 24 May 94 11:29:20 +0200 Received: by ccpnxt5.in2p3.fr. (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA01865; Tue, 24 May 94 11:29:19 MET DST Date: Tue, 24 May 94 11:29:19 MET DST From: farrache@ccpnxt5.in2p3.fr (Gilles Farrache) Message-Id: <9405240929.AA01865@ccpnxt5.in2p3.fr.> Received: by NeXT Mailer (1.63) To: martillo@penril.com (Joachim Martillo) Subject: Re: Missing In Action Cc: jh@funet.fi, bmanning@is.rice.edu, avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@penril.com >Penril Datability Networks is actually just finishing up a product >which could be used to provide such functionality. It is a modular Thank you for the advertisement ... What you have to know is that now in Europe the problem is not related to routers but to leased line prices to give you mom what she wants..... --- Gilles Farrache Centre de Calcul de l'IN2P3 29 boulevard du 11 Novembre 1918 69622 Villeubanne Cedex e-mail : farrache@ccpnxt5.in2p3.fr phone : +33 78 93 08 80 From owner-Big-Internet@munnari.OZ.AU Tue May 24 21:15:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16200; Tue, 24 May 1994 21:15:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA04691; Tue, 24 May 1994 20:46:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA04668; Tue, 24 May 1994 20:41:12 +1000 Precedence: list Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12293; Tue, 24 May 1994 19:05:33 +1000 (from martillo@penril.com) Received: from penril.penril.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwrge19521; Tue, 24 May 94 05:05:17 -0400 Received: from speedo.penril.com by penril.penril.com (4.1/SMI-4.1) id AA18124; Tue, 24 May 94 04:32:39 EDT Date: Tue, 24 May 94 04:32:39 EDT From: martillo@penril.com (Joachim Martillo) Message-Id: <9405240832.AA18124@penril.penril.com> Received: by speedo.penril.com (4.1/SMI-4.1) id AA24076; Tue, 24 May 94 05:02:24 EDT To: jh@funet.fi Cc: bmanning@is.rice.edu, avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU, martillo@penril.com In-Reply-To: Juha Heinanen's message of Mon, 23 May 1994 19:34:23 +0300 <199405231635.MAA27524@merit.edu> Subject: Missing In Action Actually, what my mother needs is a private multiprotocol version of the original Arpanet (i.e. a multiprotocol backbone fully connected switching fabric wide-area communications subnet). Penril Datability Networks is actually just finishing up a product which could be used to provide such functionality. It is a modular bridge router/wide area packet switch which can support 16 serial interfaces with data rates up to 7 Mbps. There is a virtual wide area communications subnet capability in that each packet switch can be configured under software control to support multiple logical subpacket switches. Thus a collection of packet switches and links can actually be configured under software control as multiple completely separate wide-area switching fabric communications subnets. These separate communications subnets can be completely isolated from one another or can be joined by the multiprotocol router functionality or by the virtual multidrop connection capability. The logical subpacket switches support several alternative path selection procedures within a given communications subnet. If a connectivity provider used devices such as these to provide services to people like my mother, that provider would allocate some collection of links and logical subpacket switches to each user as a private comms subnet. This comms subnet would be a wide area backbone network within a given customers internet. In contrast, FR would be a little complex in providing full connectivity of sites. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Datability Advanced Communications Research Center 251 West Central Street Natick, MA 01761 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com From owner-Big-Internet@munnari.OZ.AU Wed May 25 02:14:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28021; Wed, 25 May 1994 02:14:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA04803; Wed, 25 May 1994 01:45:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA04800; Wed, 25 May 1994 01:39:59 +1000 Precedence: list Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24731; Wed, 25 May 1994 00:57:17 +1000 (from pst@cisco.com) Received: from localhost.cisco.com by cider.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id HAA08889; Tue, 24 May 1994 07:55:27 -0700 Message-Id: <199405241455.HAA08889@cider.cisco.com> X-Authentication-Warning: cider.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: martillo@penril.com (Joachim Martillo) Cc: curtis@ans.net, avg@sprint.net, bgpd@merit.edu, big-internet@munnari.OZ.AU Subject: Re: Introducing proxy aggregations? In-Reply-To: Your message of "Tue, 24 May 1994 04:58:39 EDT." <9405240858.AA18128@penril.penril.com> Date: Tue, 24 May 1994 07:55:26 -0700 From: Paul Traina Will you kindly move this topic to a more appropriate mailing list? Get this crud off of bgpd now. From owner-Big-Internet@munnari.OZ.AU Wed May 25 02:20:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28340; Wed, 25 May 1994 02:20:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA04818; Wed, 25 May 1994 01:52:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA04797; Wed, 25 May 1994 01:39:09 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23807; Wed, 25 May 1994 00:38:01 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25941 Wed, 25 May 1994 00:37:43 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA06898; Tue, 24 May 94 10:33:34 EDT Message-Id: <9405241433.AA06898@tipper.oit.unc.edu> To: Jon Crowcroft Cc: martillo@penril.com (Joachim Martillo), farrache@ccpnxt5.in2p3.fr, jh@funet.fi, bmanning@edu.rice.is, avg@sprint.net, pst@cisco.com, bgpd@merit.edu, big-internet@munnari.OZ.AU Subject: Re: Missing In Action In-Reply-To: Your message of "Tue, 24 May 94 11:02:12 BST." <9405241007.14311@munnari.oz.au> Date: Tue, 24 May 94 10:33:33 -0400 From: Simon E Spero Being called ridiculous by Martillo is kind of like being called an asshole by John Palmer. Wear it as a badge of honour. From owner-Big-Internet@munnari.OZ.AU Wed May 25 04:18:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01810; Wed, 25 May 1994 03:54:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA04849; Wed, 25 May 1994 03:25:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA04846; Wed, 25 May 1994 03:05:28 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01140; Wed, 25 May 1994 03:33:51 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA21760; Tue, 24 May 94 12:34:59 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac23769; 24 May 94 17:32 GMT Date: Tue, 24 May 94 11:53 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Joachim Martillo To: big internet Subject: Re: IPX Missing In Action Message-Id: <44940524165344/0003858921NA1EM@mcimail.com> >> And as for internetworking itself, my Mom has a small extremely >> lucrative accounting firm with several locations in NJ and NY. She >> has a multiprotocol internet whose protocols are Novell IPX and >> Appletalk which do not suffer from the historical complexity of DARPA >> IP or from the increasing complexity associated with general stupidity >> of IETF specifications (especially SNMP, PPP and OSPF). >I seriously doubt that you mother wants to see the server broadcasts >from every IPX server in NY and NJ, let alone a globally connected >internet. What she might be able to benefit from is an IP connection >so she could set up an encapsulated tunnel between sites. The >economics may not be on her side for a few offices in NY and NJ. If >it was NY and CA or NY and London, then it certainly would be. What some people fail to see is that something that works great at a small level, like bridging IPX falls apart on a GRAND level. NetWare 3.11 uses SAPs a lot. And has a wall of death of 2,000 SAP broadcasts. Now don't think that this is hugh. Remember that every print server broadcasts AT LEAST 1 SAP, if not 3! I've been told that we are around 1,200 SAPs already and we are now having to implement additional filters to keep some SAPs on their campus. Not so easy. BTW, we route IPX, but SAPs have to be forwarded as they are broadcasts. Mr, Martillo, the network requirements of the world are big and this allows for a lot of solutions to be TRIED. But here, our experience is to demand that we be shown that it SCALES. IP has pasted this test. IPX has not. SNA has not (APPN is still untried). I have no experience with OSI to comment (I support those listed). Bob Moskowitz Chrysler Corp From owner-Big-Internet@munnari.OZ.AU Wed May 25 05:13:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05119; Wed, 25 May 1994 05:13:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA04875; Wed, 25 May 1994 04:45:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA04872; Wed, 25 May 1994 04:31:41 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04649; Wed, 25 May 1994 05:00:07 +1000 (from kre@munnari.OZ.AU) To: Simon E Spero Cc: "Peter S. Ford" , francis@cactus.slab.ntt.jp (Paul Francis), J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: NSAPs, etc In-Reply-To: Your message of "Mon, 23 May 1994 20:45:26 -0400." <9405240045.AA06352@tipper.oit.unc.edu> Date: Wed, 25 May 1994 05:00:04 +1000 Message-Id: <19735.769806004@munnari.OZ.AU> From: Robert Elz Date: Mon, 23 May 94 20:45:26 -0400 From: Simon E Spero Message-ID: <9405240045.AA06352@tipper.oit.unc.edu> Allocating 2^32 values to subsume the existing IP address space would make transitioning a little easier, especially if IPNG is deployable before IPV4 Judgment Day. Absolutely - I think this has always been part of the plan. One possibility that has sometimes also been mentioned is to actually take a larger set of values, say 2^40, and thus allocate 256 EIDs for every IP address currently assigned, while still only using 2^-24 of the total space. Allocating 2^48 values to correspond to IEEE addresses would also make sense, as if the numbers are already out there, it makes sense to use them. 2^46 actually, which is good, as its reasonable to then take the rest of that 2^48 space (3 * 2^46) and use that for GIDs (ie: EIDs for groups - if you like multicast EIDs). While putting this in the EID plan is reasonable, I'd not recommend the use of such EIDs in general, or not unless/until someone actually shows us a method by which they can be translated to names via some directory service that will work. kre From owner-Big-Internet@munnari.OZ.AU Thu May 26 12:26:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15773; Thu, 26 May 1994 11:18:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA00575; Thu, 26 May 1994 11:16:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA00572; Thu, 26 May 1994 11:14:29 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15592; Thu, 26 May 1994 11:14:17 +1000 (from barney@databus.databus.com) Date: Wed, 25 May 94 21:19 EDT Message-Id: <9405252120.AA15785@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU Subject: Re: IEEE 48-bit addresses Content-Length: 776 Content-Type: text > Allocating 2^48 values to correspond to IEEE addresses would also make > sense, as if the numbers are already out there, it makes sense to use them. Just today I discovered that SGI sends out replacement machines when one breaks, and since they use the IEEE addr as the machine's serial number, they "helpfully" make the replacement have the same IEEE address as the broken one. Unfortunately our guy who made the call to them didn't know that, and quoted the wrong serial number. The result, of course, was two machines with the same IEEE address, in the same organization. Since they were on different ethernet segs, it took us quite a while to realize this - if we hadn't been playing with bootp, we would *never* have known. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Fri May 27 02:17:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15350; Fri, 27 May 1994 01:37:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA01294; Fri, 27 May 1994 01:36:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA01291; Fri, 27 May 1994 01:33:07 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10357; Thu, 26 May 1994 23:25:59 +1000 (from Jacques.DUGAST@issy.cnet.fr) Received: from pamir.inria.fr by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20249 Thu, 26 May 1994 23:24:48 +1000 (from Jacques.DUGAST@issy.cnet.fr) X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 26 May 94 15:24:43+0200 X400-Received: by /PRMD=cnet/ADMD=ATLAS/C=FR/; Relayed; 26 May 94 15:22:08+0100 Date: 26 May 94 15:22:08+0100 From: "DUGAST Jacques CNET ISSY (Tel (1)45.29.43.74)" Message-Id: <76996932899190000dugast*/S=DUGAST/G=Jacques/OU=issy/PRMD=fr/ADMD=/@MHS> To: big-internet@munnari.OZ.AU Subject: Please subscribe jacques.dugast@issy.cnet.fr Importance: Normal Autoforwarded: False Thank you... PS : is there a FAQ and an anonymous server ? From owner-Big-Internet@munnari.OZ.AU Sat May 28 20:19:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18260; Sat, 28 May 1994 20:19:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA03524; Sat, 28 May 1994 20:17:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA03521; Sat, 28 May 1994 20:10:11 +1000 Precedence: list Received: from mercury.ukc.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17965; Sat, 28 May 1994 20:09:56 +1000 (from db15@ukc.ac.uk) Message-Id: <9405281009.17965@munnari.oz.au> Received: from stork by mercury.ukc.ac.uk with UKC POP3+ id aa21679; 28 May 94 11:08 BST Date: Sat, 28 May 94 11:08 BST From: Damiano Bolla To: big-internet@munnari.OZ.AU Subject: IPP ROuting Architecture From: db15@ukc.ac.uk (Damiano Bolla) Subject: IPP Routing Architecture Distribution: world Organization: University of Kent at Canterbury, UK. This report discusses the IPP routing architecture. What follows is an abstract of it. This is teh second edition of the report. Can you please give me an opinion about it ? You can find the Postscript version on host: eagle.ukc.ac.uk Using anonymous ftp under the directory: pub/db15/v3 -------------------------------------------------- Abstract This paper describes the structure of the IPP routing architecture. IPP is an evolution of the TCP-IP protocol. The main advantage of IPP is the variable length addressing scheme. An IPP address can be fifteen bytes long and is optimised for local area networks. The logical structure of the address is very similar to IP, with the main difference, that each byte specifies a subnet, apart from the last byte that indicates a host. Routing speed is maximised by the fact that all routing tables are accessed using a direct lookup method. The size of the routing tables within a router is fixed and small. The above two points allow the construction of very cheap and fast routers. This routing architecture supports broadcast, multicast and real time data. It uses different routing priorities for each type of service. This results in a better management of network links. For normal network traffic the link usage is maximised by automatically load balancing the usage of available links. A working router can be found in the part of this document describing the tests done on this architecture. IPP aims to keep all the other qualities of IP Eg: the method used to manage flow control, resequencing, etc.. The only things that changes are the structure of an address, the routing table and routing functions. Damiano From owner-Big-Internet@munnari.OZ.AU Sun May 29 12:59:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20398; Sun, 29 May 1994 12:59:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA04376; Sun, 29 May 1994 12:57:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA04362; Sun, 29 May 1994 12:51:27 +1000 Precedence: list Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20248; Sun, 29 May 1994 12:51:23 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa21040; 28 May 94 22:51 EDT To: Damiano Bolla Cc: big-internet@munnari.OZ.AU Subject: Re: IPP ROuting Architecture In-Reply-To: Your message of Sat, 28 May 1994 11:08:00 -0000. <9405281009.17965@munnari.oz.au> Date: Sat, 28 May 1994 22:51:14 -0400 From: John Curran Message-Id: <9405282251.aa21040@nic.near.net> -------- ] From: Damiano Bolla ] Subject: IPP ROuting Architecture ] Date: Sat, 28 May 94 11:08 BST ] ] From: db15@ukc.ac.uk (Damiano Bolla) ] Subject: IPP Routing Architecture ] Distribution: world ] Organization: University of Kent at Canterbury, UK. ] ] This report discusses the IPP routing architecture. What follows is ] an abstract of it. This is teh second edition of the report. ] Can you please give me an opinion about it ? ] You can find the Postscript version on host: ] eagle.ukc.ac.uk ] Using anonymous ftp under the directory: ] pub/db15/v3 ] ... Damiano, From a first reading, it appears as though IPP only supports strictly hierarchical addressing and routing... Did I misunderstand this aspect of the architecture? /John