From scoya@CNRI.Reston.VA.US Mon Mar 21 14:05:53 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id SAA12015 for ; Mon, 21 Mar 1994 18:32:12 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09014; 21 Mar 94 14:05 EST To: ipng@cmf.nrl.navy.mil Subject: List of documents Date: Mon, 21 Mar 94 14:05:53 -0500 From: Steve Coya Message-ID: <9403211405.aa09014@IETF.CNRI.Reston.VA.US> Status: O As requested during today's IPNG telechat, I am hereby requesting the complete set of documents. DO NOT send the actual documents, just the list of documents! :-) for each of the IPNG proposals. I will consolidate into a single list. Please send me the document title and filename (if it's not an I-D, send me location information). Thanks. Steve From deering@parc.xerox.com Mon Mar 21 16:08:45 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id TAA12231 for ; Mon, 21 Mar 1994 19:09:32 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14450(2)>; Mon, 21 Mar 1994 16:08:39 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 21 Mar 1994 16:08:46 -0800 To: ipng@cmf.nrl.navy.mil Cc: hinden@eng.sun.com, francis@cactus.ntt.jp, deering@parc.xerox.com Subject: SIPP documents ready for clarity review Date: Mon, 21 Mar 1994 16:08:45 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Mar21.160846pst.12171@skylark.parc.xerox.com> Status: O Dear IPng Directorate, The SIPP WG would like to submit the following documents for clarity review by the Directorate: S. Deering, "Simple Internet Protocol Plus (SIPP) Specification", Internet Draft, draft-ietf-sipp-spec-00.txt, February, 1994. S. Deering, et al, "Simple Internet Protocol Plus (SIPP): Routing and Addressing", Internet Draft, draft-ietf-sip- routing-addr-01.txt, February, 1994. P. Francis, "Simple Internet Protocol Plus (SIPP): Unicast Hierarchical Address Assignment", Internet Draft, , January 1994. R. Gilligan, et al, "IPAE: The SIPP Interoperability and Transition Mechanism", Internet Draft, draft-ietf-sipp-ipae-transition-01.txt, March 1994. These are the "base" SIPP documents. There are a bunch of auxilliary documents, covering DNS changes, ICMP changes, autoconfiguration, and routing protocol changes, most of which are also ready for review, and some of which we expect to have ready by the end of the Seattle IETF week. If the base set isn't enough to keep the reviewers busy for the next couple weeks, let me know, and I will forward the titles of all of the auxilliary docs that are ready now. Steve From sob@hsdndev.harvard.edu Mon Mar 21 20:51:41 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id UAA12729 for ; Mon, 21 Mar 1994 20:52:04 -0500 Date: Mon, 21 Mar 94 20:51:41 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403220151.AA22034@hsdndev.harvard.edu> To: deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Subject: Re: SIPP documents ready for clarity review Cc: francis@cactus.ntt.jp, hinden@eng.sun.com Status: O Steve, thanks (I guess) :-) Scott From brian@dxcoms.cern.ch Tue Mar 22 17:07:42 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id LAA16621 for ; Tue, 22 Mar 1994 11:08:17 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11037; Tue, 22 Mar 1994 17:07:43 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11780; Tue, 22 Mar 1994 17:07:42 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403221607.AA11780@dxcoms.cern.ch> Subject: Where, when To: ipng@cmf.nrl.navy.mil Date: Tue, 22 Mar 1994 17:07:42 +0100 (MET) 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: 244 Status: O Could somebody post an answer today to 2 questions, for those of us who missed the IPng conf call? 1. Where, when is the first Directorate meeting/meal in Seattle? 2. Where, when is the final draft of the requirements text? Thanx Brian From mankin@cmf.nrl.navy.mil Tue Mar 22 15:09:44 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with ESMTP id PAA18840 for ; Tue, 22 Mar 1994 15:09:46 -0500 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.7/8.6.6) id PAA03999 for ipng; Tue, 22 Mar 1994 15:09:44 -0500 Date: Tue, 22 Mar 1994 15:09:44 -0500 From: Allison J Mankin Message-Id: <199403222009.PAA03999@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: re: Where, when Status: O > 1. Where, when is the first Directorate meeting/meal in Seattle? Thursday night, following the IESG Open Plenary, we have dinner and then meeting. Let's just gather together in the Plenary room at the end of the IESG meeting. > 2. Where, when is the final draft of the requirements text? All comments must be to Frank, Jon and Craig for the final pre-IETF by the end of today (Tuesday) and Frank will undertake to make all the changes by the end of Wednesday so that the I-D can be published. From scoya@CNRI.Reston.VA.US Wed Mar 23 09:50:59 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id MAA25208 for ; Wed, 23 Mar 1994 12:59:21 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07792; 23 Mar 94 9:51 EST To: ipng@cmf.nrl.navy.mil Subject: Draft minutes from March 21 IPNG Telechat Date: Wed, 23 Mar 94 09:50:59 -0500 From: Steve Coya Message-ID: <9403230951.aa07792@IETF.CNRI.Reston.VA.US> Status: O DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference March 21, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES --------- Scott Bradner / Harvard Allison Mankin / NRL J Allard / Microsoft Jim Bound / DEC Dave Clark / MIT Eric Fleischman / Boeing Frank Kastenholz / FTP Greg Minshall / Novell Paul Mockapetris / ISI Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets ------- Steve Bellovin / AT&T Ross Callon / Wellfleet Brian Carpenter / CERN Jon Crowcroft / UCL John Curran / NEARnet Steve Deering / Xerox PARC Dino Farinacci / Cisco Paul Francis / NTT Daniel Karrenberg / RIPE Mark Knopper / Ameritech Craig Partridge / BBN 1. Scott and Allison will attempt to organize a dinner for the IPNG Directorate members on Thursday, following the IESG Plenary, during the Seattle IETF meeting. 2. The list of IPNG presentations that are to take place Monday morning in Seattle were reviewed. The breakdown is as follows: a. Allison and Scott - IPNG status b. Dave Clark - status of the External Review Panel c. Frank Solensky - Report from the ALE WG d. Jon Crowcroft and/or Frank Kastenholz - Report on the IPNG Requirements document 3. Coya to prepare an IPNG track for Seattle and send to Scott and Allison. Coya to send message to the IPNG list soliciting the formal set of documents from each of the groups. 4. The text of the disclaimer written by Allison and Scott, which is to be included in IPNG documents, was read to the directorate. No requests for changes were made. 5. Allison conducted a full review of the Criteria section of the requirements document. Request changes include: a. In the section on scale, the phrase "up to" should be replaced with "at least" A notation that "another 3 orders of magnitude might be needed" will be added. b. All references to the big-internet list should include the list address. c. In the discussion on scale, change "whole purpose" to "initial motivating purpose" d. Replace "very very very" with "extremely extremely extremely" :-) Ok, maybe only need one extremely... just wanted to see who's reading these minutes. e. The character string to use is IPng, not IP:NG (5 points to those who recall why the colon was there in the first place, 5 bonus points to whomever knows the entire history (with dates)! f. The requirement that multiple IPNG protocols co-exist needs to be reworded as there will only be one (1) IPNG protocol. Will be reworded to require that multiple versions of IPNG need to co-exist on the network. g. On the section on Media, expand "VJ-like" to "Van Jacobson-like" h. It was requested that the requirements include "the ability to send an IP datagram as large as allowed by the inter-network layer (assuming, of course, that the recipient is able to accept a datagram that large). The topic of fragmentation was raised, but discussion was deferred. i. In the section on Configuration, Admin, and OPS, it should be added that "nothing in the proposal should inhibit a future requirement for auto registration." j. It was suggested that the IAB report from the Security W/S might provide text for the security section of the requirements document. Coya to send to the IPNG list, Kastenholz to review. k. In the section on unique naming, use the phrase "multicast addresses" l. In the section on extensibility, reiterate the need to run multiple versions on IPNG over the same wire. m. In the section on non-goals, it was suggested that the section on IPv4 and IPng Communication be removed as it was not needed in the requirements document. n. Might be able to incorporate some ideas, concepts and text from the IAB report or the recently published RFC on Firewall in the section on Firewalls in the requirements document. o. There is a need to clarify what is meant by "accounting" in the section on non-goals. Kastenholz will reword. p. In the section on robust service, it was stated that host performance should not decrease (below the level of IPv4), and that the protocol should not, due to its complexity or other features, increase the liklihood of poor implementation on host platforms, especially with respect to performance. From kasten@Research.Ftp.Com Wed Mar 23 10:19:58 1994 Return-Path: kasten@Research.Ftp.Com Received: from Research.Ftp.Com (research.ftp.com [128.127.145.125]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id KAA24048 for ; Wed, 23 Mar 1994 10:24:02 -0500 Received: by Research.Ftp.Com (920330.SGI/) for ipng@cmf.nrl.navy.mil id AA24091; Wed, 23 Mar 94 10:19:59 -0500 Received: by Research.Ftp.Com id AA24091; Wed, 23 Mar 94 10:19:59 -0500 Date: Wed, 23 Mar 1994 10:19:58 -0500 (EST) From: Frank Kastenholz Subject: To Autoregister or not to Autoregister... To: ipng mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O The more I've thought about the autoregistration issue, the more I've come to the conclusion that it does not belong in the technical criteria for IPng. Calm down Brian and Eric -- let me explain! 0. I consider Autoregistration to be how a node is made known to any other systems on the network -- for example, (using IPv4 terms and technology) when BOOTP gives a node its IP address it might also tell DNS, getting yourself registered with Kerberos (if you've got the dubious pleasure of running Kerberos), telling NFS servers that there is a new node and who it is and giving the node the needed NFS privilges, getting email servers/relays set up to forward email properly, and so on. 1. Autoregistration IS critically important to a plug-and-play network. There is no doubt about that. 2. As I indicate in point 0, it seems that autoregistration covers a lot more than just IP level things. Setting up email relays (e.g.) has absolutely nothing to do with IP. In other words, this is a very very broad problem. 3. Most of the autoregistration protocol work would be done at higher layers than IP. For example, when registering a node with DNS, there would presumably be some DNS-level protocol operation which basically says Register Node and gives all the RR information needed (e.g. name, ip address, etc) AND includes the authentication information. This would be a dns-level protocol operation, running over tcp or udp.... 4. To me, it seems that the autoregistration technologies are orthogonal to the IP layer. For instance, the SIPPers could develop autoregistration scheme "X" and the TUBAteers scheme "Y". I would have to imagine that, modulo the formats of addresses and the like, each could use the other's scheme. 5. I am not comfortable with IPng specifying changes to other, non-IP- level protocols. Adding new RRs to DNS is one thing -- it was designed to handle this and was expected by the original architects. (In fact, from what I've been told by BIND experts, the changes to the BIND code to add a new RR are close to, if not exactly, 0). However, requiring new protocol operations as a result of this IP work, is really beyond my comfort level. So, my conclusion is that we should not specifically require autoregistration as a techncial feature of IPng. The document will contain text that says that autoregistration is a critical part of a plug-and-play internet and that we encourage IPng teams to consider this area, in conjunction with other protocol working groups (e.g. DNS autoregistration really ought to be a part of the DNS working group's efforts). Finally, I've strengthened the requirement for auto configuration: The paragraph in the config section that used to say: It should be possible for a node to dynamically obtain all of its operational, IP-level parameters... Now says We require that a node be able to dynamically obtain all of its operational, IP-level parameters at boot time via a dynamic configuration mechanism. In other words, instead of a "you might want to do this" it is a "you must do this". The list of "things to consider" with respect to auto-config has not changed. I have added the following paragraphs after the list: The requirements of this section apply only to IPng and its supporting protocols (such as for routing, address resolution, and network-layer control). Specifically, as far as IPng is concerned, we are concerned only with how routers and hosts get their configuration information. We note that in general, automatic configuration of hosts is a large and complex problem and getting the configuration information into hosts and routers is only one, small, piece of the problem. A large amount of additional, non-Internet-layer work is needed in order to be able to do "plug-and-play" networking. Other aspects of "plug-and-play" networking include things like: Autoregistration of new nodes with DNS, configuring security service systems (e.g. Kerberos), setting up email relays and mail servers, locating network resources, adding entries to NFS export files, and so on. To a large degree, these capabilities do not have any dependence on the IPng protocol (other than, perhaps, the format of addresses). We require that any IPng proposal not impede or prevent, in any way, the development of "plug-and-play" network configuration technologies. I'll be finishing the document within the hour and will put it up for anonymous FTP in research.ftp.com in pub/ip7ng/criteria.txt Frank From kasten@Research.Ftp.Com Wed Mar 23 11:29:53 1994 Return-Path: kasten@Research.Ftp.Com Received: from Research.Ftp.Com (research.ftp.com [128.127.145.125]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id LAA24555 for ; Wed, 23 Mar 1994 11:33:52 -0500 Received: by Research.Ftp.Com (920330.SGI/) for ipng@cmf.nrl.navy.mil id AA24482; Wed, 23 Mar 94 11:29:54 -0500 Received: by Research.Ftp.Com id AA24482; Wed, 23 Mar 94 11:29:54 -0500 Date: Wed, 23 Mar 1994 11:29:53 -0500 (EST) From: Frank Kastenholz Subject: final version of the document To: ipng mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O the lastest and last pre-seattle version of the document is available at research.ftp.com in pub/ip7reqs/criteria.txt i am sending it to the internet-draft people next.... ---- Frank Kastenholz FTP Software 2 High Street North Andover Mass USA 01845 508-685-4000 From ericf@atc.boeing.com Wed Mar 23 09:29:45 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id MAA25029 for ; Wed, 23 Mar 1994 12:28:29 -0500 Received: by atc.boeing.com (5.57) id AA10479; Wed, 23 Mar 94 09:29:45 -0800 Date: Wed, 23 Mar 94 09:29:45 -0800 From: Eric Fleischman Message-Id: <9403231729.AA10479@atc.boeing.com> To: ipng@cmf.nrl.navy.mil, kasten@Research.Ftp.Com Subject: Re: To Autoregister or not to Autoregister... Cc: ericf Status: O Dear Frank, Be calm? What's that? Having said that, I find your logic concerning why autoregistration should not be a part of our technical requirements to be commendable. My thoughts have also gone on similar routes. However, as one who has been repeatedly frustrated by "pidgeon-holers" (i.e., the beaurocrats (spelling?) who say "since this isn't totally in my department, we can't do anything -- we get a lot of that around here), I thought that it must be at least mentioned as something to consider and to not preclude so that it wouldn't become lost and swept under the carpet yet again. Thus, I concur with the wording and sentiment of Brian's response to you -- and of your original message. However, to be contentious, I could also say that IPng affects many layers in addition to the network layer. Need I mention DNS? How about FTP, etc.? Thus, one may counter your arguments (though I personally wouldn't dare do so) by saying that since you must add in DNS hooks for IPng, why not go the whole 9 yards. But without a DNS WG existing... Thus, let's compromise with Brian's words. However, about the "calmness" part -- you are asking too much! Sincerely yours, --Eric Fleischman From smb@research.att.com Wed Mar 23 15:06:29 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id PAA26259 for ; Wed, 23 Mar 1994 15:23:58 -0500 From: smb@research.att.com Message-Id: <199403232023.PAA26259@picard.cmf.nrl.navy.mil> Received: by bigbird.zoo.att.com; Wed Mar 23 15:06:30 EST 1994 To: ipng@cmf.nrl.navy.mil Subject: requirements document Date: Wed, 23 Mar 94 15:06:29 EST Status: O I just finished reading through the document. I'm not happy with this passage, as some of you could probably guess: Firewalls Some have requested that IPng include support for firewalls. The authors believe that firewalls are one particular solution to the problem of security and, as such, do not consider that support for firewalls is a valid requirement for IPng. I do not suggest that the criteria document mandate support for firewalls. The statement I'd like added is that many commercial customers view firewalls -- of whatever sort -- as the *only* current solution to certain security issues, and that therefore IPng should not make it harder to create a firewall than in IPv4. ``Above all, do no harm''. From Robert_Ullmann.LOTUS@CRD.lotus.com Wed Mar 23 16:28:29 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA26755 for ; Wed, 23 Mar 1994 16:23:06 -0500 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA19895; Wed, 23 Mar 94 16:24:37 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA19316; Wed, 23 Mar 94 16:28:29 EST Date: Wed, 23 Mar 94 16:28:29 EST Message-Id: <9403232128.AA19316@Mail.Lotus.com> Received: by DniMail (v1.0); Wed Mar 23 16:28:27 1994 EDT To: UNIXML::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: fragmentation in IPng Status: O Hi, On fragmentation: yes, it's harmful, yes, you want to avoid it. No, I don't think we can live without it. Note that in TCP, the transport layer can be taught to do MTU discovery, and applications won't know. But UDP is different: if IPng doesn't provide fragmentation, the MTU-discovery changes have to be made in the *application*. Existing IPv4 UDP applications expect to be able to send and receive application layer PDUs of up to about 64K. Also consider this: in the first part of a transition, IPng hosts need to be able to "tunnel" through the IPv4 infrastructure; this is all well and good. But later, we need to reverse this, with unmodified IPv4 hosts communicating over an infrastructure that is IPng, with IPv4 decomissioned. Those IPv4 hosts are still going to be sending 1480 byte TPDUs. Either we have to force IPv4 fragmentation on all of them (i.e. offer a "tunnel" MTU of less than 1500), or increase the subnetwork MTU (possible on some types, difficult on Ethernet), or use IPng fragmentation. Or arrange to fit it in: CATNIP 16 byte header (using FCIs), plus 1480 bytes of TPDU, and 4 bytes left over. This ability to do one-for-one operation without modifying the subnetwork MTU is (IMNSHO :-) really important. Rob ["tunnel" being in quotes to mean some kind of logical equivalent of a tunnel; not necessarily the strict definition. And for "1500" and "1480" read "subnetwork MTU" and "subnetwork MTU minus 20" if you like, but we've done a real good job of getting 1500 almost everywhere...] From sob@hsdndev.harvard.edu Wed Mar 23 16:54:48 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA27058 for ; Wed, 23 Mar 1994 16:54:56 -0500 Date: Wed, 23 Mar 94 16:54:48 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403232154.AA12753@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil, smb@research.att.com Subject: Re: requirements document Status: O I support Steve's view. Scott >From ipng-request@cmf.nrl.navy.mil Wed Mar 23 15:38:27 1994 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA01571; Wed, 23 Mar 1994 15:40:17 -0500 Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id PAA26259 for ; Wed, 23 Mar 1994 15:23:58 -0500 From: smb@research.att.com Message-Id: <199403232023.PAA26259@picard.cmf.nrl.navy.mil> Received: by bigbird.zoo.att.com; Wed Mar 23 15:06:30 EST 1994 To: ipng@cmf.nrl.navy.mil Subject: requirements document Date: Wed, 23 Mar 94 15:06:29 EST Status: R I just finished reading through the document. I'm not happy with this passage, as some of you could probably guess: Firewalls Some have requested that IPng include support for firewalls. The authors believe that firewalls are one particular solution to the problem of security and, as such, do not consider that support for firewalls is a valid requirement for IPng. I do not suggest that the criteria document mandate support for firewalls. The statement I'd like added is that many commercial customers view firewalls -- of whatever sort -- as the *only* current solution to certain security issues, and that therefore IPng should not make it harder to create a firewall than in IPv4. ``Above all, do no harm''. From smb@research.att.com Wed Mar 23 21:37:53 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id VAA28783 for ; Wed, 23 Mar 1994 21:39:58 -0500 From: smb@research.att.com Message-Id: <199403240239.VAA28783@picard.cmf.nrl.navy.mil> Date: Wed, 23 Mar 94 21:37:53 EST To: ipng@cmf.nrl.navy.mil Subject: better late than never.... Status: O Network Working Group S. Bellovin IPng White Paper AT&T Bell Laboratories Experimental 23 March 1994 Security Concerns for IPng Status of this Memo This document was submitted to the IETF IPng area in response to RFC 1550 Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Overview and Rationale A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective. While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse. Below, I outline a number of areas of concern. In some cases, there are features that would have a negative impact on security if nothing else is done. It may be desirable to adopt the features anyway, but in that case, the corrective action is mandatory. Firewalls For better or worse, firewalls are very much a feature of today's Internet. They are not, primarily, a response to network protocol security problems per se. Rather, they are a means to compensate for Bellovin [Page 1]  White Paper Security Concerns for IPng 21 December 1993 failings in software engineering and system administration. As such, firewalls are not likely to go away any time soon; IPng will do nothing to make host programs any less buggy. Anything that makes firewalls harder to deploy will make IPng less acceptable in the market. Firewalls impose a number of requirements. First, there must be a hierarchical address space. Many address-based filters use the structure of IPv4 addresses for access control decisions. Fortunately, this is a requirement for scalable routing as well. Routers, though, only need access to the destination address of the packet. Network-level firewalls often need to check both the source and destination address. A structure that makes it harder to find the source address is a distinct negative. There is also a need for access to the transport-level (i.e., the TCP or UDP) header. This may be for the port number field, or for access to various flag bits, notably the ACK bit in the TCP header. This latter field is used to distinguish between incoming and outgoing calls. In a different vein, at least one of the possible transition plans uses network-level packet translators [1]. Organizations that use firewalls will need to deploy their own translators to aid in converting their own internal networks. They cannot rely on centrally-located translators intended to serve the entire Internet community. It is thus vital that translators be simple, portable to many common platforms, and cheap -- we do not want to impose too high a financial barrier for converts to IPng. By the same token, it is desirable that such translation boxes not be usable for network-layer connection-laundering. It is difficult enough to trace back attacks today; we should not make it harder. (Some brands of terminal servers can be used for laundering. Most sites with such boxes have learned to configure them so that such activities are impossible.) Comprehensive logging is a possible alternative. IPAE [1] does not have problems with its translation strategy, as address are (insofar as possible) preserved; it is necessary to avoid any alternative strategies, such as circuit-level translators, that might. Encryption and Authentication A number of people are starting to experiment with IP-level encryption and cryptographic authentication. This trend will (and Bellovin [Page 2]  White Paper Security Concerns for IPng 21 December 1993 should) continue. IPng should not make this harder, either intrinsically or by imposing a substantial perforance barrier. Encryption can be done with various different granularities: host to host, host to gateway, and gateway to gateway. All of these have their uses; IPng must not rule out any of them. Encapsulation and tunneling strategies are somewhat problematic, as the packet may no longer carry the original source address when it reaches an encrypting gateway. (This may be seen more as a constraint on network topologies. So be it, but we should warn people of the limitation.) Dual-stack approaches, such as in TUBA's transition plan [2], imply multiple addresses for each host. (IPAE has this feature, too.) The encryption and access control infrastructure needs to know about all addresses for a given host, belonging to whichever stack. It should not be possible to bypass authentication or encryption by asking for a different address for the same host. Source Routing and Address-based Authentication The dominant form of host authentication in today's Internet is address-based. That is, hosts often decide to trust other hosts based on their IP addresses. (Actually, it's worse than that; much authentication is name-based, which opens up new avenues of attack. But if an attacker can spoof an IP address, there's no need to attack the name service.) To the extent that it does work, address-based authentication relies on the implied accuracy of the return route. That is, though it is easy to inject packets with a false source address, replies will generally follow the usual routing patterns, and be sent to the real host with that address. This frustrates most, though not all, attempts at impersonation. Problems can arise if source-routing is used. A source route, which must be reversed for reply packets, overrides the usual routing mechanism, and hence destroys the security of address-based authentication. For this reason, many organizations disable source- routing, at least at their border routers. One candidate IPng -- SIPP -- includes source-routing as an important component. To the extent this is used, it is a breaks address-based authentication. This may not be bad; in fact, it is probably good. But it is vital that a more secure cryptographic authentication protocol be defined and deployed before any substantial cutover to source routing, if SIPP is adopted. Accounting Bellovin [Page 3]  White Paper Security Concerns for IPng 21 December 1993 An significant part of the world wishes to do usage-sensitive accounting. This may be for billing, or it may simply be to accomodate quality-of-service requests. Either way, definitive knowledge of the relevant address fields is needed. To accomodate this, IPng should have a non-intrusive packet authentication mechanism. By ``non-intrusive'', I mean that it should (a) present little or no load to intermediate hops that do not need to do authentication; (b) be deletable (if desired) by the border gateways, and (c) be ignorable by end-systems or billing systems to which it is not relevant. [1] Robert E. Gilligan, Erik Nordmark, Erik Nordmark, ``IPAE: The SIPP Interoperability and Transition Mechanism'', working draft, March 16, 1994. [2] David M. Piscitello, ``Transition Plan for TUBA/CLNP'', working draft, March 4, 1994. Bellovin [Page 4]  From ddc@caraway.lcs.mit.edu Wed Mar 23 22:13:50 1994 Return-Path: ddc@caraway.lcs.mit.edu Received: from caraway.lcs.mit.edu (CARAWAY.LCS.MIT.EDU [18.26.0.170]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id WAA28974 for ; Wed, 23 Mar 1994 22:13:56 -0500 Received: by caraway.lcs.mit.edu id AA12241; Wed, 23 Mar 94 22:13:50 -0500 Message-Id: <9403240313.AA12241@caraway.lcs.mit.edu> To: ipng@cmf.nrl.navy.mil Subject: Draft of ext review kickoff letter From: David Clark Date: Wed, 23 Mar 94 22:13:50 -0500 Sender: ddc@caraway.lcs.mit.edu X-Mts: smtp Status: O Folks, Here is the note I intend to send to the set of known external reviewers tomorrow. Any quick comments on style or function?? Dave ----------- Dear IPng reviewers, The time has come to put you to work. The purpose of this note is to fill you in on the status of our IPng selection process, to tell you what is coming up, and to tell you what we would like you to do. As a first step in our evaluation process, we have solicited from the community white papers on the requirements which a new IP will have to meet. We have a number of papers in hand, which represent an interesting range of positions. Frank Kastenholz and Craig Partridge have produced a single summary document which represents our assessment of the integrated requirements for the new IP. Our first request for you will be to review this summary document and offer any comments you have. We will welcome comments on requirements we and the white papers have missed, or problems you identify relating our summary to the white papers. The individual white papers are now being released as draft Requests for Comments (RFCs). We will send you a set of these papers, and if you are willing we would love to have you look them over as part of the review process. The summary document is now being completed, and will be sent to you shortly, along with specific information on how to get the white papers. We are hoping that we can get some comments back from you within three weeks, so that we can start the next step of evaluating the IPng proposals against this document. Our next request to you will be to perform the same sort of review on a second and final document, which will represent the conclusions of the group concerning the actual selection. Again, there will be backup documentation on the proposals, which we will make available to you. We expect this second stage to occur in June. Our final objective is a presentation at an IETF meeting at the end of July, which is an immovable date against which we must plan. There are a variety of ways you can provide your comments to us. Written (e-mail) comments are most welcome. We will arrange some times for a teleconference, at which you can present your comments, and discuss your thoughts with some of the other reviewers and the directorate. Finally, we will be happy to talk to you one on one. At the time of the second review, we are thinking of arranging an informal workshop to discuss our conclusions. If we decide to proceed with this plan, we will make specific arrangements soon, so that you can put the dates in your calendar; we hope that some of you will be able to come. If you have any questions or comments, please send a message to me or to either of the area directors, Allison Mankin or Scott Bradner. From kasten@mailserv-D.ftp.com Thu Mar 24 09:25:29 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id JAA02052 for ; Thu, 24 Mar 1994 09:26:20 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 24 Mar 1994 09:26:17 -0500 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA09315; Thu, 24 Mar 94 09:25:29 EST Date: Thu, 24 Mar 94 09:25:29 EST Message-Id: <9403241425.AA09315@mailserv-D.ftp.com> To: deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Subject: Re: fragmentation in IPng From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 646 Status: O > What we *really* need for the IP suite is a standard request-response/RPC > transport protocol that handles frag/reasm, PMTU discovery, RTT computation, > etc. Too bad nothing ever came of all the work on this topic in the > end2end RG several years ago. Steve, this is right on. Let's look at the problem -- getting large datagrams through the net in a connectionless manner -- instead of the solution ("we must have fragmentation"). It sounds like a lightweight transport protocol, about halfway between UDP and TCP in function is desired. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From crb@faline.bellcore.com Thu Mar 24 10:55:58 1994 Return-Path: crb@faline.bellcore.com Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id KAA02908 for ; Thu, 24 Mar 1994 10:57:17 -0500 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA06135; Thu, 24 Mar 1994 11:00:21 -0500 Received: from localhost (localhost [127.0.0.1]) by faline.bellcore.com (8.6.7/8.6.4) with SMTP id KAA13452 for ; Thu, 24 Mar 1994 10:56:05 -0500 Message-Id: <199403241556.KAA13452@faline.bellcore.com> X-Authentication-Warning: faline.bellcore.com: Host localhost didn't use HELO protocol To: ipng-wp@harvard.edu Subject: rfc 1550 white paper submission Date: Thu, 24 Mar 94 10:55:58 -0500 From: Chris Brazdziunas Status: O I would like to submit this white paper as an engineering consideration for IPng as solicited by rfc1550. FYI, this output was generated by nroff. chris brazdziunas --------------------------------------------------------------------- Network Working Group C. Brazdziunas INTERNET-DRAFT Bellcore Category: Informational March 1994 IPng Support for ATM Services Executive Summary This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. IPng should provide support for existing and emerging link technologies that it will be transported over. Link technologies like Ethernet simply multiplex traffic from upper layer protocols onto a single channel. "Sophisticated" link technologies like ATM are emerging in the marketplace allowing several virtual channels to be established over a single wire (or fiber) potentially based on an applications' network performance objectives. Support for both "sophisticated" (ATM) and existing link technologies needs to be considered in an IPng candidate. End-to-end applications will communicate through a network where IPng packets travel across subnetworks such as Ethernet and Hippi and also more "sophisticated" link levels such as ATM. Though initial support for IPng over ATM subnetworks will not facilitate a virtual circuit per application, the hooks to provide such a mapping should be in place while also maintaining support for the transport of IPng packets across conventional subnetworks. Application support for QOS-based link level service requires that the following types of ATM information be mappable (or derivable) from the higher level protocol(s) such as IPng: source and destination(s) addresses, connection quality of service parameters, connection state, and ATM virtual circuit identifier. Some of these mappings may be derivable from information provided by proposed resource reservation protocols supporting an integrated services Internet [4]. However, the ATM virtual circuit identifier should be efficiently derivable from IPng packet information. An IPng candidate should provide evidence that the mapping from an applications' IPng packets to ATM virtual circuit(s) can be accomplished in a heterogeneous Internet architecture keeping in consideration the gigabit/sec rates that IPng/ATM subnetworks will eventually be operating at. Brazdziunas [Page 1] INTERNET-DRAFT IPng Support for ATM Services March 1994 1. Introduction This paper describes parameters that are needed to map IPng (or any protocol operating above the link level) to ATM services. ATM is a "sophisticated" link level technology which provides the potential capability for applications at the TCP/UDP level to map to a single ATM virtual circuit for transport across an ATM network(s) customized to the network performance and traffic requirements for that application. This is a step above many of today's existing link technologies which can only support a single level of network performance that must be shared by all applications operating on a single endpoint. The future Internet will be comprised of both conventional and "sophisticated" link technologies. The "sophisticated" features of link layers like ATM need to be incorporated into an internet where data travels not only across an ATM network but also several other existing LAN and WAN technologies. Future networks are likely to be a combination of subnetworks providing best-effort link level service such as Ethernet and also sophisticated subnetworks that can support quality of service-based connections like ATM. One can envision data originating from an Ethernet, passing through an ATM network, FDDI network, another ATM network, and finally arriving at its destination residing on a HIPPI network. IPng packets will travel through such a list of interconnected network technologies as ATM is incorporated as one of the components of the future Internet. To support per application customizable link level connections, four types of ATM information should be derivable from the higher level protocol(s) like IPng. This ATM information includes: source and destination ATM addresses, connection quality of service parameters, connection state, and an ATM virtual circuit identifier which maps to a single IPng application (i.e. single TCP/UDP application). Some of these mapping could potentially be derivable through information provided by proposed resource reservation protocols supporting an integrated services Internet [4]. However, the ATM virtual circuit identifier needs to be efficiently mappable from IPng packet information. Organization of this white paper is as follows. First the characteristics of ATM are described focusing on functions that are not provided in today's LAN technologies. This section provides background information necessary for the following section describing the parameters needed to map IPng services to ATM services. Brazdziunas [Page 2] INTERNET-DRAFT IPng Support for ATM Services March 1994 2. Terminology In this white paper, the term "application" refers to a process or set of collective processes operating at the TCP/UDP level or above in the protocol stack. For example, each instance of "telnet" or "ftp" session running on an end station is a distinct application. 3. Characteristics of ATM Service ATM has several characteristics which differentiates it from current link level technologies. First of all, ATM has the capability of providing many virtual channels to transmit information over a single wire (or fiber). This is very similar to X.25, where many logical channels can be established over a single physical media. But unlike X.25, ATM allows for each of these channels or circuits to have a customizable set of performance and quality of service characteristics. Link level technologies like Ethernet provide a single channel with a single performance and quality of service characteristic. In a sense, a single ATM link level media appears like an array of of link level technologies each with customizable characteristics. ATM virtual circuits can be established dynamically utilizing its signaling protocol. ATM signaling is a source initiated negotiation process for connection establishment. This protocol informs elements in the network of the characteristics for the desired connection. ATM signaling does not provide any guidelines for how network elements decide whether it can accept a call or where a signaling request should be forwarded if the end destination (from the link level perspective) has not been reached. In short, ATM signaling does not support any routing functionality of network admission control. ATM signaling establishes a "hard state" in the network for a call. "Hard state" implies that the state of a connection in intermediate switching equipment can be set and once established it will be maintained until a message is received by one of the ends of the call requesting a change in state for the connection [2]. As a result, an ATM end system (this could be a workstation with an ATM adapter or a router with an ATM interface) receives guaranteed service from the ATM network. The ATM network is responsible for maintaining the connection state. The price the ATM termination points pay for this guarantee is the responsibility of changing the state of the connection, specifically informing the ATM network to establish, alter, or tear-down the connection. Brazdziunas [Page 3] INTERNET-DRAFT IPng Support for ATM Services March 1994 Each ATM end point in a network has an ATM address associated with it to support dynamic connection establishment via signaling. These addresses are hierarchical in structure and globally unique [3]. As a result, these addresses are routable. This allows ATM networks to eventually support a large number of ATM endpoints once a routing architecture and protocols to support it become available. The ATM User-Network Interface (UNI) signaling protocol based on ITU-TS Q.93B allows many different service parameters to be specified for describing connection characteristics. [3] These parameters can be grouped into several categories: ATM adaptation layer (AAL) information, network QOS objectives, connection traffic descriptor, and transit network selector. The AAL information specifies negotiable parameters such as AAL type and maximum packet sizes. The network QOS objectives describe the service that the ATM user expects from the network. Q.93B allows for one of five service classes to be selected by the ATM user. The service classes are defined as general traffic types such as circuit emulation (class A), variable bit rate audio and video (class B), connection-oriented data transfer (class C), connectionless data transfer (class D), best effort service (class X), and unspecified [3]. Each of these categories are further specified through network provider objectives for various ATM performance parameters. These parameters may include cell transfer delay, cell delay variation, and cell loss ratio. The connection traffic descriptor specifies characteristics of the data generated by the user of the connection. This information allows the ATM network to commit the resources necessary to support the traffic flow with the quality of service the user expects. Characteristics defined in the ATM Forum UNI specification include peak cell rate, sustainable cell rate, and maximum and minimum burst sizes [3]. Lastly, the transit network selection parameter allows an ATM user to select a preferred network provider to service the connection [3]. 4. Parameters Required to Map IPng to ATM There are several parameters required to map ATM services from a higher level service like IPng. These ATM parameters can be categorized in the following manner: addressing parameters, connection QOS-related parameters, connection management information, and ATM virtual circuit identifier. The first three categories provide support for ATM signaling. The last parameter, a connection identifier that maps IPng packets to ATM virtual circuits, provides support for an ATM virtual circuit per application when the end-to- end connection travels across an ATM subnetwork(s) (this does not assume that ATM is the only type of subnetwork that this connection Brazdziunas [Page 4] INTERNET-DRAFT IPng Support for ATM Services March 1994 travels across). Below, mapping issues for each of these parameters will be described. 4.1. Addressing ATM supports routable addresses to each ATM endpoint to facilitate the dynamic establishment of connections. These addresses need to be derived from a higher level address such as an IPng address and IPng routing information. This type of mapping is not novel. It is a mapping that is currently done for support of current IP over link technologies such as Ethernet. An IP over ATM address resolution protocol (ARP) has been described in the Internet Standard, "Classical IP over ATM" [5]. In addition, support for IP routing over large ATM networks is being worked in the IETF's "Routing over Large Clouds" working group. 4.2. Quality of Service As described in section 3, an ATM virtual circuit is established based upon a user's traffic characteristics and network performance objectives. These characteristics which include delay and throughput requirements can only be defined by the application level (at the transport level or above) as opposed to the internetworking (IPng) level. For instance, a file transfer application transferring a 100 MB file has very different link level performance requirements than a network time application. The former requires a high throughput and low error rate connection whereas the latter could perhaps be adequately serviced utilizing a best-effort service. Current IP does not provide much support for a quality of service specification and provides no support for the specification of link level performance needs by an application directly. This is due to the fact that only a single type of link level performance is available with link technologies like Ethernet. As a result, all applications over IP today receive the same level of link service. IPng packets need not explicitly contain information parameters describing an application's traffic characteristics and network performance objectives (e.g. delay = low, throughput = 10 Mb/s). This information could potentially be mapped from resource reservation protocols that operate at the IP (and potentially IPng) level [4]. Brazdziunas [Page 5] INTERNET-DRAFT IPng Support for ATM Services March 1994 4.3. Connection Management The establishment and release of ATM connections should ultimately be controlled by the applications utilizing the circuits. As described in section 3, ATM signaling establishes a "hard state" in the network which is controlled by the ATM termination points [2]. Currently, IP provides no explicit mechanism for link level connection management. Future support for link level connection management could be accomplished through resource reservation protocols and need not necessarily be supported directly via information contained in the IPng protocol. 4.4. Connection Identifier A mapping function needs to exist between IPng packets and ATM so that application flows map one-to-one to ATM virtual circuits. Currently, application traffic flows are identified at the transport level by UDP/TCP source and destination ports and IP protocol identifiers. This level of identification should also be available at the IPng level so that information in the IPng packets identify an application's flow and map to an ATM virtual circuit supporting that flow when the IPng packets travels across an ATM subnetwork(s). Using the current IP protocol, identifying an application's traffic flow requires the combination of the following five parameters: source and destination IP addresses, source and destination UDP/TCP ports, and IP protocol identifier. This application connection identifier for IP is complex and could potentially be costly to implement in IP end stations and routers. The IPng connection identifier should be large enough so that all application level traffic from an IPng end point can be mapped into the IPng packet. Currently, ATM provides 24 bits for virtual circuit identification (VPI and VCI). This provides sufficient capacity for 2^24 (16,777,216) connections [6]. The actual number of bits that are used for the ATM virtual circuit however is established through negotiation between the ATM endpoint and ATM network. This number is useful as an upper bound for the number of mappings that are needed to be supported by IPng. An IPng candidate should be able to identify how IPng packets from an application can map to an ATM virtual circuit. In addition, this mapping should be large enough to support a mapping for every IPng application on an end system to an ATM virtual circuit. Careful consideration should be given to complexity of this mapping for IPng Brazdziunas [Page 6] INTERNET-DRAFT IPng Support for ATM Services March 1994 to ATM since it needs to eventually support gigabit/sec rates. Security Considerations Security issues are not addressed in this memo. References [1] Bradner, S., Mankin, A., "IP: Next Generation (IPng) White Paper Solicitation", RFC 1550, December, 1993. [2] Clark, D. D., "The Design Philosophy of the DARPA Internet Protocols", Proc. ATM SIGCOMM '88, August, 1988. [3] "ATM User-Network Interface Specification, Version 3.0", ATM Forum, September 10, 1993 [4] Zhang, L., Estrin, D., Herzog, S., Jamin, S., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", Internet Draft, October, 1993. [5] Laubach, M., "Classical IP and ARP over ATM", Internet Draft, December 20, 1993. [6] "Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols Generic Requirements", Bellcore Technical Advisory TA-NWT-001113, Issue 1, June 1993. Author Information Christina Brazdziunas Bellcore 445 South Street Morristown, NJ 07960 (201) 829-4173 crb@faline.bellcore.com Brazdziunas [Page 7] From sob@hsdndev.harvard.edu Thu Mar 24 11:12:37 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id LAA03106 for ; Thu, 24 Mar 1994 11:13:15 -0500 Date: Thu, 24 Mar 94 11:12:37 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403241612.AA22342@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: another white paper Status: O >From crb@faline.bellcore.com Thu Mar 24 10:57:01 1994 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA06135; Thu, 24 Mar 1994 11:00:21 -0500 Received: from localhost (localhost [127.0.0.1]) by faline.bellcore.com (8.6.7/8.6.4) with SMTP id KAA13452 for ; Thu, 24 Mar 1994 10:56:05 -0500 Message-Id: <199403241556.KAA13452@faline.bellcore.com> X-Authentication-Warning: faline.bellcore.com: Host localhost didn't use HELO protocol To: ipng-wp@harvard.edu Subject: rfc 1550 white paper submission Date: Thu, 24 Mar 94 10:55:58 -0500 From: Chris Brazdziunas Status: R I would like to submit this white paper as an engineering consideration for IPng as solicited by rfc1550. FYI, this output was generated by nroff. chris brazdziunas --------------------------------------------------------------------- Network Working Group C. Brazdziunas INTERNET-DRAFT Bellcore Category: Informational March 1994 IPng Support for ATM Services Executive Summary This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. IPng should provide support for existing and emerging link technologies that it will be transported over. Link technologies like Ethernet simply multiplex traffic from upper layer protocols onto a single channel. "Sophisticated" link technologies like ATM are emerging in the marketplace allowing several virtual channels to be established over a single wire (or fiber) potentially based on an applications' network performance objectives. Support for both "sophisticated" (ATM) and existing link technologies needs to be considered in an IPng candidate. End-to-end applications will communicate through a network where IPng packets travel across subnetworks such as Ethernet and Hippi and also more "sophisticated" link levels such as ATM. Though initial support for IPng over ATM subnetworks will not facilitate a virtual circuit per application, the hooks to provide such a mapping should be in place while also maintaining support for the transport of IPng packets across conventional subnetworks. Application support for QOS-based link level service requires that the following types of ATM information be mappable (or derivable) from the higher level protocol(s) such as IPng: source and destination(s) addresses, connection quality of service parameters, connection state, and ATM virtual circuit identifier. Some of these mappings may be derivable from information provided by proposed resource reservation protocols supporting an integrated services Internet [4]. However, the ATM virtual circuit identifier should be efficiently derivable from IPng packet information. An IPng candidate should provide evidence that the mapping from an applications' IPng packets to ATM virtual circuit(s) can be accomplished in a heterogeneous Internet architecture keeping in consideration the gigabit/sec rates that IPng/ATM subnetworks will eventually be operating at. Brazdziunas [Page 1] INTERNET-DRAFT IPng Support for ATM Services March 1994 1. Introduction This paper describes parameters that are needed to map IPng (or any protocol operating above the link level) to ATM services. ATM is a "sophisticated" link level technology which provides the potential capability for applications at the TCP/UDP level to map to a single ATM virtual circuit for transport across an ATM network(s) customized to the network performance and traffic requirements for that application. This is a step above many of today's existing link technologies which can only support a single level of network performance that must be shared by all applications operating on a single endpoint. The future Internet will be comprised of both conventional and "sophisticated" link technologies. The "sophisticated" features of link layers like ATM need to be incorporated into an internet where data travels not only across an ATM network but also several other existing LAN and WAN technologies. Future networks are likely to be a combination of subnetworks providing best-effort link level service such as Ethernet and also sophisticated subnetworks that can support quality of service-based connections like ATM. One can envision data originating from an Ethernet, passing through an ATM network, FDDI network, another ATM network, and finally arriving at its destination residing on a HIPPI network. IPng packets will travel through such a list of interconnected network technologies as ATM is incorporated as one of the components of the future Internet. To support per application customizable link level connections, four types of ATM information should be derivable from the higher level protocol(s) like IPng. This ATM information includes: source and destination ATM addresses, connection quality of service parameters, connection state, and an ATM virtual circuit identifier which maps to a single IPng application (i.e. single TCP/UDP application). Some of these mapping could potentially be derivable through information provided by proposed resource reservation protocols supporting an integrated services Internet [4]. However, the ATM virtual circuit identifier needs to be efficiently mappable from IPng packet information. Organization of this white paper is as follows. First the characteristics of ATM are described focusing on functions that are not provided in today's LAN technologies. This section provides background information necessary for the following section describing the parameters needed to map IPng services to ATM services. Brazdziunas [Page 2] INTERNET-DRAFT IPng Support for ATM Services March 1994 2. Terminology In this white paper, the term "application" refers to a process or set of collective processes operating at the TCP/UDP level or above in the protocol stack. For example, each instance of "telnet" or "ftp" session running on an end station is a distinct application. 3. Characteristics of ATM Service ATM has several characteristics which differentiates it from current link level technologies. First of all, ATM has the capability of providing many virtual channels to transmit information over a single wire (or fiber). This is very similar to X.25, where many logical channels can be established over a single physical media. But unlike X.25, ATM allows for each of these channels or circuits to have a customizable set of performance and quality of service characteristics. Link level technologies like Ethernet provide a single channel with a single performance and quality of service characteristic. In a sense, a single ATM link level media appears like an array of of link level technologies each with customizable characteristics. ATM virtual circuits can be established dynamically utilizing its signaling protocol. ATM signaling is a source initiated negotiation process for connection establishment. This protocol informs elements in the network of the characteristics for the desired connection. ATM signaling does not provide any guidelines for how network elements decide whether it can accept a call or where a signaling request should be forwarded if the end destination (from the link level perspective) has not been reached. In short, ATM signaling does not support any routing functionality of network admission control. ATM signaling establishes a "hard state" in the network for a call. "Hard state" implies that the state of a connection in intermediate switching equipment can be set and once established it will be maintained until a message is received by one of the ends of the call requesting a change in state for the connection [2]. As a result, an ATM end system (this could be a workstation with an ATM adapter or a router with an ATM interface) receives guaranteed service from the ATM network. The ATM network is responsible for maintaining the connection state. The price the ATM termination points pay for this guarantee is the responsibility of changing the state of the connection, specifically informing the ATM network to establish, alter, or tear-down the connection. Brazdziunas [Page 3] INTERNET-DRAFT IPng Support for ATM Services March 1994 Each ATM end point in a network has an ATM address associated with it to support dynamic connection establishment via signaling. These addresses are hierarchical in structure and globally unique [3]. As a result, these addresses are routable. This allows ATM networks to eventually support a large number of ATM endpoints once a routing architecture and protocols to support it become available. The ATM User-Network Interface (UNI) signaling protocol based on ITU-TS Q.93B allows many different service parameters to be specified for describing connection characteristics. [3] These parameters can be grouped into several categories: ATM adaptation layer (AAL) information, network QOS objectives, connection traffic descriptor, and transit network selector. The AAL information specifies negotiable parameters such as AAL type and maximum packet sizes. The network QOS objectives describe the service that the ATM user expects from the network. Q.93B allows for one of five service classes to be selected by the ATM user. The service classes are defined as general traffic types such as circuit emulation (class A), variable bit rate audio and video (class B), connection-oriented data transfer (class C), connectionless data transfer (class D), best effort service (class X), and unspecified [3]. Each of these categories are further specified through network provider objectives for various ATM performance parameters. These parameters may include cell transfer delay, cell delay variation, and cell loss ratio. The connection traffic descriptor specifies characteristics of the data generated by the user of the connection. This information allows the ATM network to commit the resources necessary to support the traffic flow with the quality of service the user expects. Characteristics defined in the ATM Forum UNI specification include peak cell rate, sustainable cell rate, and maximum and minimum burst sizes [3]. Lastly, the transit network selection parameter allows an ATM user to select a preferred network provider to service the connection [3]. 4. Parameters Required to Map IPng to ATM There are several parameters required to map ATM services from a higher level service like IPng. These ATM parameters can be categorized in the following manner: addressing parameters, connection QOS-related parameters, connection management information, and ATM virtual circuit identifier. The first three categories provide support for ATM signaling. The last parameter, a connection identifier that maps IPng packets to ATM virtual circuits, provides support for an ATM virtual circuit per application when the end-to- end connection travels across an ATM subnetwork(s) (this does not assume that ATM is the only type of subnetwork that this connection Brazdziunas [Page 4] INTERNET-DRAFT IPng Support for ATM Services March 1994 travels across). Below, mapping issues for each of these parameters will be described. 4.1. Addressing ATM supports routable addresses to each ATM endpoint to facilitate the dynamic establishment of connections. These addresses need to be derived from a higher level address such as an IPng address and IPng routing information. This type of mapping is not novel. It is a mapping that is currently done for support of current IP over link technologies such as Ethernet. An IP over ATM address resolution protocol (ARP) has been described in the Internet Standard, "Classical IP over ATM" [5]. In addition, support for IP routing over large ATM networks is being worked in the IETF's "Routing over Large Clouds" working group. 4.2. Quality of Service As described in section 3, an ATM virtual circuit is established based upon a user's traffic characteristics and network performance objectives. These characteristics which include delay and throughput requirements can only be defined by the application level (at the transport level or above) as opposed to the internetworking (IPng) level. For instance, a file transfer application transferring a 100 MB file has very different link level performance requirements than a network time application. The former requires a high throughput and low error rate connection whereas the latter could perhaps be adequately serviced utilizing a best-effort service. Current IP does not provide much support for a quality of service specification and provides no support for the specification of link level performance needs by an application directly. This is due to the fact that only a single type of link level performance is available with link technologies like Ethernet. As a result, all applications over IP today receive the same level of link service. IPng packets need not explicitly contain information parameters describing an application's traffic characteristics and network performance objectives (e.g. delay = low, throughput = 10 Mb/s). This information could potentially be mapped from resource reservation protocols that operate at the IP (and potentially IPng) level [4]. Brazdziunas [Page 5] INTERNET-DRAFT IPng Support for ATM Services March 1994 4.3. Connection Management The establishment and release of ATM connections should ultimately be controlled by the applications utilizing the circuits. As described in section 3, ATM signaling establishes a "hard state" in the network which is controlled by the ATM termination points [2]. Currently, IP provides no explicit mechanism for link level connection management. Future support for link level connection management could be accomplished through resource reservation protocols and need not necessarily be supported directly via information contained in the IPng protocol. 4.4. Connection Identifier A mapping function needs to exist between IPng packets and ATM so that application flows map one-to-one to ATM virtual circuits. Currently, application traffic flows are identified at the transport level by UDP/TCP source and destination ports and IP protocol identifiers. This level of identification should also be available at the IPng level so that information in the IPng packets identify an application's flow and map to an ATM virtual circuit supporting that flow when the IPng packets travels across an ATM subnetwork(s). Using the current IP protocol, identifying an application's traffic flow requires the combination of the following five parameters: source and destination IP addresses, source and destination UDP/TCP ports, and IP protocol identifier. This application connection identifier for IP is complex and could potentially be costly to implement in IP end stations and routers. The IPng connection identifier should be large enough so that all application level traffic from an IPng end point can be mapped into the IPng packet. Currently, ATM provides 24 bits for virtual circuit identification (VPI and VCI). This provides sufficient capacity for 2^24 (16,777,216) connections [6]. The actual number of bits that are used for the ATM virtual circuit however is established through negotiation between the ATM endpoint and ATM network. This number is useful as an upper bound for the number of mappings that are needed to be supported by IPng. An IPng candidate should be able to identify how IPng packets from an application can map to an ATM virtual circuit. In addition, this mapping should be large enough to support a mapping for every IPng application on an end system to an ATM virtual circuit. Careful consideration should be given to complexity of this mapping for IPng Brazdziunas [Page 6] INTERNET-DRAFT IPng Support for ATM Services March 1994 to ATM since it needs to eventually support gigabit/sec rates. Security Considerations Security issues are not addressed in this memo. References [1] Bradner, S., Mankin, A., "IP: Next Generation (IPng) White Paper Solicitation", RFC 1550, December, 1993. [2] Clark, D. D., "The Design Philosophy of the DARPA Internet Protocols", Proc. ATM SIGCOMM '88, August, 1988. [3] "ATM User-Network Interface Specification, Version 3.0", ATM Forum, September 10, 1993 [4] Zhang, L., Estrin, D., Herzog, S., Jamin, S., "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", Internet Draft, October, 1993. [5] Laubach, M., "Classical IP and ARP over ATM", Internet Draft, December 20, 1993. [6] "Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols Generic Requirements", Bellcore Technical Advisory TA-NWT-001113, Issue 1, June 1993. Author Information Christina Brazdziunas Bellcore 445 South Street Morristown, NJ 07960 (201) 829-4173 crb@faline.bellcore.com Brazdziunas [Page 7] From Robert_Ullmann.LOTUS@CRD.lotus.com Thu Mar 24 14:39:17 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id OAA05181 for ; Thu, 24 Mar 1994 14:33:58 -0500 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA14275; Thu, 24 Mar 94 14:35:25 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA28216; Thu, 24 Mar 94 14:39:17 EST Date: Thu, 24 Mar 94 14:39:17 EST Message-Id: <9403241939.AA28216@Mail.Lotus.com> Received: by DniMail (v1.0); Thu Mar 24 14:39:14 1994 EDT To: unixml::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Re: fragmentation in IPng Status: O Hi, > [smb] > I think, then, that we're converging on a consensus. I strongly disagree. > 1) IPng routers will not do fragmentation. > 2) IPng hosts may do fragmentation for now. In the present architecture, it is exactly the opposite; fragmentation is something only routers need worry about, except when the datagram is fragmented against the local subnetwork MTU. Hosts do reassembly. I wouldn't change this lightly. In particular, changing it by moving the complexity into the hosts deprives hosts of a valubale service now provided by the network. Pushing up into the transport and applications is inconceivable; it means they must each re-implement the function. Think about what happens when routes change. Think about what happens when datagrams overloading a route are splashed onto a less-desireable route with a smaller MTU. (Yes, the TCP or a similar transport MAY be able to still do something intelligent; but a connectionless protocol will not.) > 3) Path MTU discovery is the preferred option, where applicable For UDP, this changes the present expectation that a large TPDU (say an NFS write) will almost always work the first time, to an expectation that it will ALWAYS FAIL the first time. Not pleasant at all. When the RPC timer runs out and retransmits, all the pieces go out again anyway. Sure, you can invent something to improve that; and re-invent it for every new application. -------------- Right now, in both the IPv4 and OSI *architecture*, the following holds: The transport can present TDPUs with lengths up to the architectural limit (e.g. ~64Kbytes) to the network layer interface with an expectation that they will be delivered most of the time. --------------- If you want to change that, we need an area called the IP and TCP and UDP and Application Services Next Generation Area. --------------- I've been asked several times where the "application" or "API" specifications are in the CATNIP specification, as if they are somehow missing. Of course they are missing. The API presented to an IPv4 or CLNP or IPX-based application is *exactly* what it is today. You don't change the applications. The network service access point interface presented to the transport is *exactly* what it is today. You don't change the transport. Likewise, the use of the subnetwork services is *exactly* as it is now; the only problem being that we already have (for example) both ARP and ES-IS; the IETF will eventually want to pick one and (mildly) deprecate the other. Anything else is not in the charter. Then, as, when, and if individual protocols, implementations, and instances of implementations want to become knowledgeable of the new standard addressing and capabilities, they do so. Not all at once. (In between, there are some cute hacks, like offering applications addresses in the 224.x.x.x-255.x.x.x range if the actual address is outside the version 4 space, and things like that. Keep the details confined inside your implementation please.) Best Regards, Robert From bound@zk3.dec.com Thu Mar 24 16:15:02 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id QAA06077 for ; Thu, 24 Mar 1994 16:22:02 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA07172; Thu, 24 Mar 94 13:15:10 -0800 Received: by xirtlu.zk3.dec.com; id AA12419; Thu, 24 Mar 1994 16:15:08 -0500 Message-Id: <9403242115.AA12419@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Payload Length and Fragmentation Date: Thu, 24 Mar 94 16:15:02 -0500 X-Mts: smtp Status: O FYI.. Us working on IPng at Digital just pulled across all the Big-i archive mail on the subject titled in this mail. That took some work too. Anyway we are looking at it and there were some good arguments pro and con. If its useful after I read it all I will send it. Also just scanning it I must say folks get really nasty in this forum. If someone talked to me right in front of my face in person like some of the folks talk to each other on the mail I found I think I would take it as an assault and react accordingly. I might even spit on them, and see where it goes from there, and get real nasty back (just kidding). /jim From Robert_Ullmann.LOTUS@CRD.lotus.com Thu Mar 24 17:50:20 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id RAA06662 for ; Thu, 24 Mar 1994 17:44:56 -0500 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA18797; Thu, 24 Mar 94 17:46:27 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA09264; Thu, 24 Mar 94 17:50:20 EST Date: Thu, 24 Mar 94 17:50:20 EST Message-Id: <9403242250.AA09264@Mail.Lotus.com> Received: by DniMail (v1.0); Thu Mar 24 17:50:18 1994 EDT To: unixml::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: 224.x.x.x Status: O It was, of course, a typo; I meant 240.x.x.x and up. Then again, you might choose not to do Deering-style multicasting ... Rob From Greg_Minshall@Novell.COM Thu Mar 24 22:19:56 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id BAA08990 for ; Fri, 25 Mar 1994 01:28:51 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA05492; Thu, 24 Mar 94 23:33:17 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB27175; Thu, 24 Mar 94 22:19:56 PST Date: Thu, 24 Mar 94 22:19:56 PST Message-Id: <9403250619.AB27175@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng mailing list From: Greg Minshall Subject: If *i* were to write a white paper... Status: O If i were to actually write a white paper, it would suggest 3 things as required for operation (today) in an IPng. 1. No configuration needed for a host. So, use IEEE address as the "node id". (But, to allow sites to be more administration-intensive, define an ICMP which says "can't route autoconfigured address"; and a way, a la DHCP, to acquire an "administered" address.) (**) 2. Ease configuration of "subnets" (wires, whatever). One of the hardest things in configuring IPv4 networks is *subnet masks*. They are a total disaster from an ease of use point of view. So, no subnet masks. At most, choose one single number from some set of numbers and assign it to a subnet. Nothing more complex than that. 3. Some sort of dynamic name (and service) registration/query protocol, which does NOT rely on servers (you can't assume servers in an ad hoc case, for example). We use something called SAP (Apple uses something called NBP, which is similar) which has bad problems with scaling. The scaling problems can probably be dealt with; it works very well for local and ad hoc networking. (In IPv4, hosts, not services, are named; i would suggest there is a problem here, though SMB would suggest that we just think of "host names" as, really, being "service names"; long sentence, but i'm uncomfortable with this view.) (Which is to say, yes, autoregistration is important!) Greg (**) There *will*, of course, be manual configuration for *users*, conveying rights to file services, etc. ps - still looking for warts (the above reflect a few). From Greg_Minshall@Novell.COM Thu Mar 24 22:21:24 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id BAA09002 for ; Fri, 25 Mar 1994 01:30:21 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA05527; Thu, 24 Mar 94 23:34:48 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB27175; Thu, 24 Mar 94 22:21:24 PST Date: Thu, 24 Mar 94 22:21:24 PST Message-Id: <9403250621.AB27175@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: smb@research.att.com, ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: Re: better late than never.... Status: O Steve, > There is also a need for access to the transport-level (i.e., the TCP > or UDP) header. This may be for the port number field, or for access > to various flag bits, notably the ACK bit in the TCP header. This > latter field is used to distinguish between incoming and outgoing > calls. You probably meant the SYN bit? > A number of people are starting to experiment with IP-level > encryption and cryptographic authentication. This trend will (and > should) continue. IPng should not make this harder, either > intrinsically or by imposing a substantial perforance barrier. How *could* IPng make this harder? > Dual-stack approaches, such as in TUBA's transition plan [2], imply > multiple addresses for each host. (IPAE has this feature, too.) The > encryption and access control infrastructure needs to know about all > addresses for a given host, belonging to whichever stack. It should > not be possible to bypass authentication or encryption by asking for > a different address for the same host. Somebody, if i remember correctly, wrote a wp about the need for multiple addreses for a single host. Who was that? Greg From craig@aland.bbn.com Fri Mar 25 09:05:24 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id MAA02708 for ; Fri, 25 Mar 1994 12:07:25 -0500 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA23692 for ipng@cmf.nrl.navy.mil; Fri, 25 Mar 94 12:06:57 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA03370; Fri, 25 Mar 1994 09:05:27 -0800 Message-Id: <199403251705.JAA03370@aland.bbn.com> To: ipng@cmf.nrl.navy.mil Subject: avoiding second system syndrome Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 25 Mar 94 09:05:24 -0800 Sender: craig@aland.bbn.com Status: O Hi folks: As we go to IETF, I'd like to send out a brief cautionary note. Remember Fred Brooks' warning to avoid second system syndrome. (The instinct to put everything into the second version of a system that you couldn't put into the first, with the result that the second system is delivered late or not at all). Another stricter standard is one I heard from a software engineering friend who had somehow inherited the wisdom that, in general, a successful project does at most one thing that no one has done before. There are lots of things we'd like in IPng... Lets make sure that we don't overburden ourselves with many requirements that each force us to solve problems that no one has successfully solved before. Right now, by my count, we have at least three activities that no one has quite done: * expanding the address space to huge proportions (and note, I was reminded last week that folks are working on networking individual people -- for military reasons -- yes, your gun might have a separate IP address from your heads-up display). * support for real-time flows * autoconfiguration that works for arbitrary networks (not just 802) and topologies There are precedents for each task (except autoconfig) but the point is the technical risks are mounting, and we should think long and hard before we any more hard problems to this list. Craig From Greg_Minshall@Novell.COM Mon Mar 28 14:34:46 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id RAA00899 for ; Mon, 28 Mar 1994 17:43:51 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA28417; Mon, 28 Mar 94 15:48:20 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB04242; Mon, 28 Mar 94 14:34:46 PST Date: Mon, 28 Mar 94 14:34:46 PST Message-Id: <9403282234.AB04242@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: kasten@ftp.com From: Greg Minshall Subject: Re: If *i* were to write a white paper... Cc: ipng mailing list Status: O Frank, Thanks for the response. > > 1. No configuration needed for a host. So, use IEEE address as the "node > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >I think that this succinctly states the requirements vis hosts. I really >don't want to change the draft now -- will you be at the BOF to suggest >it? Yes. >Though the word "no" worries me a bit -- I am afraid that there might >be some needed config -- as your other post pointed out, a host can't >be expected to divine its node-name... And there was a lot of >discussion on big-i as to whether relying on IEEE 802 numbers was valid >(some machines might not have them etc etc etc). I'd probably word >an explanation to say that > "No config" is the ideal. We realize that there will probably need > to be some manual config and proposals will be evaluated based on the > amount and complexity of manual config that they require (the less > of both, the better)" I guess "needed" is the key. I *don't* need to set up a DNS name in order to use a host (as a client, say). Also, my third point (dynamic naming a la SAP) implies that once someone types *in* my name, it should be exported to the net with not additional configuration/manual entries. > > 2. Ease configuration of "subnets" (wires, whatever). One of the hardest > > things in configuring IPv4 networks is *subnet masks*. They are a total > > disaster from an ease of use point of view. So, no subnet masks. At most, > > choose one single number from some set of numbers and assign it to a > > subnet. Nothing more complex than that. > >I've always thought along the lines of having the routers periodically >advertise onto all connected nets >a) the 'network prefix' of the network which gives any receiving host > all it needs to know in order to determine the 'network number' > component of its address, (i.e. solving the auto-config issue > for getting network numbers/subnet-masks, etc, in to the hosts) and >b) what the router can connect to, which gives us router discovery... > >This has the added property that to change the network number of a >subnet, I simply have to tell the routers and they tell the hosts. I >do not even have to know that a host exists in order to change its >network number (AND, if there is a hierarchical relationship among >routers, the I can change the 'network number' in the 'network-level >router' and it can tell all the 'subnet-level routers' and they can >tell the hosts)... This is thinking done while driving to work in the >mornings - I'm sure that there is a hole or two in it :-) You aren't getting my point (i think). My point is *MAKE ROUTER CONFIGURATION SIGNIFICANTLY EASIER*. With (traditional) IPX and AppleTalk, configuring a router is fairly trivial: reach in a bag of 32 or 16 bit numbers and choose a network number and assign that number to the router. With non-subnetted IP, configuring a router is slightly harder: ask some *authority* for a number (or numbers), then assign one of those assigned numbers to the router. But, SUBNETTING has made configuring IP routers a nightmare for your mere mortal. Get this, get this, get this! Configuring routers is every bit as important as configuring hosts in terms of the needed simplicity. You (we) need to make this incredibly easy to do. Greg From J.Crowcroft@cs.ucl.ac.uk Tue Mar 29 16:42:13 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id KAA04780 for ; Tue, 29 Mar 1994 10:42:34 -0500 Message-Id: <199403291542.KAA04780@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 29 Mar 1994 16:42:15 +0100 To: ipng mailing list Subject: Comments on White Papers so far... Inereply-to: Your message of "Mon, 28 Mar 94 14:34:46 PST." <9403282234.AB04242@WC.Novell.COM> Date: Tue, 29 Mar 94 16:42:13 +0100 From: Jon Crowcroft Status: O 1. Technical Criteria Draft: couple of typos c.f. page 19, under Time Scale - sentance does not parse ("is immidiately" page 27, the novel portmanteua "bothe" appears in place of the conventional both the page 29 - the word specifically is misspelled, and the phrase "trwat a tunneled" doesnt parse. on page 23, the multicast groups "up to 10**6", doesnt fit with the Time Warner vision Vision - if you want to run cable tv, and cover Live Aid, you need 10**9 recipients i na group - you probably also want 10**6 groups. I think that the _range_ of speeds is important as well as the higher speeds - it means that you need flexible protocols and very stable control algorithms (c.f. congestion ctl).o I think there should be a specific requirement for "testability" - it is possible to design protocols that apparently meet requirements but which are hard to implement in testable ways... 2. Tuba as IPng white paper i thought this was unclear, but couldn't specify i ndetail why. 3. On adding a flow spec to clnp - needs complete revision after the Int-Servoutput is available...afor isntance use of the soruce TSEL to give 256 independnet flows is just to simple, insecure, and too few...o 4. cable television induistry viewpoint this is excellent - the best contrib so far 5. HPN contribution this was also very good - the requirement for clock synch hooks was interesting - as was the extreme example of mobility ... one thing we might beware of is whether we want to combine this type of extreme mobility with the time warner vision of very large sclae multimedia? 6,. Multiprotocol Interop....from georgeia texh this was useful just in enumerating the understood interworking techniques availbe... 7. SIPP - i'm biiased so i'll say nothing 8. TUBA Transision this is based on the same idea as the OSI transisiotn in the UK - the use of context in nameservers to indicate what protocol stack a hosts' lookup was in (source and destination version/protocol versiosns) i prefer the previous ISO idea of end to end negotiation - like MTU discovery - a source shoul just start sending hughest ersion IP it supports, and an ICMP version unre
cable, try this, error report will move it wn a version, or else it will timeout, and try a lower version til, when it succeeds, it caches the versio nfor use wit hther other host (and keeps the cache entry alive while conversastions persist, or unti la timeout similar to ARP...) 9. CERN paper on Engineering Considerations useful simple list of concerns 10. CATNIP the only really "unifying" approach - as an ex-phsysicist, i feel unifying approaches are holy grails, and not attainable (even to the Parsifal that is the IETF:-) - i don't believe you can do the header translations suggested, efficiently, or in a general bug free way (though I do believe you can do them...)o 11. Mark Pullens DSI input this is also very useful, in terms of big stressful systems - i was very impressed he didnt say ST-II once:-) 12. Electric Power Research this is frankly baloney - 13. implementation analysis this is useful except i dispute the assertion about confornmant APIs making recompiliation necessary for networked applications - forinstance, in programming languages like C (and C++) peoplke +_always_ workaround, nd get the return structure pointer from a gethostbyname() call, and just bcopy 4 bytes out of it....so you are just going to +have _ to recompile and probably mildyly fix a fairly large number of applicatiuons, or design the API (e.g. SIPP could quite easily use the low 4 bytes of a SIPP addr and add the rest as default...)o 14. Carpenters "on dynamica header translation considered harnful" depends - if the header translation is an innate iece of IOng, then it will be present at _all_ border gateways betewren IPng and IPv4 clouds so the config problem is non-problem. its clear to me that this also suggests that dynamic host config (plug and play) and mobility provide ways for intewrworking between IPng and IPv4 - we reserve some Ipv4 address space for 10 years past the IPng startup date - all IPng hosts must support IPv4 if they are to taslk to legacy hosts, but thwy must also support dynamic config of addresses, whether IPng or IUOv4 - so then to talk to an old site, you merely on demand get a IPv4 trasnsient address. assuming the number of IPv4 siters is _decreasing_ once IPng starts to be fielded, this is a scalable viable solution, and must also be a paret of the technology at least 2 of the requirements on IPng demand,. 15. the Boeing Usaers View. This is excellent - - it complkements the Time Warner view of technology, with the naive (in the good sense) requirement for simple application connectivity....- keepos our feet on the ground cheers jon p.s. sorry about the typos, but the 21 hps from seattly to london make it hard to drive a creen editor... From Greg_Minshall@Novell.COM Tue Mar 29 12:11:31 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id PAA04306 for ; Tue, 29 Mar 1994 15:20:38 -0500 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA10818; Tue, 29 Mar 94 13:25:07 MST Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06393; Tue, 29 Mar 94 12:11:31 PST Date: Tue, 29 Mar 94 12:11:31 PST Message-Id: <9403292011.AB06393@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: Comments on White Papers so far... Cc: ipng mailing list Status: O Jon, >i prefer the previous ISO idea of end to end negotiation - like MTU >discovery - a source shoul just start sending hughest ersion IP it >supports, and an ICMP version unre
cable, try this, error report >will move it wn a version, or else it will timeout, and try a lower >version til, when it succeeds, it caches the versio nfor use wit hther >other host (and keeps the cache entry alive while conversastions >persist, or unti la timeout similar to ARP...) Do IP implementations (i.e., does BSD) send back ICMP "version unreachable" messages? (Or, does the rawip handler get them? :) Greg From J.Crowcroft@cs.ucl.ac.uk Wed Mar 30 21:20:40 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.7/8.6.4) with SMTP id PAA03305 for ; Wed, 30 Mar 1994 15:21:54 -0500 Message-Id: <199403302021.PAA03305@picard.cmf.nrl.navy.mil> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 30 Mar 1994 21:20:45 +0100 To: Greg Minshall cc: ipng mailing list Subject: Re: Comments on White Papers so far... In-reply-to: Your message of "Tue, 29 Mar 94 12:11:31 PST." <9403292011.AB06393@WC.Novell.COM> Date: Wed, 30 Mar 94 21:20:40 +0100 From: Jon Crowcroft Status: O >>will move it wn a version, or else it will timeout, and try a lower >>version til, when it succeeds, it caches the versio nfor use wit hther >>other host (and keeps the cache entry alive while conversastions >>persist, or unti la timeout similar to ARP...) >Do IP implementations (i.e., does BSD) send back ICMP "version unreachable" >messages? (Or, does the rawip handler get them? :) Greg it isn't the host that wil lreport this - if the host doesnt provide IPvn, then the last hop router in IPvn router world will report that the host on IPvn is unreachiable, at which point the source moves to IPvn-1. jon From jcurran@nic.near.net Thu Mar 31 06:32:31 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id GAA22326 for ; Thu, 31 Mar 1994 06:32:54 -0500 Received: from nic.near.net by nic.near.net id aa08578; 31 Mar 94 6:32 EST To: ipng@cmf.nrl.navy.mil cc: Big-Internet@munnari.oz.au Subject: Market viability for IPng Date: Thu, 31 Mar 1994 06:32:31 -0500 From: John Curran Message-ID: <9403310632.aa08578@nic.near.net> Status: O This is already submitted as an ID earlier this week, but I figured some folks wouldn't want to wait... /John p.s. Please excuse the rather rough format. ---  Network Working Group J. Curran Internet draft BBN 25 March 1994 Market Viability as a IPng Criteria Status of this Memo This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Introduction In an open marketplace, adoption of new technology is driven by consumer demand. New technologies that wish to succeed in the marketplace must provide new capabilities or reduced costs to gain consumer confidence. Internetworking technologies can be particularly difficult to deploy and must provide a correspondingly high return on investment. In order to determine market viability of new internetworking technology, it's necessary to compare the required deployment effort against the potential benefits as seen by the customer. "Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. Curran [Page 1]  Internet draft IPng White Paper on Market Viability 25 March 1994 "Pushing" Internetworking Technology It has been asserted by some that the adoption of a single IPng protocol by the computing industry would generate general acceptance in the networking industry. There is ample evidence to support this view; for example, some of the today's more prevalent networking protocols gained initial market acceptance through bundling with computer operating systems (e.g. IP via UNIX, DECNET via VMS, etc.) It should be noted, however, that this approach to technology deployment is by no means assured, and some of today's most popular internetworking software (Novell, etc.) have thrived despite alternatives bundled by computing manufacturers. Given that IPng will have to compete against an well established and mature internetworking protocol (IP version 4), promotion of an IPng solution by computer system manufacturers should be recognized as highly desirable but not sufficient on its own to ensure IPng acceptance in the marketplace. Can IPng compete against IPv4? Given the large installed base of IPv4 systems, computer system manufacturers will need to continue to provide IPv4 capabilities for the foreseeable future. With both IPng and IPv4 support in their new systems, users will be facing a difficult choice between using IPv4 and IPng for internetworking. Existing IPv4 users will migrate to IPng for one of three possible reasons: New functionality not found in IPv4 IPng needs to provide functionality equivalent to that currently provided by IPv4. It remains to be seen whether additional functionality (such as resource reservation, mobility, autoconfiguration, autoregistration, or security) will be included in the base specification of any IPng candidate. In order to provide motivation to migrate to IPng, it will be necessary for IPng proposals to offer capabilities beyond those already provided IPv4. Reduced costs by using IPng It is quite unlikely that migration to IPng will result in cost savings in any organization. Migration to IPng will certainly result in an increased need for training and engineering, and hence increased costs. To gain connectivity to otherwise unreachable IPng hosts For existing sites with valid IPv4 network assignments, connectivity is not affected until address depletion occurs. Systems with globally-unique IPv4 addresses will have complete connectivity to any systems since backwards- compatible communication is required of new IPng hosts. Curran [Page 2]  Internet draft IPng White Paper on Market Viability 25 March 1994 >From the perspective of an existing IPv4 site, IPng provides little tangible benefit until IPv4 address depletion occurs and organizations reachable only via IPng appear. Given the absence of benefits from migration, it is uncertain whether a significant base of IPng sites will be occur prior to IPv4 address depletion. Sites which are not yet running IP have little motivation to deploy IPng for the immediate future. As long as IPv4 network assignments are available, new sites have an choice to use IPv4 which provides the sufficient internetworking capabilities (measured in functionality, cost, and connectivity) for many organizations today. Given the parity in IPng and IPv4 capabilities, IPv4 (as a more mature internetworking protocol) is the more probable choice for organizations just now selecting an internetworking protocol. Once IPv4 address assignments are no longer available, sites wishing to participate in the global Internet will have a very difficult decision in selection of an internetworking protocol. The current suite of IPng proposals cannot provide complete internetworking between IPng-only sites and IPv4-only sites since (by definition) there will be insufficient space to map all IPng addresses into the IPv4 address space. As none of the proposals currently call for dynamic network address translation (NAT), it is inevitable that IPng-only sites will have access to a partial set of IPv4 sites at any given moment. Internetworking services which do not allow complete access to the global Internet (IPv4 and IPng in the post-IPv4-address-depletion world) are clearly not as valuable as services which offer complete Internet access. Sites which are unable to obtain IPv4 network assignments will be seeking Internet services which can provide complete Internet service. Additionally, some sites will have "privately numbered" IPv4 networks and will desire similar Internet services which provide transparent access to the entire Internet. The development of network address translation devices and subsequent services is highly likely under these market conditions. Summary No internetworking vendor (whether host, router, or service vendor) can afford to deploy and support products and services which are not desired in the marketplace. Given the potential proliferation of network address translation devices, it is not clear that IPng will secure sufficient following to attain market viability. In the past, we have seen internetworking protocols fail in the marketplace despite vendor deployment and IPng cannot succeed if it is not deployed by organizations. As currently envisioned, IPng may not be ambitious enough in the delivery of new capabilities to compete against IPv4 and the inevitable arrival of network address translation devices. In order to meet the requirement for "viability in the marketplace', IPng needs to deliver clearly improved functionality over IPv4 while offering some form transparent access between the IPv4 and IPng communities once IPv4 address depletion has occurred. Curran [Page 3]  Internet draft IPng White Paper on Market Viability 25 March 1994 Author's Address John Curran BBN Technology Services, Inc. 10 Moulton Street Cambridge MA 02138 jcurran@near.net From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 06:32:31 1994 Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id HAA22448 for ; Thu, 31 Mar 1994 07:28:07 -0500 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA29066; Thu, 31 Mar 1994 21:40:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA29029; Thu, 31 Mar 1994 21:31:47 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24511; Thu, 31 Mar 1994 21:32:57 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa08578; 31 Mar 94 6:32 EST To: ipng@cmf.nrl.navy.mil Cc: Big-Internet@munnari.OZ.AU Subject: Market viability for IPng Date: Thu, 31 Mar 1994 06:32:31 -0500 From: John Curran Message-Id: <9403310632.aa08578@nic.near.net> Status: O This is already submitted as an ID earlier this week, but I figured some folks wouldn't want to wait... /John p.s. Please excuse the rather rough format. ---  Network Working Group J. Curran Internet draft BBN 25 March 1994 Market Viability as a IPng Criteria Status of this Memo This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Introduction In an open marketplace, adoption of new technology is driven by consumer demand. New technologies that wish to succeed in the marketplace must provide new capabilities or reduced costs to gain consumer confidence. Internetworking technologies can be particularly difficult to deploy and must provide a correspondingly high return on investment. In order to determine market viability of new internetworking technology, it's necessary to compare the required deployment effort against the potential benefits as seen by the customer. "Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. Curran [Page 1]  Internet draft IPng White Paper on Market Viability 25 March 1994 "Pushing" Internetworking Technology It has been asserted by some that the adoption of a single IPng protocol by the computing industry would generate general acceptance in the networking industry. There is ample evidence to support this view; for example, some of the today's more prevalent networking protocols gained initial market acceptance through bundling with computer operating systems (e.g. IP via UNIX, DECNET via VMS, etc.) It should be noted, however, that this approach to technology deployment is by no means assured, and some of today's most popular internetworking software (Novell, etc.) have thrived despite alternatives bundled by computing manufacturers. Given that IPng will have to compete against an well established and mature internetworking protocol (IP version 4), promotion of an IPng solution by computer system manufacturers should be recognized as highly desirable but not sufficient on its own to ensure IPng acceptance in the marketplace. Can IPng compete against IPv4? Given the large installed base of IPv4 systems, computer system manufacturers will need to continue to provide IPv4 capabilities for the foreseeable future. With both IPng and IPv4 support in their new systems, users will be facing a difficult choice between using IPv4 and IPng for internetworking. Existing IPv4 users will migrate to IPng for one of three possible reasons: New functionality not found in IPv4 IPng needs to provide functionality equivalent to that currently provided by IPv4. It remains to be seen whether additional functionality (such as resource reservation, mobility, autoconfiguration, autoregistration, or security) will be included in the base specification of any IPng candidate. In order to provide motivation to migrate to IPng, it will be necessary for IPng proposals to offer capabilities beyond those already provided IPv4. Reduced costs by using IPng It is quite unlikely that migration to IPng will result in cost savings in any organization. Migration to IPng will certainly result in an increased need for training and engineering, and hence increased costs. To gain connectivity to otherwise unreachable IPng hosts For existing sites with valid IPv4 network assignments, connectivity is not affected until address depletion occurs. Systems with globally-unique IPv4 addresses will have complete connectivity to any systems since backwards- compatible communication is required of new IPng hosts. Curran [Page 2]  Internet draft IPng White Paper on Market Viability 25 March 1994 >From the perspective of an existing IPv4 site, IPng provides little tangible benefit until IPv4 address depletion occurs and organizations reachable only via IPng appear. Given the absence of benefits from migration, it is uncertain whether a significant base of IPng sites will be occur prior to IPv4 address depletion. Sites which are not yet running IP have little motivation to deploy IPng for the immediate future. As long as IPv4 network assignments are available, new sites have an choice to use IPv4 which provides the sufficient internetworking capabilities (measured in functionality, cost, and connectivity) for many organizations today. Given the parity in IPng and IPv4 capabilities, IPv4 (as a more mature internetworking protocol) is the more probable choice for organizations just now selecting an internetworking protocol. Once IPv4 address assignments are no longer available, sites wishing to participate in the global Internet will have a very difficult decision in selection of an internetworking protocol. The current suite of IPng proposals cannot provide complete internetworking between IPng-only sites and IPv4-only sites since (by definition) there will be insufficient space to map all IPng addresses into the IPv4 address space. As none of the proposals currently call for dynamic network address translation (NAT), it is inevitable that IPng-only sites will have access to a partial set of IPv4 sites at any given moment. Internetworking services which do not allow complete access to the global Internet (IPv4 and IPng in the post-IPv4-address-depletion world) are clearly not as valuable as services which offer complete Internet access. Sites which are unable to obtain IPv4 network assignments will be seeking Internet services which can provide complete Internet service. Additionally, some sites will have "privately numbered" IPv4 networks and will desire similar Internet services which provide transparent access to the entire Internet. The development of network address translation devices and subsequent services is highly likely under these market conditions. Summary No internetworking vendor (whether host, router, or service vendor) can afford to deploy and support products and services which are not desired in the marketplace. Given the potential proliferation of network address translation devices, it is not clear that IPng will secure sufficient following to attain market viability. In the past, we have seen internetworking protocols fail in the marketplace despite vendor deployment and IPng cannot succeed if it is not deployed by organizations. As currently envisioned, IPng may not be ambitious enough in the delivery of new capabilities to compete against IPv4 and the inevitable arrival of network address translation devices. In order to meet the requirement for "viability in the marketplace', IPng needs to deliver clearly improved functionality over IPv4 while offering some form transparent access between the IPv4 and IPng communities once IPv4 address depletion has occurred. Curran [Page 3]  Internet draft IPng White Paper on Market Viability 25 March 1994 Author's Address John Curran BBN Technology Services, Inc. 10 Moulton Street Cambridge MA 02138 jcurran@near.net From J.Crowcroft@cs.ucl.ac.uk Thu Mar 31 21:43:02 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA26521 for ; Thu, 31 Mar 1994 15:43:23 -0500 Message-Id: <199403312043.PAA26521@picard.cmf.nrl.navy.mil> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 Mar 1994 21:43:06 +0100 To: ipng@cmf.nrl.navy.mil Subject: Summary of European RTDNET Backbone requirements Date: Thu, 31 Mar 94 21:43:02 +0100 From: Jon Crowcroft Status: O the attached messages may be of itnerest for their requirements... ------- Forwarded Messages Return-Path: Received: from sapling.surfnet.nl by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 31 Mar 1994 18:41:45 +0100 X400-Received: by mta sapling.surfnet.nl in /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:41:25 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:27:19 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:27:02 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:26:57 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:26:43 +0200 Date: Thu, 31 Mar 1994 19:26:43 +0200 X400-Originator: rtdnet-forum-request@nl.rare X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;<9403311726.AA09158@dante.org.uk] X400-Content-Type: P2-1984 (2) Content-Identifier: Summary of Ba... From: " (Dai Davies)" Sender: rtdnet-forum-request@nl.rare Message-ID: <9403311726.AA09158@dante.org.uk> To: rtdnet-forum@nl.rare Cc: dai@uk.org.dante, sho@be.cec.dg13, mgri@be.cec.dg13 Subject: Summary of Backbone network results 1 X-Sender: dai@sun Content-Length: 15557 The backbone network panel members have extended the contributions made at the working meetings. I have edited and combined these to form the basis of discussions at the next Meeting. They are being sent to the RTDNet forum for wider information and comment This set of Contributions deal with issues surrounding the Implementation of the backbone both from an Implementation and pilot experimentation perspective. There has been a debate about whether we are talking about a single or multiple backbones. The requirements here do not take a position on implementation per-se. They do recognise the need to interwork with what exists today and allow the potential for High performnance operational serrvice to co-exist with one another. No position on the commercial implications of this work. Please note that the following information is being made public to stimulate discussion, in the preparation of the work programme for Telematics for Research, under the EC Fourth Framework Programme. It is assembled by the Rapporteur. The European Commission makes no commitment to incorporate any part of the information into future calls for proposals; neither is the European Commission responsible for any use to which the information is put. 1 Planning implications of interconnecting with existing networks User Requirements There is a range of user requirements for the high performance backbone inclding piloting new applications, dealing with the aggregate demand from existing, applications, pilotting the new backbone itself and routine use of the new high performanec applications by the broad range of the European reserach community. In this context inter-connection with existing networks has to be an important work item of any developments. It has both commercial and technical implications Even in a pilot project phase users will not accept degradation concerning their actual levels of service quality and full connectivity. Planning will have to cope with the interconnection of existing networks problems and needs tio address this question on a global scale. Objectives To define plans for the the integration of current networking facilities with the new high performnace backbone taking inot account geographic scope, the distinction between "pilot" and "service" networks and the need to maintain and enhance quality of service. Approach - -QOS needs to be guaranteed from END user to END user. Both the Backbone and the connected networks are concerned. Transparency to the user should be guaranteed. - -Rules, rule-sets are needed regarding common use policies. Are research 'for profit' organisations allowed in the programme ? - -Standards are needed regarding global issues such as network management, quality of service, experiments with potential standards, market proven..... - -To ensure full connectivity the Backbone and traffic interchange should be sufficiently open. Monopolistic situations have to be avoided. - -Fair schemes for cost allocation to the different networks using the Backbone infrastructure need to be defined. 2 Development of criteria for success in backbone piloting activities Interactions with other areas - ----------------------------- This area interlinks with: charging - one criterion of success is (may be) that services should still be viable when charged at eventual commercial rates migration to operational service - another criterion of success is (may be) that services should successfully make this transition quality of service - ability to meet defined Q-O-S goals, and hence a requirement to be able to measure delivered quality of service, are central to the success of operational services user support - subjective evaluation of services by the user community is an important component of overall evaluations in all backbone areas project management - the gathering of data, monitoring and reporting of progress which are required for project evaluation are management roles Rationale - --------------- Telematics for RTD is a technically demanding area and directions will change during the programme. The project guidelines foresee this as 'iterations' in the project plans, and input to that process is required. Further, the Telematics for RTD imperatives require that technical validation of projects be carried out by some process. Objectives - ---------------- The criteria for success adopted for any individual pilot infrastructure activity must be such as to provide feedback to sponsors, participants and others on the effectiveness of that part of the 4th framework programme. The criteria listed for an activity should be sufficiently concrete to provide objectives for project participants. Technical Approach - ------------------------ 1) 'Success' must be defined in explicit and concrete terms for each proposed infrastructure project. It will be necessary to establish a working group to set a standard practice for pilot projects to be carried out under this programme. Suitable inputs for gauging success will be: a) Subjective criteria - based on the reactions of users/participants/sponsors. 'Users' is not a preordained group in this context, implying merely the group or community which is supposed to benefit from the implementation of the particular pilot. This may consist of (groups of) end users, research computing centres, research network operators or backbone network operators. The approach should be to weigh the reactions of users more heavily than others in assessing the subjective success of pilot projects. It may not be necessary to gauge the reaction of sponsors (EC?) at all, depending on established practice. A convenient methodology is to ask for scores on a 5-point scale from the evaluation groups, and to weight the scores (e.g.) 80-20 in favour of the user ratings. Pilot projects should always be required to define their target community (-ies). In some cases, where a pilot project is considered advisable for technical reasons but has no obvious or appropriate user community (e.g. level of demand is insufficient to adequately exercise some new technology), it may be necessary to *construct* an application group or project to provide on-going verification for the pilot. It may be further advisable that a proposed sample of the target group should be involved in the pilot planning, even to the extent of requiring endorsement from such a group as a precondition of acceptance. b) Objective criteria - based on measurement or evidence Objective project characteristics may be performance-related (requiring measurement procedures for the parameters - such as rates, availabilities etc. - which are targeted); or may be sub-goal- related (requiring verification of deliverable services, milestones, procedures or attributes). One important category of objective criteria consists of the planned implementation time-scale, against which subsequent progress may be judged. One consequence of the early lack of sophistication which the network infrastructure is likely to exhibit is that it may be difficult to gather some kinds of statistics on network performance and behaviour. Objectives should therefore, where possible, be of such a nature as to be verifiable from the point of view of a target user or group. (Note in this context that the measurements used to determined success of the pilot project will not be as detailed as the measurements needed for maintenance and control of the pilot service, mechanism or infrastructure itself). An important objective for some (but perhaps not all) pilot activities is the degree of commercial viability of the resulting service. This may be measured in two ways: by the actual degree of take-up (during the pilot) of the service within its target community, and by determining (by opinion survey) the intended future degree of take-up of the service once (commercially viable) charging begins. This may imply further that some marketing activity could be appropriate for some projects (and may improve their success scores). c) A-priori requirements Apart from the set of subjective and objective evaluations which a pilot project may be required to undergo, there may be also a set of requirements, largely common to all such projects, which represent external or customary imperatives. In some cases it is appropriate that compliance with these imperatives should also be verified when assessing the success of the pilot project. Examples of this category of requirement: - agreed supplementary activities (e.g. establishment of support structures, etc.) - intuitively evident requirements (e.g. existing services, protocols, equipment should be able to work over new networks) - management and reporting standards (e.g. usual EC project deliverables) d) Completion Projects in this area (which is far from pure research) should in general have an explicit end-of-project goal and not merely a stop date. e) Outputs Projects should include in their proposals a definition of the project outputs: what is to remain in place once the pilot period is over. 2) Where measurable criteria have been adopted (i.e., in the majority of cases), target numerical values (or acceptable ranges) for them need to be set. This may arguably be extended to setting targets for user-group satisfaction with the service. Such numerical targets may represent standard practice of some kind, the expressed needs of the target user community, or an abstract goal. In the particular technological area (advanced technology wide-area networking) under consideration, it is reasonable to anticipate that additional measurable criteria will be imposed on backbone pilot projects after they are already under way (e.g. maximum jitter tolerated in nominally isochronous service, which will not be subject to end-user review until some of the novel application projects come on-stream). This may require negotiation between the user groups concerned and the backbone pilot implementors. Where progressive implementation, or progressive takeup of a backbone project is anticipated, suitable criteria for each phase of the project should preferably be established at the outset. 3) During the progress of the pilot projects, an on-going activity to measure the performance, degree of compliance, and user group acceptability of the pilot service must take place. Groups running application projects under the 4th framework programme must be aware of the need to instrument their applications sufficiently well to be able to deliver meaningful data to the backbone groups supporting them. The staff and other resources needed to gather this data and prepare it for submission must be either included in the original project proposals, or funded as an accompanying measure. 4) The deliverable product of these monitoring activities will be reports and/or periodic reviews of the effectiveness of the various backbone projects. The need to maintain a strong user-oriented culture in all the backbone projects implies that the application projects themselves must assume a responsibility for gathering and reporting findings on the service they are receiving from the backbone projects. The frequency, circulation, content and scope of such periodic project reports needs to be established. 5) Not strictly a 'criterion for success', it is nevertheless necessary that the data gathered and the reports and reviews generated by this activity should feed into the general process of management of the backbone projects. A failure to meet planned criteria may result in one of several possible compensating actions: - correction of mis-directed or under-performing activity - changing objectives - revision of the implementation plan 2.4.4 Validation - ---------------- Validation of the mechanism outlined here is a project management role, at several levels. Among other aspects, the following may be monitored: 1) Do all projects have defined criteria? 2) Are data related to the criteria being received? 3) Are the project overheads related to the collection and processing of this data at a reasonable level? 4) Is the feedback from the monitoring process reaching the right people? 2.4.5 Expected results - ---------------------- (The categorisation 'Expected results' does not appear appropriate to this activity). END Of Part 1 dai davies d.r.h.davise@dante.org.uk ------- Message 2 Replied: Thu, 31 Mar 94 21:38:36 +0100 Replied: " (Dai Davies)" Replied: rtdnet-forum@nl.rare Replied: dai@uk.org.dante Replied: sho@be.cec.dg13 Replied: mgri@be.cec.dg13 Return-Path: Received: from sapling.surfnet.nl by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 31 Mar 1994 18:54:30 +0100 X400-Received: by mta sapling.surfnet.nl in /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:55:20 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:43:46 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:43:25 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:43:16 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 19:42:55 +0200 Date: Thu, 31 Mar 1994 19:42:55 +0200 X400-Originator: rtdnet-forum-request@nl.rare X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;<9403311742.AA09218@dante.org.uk] X400-Content-Type: P2-1984 (2) Content-Identifier: Summary of ba... From: " (Dai Davies)" Sender: rtdnet-forum-request@nl.rare Message-ID: <9403311742.AA09218@dante.org.uk> To: rtdnet-forum@nl.rare Cc: dai@uk.org.dante, sho@be.cec.dg13, mgri@be.cec.dg13 Subject: Summary of backbone Network results 2 X-Sender: dai@sun Content-Length: 8396 The backbone network panel members have extended the contributions made at the working meetings. I have edited and combined these to form the basis of discussions at the next Meeting. They are being sent to the RTDNet forum for wider information and comment This set of Contributions deal with Management issue from both a technical and human persective. associated with this area of activity is the question of security. It was recognised that this is an area for both backbone network and applications and that there could be interaction Please note that the following information is being made public to stimulate discussion, in the preparation of the work programme for Telematics for Research, under the EC Fourth Framework Programme. It is assembled by the Rapporteur. The European Commission makes no commitment to incorporate any part of the information into future calls for proposals; neither is the European Commission responsible for any use to which the information is put. 1 Network management Rationale Networking services in the research community are provided by a combination of concatenated networks each with its own independent network management domain. When there are operational or performance problems, these can be difficult to resolve because of the lack of overall visibility of the networking service. The purpose of this task is to explore what can be managed and monitored in this concatenated networking environment to make proposals for the implementation of management systems and procedures to deal with performance, fault and planning management and to pilot the implementation of such systems Objectives To determine what objects and performance parameters can be measured and managed in a concatenated networking environment. To propose techniques for information gathering analysis and control of such objects and performance parameters To implement pilot systems, both technical and organisational that will provide better information and control in this networking environment Technical approach Survey of management interfaces on current networks Definition of performance parameters to be measured Review of the problems of interaction between different management domains Definition and implementation of a policy with respect to Standards in particular recognising the commercial signifigance an practical realities in this area Development of a pilot project to implement and test improved multi-network management systems Validation Via a pilot implementation which would have defined objectives Expected results Improved network performance and diagnostic capabilities leading to faster elimination of faults and better network utilisation 2 REQUIREMENTS FOR USER SUPPORT Rationale Research networks are being built to meet the needs of a wide variety of user communities. Users in those communities are not necessarily familiar with the technology as well as the potential of current or future communication networks. Moreover, users from disciplines other than informatics or telematics experience great difficulties in identifying sources that can provide them with networking services initially and in helping them maintain their connection properly after they have been offered a connection. Objectives To provide training and advice on networking aspects in addition to troubleshooting aid need to be offered on a continuous basis following the initial connection of a user or a group of users to the future trans-European research network. To encourage the use of Research Network facilities including the use of advanced, high performance applications by the broad range of European researchers. Special attention should be focused on developing mechanisms that mask out technicalities as well as other complexities of research networks and provide users who have no previous networking experience with the necessary support to meet their networking needs. Approach The concept of one-stop shopping for network services provision should be aimed for in order to reduce the potential complexities that a common user is confronted with in his/her struggle to get 'networked'. Although the future trans-European research network will be based on the co-operation of different national and international network operators and service providers, there should be a virtual common 'front desk' that a potential ordinary user has to refer to. The aim of this management task is, first, to develop common standards for setting up such 'front desks' in a large number of points-of-presence' in all countries of EU and in as many regions as possible in each country and, second, to implement one-stop shopping mechanisms for (a) network procurement (b) service subscription (c) training provision and (d) troubleshooting support by considering the differences in the local communications environment that a particular 'front desk' happens to operate. The option of taking specific groups of potential users united by a common interest and supporting their use of new and existing applications is a potential approach to this Finally, marketing and advertising, awareness creation and technology watching are key activities that should be maintained at a high level throughout this task in order to increase the benefit that the future trans-European research network may have for as many research communities as possible, thus preserving the critical mass of users that is necessary to secure cost-effective and self-sustained network operations. Validation There are a number of solutions to validating the results of this activity. Qualitative analysis of user perception of service is relevant. A quantitative approach based on the number of new International user groups created would also be appropriate. The Validation Criteria need to be further defined as part of the project proposal. Expected results A significant increase in the number of researcher using Telematics as part of Pan-European research programs. An improvement in the overall quality of support for Non-Computer Literate International users. It was recognised that this activity could form the basis for an accompanying measures proposal. 3 Security Rationale - --------- Network users need to be assured that data is transferred uncorrupted over the network and that machines and persons they communicate with are actually the same as they purport to be. In addition, the backbone is a large economical resource and the security design should assure that only organizations and persons who have a license to access the backbone can do so. On the other hand, the backbone will be used by thousands of organizations and milliones of people and elaborate security procedures for using the backbone are not acceptable. The main point is that the degree of security of each network layer and application is understandable and acceptable. Objectives - ---------- The degree of security must be described for each network layer. The description should cover access control, authentication and reliability of the processes where appropriate. Technical approach - ------------------ Security breaches may occur at all layers in the network architectural model so there is a need to consider security at all layers from the physical layer up to the application layer. Basically, it must be considered how data can be protected from willful or accidental corruption in all processes between the ultimate sender and receiver in the communication process. The consideration of reliability should include major design factors that may influence this such as protection against overload both in normal and exceptional conditions. Validation - ---------- A system for reporting security breaches must be set up. Where appropriate procedures for auditing an reviewing security should be established. Expected results - ---------------- The backbone should be proven as sufficiently reliable for users to trust it as a basic communication infrastructure on the level of telephone and postal mail. As applications such as encrypted mail and digital signatures evolve and are taken up by the user community, the backbone should be sufficiently secure not to corrupt the security obtained at the application level for such uses. End of Part 2 Dai davies d.r.h.davies@dante.org.uk ------- Message 3 Return-Path: Received: from sapling.surfnet.nl by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 31 Mar 1994 19:14:29 +0100 X400-Received: by mta sapling.surfnet.nl in /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 20:15:36 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 20:13:36 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 20:12:54 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 20:12:50 +0200 X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed; Thu, 31 Mar 1994 20:12:45 +0200 Date: Thu, 31 Mar 1994 20:12:45 +0200 X400-Originator: rtdnet-forum-request@nl.rare X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;<9403311812.AA09422@dante.org.uk] X400-Content-Type: P2-1984 (2) Content-Identifier: Summary of ba... From: " (Dai Davies)" Sender: rtdnet-forum-request@nl.rare Message-ID: <9403311812.AA09422@dante.org.uk> To: rtdnet-forum@nl.rare Cc: dai@uk.org.dante, sho@be.cec.dg13, mgri@be.cec.dg13 Subject: Summary of backbone network results 3 X-Sender: dai@sun Content-Length: 7991 The backbone network panel members have extended the contributions made at the working meetings. I have edited and combined these to form the basis of discussions at the next Meeting. They are being sent to the RTDNet forum for wider information and comment. this set of contributions is intended to define the requirements for the backbone and the definition of the Networking services required. There is a context to the contributions received here namely the proposal from the PNO representatives on the panel that the European ATM pilot could form a sensible basis for the future High performance research backbone. It was decided to consider the option in more detail in the context of the future support, both technical operational and commercial, for the activity bearing in mind its current limited time scale. The definition of Networking Services reflects this context. The contributions on charging and Quality of Service (QoS) were independant of any particular solution. The Qos contribuiton is repeated here. The conclusion with respect to charging was that this was not a question for action in respect of the Fourth Framework program but a commercial issue. subsequently the question of application charging requirements from networking services was raised and this point needs further consideration in respect of charging facilities for applications Please note that the following information is being made public to stimulate discussion, in the preparation of the work programme for Telematics for Research, under the EC Fourth Framework Programme. It is assembled by the Rapporteur. The European Commission makes no commitment to incorporate any part of the information into future calls for proposals; neither is the European Commission responsible for any use to which the information is put. Definition of Networking Services Rationale ATM is considered as the transfer mode suitable to convey almost all types of user services, bringing to the reality the dream of one network for all the services as opposed to the today's fact of "almost" one network for one service. European Telecom Operators are implementing a Pan European Pilot based on ATM, offering a few experimental services (Circuit emulation, SMDS/CBDS, Frame Relay, ATM Virtual Paths,...) aiming in the near future, to offer switched VC. But, are those network services fulfilling all the requirements of the European Research Community? A network with higher potentialities will lead to the appearance of new applications and services from the user, in particular from the Research Community. The increase in terms of quality offered today, the bandwidth of some applications/services and the need to take in account the time to transfer the information across the network, will affect the protocols (error correction, retransmission of information, may no longer be necessary....). Probably, some simplicity should be reintroduced in order to take full advantage of the network capabilities. But, in this case, how can the user know that his application is working properly? For a certain number of services, like multimedia, VPN (virtual private networks), is essential to give to the user control of the calls. Applications with different service components may face the fact that those components may follow, through the network, different routes with different propagation time. Should the application be prepared to coop with that or should the network have the capability to offer as a service the use of the same route to send the cells? ATM is also offering to the network operator the possibility to better use their resources (Statistic multiplexing gain). This may lead to a different behaviour: the negotiation of bandwidth before the call and the dynamic allocation of resources, according to the request of the user once established the "connection". Some applications/services will have an asymmetric behaviour in terms information flow. Should the charging be flat (according for instance the maximum capacity of the access link..) or should it be by volume or a mix of the two options? It will take time to make the ATM facilities available to all the members of the research community. This means that inter working with existing networks is a must. Should that interworking be transparent to the user? The broadband capabilities of the new network will allow the implementation application like CW, video libraries, multimedia BBS, Teleteaching,.... Some of those applications will require capabilities like multicasting. This could be achieved by the application itself or by the network, saving, in this case, network resources. Should this be a feature of every network node? Objectives The main objective is to identify, besides the services already referred, services required to the Research Community and to verify the network capabilities to fulfil them and the impact on the applications Technical Approach Using the PEAN facilities and acting as a special user group working in close cooperation with the PNO's consortium, build a pilot network interconnecting some representative users. Define the services to be implemented and a realistic time scale, according to the deployment of the pilot network. Define the requisites of the network services to fulfil the requirements of the user community Define a set of parameters/criteria to evaluate the benefits Validation Validation of the approach is made through the VPN build upon the PEAN to implement the Pilot Research Network. Verification of the results in the pilot against the criteria defined Expected Results To identify the requirements over the network services to satisfy the Research Community needs Contributions to the relevant standards. Establish the base to go from the pilot phase to the operational phase at European level 2 Definition of Quality of Service Requirements and Proposals for Measurement Rationale It is important for users to know the quality of a high-speed backbone service. Measurements of QoS will feature in contracts and service-level agreements between the customers and the providers of the backbone infrastructure. Objectives It is necessary to quantify the QoS under headings such as: 1 Faults These inclulde mean time between failure, guaranteed up-time over various periods, robustness, data loss, profile of fault duration, maintenance windows. 2 Performance Measures here include available bandwidth, round-trip times, probability of success of bursty traffic, mean available user throughput. Diurnal variations in these are also needed. Aspects of the service that deliver broadband applications should be studied, together with the relevant standards, to determine the necessary metrics. Means of measuring these values regularly and by means of recognised standards must be determined. Technical Approach The quality of service will be demanded by the customer and offered by the infrastructure providers. It will describe, within quantified limits, the performance of the network from the perspective of the user. The task will develop the tools needed to monitor the service and gather the metrics. It will also determine the data points needed in the concatenation of networks. Validation QoS metrics will be taken and reported at regular intervals during the pilot and production phases of the infrastructure. Their values will determine the relative success of the service. Expected Results The QoS metrics, in conjunction with the standards adhered to, will be refined by the user community and used in preparing service-level agreements for commercial service. End of Part 3 Dai davies d.r.h.davies@dante.org.uk ------- End of Forwarded Messages From ericf@atc.boeing.com Thu Mar 31 23:32:50 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA01101 for ; Fri, 1 Apr 1994 10:24:52 -0500 Received: by atc.boeing.com (5.57) id AA13498; Thu, 31 Mar 94 23:32:50 -0800 Date: Thu, 31 Mar 94 23:32:50 -0800 From: Eric Fleischman Message-Id: <9404010732.AA13498@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: Six views for IPng Decision Status: O Six views for Evaluating IPng Proposals 1) "Spec Check": compare IPng alternatives to requirements doc 2)Enumerate the real technical differences between proposals in regards to the requirements 3) Enumerate the real operational differences between the proposals 4)Address real deployment and transition plans: contrast dual stack and IPAE transition scenarios 5)Proof of concept: what has actual "running code" to date demostrated about the approach -- address scalability issues if possible. 6)Identify the incentives provided by each approach for users to deploy that option. From brian@dxcoms.cern.ch Fri Apr 1 18:48:48 1994 Return-Path: brian@dxcoms.cern.ch 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 LAA01874 for ; Fri, 1 Apr 1994 11:49:24 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12792; Fri, 1 Apr 1994 18:48:50 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA26190; Fri, 1 Apr 1994 18:48:49 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404011648.AA26190@dxcoms.cern.ch> Subject: Re: fragmentation in IPng To: pvm@isi.edu Date: Fri, 1 Apr 1994 18:48:48 +0200 (MET DST) Cc: J.Crowcroft@cs.ucl.ac.uk, kasten@ftp.com, deering@parc.xerox.com, ipng@cmf.nrl.navy.mil In-Reply-To: <199403241837.AA04534@zephyr.isi.edu> from "Paul Mockapetris" at Mar 24, 94 10:36:18 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: 510 Status: O I'm glad I didn't have time to follow this chain in real time. Just one observation: IP over ATM specifies an MTU of approx 9 kbytes, chosen to match SMDS size, and IP over ATM can negotiate UP to 64 kb in theory. I think Paul's rule is not enough (if you believe any part of the ATM hype). Brian >--------- Text sent by Paul Mockapetris follows: > > > Rule1: All IPngs must be able to handle arriving datagrams of 2K. > > Link level fragmentation should be used if the link doesn't like rule > 1. > From ericf@atc.boeing.com Fri Apr 1 13:45:32 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA03986 for ; Fri, 1 Apr 1994 16:44:00 -0500 Received: by atc.boeing.com (5.57) id AA29255; Fri, 1 Apr 94 13:45:32 -0800 Date: Fri, 1 Apr 94 13:45:32 -0800 From: Eric Fleischman Message-Id: <9404012145.AA29255@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: Brian's Comment Status: O Dear Frank Kastenholz and the IPng Directorate, Brian Carpenter is now on a week's vacation. Before leaving the IETF meeting he asked me to forward on to Frank Kastenholz (via the IPng list) the following specific text to be added as a specific new Technical Requirement within the Criteria document. This text is in response to a verbal request which Frank made to Brian during the Open IPng Plenary meeting earlier today. The proposed text of the new requirement now follows: "It must be possible from day one to interconnect CLNP islands (which have NSAP addresses) via the IP and IPng Internet (i.e., during transition). This is a first step towards convergence of the CLNP and IPng infrastructures." By asking me to post this item to the list Brian is also asking for the group to word-smith or debate any item. Both he and I believe that convergence between the protocols is A Good Thing (in the general case) and an important technical requirement component of IPng (especially vis-a-vis CLNP and possibly IPX as well). Both Brian and I feel that the current criteria should reflect this orientation and make this requirement be a explicit criteria to be used during our evaluation of the proposals. Sincerely yours, --Eric Fleischman From craig@aland.bbn.com Fri Apr 1 14:14:37 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA04199 for ; Fri, 1 Apr 1994 17:16:16 -0500 Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA19383 for ipng@cmf.nrl.navy.mil; Fri, 1 Apr 94 17:16:02 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id OAA08917; Fri, 1 Apr 1994 14:14:42 -0800 Message-Id: <199404012214.OAA08917@aland.bbn.com> To: Eric Fleischman Cc: ipng@cmf.nrl.navy.mil, craig@aland.bbn.com Subject: Re: Brian's Comment In-Reply-To: Your message of Fri, 01 Apr 94 13:45:32 -0800. <9404012145.AA29255@atc.boeing.com> From: Craig Partridge Date: Fri, 01 Apr 94 14:14:37 -0800 Sender: craig@aland.bbn.com Status: O The proposed text of the new requirement now follows: "It must be possible from day one to interconnect CLNP islands (which have NSAP addresses) via the IP and IPng Internet (i.e., during transition). This is a first step towards convergence of the CLNP and IPng infrastructures." Hi Eric: For the moment I'll put aside the question of whether this is a technical or political requirement (since I'm of mixed minds), and focus on this note as a technical proposal. As a technical proposal, we need to sharpen it up. First, I'll note that twenty years of work on protocol conversion have resulted, almost without exception in failure. Is tunnelling an acceptable solution? Since the statement is "interconnect CLNP islands", I assume direct connectivity between CLNP hosts and IPng hosts is not required? If direct connectivity is required, then we need some more details thrashed out. Everyone understands that when we say IP-IPng interoperability, we mean that TCP/UDP/ICMP etc on IP has to have a mapping onto IPng. For CLNP are we to say the same thing, e.g., TCP/UDP etc on CLNP (e.g. TUBA) must be mapped into IPng? Or is it saying TP4-0 on CLNP (not to mention other higher layers) must be mapped onto IPng? Also, is it permissible to define a CLNP addressing structure to make this work? For instance, suppose, for instance, that the CATNIP folks said "if you use this IETF-defined addressing structure in CLNP" then everything maps cleanly between CATNIP and CLNP, but all those other CLNP addressing formats (of which there can be many, though I gather only a few are in use) don't work. Is this OK? Thanks! Craig From bound@zk3.dec.com Sat Apr 2 20:56:19 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA08152 for ; Sat, 2 Apr 1994 21:01:07 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA21436; Sat, 2 Apr 94 17:56:28 -0800 Received: by xirtlu.zk3.dec.com; id AA13085; Sat, 2 Apr 1994 20:56:26 -0500 Message-Id: <9404030156.AA13085@xirtlu.zk3.dec.com> To: Jon Crowcroft Cc: ipng mailing list Subject: Re: Comments on White Papers so far... In-Reply-To: Your message of "Tue, 29 Mar 94 16:42:13 +0100." <199403291542.KAA04780@picard.cmf.nrl.navy.mil> Date: Sat, 02 Apr 94 20:56:19 -0500 X-Mts: smtp Status: O Jon, That was useful thanks. Also I completed my mental design of an IPng API that will work for all proposals. In this design any IPng when installing their new set of stacks on the host will not break existing IPv4 apps that do not want to take advantage of IPng until they are ready. Once they want to use IPng from the API the code changes would be minimal. Of course each solution has a different hack on my end. Performance would vary but not by enough to sway me to one proposal or the other. Whether I code this up is dependent on some other deliverables for April. I just don't know when I will. I want to run it by some other engineers too at Digital. I also want to run it by a POSIX person I know too from my past who is still active in POSIX. Should I patent something like this ????? (just kidding). /jim From sob@hsdndev.harvard.edu Mon Apr 4 00:11:56 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA10884 for ; Mon, 4 Apr 1994 00:13:04 -0400 Date: Mon, 4 Apr 94 00:11:56 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404040411.AA16045@hsdndev.harvard.edu> To: J.Crowcroft@cs.ucl.ac.uk, bound@zk3.dec.com Subject: Re: Comments on White Papers so far... Cc: ipng@cmf.nrl.navy.mil Status: O a question about APIs (not withstanding Marshall's fondness for them) how many would an IPng need? there is sockets, winsoc (or is that the same), streams ... Scott From J.Crowcroft@cs.ucl.ac.uk Mon Apr 4 14:05:28 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA12311 for ; Mon, 4 Apr 1994 09:05:59 -0400 Message-Id: <199404041305.JAA12311@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Apr 1994 14:05:34 +0100 To: Eric Fleischman cc: ipng@cmf.nrl.navy.mil Subject: Re: Brian's Comment In-reply-to: Your message of "Fri, 01 Apr 94 13:45:32 -0900." <9404012145.AA29255@atc.boeing.com> Date: Mon, 04 Apr 94 14:05:28 +0100 From: Jon Crowcroft Status: O > "It must be possible from day one to interconnect CLNP islands > (which have NSAP addresses) via the IP and IPng Internet (i.e., during > transition). This is a first step towards convergence of the > CLNP and IPng infrastructures." I belive interpreting this hangs on one word: "via". if you want to propose use of IP, IPng to carry stuff, we already do it - X.25 and IPX support in the UK is done over IP, and will be over IPng. Its also in the requirements for IPng: see 'Tunneling'. If you want to propose interworking, specifically, for CLNP _to_ IPng, then I have a problem. A priority for this in terms of connectivty would be higher for IPX than for CLNP. however, I disagree with Craig about interworking research being a failure...I belive the 3 techniques, tunneling, transport service briding (rfc1006) and application relaying are well understood. If we want to urge convergence, do we want it at the network service, or the packet format. If the latter, can I suggest that this is a very strong statement, and eneeds much more movement from the CLNP community. let me also note that the requirements for multicast, network service (aka flows), and performance are causing CLNP to converge nicely already. However, there is a bottom line. At hte decision point, I believe the choice for IPng is made based on the _best_ candidate. Not on whether some candidate _can_ achive the required functions, but on which can do them best. This is why I think the 'performance' requirement is key. Let me assert that under some unifying theory of datagram communication, you can probably show (like yo ucan under the church/turing/markov theorem) that all protocols are funcationally equivalent, so we could never have a bakeoff. However, the fact that an intel 8086 can execute the same program as a cray is neither here nor there. we would like the let me also point out that there were at least 2 requirements I heard in the int-serv WG, on flows the model Wroclawski presented for classifcation was that the cost was linar in the number of fields to classify, and also hard to code efficiently in variable length mask/match fields (though easire in the procedural model, but less efficient). i.e. we are being told something quite strong about how fast you can make a given router go on putting packets into the right queue (includes route lookup as well as QoS matching). That thing is that fixed fields (c.f. IPv4, catnip and SIPP) are better than variable ones (c.f. CLNP). perhaps convergence could be the adoption of some fixed address fields in CLNP, and a similar to SIPP convention on option ordering. cheers jon From kasten@mailserv-D.ftp.com Mon Apr 4 15:22:28 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA15518 for ; Mon, 4 Apr 1994 15:23:21 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 4 Apr 1994 15:23:19 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA17334; Mon, 4 Apr 94 15:22:28 EDT Date: Mon, 4 Apr 94 15:22:28 EDT Message-Id: <9404041922.AA17334@mailserv-D.ftp.com> To: ericf@atc.boeing.com Subject: Re: Brian's Comment From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 3240 Status: O > By asking me to post this item to the list Brian is also asking for > the group to word-smith or debate any item. Both he and I believe > that convergence between the protocols is A Good Thing (in the general > case) and an important technical requirement component of IPng (especially > vis-a-vis CLNP and possibly IPX as well). Both Brian and I feel that the > current criteria should reflect this orientation and make this requirement > be a explicit criteria to be used during our evaluation of the proposals. I'm sorry. I have to say that I do not see this as a technical criteria. It does not go in. I'd point out that many years ago, the ISO declared that CLNP would be the One True Network-Layer Protocol and that all other NLPs would eventually fade away as the world converged onto CLNP. Eric showed a nice slide last Friday showing how effective that declaration was. Why has convergence to CLNP as the OTNLP not occured? There were two reasons that I got -- first, for the most part, systems were converging to IP as the OTNLP, or a system was a legacy system which could not be upgraded (I include the "we've got too much invested in our own protocol suite so we can't go to xxxx" in this category). Also, a systm which had not gone to IP and was not a legacy system would probably eventually go to IP as IP got more of the needed functions. So, my observation is that the world will, to the best of its ability, converge of its own accord to the best common open protocol suite, regardless of the diktats of political organizations such as the ISO or the IETF. Our goal should be to A) return the E to the IETF and B) make IPng the best technology that we can -- and don't worry, if it is good, the world will come and use it. Furthermore, I see convergence (especially forced convergance) as, necessarily, a bad thing. First, it would require that IPng be able to handle all demands, that it be suitable for all possible applications and uses. In otherwords, it must do everything. IPng would be mediocre at all tasks, rather than excelling at a few, well-chosen, tasks. Second, by implying that IPng is the one and only network-layer protocol, we would lose competition. Other network-layer efforts would be doomed to failure since, by definition, IPng is the One and Only, the True, Network Layer Protocol - and as a result, bright ideas from unlikely corners of the universe would be lost. A contributing factor in the development in the IPv4 world is all the competition which is given by the other protocol families -- e.g. appletalk's spurring on of our resource location efforts. To imply that there is to be only one network layer protocol would kill off the competition. Of course, our declaration of convergence might not kill off other network layer efforts. But then, why make the declaration? So I will not include this as in a document which I am the editor and co-author of. Of course, the IPng directorate are perfectly free to write their own criteria document, including this as a criterion. The directorate might even wish to incorporate our document (with suitable attribution, of course). -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From kasten@mailserv-D.ftp.com Mon Apr 4 15:46:58 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA15846 for ; Mon, 4 Apr 1994 15:48:09 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 4 Apr 1994 15:47:56 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA17606; Mon, 4 Apr 94 15:46:58 EDT Date: Mon, 4 Apr 94 15:46:58 EDT Message-Id: <9404041946.AA17606@mailserv-D.ftp.com> To: sob@hsdndev.harvard.edu Subject: Re: Comments on White Papers so far... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: J.Crowcroft@cs.ucl.ac.uk, bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Content-Length: 659 Status: O > a question about APIs (not withstanding Marshall's fondness for them) > how many would an IPng need? there is sockets, winsoc (or is that the same), > streams ... and for which operating systems? and which languages? I want, at least, the following: autocode fortran-iv cobol forth lisp (including emacs-lisp) algol snobol dibol basic midas mumps smalltalk modula-2 pdp-8 focal prolog scheme and the following os's: its ctss multics tops-20 rsts rt-11 rsx-11 os-9 vrtx and psos cdc cyber nos tenex tops-10 vm/370 vm/sp mvs -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ericf@atc.boeing.com Mon Apr 4 16:16:29 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA12389 for ; Mon, 4 Apr 1994 19:14:53 -0400 Received: by atc.boeing.com (5.57) id AA10589; Mon, 4 Apr 94 16:16:29 -0700 Date: Mon, 4 Apr 94 16:16:29 -0700 From: Eric Fleischman Message-Id: <9404042316.AA10589@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: IPng and APIs Status: O Dear Group, I am very disappointed by the following posting. It represents to me a complete failure on my part to adequately represent a user's view to the IETF. The included posting (below) attempts to list many of the operating systems and languages which have been deployed and in effect say: the task of supporting APIs is impossible for IPng so forget the whole idea. However, this argumentum ad adsurdum (below) is a red herring. Now for some common sense: (1) A few APIs are currently widely deployed in support of TCP/IP communications: * sockets and its relatives (e.g., WinSock) * XTI and its relatives (e.g., Revised XTI, TLI, CLI, MPTN). Others also exist but these two families are very important and recognizable by most of us. (2) Users use these APIs to write user-written applications. Users have been doing this for quite a long time resulting in many such applications. (3) If IPng does not support the APIs formerly supported by TCP/IP then the users will have to re-write their abundant TCP/IP-based applications to use IPng. (4) If users must re-write their applications, the re-write had better be mighty trivial (preferentially merely recompiling) or else there may not be a business justification (e.g., adequate return on investment) to convert these multitudes of applications to IPng. (5) If user-written applications can not be readily migrated to support IPng then the IETF has provided a VERY POWERFUL DISINCENTIVE for users to use IPng. (6) If these APIs can not support IPng, then any IPng transition discussion is farcical. End of story. Therefore, we can continue to write cute (and adsurd) comments such as the following or we can face the facts that this is an issue of upmost importance to the eventual success (or lack thereof) of IPng. Similarly, the IETF simply must learn that our failure to address API issues causes many diverse and vexacious problems for the end users of TCP/IP products. Sincerely yours, --Eric Fleischman =============================================== > a question about APIs (not withstanding Marshall's fondness for them) > how many would an IPng need? there is sockets, winsoc (or is that the same), > streams ... and for which operating systems? and which languages? I want, at least, the following: autocode fortran-iv cobol forth lisp (including emacs-lisp) algol snobol dibol basic midas mumps smalltalk modula-2 pdp-8 focal prolog scheme and the following os's: its ctss multics tops-20 rsts rt-11 rsx-11 os-9 vrtx and psos cdc cyber nos tenex tops-10 vm/370 vm/sp mvs From ericf@atc.boeing.com Mon Apr 4 16:45:54 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA20969 for ; Mon, 4 Apr 1994 19:45:18 -0400 Received: by atc.boeing.com (5.57) id AA13167; Mon, 4 Apr 94 16:45:54 -0700 Date: Mon, 4 Apr 94 16:45:54 -0700 From: Eric Fleischman Message-Id: <9404042345.AA13167@atc.boeing.com> To: craig@aland.bbn.com, ericf@atc.boeing.com Subject: Re: Brian's Comment Cc: ipng@cmf.nrl.navy.mil Status: O Dear Craig (and IPng Directorate), The enclosed text was what Frank verbally agreed to at the Open IPng Directorate meeting. At the time of his agreement there was substantial concurrence that convergence is an important requirement for IPng -- particularly convergence between Novell NetWare and ISO with TCP/IP. The situation is identical to what Tony Li is currently arguing on Big-internet right now: users investment in computing is injured by the excess overhead expenses and inter-communication impairments associated with multiple protocol family deployments. Therefore, we desire to have an enhanced ability to "converge" existing protocols upon a minimal set of protocols (i.e., to have IPng become a suitable migration target for multiple protocol families in addition to TCP/IP). We hope that IPng will provide such a convergence functionality. Now I personally think that this is a technical requirement as technically valid as any other in the criteria document. I don't understand why everyone doesn't think this way since this is so "intuitively obvious" to me. However, Frank (and others) didn't see how this could be considered to be "technical". (Don't ask me why.) Thus, Brian posed the following text as a "technical statement" which Frank was then willing to accept. Of course, it is possible to satisfy this requirement (as stated) via tunneling. This bothers me because tunneling is NOT a convergence path for these other protocols. Rather, a convergence path must be able to backwardly address the other protocols as per Tony Li's suggestion and as explained in great detail in CATNIP. However, this (very weak) text is better than nothing. When Brian returns from vacation I would be honored to learn why he postulated such a weak text: was it due to "political correctness" or does he have a differing viewpoint about my convergence goals? Sincerely yours, --Eric Fleischman > From craig@aland.bbn.com Fri Apr 1 14:18:07 1994 > > The proposed text of the new requirement now follows: > "It must be possible from day one to interconnect CLNP islands > (which have NSAP addresses) via the IP and IPng Internet (i.e., during > transition). This is a first step towards convergence of the > CLNP and IPng infrastructures." > >Hi Eric: > > For the moment I'll put aside the question of whether this is a technical >or political requirement (since I'm of mixed minds), and focus on this note as >a technical proposal. > > As a technical proposal, we need to sharpen it up. > > First, I'll note that twenty years of work on protocol conversion have >resulted, almost without exception in failure. Is tunnelling an acceptable >solution? Since the statement is "interconnect CLNP islands", I assume >direct connectivity between CLNP hosts and IPng hosts is not required? > > If direct connectivity is required, then we need some more details >thrashed out. Everyone understands that when we say IP-IPng interoperability, >we mean that TCP/UDP/ICMP etc on IP has to have a mapping onto IPng. For CLNP >are we to say the same thing, e.g., TCP/UDP etc on CLNP (e.g. TUBA) must >be mapped into IPng? Or is it saying TP4-0 on CLNP (not to mention other >higher layers) must be mapped onto IPng? > > Also, is it permissible to define a CLNP addressing structure to make >this work? For instance, suppose, for instance, that the CATNIP folks said >"if you use this IETF-defined addressing structure in CLNP" then everything >maps cleanly between CATNIP and CLNP, but all those other CLNP addressing >formats (of which there can be many, though I gather only a few are in use) >don't work. Is this OK? > >Thanks! > Craig From jcurran@nic.near.net Mon Apr 4 20:44:15 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA09080 for ; Mon, 4 Apr 1994 20:45:10 -0400 Received: from platinum.near.net by nic.near.net id ab03837; 4 Apr 94 20:45 EDT To: ipng@cmf.nrl.navy.mil Subject: Misc on IPng Date: Mon, 04 Apr 1994 20:44:15 -0400 From: John Curran Message-ID: <9404042045.ab03837@nic.near.net> Status: O CLNP Convergence I definitely heard this being asked for in the discussion, but do not remember it making to the "additional criteria list" which Frank was maintaining. Ability to support tunnels (a very simple requirement) _was_ on the list, I believe. I probably would have objected to a requirement that IPng directly support CLNP addressing for the purposes of convergence. I think it's a "nice idea", but I certainly wouldn't discard IPng proposals simply because they lacked such capabilities. TURNIPP Interesting... 56 bit addresses (AFI B) are plenty, _as long as_ we have variable length escape hatch via other AFI's. Picking up existing NSAP address convergance is also very useful. Do we get to find out what the acronym stands for? Costs and IPng Jon C. says "i believe a selling point of an IPng may well be cost savings, either on Link share savings, ot on multidservice supoort (e.g. routing all our phone calls over a virtual private phone system - ..." Jon, if deployment is going to be motivated by this, then we will need to have resource sharing and allocation ready in the initial public release, no? /John From bound@zk3.dec.com Tue Apr 5 00:06:15 1994 Return-Path: bound@zk3.dec.com Received: from crl.dec.com (crl.dec.com [192.58.206.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA07266 for ; Tue, 5 Apr 1994 00:13:13 -0400 From: bound@zk3.dec.com Received: by crl.dec.com; id AA01190; Tue, 5 Apr 94 00:10:11 -0400 Received: by xirtlu.zk3.dec.com; id AA21240; Tue, 5 Apr 1994 00:06:21 -0400 Message-Id: <9404050406.AA21240@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: IPng and APIs In-Reply-To: Your message of "Mon, 04 Apr 94 16:16:29 PDT." <9404042316.AA10589@atc.boeing.com> Date: Tue, 05 Apr 94 00:06:15 -0400 X-Mts: smtp Status: O Eric, I share your concern. I would like to use your very exact message to further add support to this cause. Hence, I am not talking to you directly but using your message as a spring board ..thanks... Group, >I am very disappointed by the following posting. It represents to me >a complete failure on my part to adequately represent a user's view to the >IETF. The included posting (below) attempts to list many of the operating >systems and languages which have been deployed and in effect say: the task of >supporting APIs is impossible for IPng so forget the whole idea. We support TCP/IP on at least 6 operating systems. All of them use some incantation of sockets. XTI is also a candidate but that is dejure standards driven via X/Open and IEEE POSIX committees. The odds that if BSD sockets work then so will all versions of sockets work too. I don't think we can define an exact API but we can ask each proposal to discuss it in depth to make sure the results of their protocol does not break the existing applications using IPv4 that will not port to IPng for sometime. I do not think this is an unreasonable request. Scott: To answer your orginal question if the APIs are done right the algorithm and technical strategy will benefit any leaf on the BSD Sockets tree like WINsockets or even XTI. >However, this argumentum ad adsurdum (below) is a red herring. I am getting to know Frank I don't think it was a red herring like the one they pulled on the U.S. in Vietnam or the Korean War during peace talks. But more a real concern how the heck do you specify this for all those operating systems. What I am saying is they all are now supporting sockets directly or indirectly. By finding the technical fulcrum at the transport layer where the APIs must integrate and solving that problem we may be able to solve the problem for all socket 1st and 2cnd derivatives. >Now for some common sense: >(1) A few APIs are currently widely deployed in support of TCP/IP > communications: > * sockets and its relatives (e.g., WinSock) > * XTI and its relatives (e.g., Revised XTI, TLI, CLI, MPTN). > Others also exist but these two families are very important and > recognizable by most of us. Absolutely. >(2) Users use these APIs to write user-written applications. Users have > been doing this for quite a long time resulting in many such applications. In fact the IETF is completely missing their input. In most cases this is OK. But when you change the interface to the network (which we are doing) that is another matter. I think by putting in the requirements that an API spec must be included with details is an honorable thing to do in this process. It will also assure the ISV community we care. The ISVs will have a lot to do with part of the carrot for folks to move to IPng. No one is going to move their engineering or commercial workstations to IPng if the applications are not also ported. >(3) If IPng does not support the APIs formerly supported by TCP/IP then the > users will have to re-write their abundant TCP/IP-based applications to > use IPng. No they will just not use IPng if its too painful. Which will affect IPng as a carrot for the market place. >(4) If users must re-write their applications, the re-write had better be > mighty trivial (preferentially merely recompiling) or else there may not > be a business justification (e.g., adequate return on investment) to > convert these multitudes of applications to IPng. Well they will have to make some minor modifications to their DNS access and connection set up strategy but it should be minimal. >(5) If user-written applications can not be readily migrated to support IPng > then the IETF has provided a VERY POWERFUL DISINCENTIVE for users to use IPng. Absolutely. >(6) If these APIs can not support IPng, then any IPng transition discussion > is farcical. I agree in fact any proposal that does not supply a technical specification per the changes to the sockets interface just to get prototypes built is suspect in my mind. >End of story. That was a real story too. >Therefore, we can continue to write cute (and adsurd) comments such as the >following or we can face the facts that this is an issue of upmost >importance to the eventual success (or lack thereof) of IPng. Similarly, >the IETF simply must learn that our failure to address API issues causes >many diverse and vexacious problems for the end users of TCP/IP products. I agree. Note Eric stated 'address API issues' not standarize them. Thats all we are asking with this requirement. /jim From kasten@mailserv-D.ftp.com Tue Apr 5 09:16:45 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA06471 for ; Tue, 5 Apr 1994 09:18:54 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 5 Apr 1994 09:17:37 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA24198; Tue, 5 Apr 94 09:16:45 EDT Date: Tue, 5 Apr 94 09:16:45 EDT Message-Id: <9404051316.AA24198@mailserv-D.ftp.com> To: ericf@atc.boeing.com Subject: Re: Brian's Comment From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: craig@aland.bbn.com, ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil Content-Length: 886 Status: O > Dear Craig (and IPng Directorate), > > The enclosed text was what Frank verbally agreed to at the Open IPng Directorate > meeting. a) Frank said at the directorate meeting that he was tired and had a cold and that he wasn't really up to discussing a particular requirement. He requested that Brian post the requirement and to continue discussion via email. b) Frank seems to recall that Brian's requirement had two parts -- being able to connect islands of non-ipng using ipng as a substrate - which to Frank seems to be a bit more detail on the requirement for tunneling - and Frank seems to recall agreeing to this. The second part was a fuzzy statement about how we should be aiming for convergence - and Frank stands by his earlier posts on the subject. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From kasten@mailserv-D.ftp.com Tue Apr 5 09:16:47 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA06033 for ; Tue, 5 Apr 1994 09:17:40 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 5 Apr 1994 09:17:38 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA24201; Tue, 5 Apr 94 09:16:47 EDT Date: Tue, 5 Apr 94 09:16:47 EDT Message-Id: <9404051316.AA24201@mailserv-D.ftp.com> To: ericf@atc.boeing.com Subject: Re: Comments on White Papers so far... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 4243 Status: O Let's take sockets as an example. I took a quick look at a sys/socket.h that I have around here and I find that a struct sockaddr is defined as: struct sockaddr { u_short sa_family char sa_data[14]; }; Now, let's go look at netinet/in.h. I find a struct sockaddr_in (which is supposed to map to the struct sockaddr) and it is defined as struct sockaddr_in { short sin_family; u_short sin_port; struct in_addr sin_addr; char sin_zero[8]; }; AND I go look at the struct in_addr. It's defined as: struct in_addr { u_long s_addr; }; For the programming-clue-impaired, a u_long is a berkeley-ism for "unsigned long", a 4 byte number (and u_short is an unsigned short ... a 2 byte number). Now, if we were to demand that the proposals use sockets as their API, and as I read Eric's posting, and then look at the definitions of the socket data structures, I note a couple of interesting things: 1) We would be limited to a 2-byte port number. This is not a restriction that I wish to make, 2) Most programmers store IP addresses in an unsigned-long (or struct in_addr). It's bad programming practice, but that's life. If an IPng address could not be stored in a 4 byte number then an application would need to be more than simply recompiled -- data structures would need to change, stack-space requirements (for those of us who have machines with stacks) would increase (and who knows, maybe overflow the stack), and lots of hard-coded "4"s would need to be changed. 3) For those good programmers who use the struct sockaddr_in, well, they would have 12 bytes of address to use. At most, we'd have 14 bytes. Now, you might claim that some other standards group has come up with a jumbo-sockets-standard (JSS) that gets rid of these silly, trivial, piddling limitations, but I got this stuff from the two machines on which I exclusively program these days - none of them seem to have heard of the hypothecated JSS. It would appear that JSS is a non-starter. Why not let the people who are (supposed to be) API experts worry about these things? It seems to me that the Posix people (posixians?) are good at writing unix-ish apis... Ansi, the (presumed) keeper of the Fortran Light, could do the Fortran stuff. And so on. I do not believe that standardizing APIs is within the IETF's charter. My view of the IETF's role is in developing protocols that enhance communications between computers across IP (and IPng) based internetworks. APIs are a purely local issue. An API on one machine may be unix-sockets and on another machine may be the KNET K-Routines. The machines can still talk. Having the IETF do standards work in areas that are not clearly within the IETF's jurisdiction is very problematic. For example, the IETF has, in recent history, embarked on developing Management Information Bases (MIB) for IEEE 802.1 bridges and for IEEE 802.3 LANs. Both efforts caused great intestinal distress among the IEEE on the theory that we, the IETF, were somehow attempting to encroach on their, the IEEE's, turf. In fact, through a long series of rather sordid events, the 802.3 effort was, in part, responsible for the downfall of the old-world-order, and perhaps one IAB member in particular. So, to reiterate, I 1) do not see the API issue as something that the IETF can legitimately do standards on, 2) do not see APIs as a technical requirement of the protocol in that the API does not enhance the computer to computer communications, 3) do not see that APIs are a problem with the current Internet or internet protocol suite in the sense that they prevent a user of IP from doing something, and 4) do see some possible restrictions in one of the APIs that you mentioned and would find these restrictions unacceptable. So therefore do not consider that APIs should be mentioned in a technical criteria document. Finally, the directorate probably have their own idea of what the proposals need to submit as a part of the process and can certainly request that one document be an API. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From craig@aland.bbn.com Tue Apr 5 10:19:44 1994 Return-Path: craig@aland.bbn.com Received: from uu7.psi.com (uu7.psi.com [38.145.204.6]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA27372 for ; Tue, 5 Apr 1994 13:23:40 -0400 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA25657 for ipng@cmf.nrl.navy.mil; Tue, 5 Apr 94 13:22:40 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA10777; Tue, 5 Apr 1994 10:19:45 -0700 Message-Id: <199404051719.KAA10777@aland.bbn.com> To: Eric Fleischman Cc: craig@aland.bbn.com, ipng@cmf.nrl.navy.mil Subject: Re: Brian's Comment In-Reply-To: Your message of Mon, 04 Apr 94 16:45:54 -0700. <9404042345.AA13167@atc.boeing.com> From: Craig Partridge Date: Tue, 05 Apr 94 10:19:44 -0700 Sender: craig@aland.bbn.com Status: O Eric: Let me try to explain my concerns about convergence as a "technical goal." First, off, let me say that if we're being hardnosed, all requirements are political. I mean, who says we really need all these addresses -- why not just tell everyone to connect only via e-mail over UUCP dial-up links, and let everyone have an entire IP address space to use within their own organization? We don't say that because we believe that there are benefits to interactive services like TELNET, FTP, etc., even though America On-Line is clearly doing OK without them. But once we take the not very difficult plunge and say, yes we want everyone hooked up to everyone else to support interactive services, lots of requirements fall out. More generally, at the start of the requirements document we raise some key philosophical points, which helped motivate our requirements. Now, if we look at convergence, it is very hard to find a technical need for it. The argument is more sociological -- it *might* make IPng more popular if it converged with CLNP. But if we're looking for popularity, shouldn't we be looking at NetWare and SNA (both with bigger market shares) before we try CLNP? Also, there are tremendous perils in trying to do cooperative standards, and lots of folks don't believe in them. (I've got psychic burn scars from at least one such attempt in the past). So convergence with CLNP seems likely to put large obstacles in the process, with uncertain benefit. (I guess this points up a bit of my religion -- I'm most interested in IPng requirements which are clearly achievable at modest risk). However, I'd still like to work to tighten up the requirement, especially as applied to tunnelling issues. Craig From rcallon@pobox.wellfleet.com Tue Apr 5 14:05:21 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA13989 for ; Tue, 5 Apr 1994 14:12:32 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA00836; Tue, 5 Apr 94 13:54:13 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA06556; Tue, 5 Apr 94 14:05:21 EDT Date: Tue, 5 Apr 94 14:05:21 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9404051805.AA06556@pobox.wellfleet> To: craig@aland.bbn.com, ericf@atc.boeing.com Subject: Re: Brian's Comment Cc: ipng@cmf.nrl.navy.mil Status: O Now, if we look at convergence, it is very hard to find a technical need for it. The argument is more sociological -- it *might* make IPng more popular if it converged with CLNP. I think that the need for convergence with other protocols which are actively being used is a real technical requirement. There is a desire to ease configuration and management of real networks, and the large number of different protocol suites makes managment a lot harder. It also makes equipment more expensive, and reduces interoperation. This is a major concern of a lot of folks who are using networks (the vast majority of our customers have multiple protocol suites), and it is a pity that the IETF (and also other standards bodies) is so reluctant to take multi-protocol interoperation seriously. Now, I might add here that at least the IETF does debate whether multi protocol interaction is important. Some very good multi-protocol stuff is done (for example, PPP from day one allowed multiple network layer protocols to run over it). Thus, if you believe that CLNP is actually being used in a significant number of places, then convergence with CLNP is a real technical requirement. On the other hand, if you believe that CLNP is not being used at all, then convergence with CLNP is a political requirement. The truth may be in the middle somewhere. It might be worth noting that Catnip is also talking about convergence with IPX, which clearly *is* being used a lot. But if we're looking for popularity, shouldn't we be looking at NetWare and SNA (both with bigger market shares) before we try CLNP? Also, there are tremendous perils in trying to do cooperative standards, and lots of folks don't believe in them. (I've got psychic burn scars from at least one such attempt in the past). So convergence with CLNP seems likely to put large obstacles in the process, with uncertain benefit. (I guess this points up a bit of my religion -- I'm most interested in IPng requirements which are clearly achievable at modest risk). This is a valid concern: We have to ask whether convergence is actually achievable. There seems to be a chicken and egg problem here: convergence is probably achievable if folks believe that it is important, but if most folks think that it is not achievable, then they won't work to try to achieve it. Ross From ericf@atc.boeing.com Tue Apr 5 14:55:55 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA02820 for ; Wed, 6 Apr 1994 09:34:42 -0400 Received: by atc.boeing.com (5.57) id AA12577; Tue, 5 Apr 94 14:55:55 -0700 Date: Tue, 5 Apr 94 14:55:55 -0700 From: Eric Fleischman Message-Id: <9404052155.AA12577@atc.boeing.com> To: craig@aland.bbn.com, ericf@atc.boeing.com Subject: Re: Brian's Comment Cc: ericf, ipng@cmf.nrl.navy.mil Status: O Dear Craig (and Directorate), Thank you for your excellent comment and your commendable willingness to dialog concerning the inclusion of "convergence" as a technical requirement or not. The purpose of this reply is to continue this dialog in the hopes that through it others may participate and we would eventually move towards a common viewpoint on this matter within the IPng Directorate. >From craig@aland.bbn.com Tue Apr 5 10:26:40 1994 > Also, there are tremendous perils in trying to do >cooperative standards, and lots of folks don't believe in them. (I've got >psychic burn scars from at least one such attempt in the past). So convergence >with CLNP seems likely to put large obstacles in the process, with uncertain >benefit. (I guess this points up a bit of my religion -- I'm most interested >in IPng requirements which are clearly achievable at modest risk). I agree with you: we (the IPng Directorate) are NOT interested in doing cooperative standards work with any non-IETF entity for the reasons that Scott and Allison have consistently stated. However, I disagree with you in that I think that it is very desirable to select an IPng which provides a framework whereby other communities (i.e., other protocol families outside of our purview) can VOLUNTARILY (i.e., THEIR own volition without compulsion from us) use as their own next generation protocols. That is, I really believe that the IPng which *I* want us to design is indeed "one protocol to bind them all": it possesses superior capabilities with functionalities not found in existing protocols and it is designed so a clean migration from existing protocols to IPng can be made. My own arguments to date have not yet been technical on this issue. I will now begin a technical discussion of this matter: 1) Convergence at the network layer will NOT solve the End User's real problem which is getting our diverse deployments to interoperate together. However, there are two components to interoperability: (A) being able to establish communication links between end systems and (B) having the end systems being actually able to communicate together once those links are established. Point A is addressed by network layer convergence. That is, a common network layer implies a common data link and physical layer. A common lower layer stack implies the possibility of a common physical infrastructure (e.g., routers, bridges, concentrators, etc.). A common infrastructure implies the possibility of packets actually being able to go between two end systems, even if the end systems are not then able to process the packets due to lack of upper layer compatibilities. Thus, convergence only addresses HALF of the total problem. But it is an important half. 2) Should network layer convergence occur, then it would become theoretically possible for the same infrastructure to carry traffic which previously required separate infrastructures. This may translate into substantial infrastructural support savings. This is true even in those cases in which two protocol families can theoretically be supported by the same infrastructure today. For example, we have deployed a separate physical infrastructure to support our OSI devices simply because our backbone routers already support five protocols (IP, IPX, AppleTalk Phase II, DECnet Phase IV, and XNS) and we are concerned by the degredation and support overhead of adding in a sixth protocol to this essential corporate infrastructural component. 3)What we really would like is to be able to systematically "turn off" these many protocols because they each, in turn, have support and performance impacts. Thus, even though our infrastructure already supports these protocols, we believe that savings may be associated with migrating these applications to a single network layer infrastructure. Of course, any actual change will need a business case (cost/benefit analysis). 4) Therefore, for the last many years we have closely been working with our vendors urging them to converge their data communications protocols at least at the network layer. Several of them have responded by redesigning their proprietary stacks to make them modular: The upper layers can be supported over many protocol families in addition to the original lower layers of their own design. I can not (due to disclosure reasons) identify all of these vendors, but I will assert that IBM's Multi-Protocol Transport Networking (MPTN; which I originally designed) is just such a scheme and that RFC 1006 is not incompatible with this idea. I assume that other users have been similarly lobbying their vendors for this certainly has become a common theme (as opposed to the historic alternative (application-layer gateways) which does not scale and is economically undesirable). In any case, we are currently migrating SNA and CATIA/GAM to TCP/IP transports. We are considering migrating other protocols to TCP/IP transports as well. 5) Therefore, there is a market desire to converge lower layers. However, convergence is a technical problem. Each vendor must do their own cost/benefit analysis. The costs go up for the vendors if convergence is technically difficult. Therefore, it is desirable that *IF* IPng is to be used for convergence that IPng be technically easy to converge upon. This is the nature of my requirement: I want IPng to be technically easy to converge upon to encourage vendors to perform such convergences. Thus, this is a TECHNICAL REQUIREMENT, not just a marketing requirement. 6) As we have said many times: IPng has to be sold to end users. Will convergence alone sell it? Perhaps in some cases. However, in the general case it will be an important factor but it simply must be coupled with improved functionality (benefits). Thus, it is a necessary but not sufficient characteristic. However, if IPng can not offer convergence then that is a SERIOUS blow against deploying IPng at all: it will therefore be a Yet Another Protocol (YAP; i.e., part of our problem rather than part of our solution). IPng is such a "hard sell" already that I really think that it can not afford to become a YAP. The only way I believe that it could survive such a blow is either (A) users are totally unaware of IPng differing from another deployed protocol (e.g., an immensely successful IPAE or CATNIP) or (B) absolutely incredable functionality improvements are bundled with must- have applications. (But what vendors will bundle these applications initially to IPng rather than taking the exponentially safer alternative of bundling them with IPv4 -- unless IPv4 can't be made to support those functionalities?) Please let me know if you did not follow my arguments at any point of the logic progression. This is an immensely important concept and I want to be sure that nobody fails to understand what I am arguing -- and its direct implication to IPng and to what vendors (and users) will probably do with IPng. To be nasty (but to try to drive my point home): during the Vietnam war people used to say "Suppose they called a war and nobody came to fight." I'd like to turn that slogan around to say "suppose they selected a protocol and nobody chose to use it." Sincerely yours, --Eric Fleischman From ericf@atc.boeing.com Tue Apr 5 15:29:27 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA02809 for ; Wed, 6 Apr 1994 09:33:09 -0400 Received: by atc.boeing.com (5.57) id AA19150; Tue, 5 Apr 94 15:29:27 -0700 Date: Tue, 5 Apr 94 15:29:27 -0700 From: Eric Fleischman Message-Id: <9404052229.AA19150@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: API and IPng Transition Status: O Dear Frank, I understand your rebuttal to my "IPng must address APIs" comment to state: "It's too tough to handle APIs, we've never done it before, so it is therefore out of our scope." APIs are tough to do correctly. The IETF has minimal experience with APIs -- to the considerable detriment of its work as a whole. However, since the IETF is doing IPng and since the IETF is doing IPng Transition and since APIs (particularly sockets) are an essential part of IPng Transition then the IETF had jolly well handle APIs within its transition schemas. To not do so is to not do Transition. To not do Transition is to provide a solution with no common way to get there. To not provide a Transition direction is to castrate IPng. Thus, the bottom line is: are we playing around with protocols or are we trying to design something which may be actually deployable? That is, your arguments that "the IETF has never done APIs before" fails to recognize that the IETF has never tried to design a replacement of a popularly deployed protocol before. Lucky for the IETF many of us are intimately acquainted with what is involved in such an effort from extensive experience doing so in other domains. Thus, while the IETF may be new at this, many in our community are old hands at this. My own previous experience tells me that this is serious stuff indeed: We had better aim to get it right or we had better cut our loses and quit wasting our time. APIs are a transition requirement which you just can't avoid no matter how much you may wish that it wasn't so. Sincerely yours, --Eric Fleischman From pvm@ISI.EDU Tue Apr 5 17:04:49 1994 Return-Path: pvm@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA00847 for ; Wed, 6 Apr 1994 07:47:36 -0400 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 5 Apr 1994 17:06:29 -0700 Message-Id: <199404060006.AA07584@zephyr.isi.edu> To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: craig@aland.bbn.com, ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil Reply-To: pvm@ISI.EDU Subject: Re: Brian's Comment In-Reply-To: Your message of Tue, 05 Apr 1994 14:05:21 -0400. <9404051805.AA06556@pobox.wellfleet> Date: Tue, 05 Apr 94 17:04:49 PDT From: Paul Mockapetris Status: O "convergence" is an 800 pound gorilla, so can sit where it wants. However, calling it technical seems a bit like making the gorilla wear a tutu. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From J.Crowcroft@cs.ucl.ac.uk Wed Apr 6 15:26:47 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA03395 for ; Wed, 6 Apr 1994 10:27:22 -0400 Message-Id: <199404061427.KAA03395@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Apr 1994 15:26:49 +0100 To: Eric Fleischman cc: ipng@cmf.nrl.navy.mil Subject: Re: API and IPng Transition In-reply-to: Your message of "Tue, 05 Apr 94 15:29:27 PDT." <9404052229.AA19150@atc.boeing.com> Date: Wed, 06 Apr 94 15:26:47 +0100 From: Jon Crowcroft Status: O >APIs are tough to do correctly. 'm not sure i agree with this statement - what i think is that APIs are hard to get vendors to agree to.... >The IETF has minimal experience with APIs -- to the considerable detriment >of its work as a whole. the folkks who go to ietf from berkeley and ftp software and bellcore have had a HUGE say in sockets, winsock, streams the 3 main IPv4 APIs... >Thus, the bottom line is: are we playing around with protocols or are >we trying to design something which may be actually deployable? the work in most of the IPng proposals to do prototypes has (in my reading at least of CATNIP, SIPP, TUBA) addressed the practicalities of the API the Tuba people especially have listed exhaustively, the applications affected because of lack of transparency of TCP, through to IP - there is only 1 - FTP. all the others can run on the tcp and udp APIs that exist, unchanged - this is key. only the router folks have to concern themselves weith all the protocols tat run direct on IP[ng] (apart from ICMP).... if you want IPng to define a clean TCPng API, that is a different (and also very useful) matter... cheers jon From J.Crowcroft@cs.ucl.ac.uk Wed Apr 6 15:34:54 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA03471 for ; Wed, 6 Apr 1994 10:36:43 -0400 Message-Id: <199404061436.KAA03471@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Apr 1994 15:34:55 +0100 To: Eric Fleischman cc: craig@aland.bbn.com, ericf@picard.cmf.nrl.navy.mil, ipng@cmf.nrl.navy.mil Subject: Re: Brian's Comment, convergence In-reply-to: Your message of "Tue, 05 Apr 94 14:55:55 PDT." <9404052155.AA12577@atc.boeing.com> Date: Wed, 06 Apr 94 15:34:54 +0100 From: Jon Crowcroft Status: O I ran a DARPA sponsored project for 3 years looking at protocol migration and interworking (mainly how to get to ISO from IPv4), and I can address this convergence debate, layer by layer: given a datagram network layer (thank goodness that debate is past!), we can interwork in 3 ways, and use each others (inter)networks in two: 1. we can translate IP[ng] to CLNP 2. we can transport bridge (ISO TS/rfc1006 to TCP) 3. we can application layer relay a. tunneling b. dual stack. now given these, how can we converge? well, we can move to running a single network layer - this elimates 1, a and b, iff we move clnp -> ip (i.e. ISO adopt ip[ng]) however if you move from ip -> clnp, you get the same effect. so this doesnt tell us which is best, except possibly by measuring the ration of end systems to routers capable of both, which gives an obvious convergence now of clnp-> ip, but of ipng->clnp later - i.e. not very helpful:-( neither elimates 2 & 3, as these are features of 2) a different transport syntax (not semantics) or 3) a different application semantics or syntax jon From deering@parc.xerox.com Wed Apr 6 08:53:11 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA04390 for ; Wed, 6 Apr 1994 11:54:25 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14544(8)>; Wed, 6 Apr 1994 08:53:14 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 6 Apr 1994 08:53:19 -0700 To: Eric Fleischman Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: API and IPng Transition In-reply-to: ericf's message of Tue, 05 Apr 94 15:29:27 -0800. <9404052229.AA19150@atc.boeing.com> Date: Wed, 6 Apr 1994 08:53:11 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Apr6.085319pdt.12171@skylark.parc.xerox.com> Status: O > I understand your rebuttal to my "IPng must address APIs" comment to state: > "It's too tough to handle APIs, we've never done it before, so it is > therefore out of our scope." While I agree that APIs are out-of-scope, defining service interfaces is not. Service interfaces specify the interactions and information exchange that are required to use a protocol implementation or service, in an abstract, OS- and language-independent, way. It is something we have done before. For example, the base IPv4 spec (RFC-791) includes a service interface, and that interface was subsequently updated by the Host Requirements doc (RFC-1122). I believe it is reasonable to require that any IPng proposal include a description of how the IPng service interface differs from the IPv4 service interface. (I had a such a section in the previous SIP[P] spec, but for some reason that I can't immediately recall, I deleted some of it from the latest version -- I suppose I should put it back.) Would that satisfy Eric's concerns? (By the way, the SIPP group has also produced an Internet Draft proposing a BSD sockets API for SIP[P], to stimulate discussion of API issues among implementors of SIPP on sockets-based platforms and, ideally, to result in portability of SIPP applications across such platforms. However, it is not at all clear to me that such a document would belong on the Standards track, should SIPP be adopted as IPng; I think it would be best published only as an Informational RFC.) Steve From bound@zk3.dec.com Wed Apr 6 12:06:39 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA04535 for ; Wed, 6 Apr 1994 12:13:55 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA19631; Wed, 6 Apr 94 09:06:53 -0700 Received: by xirtlu.zk3.dec.com; id AA12732; Wed, 6 Apr 1994 12:06:44 -0400 Message-Id: <9404061606.AA12732@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Comments on White Papers so far... In-Reply-To: Your message of "Tue, 05 Apr 94 09:16:47 EDT." <9404051316.AA24201@mailserv-D.ftp.com> Date: Wed, 06 Apr 94 12:06:39 -0400 X-Mts: smtp Status: O Frank, Well seeing how I am building this right now I thought I would reply technically. This is why my mail responses will be late here and on the bigi I have to do some implementation work too. >Let's take sockets as an example. I took a quick look at a sys/socket.h >that I have around here and I find that a struct sockaddr is defined as: > struct sockaddr { > u_short sa_family > char sa_data[14]; > }; This is the generic 4.3 structure the 4.4 new structure adds a length field to the structure which will help with IPng. It can be used exclusively within the if_net protocol and address family domains at the lower levels of an implementation. Also the sa_family is a value that is important to the point of binding the socket to a specific address family as opposed to the binding of the communications domain (also called the protocol domain). >Now, let's go look at netinet/in.h. I find a struct sockaddr_in (which >is supposed to map to the struct sockaddr) and it is defined as > struct sockaddr_in { > short sin_family; > u_short sin_port; > struct in_addr sin_addr; > char sin_zero[8]; > }; >AND I go look at the struct in_addr. It's defined as: > struct in_addr { > u_long s_addr; > }; >For the programming-clue-impaired, a u_long is a berkeley-ism for "unsigned >long", a 4 byte number (and u_short is an unsigned short ... a 2 byte number). > The point of in.h is to provide the user application with different options to handle different formats of in_addr address families. For example on OSF/1 you can use the 4.3 or 4.4 structure to develop an applications. That difference is handled at the transport in what is called often in BSD the uipc_socket.c module. This module will demux the address family and bind the address family type to the INET (Internet) communications domain. Also on Alpha a long is now 64bits. >Now, if we were to demand that the proposals use sockets as their API, >and as I read Eric's posting, and then look at the definitions of the socket >data structures, I note a couple of interesting things: No one is demanding that sockets be used by anybody. What we are saying is that we need to make sure different proposals, can support a smooth transition to IPng for the applications. This was defined in detail in my Host White Paper and I think we are missing tHe point if we think we are defining an API. For example a complete variable address will break all applications badly for IPv4 that has not ported to IPng. Let me restate once more my point this way: 1. IPv4 apps run today over an API. 2. Host vendors update their systems to support IPng. 3. IPv4 apps are not ported day to even know about IPng. 4. IPv4 apps binarys should continue to run over this new host until they are ported to be IPng capable. 5. Once IPv4 apps are ported to IPng then source code changes will be required to those IPv4 apps. So here are the requirements: 1. When an IPng proposal is implemented on a host system the existing applications until they are ported to be IPng capable should be able to execute without recompilation or source code changes to the existing APIs, until that application is consciously ported to become IPng capable. 2. Each IPng proposal should discuss the affect to transport APIs to support IPv4 binary compatibility and the paradigm that will cause this effect on host implementations. 3. It is suggested that the BSD sockets API be used to define the paradigm used as this is a defacto widely used method to provide an API within the TCP/IP community and is being standardized by the IEEE POSIX 1003.12 committee. 4. Each IPng proposal should also discuss the implications to transition for applications as the BIND DNS names space is populated with new IPng resource records, services, and the like. >1) We would be limited to a 2-byte port number. This is not a restriction > that I wish to make, This is a UDP and TCP limitiation not a sockets limitation. >2) Most programmers store IP addresses in an unsigned-long (or struct > in_addr). It's bad programming practice, but that's life. If an IPng > address could not be stored in a 4 byte number then an application would > need to be more than simply recompiled -- data structures would need > to change, stack-space requirements (for those of us who have machines > with stacks) would increase (and who knows, maybe overflow the stack), > and lots of hard-coded "4"s would need to be changed. See above I answered this question its how you bind the address family at the transport. We do this today to support multi-protocols. Regarding the queues and control blocks that is an issue but each implementation will have to handle that and this has a lot to do with transition. For example on a server app that is now IPng capable it will want to accept both IPng and IPv4 addresses sessions from clients. One our engineers working on IPng has suggested that we maintain different lists for each type of connection which so far seems to provide better performance than searching single lists or caches architecturally. >3) For those good programmers who use the struct sockaddr_in, well, they > would have 12 bytes of address to use. At most, we'd have 14 bytes. To do IPng the best think to do is use 4.4 sockets which defines variable addresses by the length. the sa_data[] array was mean't to support more than 14 octets and can with the 4.4 length field. But you need to put some limit on this for reality. For example using GOSIP V2 NSAP you know how big the address is so there is a reality check. What we don't want is to be told to look at delimiters like in the old days but this is another discussion I am going to bring up on bigi list. >Now, you might claim that some other standards group has come up with >a jumbo-sockets-standard (JSS) that gets rid of these silly, trivial, >piddling limitations, but I got this stuff from the two machines on >which I exclusively program these days - none of them seem to have >heard of the hypothecated JSS. It would appear that JSS is a >non-starter. This is not a problem per 4.4 addresses. Again we are not saying build and state the actualy API but verify using the sockets 'model' as a computer science tool that each proposal can support the requirements I listed above. >Why not let the people who are (supposed to be) API experts worry >about these things? It seems to me that the Posix people (posixians?) >are good at writing unix-ish apis... Ansi, the (presumed) keeper of >the Fortran Light, could do the Fortran stuff. And so on. Fortran and the like are languages and they don't build APIs to the network layer. Its done by POSIX and X/Open as Berkeley has went away. This is why the IEEE is making sockets at present a dejure API like XTI. IPng will cause changes that standard and we need to make sure before we change to IPng what the end result is to those APIs to see if they are valid to support applications. Then we can ask those folks to enhance both sockets and XTI. >I do not believe that standardizing APIs is within the IETF's >charter. My view of the IETF's role is in developing protocols that >enhance communications between computers across IP (and IPng) based >internetworks. APIs are a purely local issue. An API on one machine >may be unix-sockets and on another machine may be the KNET >K-Routines. The machines can still talk. Having the IETF do standards >work in areas that are not clearly within the IETF's jurisdiction is >very problematic. For example, the IETF has, in recent history, >embarked on developing Management Information Bases (MIB) for IEEE >802.1 bridges and for IEEE 802.3 LANs. Both efforts caused great >intestinal distress among the IEEE on the theory that we, the IETF, >were somehow attempting to encroach on their, the IEEE's, turf. In >fact, through a long series of rather sordid events, the 802.3 effort >was, in part, responsible for the downfall of the old-world-order, >and perhaps one IAB member in particular. We are not talking about building an API standard AGAIN. >So, to reiterate, I >1) do not see the API issue as something that the IETF can legitimately > do standards on, No but we have a technical responsibility to verify all points of transition that could break and applications breaking for IPv4 that have not been ported to be IPng capable will effect the transition to IPng very negatively. I think this is critical for the Directorate to verify. But I do agree we should not standardize APIs but make sure IPng does not break the existing ones. >2) do not see APIs as a technical requirement of the protocol in that > the API does not enhance the computer to computer communications, Of course it does without the API you cannot communiate. Its like saying ones mouth is not relative to ones vocal chords and the viceral vibrations used in the abdomen for speech. >3) do not see that APIs are a problem with the current Internet or > internet protocol suite in the sense that they prevent a user of IP > from doing something, and If the user has to recompile all their IPv4 applications (and the entire market) before they want to use IPng for the application then I would say that is preventing them from implementing a smooth transition. Which is a requirement in my mind. >4) do see some possible restrictions in one of the APIs that you > mentioned and would find these restrictions unacceptable. Just as a note the sockets strategy I discussed in my white paper will work with XTI too. So what ever I do to sockets will work for XTI too. >So therefore do not consider that APIs should be mentioned in a technical >criteria document. LET ME SHOUT A BIT. WELL SOME DISAGREE AND HAVE PRESENTED VALID ARGUMENTS FOR SOME WORDING. IF WE WANT IT CHANGED THEN I ASSUME EVEN IF YOU DON'T LIKE IT YOU WILL CHANGE RIGHT? YOU ARE GOING TO BUILD THESE WITH SOME CONSENSUS RIGHT? >Finally, the directorate probably have their own idea of what the >proposals need to submit as a part of the process and can certainly >request that one document be an API. Yes this could be done but I think the requirements doc would be a better recognition of the issue. Again we are not trying to standarize the APIs but force discussion of IPng proposals affects on the transport interface. /jim From kasten@mailserv-D.ftp.com Wed Apr 6 12:38:43 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA04844 for ; Wed, 6 Apr 1994 12:40:12 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 6 Apr 1994 12:39:36 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA13500; Wed, 6 Apr 94 12:38:43 EDT Date: Wed, 6 Apr 94 12:38:43 EDT Message-Id: <9404061638.AA13500@mailserv-D.ftp.com> To: ericf@atc.boeing.com Subject: Re: Brian's Comment From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: craig@aland.bbn.com, ipng@cmf.nrl.navy.mil Content-Length: 2155 Status: O > My own arguments to date have not yet been technical on this issue. I will now > begin a technical discussion of this matter: > > 1) Convergence at the network layer will NOT solve the End User's real > problem which is getting our diverse deployments to interoperate together. > However, there are two components to interoperability: > (A) being able to establish communication links between end systems and > (B) having the end systems being actually able to communicate together > once those links are established. > Point A is addressed by network layer convergence. That is, a common > network layer implies a common data link and physical layer. > A common lower layer stack implies the possibility of a common > physical infrastructure (e.g., routers, bridges, concentrators, etc.). > A common infrastructure implies the possibility of packets actually > being able to go between two end systems, even if the end systems are > not then able to process the packets due to lack of upper layer > compatibilities. Last time I checked, most all datalink-levels were 'multi-protocol'. Right now, looking at lanwatch, here at ftp, I see Banyan and Novell and CLNP and LanManager and TCP/IP running quite happily on the same Ethernet. At other sites, I've watched Decnet-IV and Decnet-V and some oddball IBM protocols and several proprietary protocols and TCP/IP happily coexist. > Point A is addressed by network layer convergence. That is, a common > network layer implies a common data link and physical layer. > A common lower layer stack implies the possibility of a common > physical infrastructure (e.g., routers, bridges, concentrators, etc.). This, to me, says that because you have different network layer protocols, you need physically different media. This is confusing to me. I grant that you need differnet forwarders for your router -- but you will always need them since you will never get ALL (100.0%, not 99.9%) of your systems to use the new protocol. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From kasten@mailserv-D.ftp.com Wed Apr 6 12:38:44 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA04835 for ; Wed, 6 Apr 1994 12:39:41 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 6 Apr 1994 12:39:37 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA13503; Wed, 6 Apr 94 12:38:44 EDT Date: Wed, 6 Apr 94 12:38:44 EDT Message-Id: <9404061638.AA13503@mailserv-D.ftp.com> To: ericf@atc.boeing.com Subject: Re: API and IPng Transition From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 3783 Status: O >I understand your rebuttal to my "IPng must address APIs" comment to state: >"It's too tough to handle APIs, we've never done it before, so it is therefore >out of our scope." My rebuttals have been threefold -- 1. You offered a couple of APIs and expressed a very strong desire that we standardize on them. I pointed out that one such API, with which I am familiar, has some technical limitations which, in effect, prevent it from being adopted 'as is'. We would have to modify it some what. But then of course, it would not be sockets, but rather IETF-IPng-sockets. Code which ran on BSD-Sockets would have to be very very carefully examined to determine any dependencies on subtleties in the BSD-sockets model, with appropriate changes made to use IETF-IPng-sockets. Also, as IPng will have new functions that are not available in IPv4, we would presumably need to be able to access these capabilities via the API. This means new functions or data structures... So, we will not be true bsd-sockets compliant, but rather very similar to it. There will be another API out there. 2. APIs, to a large degree, are host-system and language dependent (ignoring Turing arguments). There are subtle issues in the host system that make a 'common' api very problematic. For example, in Windows, there is WinSock which, to the uninitiated, might seem to be sockets-on-windows-i'll-just-recompile-my-bsd-code- and-everything-will-work. Well, it just ain't so. There are subtle changes made to sockets to make it work in the windows environment: the close() function on BSD will close a socket, it won't on winsock - you have to do a closesocket() [and, by the way, removing BSD's socket==filedescriptor equivalence you make it effectively impossible to port programs like inetd {and all the programs that it calls} from the BSD world]. 3. As my first post indicated, WHICH SYSTEMS do you wish to create an API for? If we do sockets and streams, we'd be disenfranchising a lot of other systems and languages. For example, how would we fit this to COBOL or Fortran running on MVS? If we do the two APIs you proposed, it may be interpreted as saying that only really care about C and Unix. How do you deal with the people who can only provide a partial implementation of the interface on their hosts? Are they guilty of not having an implementation of IPng because they can not implement the API? Who do you disenfranchise by not developing an officially blessed, standard API for them? > That is, your arguments that "the IETF has never done APIs before" fails to > recognize that the IETF has never tried to design a replacement of a > popularly deployed protocol before. Lucky for the IETF many of us > are intimately acquainted with what is involved in such an effort from > extensive experience doing so in other domains. Thus, while the IETF > may be new at this, many in our community are old hands at this. > My own previous experience tells me that this is serious stuff indeed: We > had better aim to get it right or we had better cut our loses and > quit wasting our time. APIs are a transition requirement which you just > can't avoid no matter how much you may wish that it wasn't so. I see this as a tail-wagging-the-dog issue. APIs should be built to suit their host systems and underlying services, and not the other way around. If we specify that IPng's API must be sockets and streams then I am deeply concerned that a bad engineering tradeoff will be made -- function X which we want will not be implemented since it won't fit under the API. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From bound@zk3.dec.com Wed Apr 6 13:00:44 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA05146 for ; Wed, 6 Apr 1994 13:09:57 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA22966; Wed, 6 Apr 94 10:00:52 -0700 Received: by xirtlu.zk3.dec.com; id AA14119; Wed, 6 Apr 1994 13:00:50 -0400 Message-Id: <9404061700.AA14119@xirtlu.zk3.dec.com> To: Jon Crowcroft Cc: Eric Fleischman , ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: API and IPng Transition In-Reply-To: Your message of "Wed, 06 Apr 94 15:26:47 BST." <199404061427.KAA03395@picard.cmf.nrl.navy.mil> Date: Wed, 06 Apr 94 13:00:44 -0400 X-Mts: smtp Status: O Jon, >>APIs are tough to do correctly. >'m not sure i agree with this statement - what i think is that APIs >are hard to get vendors to agree to.... I agree with you. > >The IETF has minimal experience with APIs -- to the considerable detriment > >of its work as a whole. >the folkks who go to ietf from berkeley and ftp software and bellcore >have had a HUGE say in >sockets, winsock, streams True but just as a point of notice if you look at the UNIX implementations most have still not set socket options to set the DF bit, TOS bits, etc.. My point is that folks could not figure out how to tell applications to use them so they left them out and I believe all the bugs are still not chased out with these options simply because they were not used. Bascially this was OK but now with the proliferation of routers and Internet applications we need to start using the nice little bits of extra in the network packet. For IPng the transition and new bits will need to be verified at least architecturally so this time they can be explained and used more clearly. >the 3 main IPv4 APIs... > >Thus, the bottom line is: are we playing around with protocols or are > >we trying to design something which may be actually deployable? YES YES YES. If its going to be deployable then the APIs need to be verified architecturally and technically. >the work in most of the IPng proposals to do prototypes has (in my >reading at least of CATNIP, SIPP, TUBA) addressed the practicalities >of the API Well right now the only depth is from the SIPP group as far as technical 'how to' do it at the 'primitive' descriptions. >the Tuba people especially have listed exhaustively, the applications >affected because of lack of transparency of TCP, through to IP - there >is only 1 - FTP. all the others can run on the tcp and udp APIs that exist, >unchanged - this is key. A point. The list other than FTP came from the IPAE document via SIPP. >only the router folks have to concern themselves weith all the >protocols tat run direct on IP[ng] (apart from ICMP).... What does this mean Jon? Thanks .... >if you want IPng to define a clean TCPng API, that is a different (and >also very useful) matter... I think UDP or TCP can be transparent unless we want to delve into 'how to' handle the transport conversions/translations for IPv4 and IPng clients in my model proposed to Frank. But I agree it would be useful. The new SIPP api should be an ID any day now I am sure others can plagarize from it as when this version was built the idea of IPng was addressed generically I think well. I worked on this with Bob Gilligan, Ramesh Govinden, and Sue Thompson and will be implementing it. Its based on Bob's orginal design and added that from PIP which affected SIP (with one P). Its pretty good I think. /jim cheers jon From ericf@atc.boeing.com Wed Apr 6 10:16:23 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA05265 for ; Wed, 6 Apr 1994 13:14:50 -0400 Received: by atc.boeing.com (5.57) id AA03683; Wed, 6 Apr 94 10:16:23 -0700 Date: Wed, 6 Apr 94 10:16:23 -0700 From: Eric Fleischman Message-Id: <9404061716.AA03683@atc.boeing.com> To: deering@parc.xerox.com, ericf@atc.boeing.com Subject: Re: API and IPng Transition Cc: ipng@cmf.nrl.navy.mil Status: O Dear Steve, Thank you for your much-appreciated message regarding APIs. I hope to also hear from other Directorate members because this is a very important topic and I would like to have a consensus position formed. The rest of this message is in regard to the following text of your message: > From deering@parc.xerox.com Wed Apr 6 08:55:33 1994 > While I agree that APIs are out-of-scope, defining service interfaces is not. > Service interfaces specify the interactions and information exchange that > are required to use a protocol implementation or service, in an abstract, > OS- and language-independent, way. It is something we have done before. ... > I believe it is reasonable to require that any IPng proposal >include a description of how the IPng service interface differs from the >IPv4 service interface. (I had a such a section in the previous SIP[P] spec, >but for some reason that I can't immediately recall, I deleted some of it >from the latest version -- I suppose I should put it back.) Would that >satisfy Eric's concerns? I am a believer that the standard ISO distinction between services and protocols is desirable. Thus, I naturally believe that explicit service interfaces are A Good Thing. As the OSE Reference Model [no, this is not a misspelling but a different model] points out, a service definition gives a natural interface to the definition of APIs. However, this is NOT what I am talking about and it in no way satisfies my concerns. My concerns deal with transition. To date most of our IPng discussions have been dealing with the impact of IPng upon standard TCP/IP applications (FTP, TELNET, etc.). These are important. However, users have invested billions of dollars in writing their own applications which use TCP/IP. Within The Boeing Company, most of these applications directly use BSD Sockets, though other related approaches (e.g., Winsock) are also important. In addition, important communities (X/Open, IEEE POSIX, etc.) have developed numerous APIs based upon the AT&T TLI API. I must agree with Jon that the latter camp of APIs (i.e., the TLI-based APIs which include XTI, revised XTI, CLI, MPTN) are vendor and consortia based and thus out-of-our domain (except to propose a possibility to consider which seems to me to not be worth our efforts). However, the socket based APIs are a different matter altogether -- and are by far the more widespread used API. This API was originally defined (I believe) by BSD but has long since become a ubiquitous de facto standard. Nobody owns it now but "every- body" uses it. This API *greatly needs" the attention of the IETF to define a IPng version of it. In any case, if no IPng version of these widespread TCP/IP APIs exists then the installed base of TCP/IP applications CAN NOT migrate to IPng. Why is this so difficult to understand? My whole point is that unless an IPng version of sockets is created, and that version does not have strong backward compatibility to present-day sockets that no viable transition schema would have been devised. This is not an exaggeration Sincerely yours, --Eric Fleischman From bound@zk3.dec.com Wed Apr 6 14:24:47 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA05976 for ; Wed, 6 Apr 1994 14:30:59 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA27522; Wed, 6 Apr 94 11:24:58 -0700 Received: by xirtlu.zk3.dec.com; id AA17458; Wed, 6 Apr 1994 14:24:53 -0400 Message-Id: <9404061824.AA17458@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Subject: Parts of API and Transition Discussion Date: Wed, 06 Apr 94 14:24:47 -0400 X-Mts: smtp Status: O Frank, We are talking in three different vains here and I would like to parse it out cause I think we may all agree if we talk about distinct parts of the API and Transition discussion. 1. IPng needs a specification for APIs and a standards track (Eric F.) I don't think we can build this in the IETF. But, I do think an informational RFC is a good thing for any IPng proposal to provide to get this standards track moving in POSIX and X/Open at some point. This may be something the IPng AD's would send to the POSIX and X/Open folks once we have selected an IPng. I don't think the above should be a requirement but maybe a non-goal paragraph to assist the AD's for IPng in the future. 2. Service interfaces defined to the network interface because of IPng (Steve D.). Yes I think this should be an IPng requirement as part of the IPng network layer packet proposal. 3. Don't break existing IPv4 apps that have not ported to IPng yet and maintain binary compatibility in that specfic case (Jim B.). Well of course I believe my self. The issue here is that if not watched closely an IPng could create a negative end result which would affect the deployment and transition to IPng. Maybe this will help us focus on a resolution so we can move on. /jim From ericf@atc.boeing.com Wed Apr 6 13:30:56 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA07209 for ; Wed, 6 Apr 1994 16:29:17 -0400 Received: by atc.boeing.com (5.57) id AA25418; Wed, 6 Apr 94 13:30:56 -0700 Date: Wed, 6 Apr 94 13:30:56 -0700 From: Eric Fleischman Message-Id: <9404062030.AA25418@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: RE: API and IPng Transition Status: O Dear Jim, I concur with you concerning the POSIX and X/Open APIs. However, my points were concerning sockets which (of course) need to be addressed within those environments. However, there is a very close linkage between sockets and TCP/IP which are not found in the other API alternatives. There is no consortia or body which owns sockets -- though IEEE POSIX is "standardizing" the IPv4 variant. Sockets is by far the widest deployed of all of the TCP/IP APIs. Sockets needs to be addressed as part of the IPng Transition just as much as FTP needs to be addressed. But all this is a side issue. My point is that an IPng Transition is incomplete until the transition of ubiquitous TCP/IP APIs into the "IPng world" have been addressed. These APIs are the key for whether user written applications can be migrated to IPng or not. Literally multiple billions of dollars in investments have already been spent in these user applications. They are dramatically important "ties that bind" real end users to IPv4 and are one of the more important issues concerning why IPng is such a "hard sell". Now it is my turn to shout: THERE WILL NEVER EVEN BE A THEORETICAL CHANCE FOR REAL END USERS TO COMPLETELY MIGRATE FROM IPv4 TO IPng UNLESS THESE APPLICATIONS CAN BE EASILY PORTED TO AN IPng ENVIRONMENT. IF WE FAIL TO PROVIDE A MECHANISM TO TRANSITION THESE APPLICATIONS THEN IPv4 CAN NOT EVEN BE THEORETICALLY REPLACED BY IPng. Sincerely yours, --Eric Fleischman P.S. Since 1990 I have been writing about API issues. Beginning in 1992 versions of my paper have been made available to the outside world -- and excerpts have been published in both the USA and Europe. Last January I finished my latest non-proprietary version. It is 72 pages long. I would be happy to send it to whatever directorate member is interested. Also, should we move this discussion over to the big-internet? >From: bound@zk3.dec.com >1. IPng needs a specification for APIs and a standards track (Eric F.) >I don't think we can build this in the IETF. But, I do think an >informational RFC is a good thing for any IPng proposal to provide to >get this standards track moving in POSIX and X/Open at some point. This >may be something the IPng AD's would send to the POSIX and X/Open folks once >we have selected an IPng. > >I don't think the above should be a requirement but maybe a non-goal >paragraph to assist the AD's for IPng in the future. From sob@hsdndev.harvard.edu Wed Apr 6 16:49:12 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA07405 for ; Wed, 6 Apr 1994 16:49:22 -0400 Date: Wed, 6 Apr 94 16:49:12 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404062049.AA08297@hsdndev.harvard.edu> To: ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil Subject: RE: API and IPng Transition Status: O > Also, should we move this discussion over to the big-internet? Eric et all, yes - please do move the discussion. There are inportant points here ( I, for one, agree with Eric's last paragraph - though not the yelling :-) ) But I think that we need to involve the broader IETF community in this type of issue. Scott From bound@zk3.dec.com Wed Apr 6 23:48:59 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA00798 for ; Thu, 7 Apr 1994 07:54:39 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA17232; Wed, 6 Apr 94 20:49:16 -0700 Received: by xirtlu.zk3.dec.com; id AA05255; Wed, 6 Apr 1994 23:49:04 -0400 Message-Id: <9404070349.AA05255@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: ipng@cmf.nrl.navy.mil Subject: Re: API and IPng Transition In-Reply-To: Your message of "Wed, 06 Apr 94 13:30:56 PDT." <9404062030.AA25418@atc.boeing.com> Date: Wed, 06 Apr 94 23:48:59 -0400 X-Mts: smtp Status: O Eric, I have to agree with you after that last mail. We need to define a sockets API. Just because it has not been done before in the IETF is not a good argument. We have the experts to do this in our ranks and as an API expert I am willing to help. I too have papers on the subject but I cannot share them as they are confidential. Essentially they may become products someday and are an engineering study I worked on to produce a multiprotocol API based on Sockets and for XTI. It is costly to implement but would reduce the present engineering costs of applications groups by an order of magnitude. But we have the chicken and the egg issue; when do you actually change the API. In the case of IPng we have no choice. With all that said would you be open to an RFC that documented the changes to the sockets API to support IPng and then let POSIX or X/Open complete the finishing touches that are necessary to support OSI, Netbios, SNA, and IPX? If we take that on I can't commit its too much API work and they are paying to work on network protocols right now. If we do more than state an informational RFC X/Open and POSIX will yell loudly just like we would if X/Open or POSIX tried to standardize a new transport layer protocol. There is a standards space we need to live in don't we? Good shout too. /jim From bound@zk3.dec.com Thu Apr 7 00:48:42 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA01029 for ; Thu, 7 Apr 1994 08:16:12 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA19102; Wed, 6 Apr 94 21:48:53 -0700 Received: by xirtlu.zk3.dec.com; id AA06377; Thu, 7 Apr 1994 00:48:48 -0400 Message-Id: <9404070448.AA06377@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: telechats ??? Date: Thu, 07 Apr 94 00:48:42 -0400 X-Mts: smtp Status: O Any idea on dates for our telechats. Seems I have to use the practical alternative to work and go to a few meetings this month. But I won't go if we have telechats scheduled. thanks /jim From ericf@atc.boeing.com Thu Apr 7 09:39:00 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA08958 for ; Thu, 7 Apr 1994 12:37:22 -0400 Received: by atc.boeing.com (5.57) id AA17657; Thu, 7 Apr 94 09:39:00 -0700 Date: Thu, 7 Apr 94 09:39:00 -0700 From: Eric Fleischman Message-Id: <9404071639.AA17657@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: RE: APIs Status: O Dear Jim, Thank you for your note. I fully understand about your paper being proprietary. Most of mine are too and it is rare that I am permitted to write something that isn't. Now, back to the API issue: >With all that said would you be open to an RFC that documented the >changes to the sockets API to support IPng and then let POSIX or X/Open >complete the finishing touches that are necessary to support OSI, >Netbios, SNA, and IPX? If we take that on I can't commit its too much >API work and they are paying to work on network protocols right now. >If we do more than state an informational RFC X/Open and POSIX will yell >loudly just like we would if X/Open or POSIX tried to standardize a new >transport layer protocol. There is a standards space we need to live in >don't we? I absolutely agree that we can't be arrogant and that when we make suggestions to other communities are suggestions are only that: suggestions. However, because IPng represents new work for them and this work is OUR DOING not theirs (i.e., if it wouldn't be for us, they wouldn't be bothered by IPng at all) then I believe that we owe them suggestions as to how they can address IPng within their standards -- otherwise they might choose to ignore it altogether. Concerning sockets I think that we should define a IPng sockets and then ask POSIX or X/Open to standardize it. This is something they are very good at and both users and vendors are already VERY familiar and comfortable with this process. One must hope that the IETF definition will be very similar to today's sockets and also very similar to the final standardized version. However, I believe that we need to handle this as an intimate part of our IPng transition work because if we don't it may not get handled at all. Sincerely yours, --Eric Fleischman From lkeiper@IETF.CNRI.Reston.VA.US Thu Apr 7 18:02:19 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA23477 for ; Thu, 7 Apr 1994 18:59:14 -0400 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa14400; 7 Apr 94 18:01 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Apr 1994 18:02:19 +0100 To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference Cc: lkeiper@cnri.reston.va.us Message-ID: <9404071801.aa14400@IETF.CNRI.Reston.VA.US> Status: O ANNOUNCEMENT: The names marked with an asterisk are those who have confirmed participation for the IPng teleconference sheduled for Monday, April 11, 1994 11:30 - 1:30pm EST. Please send your RSVP as soon as possible. Please contact me with any changes @lkeiper.cnri.reston.va.us. J. Allard 206-936-9031 Scott Bradner 617-495-3864 Steve Bellovin 908-582-5886 Jim Bound 603-881-0400 Ross Callon 508-436-3936 Brian Carpenter +41 227 674 967 Dave Clark 617-253-6003 ?Steve Coya 703-620-8990? (unsure at this time) Jon Crowcroft +44 713 807 296 John Curran 617-873-4398 Steve Deering 415-812-4839 Dino Farinacci 408-226-6870 Eric Fleischman 206-957-5334 Paul Frances +81 339 280 408 Dan Karrenberg +31 205 925 065 Frank Kastenholtz 508-685-4000 Mark Knopper 313-741-5445 Alison Mankin 202-404-7030 Greg Minshall 510-975-4507 Paul Mockapetris 310-822-1511 Frank Kastenholtz 508-685-4000 Craig Partridge 415-326-4541 Rob Ullmann 617-693-1315 Lixia Zhang 415-812-4415 If you need to be added to the call in progress, Please call 1-800-232-1234 or for international particpants, 516-424-3151. The call can be referenced by the confirmation number ER43333 in the orginators name, Steve Coya. Many thanks, Lois From sob@hsdndev.harvard.edu Thu Apr 7 20:17:59 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA07844 for ; Thu, 7 Apr 1994 20:18:07 -0400 Date: Thu, 7 Apr 94 20:17:59 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404080017.AA16266@hsdndev.harvard.edu> To: crocker@tis.com Subject: IPng security workshop Cc: galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Status: O Steve, (I've included the IPng directorrate for this reply) Allison & I talked about your suggestion and think it is a very good idea. We are planning an IPng retreat in May (it looks like it will be at CNRI for a number of reasons). Could we tack a security workshop on the front or back of the retreat for those of the directorate would be interested and could spend the time and as you suggest, a select set of additional people. Scott ------ >From crocker@tis.com Wed Apr 6 12:10:33 1994 Status: RO id AA20058; Wed, 6 Apr 1994 12:14:14 -0400 Received: by relay.tis.com; id AA11205; Wed, 6 Apr 94 12:10:11 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma011202; Wed Apr 6 12:10:00 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA24917; Wed, 6 Apr 94 12:09:12 EDT Message-Id: <9404061609.AA24917@tis.com> To: mankin@cmf.nrl.navy.mil, sob@harvard.edu, jis@mit.edu Cc: crocker@tis.com, sandy@tis.com, galvin@tis.com, smb@ulysses.att.com Return-Receipt-To: crocker@tis.com Subject: IPng security workshop Date: Wed, 06 Apr 94 12:09:09 -0400 From: Stephen D Crocker Allison, Scott, and Jeff As I understand it, the IPng requirements are firming up and a recommendation for a decision is scheduled for the summer. This seems like an ideal time to review the security issues and make sure all the bases are covered. I had mentioned to Allison the possibility of having a workshop specifically to review all aspects of IPng security, and I'd like to press the idea. I have in mind a two day effort in the D.C. area limited to a selected set of people with a well organized agenda. How do you all feel about this? If you're in favor, when is the right time? And how would you like to proceed? There should probably be a small planning committee; suggest the right set of people. Steve +-------------------------------------+-------------------------------+ | Steve Crocker | Voice: 301-854-6889 | | Trusted Information Systems | FAX: 301-854-5363 | | 3060 Washington Road (Route 97) |-------------------------------| | Glenwood, MD 21738 | Internet: crocker@tis.com | +-------------------------------------+-------------------------------+ From crocker@tis.com Thu Apr 7 22:23:42 1994 Return-Path: crocker@tis.com Received: from relay.tis.com (firewall_user@relay.tis.com [192.94.214.100]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id WAA04895 for ; Thu, 7 Apr 1994 22:24:29 -0400 Received: by relay.tis.com; id AA21983; Thu, 7 Apr 94 22:24:36 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma021979; Thu Apr 7 22:24:32 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA09087; Thu, 7 Apr 94 22:23:44 EDT Message-Id: <9404080223.AA09087@tis.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Subject: Re: IPng security workshop In-Reply-To: Your message of "Thu, 07 Apr 94 20:17:59 EDT." <9404080017.AA16266@hsdndev.harvard.edu> Date: Thu, 07 Apr 94 22:23:42 -0400 From: Stephen D Crocker Status: O CNRI is fine with me. May is generally ok. I'm scheduled to for a trip May 10-12. What dates are you thinking of for the retreat? Want to do it at the beginning and have the results available for the rest of the retreat, or do it afterwards with questions and/or constraints in hand from the retreat? (My guess is it'll be more useful before, but I see pros and cons either way.) If the schedule has not yet been set, does it make sense to poll key people for availability? Steve From sob@hsdndev.harvard.edu Fri Apr 8 10:32:37 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA01151 for ; Fri, 8 Apr 1994 10:33:00 -0400 Date: Fri, 8 Apr 94 10:32:37 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404081432.AA03710@hsdndev.harvard.edu> To: crocker@tis.com Subject: Re: IPng security workshop Cc: galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Status: O Steve, Who did you have in mind? Scott From crocker@tis.com Fri Apr 8 10:51:50 1994 Return-Path: crocker@tis.com Received: from relay.tis.com (firewall_user@relay.tis.com [192.94.214.100]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA01627 for ; Fri, 8 Apr 1994 11:33:50 -0400 Received: by relay.tis.com; id AA25499; Fri, 8 Apr 94 10:53:33 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma025495; Fri Apr 8 10:53:12 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA27485; Fri, 8 Apr 94 10:51:57 EDT Message-Id: <9404081451.AA27485@tis.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com, crocker@tis.com Subject: Re: IPng security workshop In-Reply-To: Your message of "Fri, 08 Apr 94 10:32:37 EDT." <9404081432.AA03710@hsdndev.harvard.edu> Date: Fri, 08 Apr 94 10:51:50 -0400 From: Stephen D Crocker Status: O > Steve, > Who did you have in mind? > > Scott The following is a list of names that comes to mind. (Ignore the order, these have just tumbled out.) This list is not complete; I'm sure there are a at least a few I should have included. And it's also far too many to check with before setting a schedule. Jeff may have some ideas on how to limit this and/or who else is critical. Jeff Schiller Security AD Steve Bellovin IPng directorate, security focus Paul Lambert IPSEC WG co-chair Jim Zmuda IPSEC WG co-chair Phil Karn IPSEC WG member; thinker and implementer Dave Solo SDNS expert, PSRG member Steve Kent SDNS expert, PSRG chair Russ Housely SDNS expert, PSRG member Mike StJohns Network security expert Robbie Rosenthal PSRG, NIST Hilarie Orman x-kernel and IPSEC researcher Ran Atkinson SIPP security designer, etc. Don Eastlake active security designer Steve Crocker Sandy Murphy Jim Galvin Steve From lkeiper@IETF.CNRI.Reston.VA.US Fri Apr 8 16:39:23 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA02742 for ; Fri, 8 Apr 1994 16:40:34 -0400 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa13995; 8 Apr 94 16:38 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Apr 1994 16:39:23 +0100 To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference Cc: lkeiper@cnri.reston.va.us Message-ID: <9404081638.aa13995@IETF.CNRI.Reston.VA.US> Status: O UPDATE: The names marked with an asterisk are those who have confirmed participation for the IPng teleconference sheduled for Monday, April 11, 1994 11:30 - 1:30pm EST. Please send your RSVP as soon as possible. Thank You!! Please contact me with any changes @lkeiper.cnri.reston.va.us. J. Allard 206-936-9031 Scott Bradner 617-495-3864 Steve Bellovin 908-582-5886 *Jim Bound 603-465-3130* Ross Callon 508-436-3936 Brian Carpenter +41 227 674 967 Dave Clark 617-253-6003 ?Steve Coya 703-620-8990? (unsure at this time) Jon Crowcroft +44 713 807 296 John Curran 617-873-4398 Steve Deering 415-812-4839 *Dino Farinacci 408-226-6870* *Eric Fleischman 206-957-5334* Paul Frances +81 339 280 408 Daniel Karrenberg +31 205 925 065 *Frank Kastenholz 508-685-4000* Mark Knopper 313-741-5445 Alison Mankin 202-404-7030 *Greg Minshall will call in* Paul Mockapetris 310-822-1511 *Craig Partridge 415-326-4541* Rob Ullmann 617-693-1315 *Lixia Zhang 415-812-4415* If you need to be added to the call in progress, Please call 1-800-232-1234 or for international particpants, 516-424-3151. The call can be referenced by the confirmation number ER43333 in the orginators name, Steve Coya. Many thanks, Lois From sob@hsdndev.harvard.edu Fri Apr 8 11:42:31 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA01730 for ; Fri, 8 Apr 1994 11:42:49 -0400 Date: Fri, 8 Apr 94 11:42:31 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404081542.AA10301@hsdndev.harvard.edu> To: crocker@tis.com Subject: Re: IPng security workshop Cc: galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Status: O Steve, Did you also have an idea of what an agenda would look like? Scott From crocker@tis.com Fri Apr 8 11:53:01 1994 Return-Path: crocker@tis.com Received: from relay.tis.com (firewall_user@relay.tis.com [192.94.214.100]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA01809 for ; Fri, 8 Apr 1994 11:54:42 -0400 Received: by relay.tis.com; id AA25905; Fri, 8 Apr 94 11:54:45 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma025901; Fri Apr 8 11:53:54 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA00359; Fri, 8 Apr 94 11:53:04 EDT Message-Id: <9404081553.AA00359@tis.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com, crocker@tis.com Subject: Re: IPng security workshop In-Reply-To: Your message of "Fri, 08 Apr 94 11:42:31 EDT." <9404081542.AA10301@hsdndev.harvard.edu> Date: Fri, 08 Apr 94 11:53:01 -0400 From: Stephen D Crocker Status: O Scott, Here's what I want to see covered. Some of this should be done in advance. The goal is to know whether we have proposals on the table which contain enough security, and if not, what the issues are. I would hope the material for the first two bullets is already in hand. If it isn't, this workshop may serve as a forcing function. On that account, it would be good to get it organized and advertised at least a couple of weeks in advance. Steve IPng Security Assessment o Clear statement of the requirements - Integrity, authentication, privacy - Within the PDU or via encapsulation (This may or may not be a requirement; it's possible it's just a design choice.) - Efficiency or other metrics - License and export environment issues o Specific proposals Review of each of the proposals. Examination for completeness, etc. Key management has to be included, not treated as a separate and deferred topic. o Deployment issues - Compatibility with current protocols - Introduction of key management infrastructure - Other? o Assessment of where we stand From kasten@mailserv-D.ftp.com Fri Apr 8 12:07:13 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA00768 for ; Fri, 8 Apr 1994 13:11:25 -0400 Received: from ftp.com by ftp.com ; Fri, 8 Apr 1994 12:08:06 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 8 Apr 1994 12:08:06 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA08848; Fri, 8 Apr 94 12:07:13 EDT Date: Fri, 8 Apr 94 12:07:13 EDT Message-Id: <9404081607.AA08848@mailserv-D.ftp.com> To: crocker@tis.com Subject: Re: IPng security workshop From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: sob@hsdndev.harvard.edu, galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Content-Length: 800 Status: O what's the goal of ipng security? the intent of the criteria document (at least my interpretation of what we wrote :-) is that ip-layer security's goal is to secure the internetwork layer from attack, in other words, to provide a 'safe' and 'secure' substrate. i am not sure that i see ipng security as providing the more end-to-end security (e.g. providing authentication for a telnet login or the like). ipng should be concerned with protecting its own things -- making sure that the routing protocols are safe from bogus packets, that icmp redirects can't be spoofed, and stuff like that. am i in synch with the rest of you? or have my brain cells decided to leave early on a nice friday afternoon? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From crocker@tis.com Fri Apr 8 13:19:03 1994 Return-Path: crocker@tis.com Received: from relay.tis.com (firewall_user@relay.tis.com [192.94.214.100]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA01010 for ; Fri, 8 Apr 1994 13:20:17 -0400 Received: by relay.tis.com; id AA26598; Fri, 8 Apr 94 13:20:19 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma026593; Fri Apr 8 13:19:57 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA03175; Fri, 8 Apr 94 13:19:07 EDT Message-Id: <9404081719.AA03175@tis.com> To: kasten@ftp.com Cc: sob@hsdndev.harvard.edu, galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Subject: Re: IPng security workshop In-Reply-To: Your message of "Fri, 08 Apr 94 12:07:13 EDT." <9404081607.AA08848@mailserv-D.ftp.com> Date: Fri, 08 Apr 94 13:19:03 -0400 From: Stephen D Crocker Status: O Frank, Ulp! Yes, we seem to be headed in quite distinct directions. As it turns out, I am also deeply concerned about the protection of internet level infrastructure. We've got some funding from StJohns to study it carefully. The main focus of our concern is protection of routing information using authentication mechanisms. We have not spent any time worrying about ICMPs and the like; your note suggests to me we should. Meanwhile, let's do indeed sort out what the issues are. I had thought the goals for IPng included appropriate controls to protect the authenticity, integrity and privacy of packets traversing the net, i.e. host-to-host security for the users. If this is not one of the goals, then there needs to some serious thinking about that topic. However, I agree completely that the network infrastructure also needs to be protected. If the IPng candidates are designed to provide that protection, then things in that area in much better shape than I thought they were. To facilitate discussion, let's designate the security you're talking about as "infratructure protection" or "internal security" and the kind I'm talking about as "end-to-end security" or "user protection." Where do we go from here? Steve > Reply-To: kasten@ftp.com > From: kasten@ftp.com (Frank Kastenholz) > To: crocker@tis.com > cc: sob@hsdndev.harvard.edu, galvin@tis.com, ipng@cmf.nrl.navy.mil, > jis@mit.edu, sandy@tis.com > Date: Fri, 8 Apr 94 12:07:13 EDT > Subject: Re: IPng security workshop > > > what's the goal of ipng security? > > the intent of the criteria document (at least my interpretation of > what we wrote :-) is that ip-layer security's goal is to secure the > internetwork layer from attack, in other words, to provide a 'safe' > and 'secure' substrate. i am not sure that i see ipng security as > providing the more end-to-end security (e.g. providing authentication > for a telnet login or the like). ipng should be concerned with > protecting its own things -- making sure that the routing protocols > are safe from bogus packets, that icmp redirects can't be spoofed, > and stuff like that. > > am i in synch with the rest of you? or have my brain cells decided > to leave early on a nice friday afternoon? > > -- > Frank Kastenholz > FTP Software > 2 High Street > North Andover, Mass. USA 01845 > (508)685-4000 > > From lixia@parc.xerox.com Fri Apr 8 11:55:50 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA01986 for ; Fri, 8 Apr 1994 14:56:43 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14444(1)>; Fri, 8 Apr 1994 11:55:46 PDT Received: by redwing.parc.xerox.com id <57155>; Fri, 8 Apr 1994 11:55:55 -0700 Date: Fri, 8 Apr 1994 11:55:50 PDT Sender: Lixia Zhang From: Lixia Zhang To: Stephen D Crocker Cc: kasten@ftp.com, sob@hsdndev.harvard.edu, galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Subject: Re: IPng security workshop In-Reply-To: Your message of Fri, 8 Apr 1994 10:19:03 -0700 Message-ID: Status: O > To facilitate discussion, let's designate the security you're talking > about as "infratructure protection" or "internal security" and the > kind I'm talking about as "end-to-end security" or "user protection." I like this sorting but would also like to add that the "infrastructure protection" should also include prevention from denial of service (the issue Clark talked at Seattle IETF). Lixia From crocker@tis.com Fri Apr 8 15:02:13 1994 Return-Path: crocker@tis.com Received: from relay.tis.com (firewall_user@relay.tis.com [192.94.214.100]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA02144 for ; Fri, 8 Apr 1994 15:03:49 -0400 Received: by relay.tis.com; id AA27465; Fri, 8 Apr 94 15:03:51 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma027459; Fri Apr 8 15:03:07 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA08093; Fri, 8 Apr 94 15:02:16 EDT Message-Id: <9404081902.AA08093@tis.com> To: Lixia Zhang Cc: kasten@ftp.com, sob@hsdndev.harvard.edu, galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Subject: Re: IPng security workshop In-Reply-To: Your message of "Fri, 08 Apr 94 11:55:50 PDT." Date: Fri, 08 Apr 94 15:02:13 -0400 From: Stephen D Crocker Status: O Yes, infrastructure protection should indeed include Dave Clark's prevention of denial of service. I confess that I don't fully understand how to implement this sort of protection in today's networks, but to the extent that there are mechanisms we can find for such protection, it belongs in the infrastructure protection bucket. Steve From adamson@itd.nrl.navy.mil Fri Apr 8 15:06:14 1994 Return-Path: adamson@itd.nrl.navy.mil Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA02172 for ; Fri, 8 Apr 1994 15:06:59 -0400 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA05724; Fri, 8 Apr 1994 15:10:18 -0400 Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA09681; Fri, 8 Apr 94 15:06:15 EDT Date: Fri, 8 Apr 94 15:06:14 EDT Message-Id: <9404081906.AA09681@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng-wp@harvard.edu From: adamson@itd.nrl.navy.mil (Brian Adamson) Subject: IPng Tactical RF Requirements (Text Version) Cc: adamson@itd.nrl.navy.mil, cole@itd.nrl.navy.mil Status: O Attached is the ascii text version of a short IPng requirements white paper. This paper represents experiences with implementing Internetworking designs in tactical RF scenarios, in the NATO CSNI project and in the Navy's CSS and Data/Voice Integration ATD. Brian Adamson ---------------------------CUT HERE------------------------------------ IPng White Paper: TACTICAL RADIO FREQUENCY COMMUNICATION REQUIREMENTS FOR NEXT GENERATION INTERNET PROTOCOLS R. Brian Adamson Communication Systems Branch Information Technology Division 8 April 1994 Naval Research Laboratory STATUS OF THIS REPORT This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. EXECUTIVE SUMMARY The U.S. Navy has several efforts exploring the applicability of commercial internetworking technology to tactical RF networks. Some these include the NATO Communication System Network Interoperability (CSNI) project, the Naval Research Laboratory Data/Voice Integration Advanced Technology Demonstration (D/V ATD), and the Navy Communication Support System (CSS) architecture development. Critical requirements have been identified for security, mobility, real-time data delivery applications, multicast, and quality-of-service and policy based routing. Address scaling for Navy application of internet technology will include potentially very large numbers of local (intra-platform) distributed information and weapons systems and a smaller number of nodes requiring global connectivity. The flexibility of the current Internet Protocol (IP) for supporting widely different communication media should be preserved to meet the needs of the highly heterogeneous networks of the tactical environment. Compact protocol headers are necessary for efficient data transfer on the relatively-low throughput RF systems. Mechanisms which can enhance the effectiveness of an internet datagram protocol to provide resource reservation, priority, and service quality guarantees are also very important. The broadcast nature of many RF networks and the need for broad dissemination of information to warfighting participants makes multicast the general case for information flow in the tactical environment.  BACKGROUND This paper describes requirements for Internet Protocol next generation (IPng) candidates with respect to their application to military tactical radio frequency (RF) communication networks. The foundation for these requirements are experiences in the NATO Communication System Network Interoperability (CSNI) project, the Naval Research Laboratory Data/Voice Integration Advanced Technology Demonstration (D/V ATD), and the Navy Communication Support System (CSS) architecture development. The goal of the CSNI project is to apply internetworking technology to facilitate multi-national interoperability for typical military communication applications (e.g. electronic messaging, tactical data exchange, and digital voice) on typical tactical RF communication links and networks. The International Standard Organization (ISO) Open Systems Interconnect (OSI) protocol suite, including the Connectionless Network Protocol (CLNP), was selected for this project for policy reasons. This paper will address design issues encountered in meeting the project goals with this particular protocol stack. The D/V ATD is focused on demonstrating a survivable, self-configuring, self-recovering RF subnetwork technology capable of simultaneously supporting data delivery, including message transfer, imagery, and tactical data, and real-time digital voice applications. Support for real-time interactive communication applications was extended to include a "white board" and other similar applications. IP datagram delivery is also planned as part of this demonstration system. The CSS architecture will provide U.S. Navy tactical platforms with a broad array of user-transparent voice and data information exchange services. This will include support for sharing and management of limited platform communication resources among multiple warfighting communities. Emphasis is placed on attaining interoperability with other military services and foreign allies. Utilization of commercial off-the-shelf communications products to take advantage of existing economies of scale is important to make any resulting system design affordable. It is anticipated that open, voluntary standards, and flexible communication protocols, such as IP, will play a key role in meeting the goals of this architecture. INTRODUCTION Before addressing any IPng requirements as applied to tactical RF communications, it is necessary to define what this paper means by "IPng requirements". To maintain brevity, this paper will focus on criteria related specifically to the design of an OSI model's Layer 3 protocol format and a few other areas suggested by RFC 1550. There are several additional areas of concern in applying internetwork protocols to the military tactical RF setting including routing protocol design, address assignment, network management, and resource management. While these areas are equally important, this paper will attempt to satisfy the purpose of RFC 1550 and address issues more directly applicable to selection of an IPng candidate. 2 (IPng Tactical Requirements)  REQUIREMENTS SCALING The projection given in RFC 1550 that IPng should be able to deal with 10 to the 12th nodes is more than adequate in the face of military requirements. More important is that it is possible to assign addresses efficiently. For example, although a military platform may have a relatively small number of nodes with requirements to communicate with a larger, global infrastructure, there will likely be applications of IPng to management and control of distributed systems (e.g. specific radio communications equipment and processors, weapons systems, etc) within the platform. This local expansion of address space requirements may not necessarily need to be solved by "sheer numbers" of globally-unique addresses but perhaps by alternate delimitation of addressing to differentiate between globally-unique and locally-unique addressing. The advantages of a compact internet address header are clear for relatively low capacity RF networks. TIMESCALE, TRANSITION AND DEPLOYMENT The U.S. Navy and other services are only recently (the last few years) beginning to design and deploy systems utilizing open systems internetworking technology. From this point of view, the time scale for selection of IPng must be somewhat rapid. Otherwise, two transition phases will need to be suffered, 1) the move from unique, "stove pipe" systems to open, internetworked (e.g. IP) systems, and then 2) a transition from deployed IP-based systems to IPng. In some sense, if an IPng is quickly accepted and widely implemented, the transition for tactical military systems will be somewhat easier than the enterprise Internet where a large investment in current IP already exists. However, having said this, the Department of Defense as a whole already deploys a large number of IP-capable systems, and the issue of transition from IP to IPng remains significant. SECURITY As with any military system, information security, including confidentiality and authenticity of data, is of paramount importance. With regards to IPng, network layer security mechanisms for tactical RF networks generally important for authentication purposes, including routing protocol authentication, source authentication, and user network access control. Concerns for denial of service attacks, traffic analysis monitoring, etc usually dictate that tactical RF communication networks provide link layer security mechanisms. Compartmentalization and multiple levels of security for different users of common communication resources call for additional security mechanisms at the transport layer or above. In the typical tactical RF environment, network layer confidentiality and, in some cases, even authentication becomes redundant with these other security mechanisms. 3 (IPng Tactical Requirements)  The need for network layer security mechanisms becomes more critical when the military utilizes commercial telecommunications systems or has tactical systems inter-connected with commercial internets. While the Network Encryption Server (NES) works in this role today, there is a desire for a more integrated, higher performance solution in the future. Thus, to meet the military requirement for confidentiality and authentication, an IPng candidate must be capable of operating in a secure manner when necessary, but also allow for efficient operation on low-throughput RF links when other security mechanisms are already in place. In either of these cases, key management is extremely important. Ideally, a common key management system could be used to provide key distribution for security mechanisms at any layer from the application to the link layer. As a result, it is anticipated, however, that key distribution is a function of management, and should not dependent upon a particular IPng protocol format. MOBILITY The definition of most tactical systems include mobility in some form. Many tactical RF network designs provide means for members to join and leave particular RF subnets as their position changes. For example, as a platform moves out of the RF line-of-sight (LOS) range, it may switch from a typical LOS RF media such as the ultra-high frequency (UHF) band to a long-haul RF media such as high frequency (HF) or satellite communication (SATCOM). In some cases, such as the D/V ATD network, the RF subnet will perform its own routing and management of this dynamic topology. This will be invisible to the internet protocol except for (hopefully) subtle changes to some routing metrics (e.g. more or less delay to reach a host). In this instance, the RF subnetwork protocols serve as a buffer to the internet routing protocols and IPng will not need to be too concerned with mobility. In other cases, however, the platform may make a dramatic change in position and require a major change in internet routing. IPng must be able to support this situation. It is recognized that an internet protocol may not be able to cope with large, rapid changes in topology. Efforts will be made to minimize the frequency of this in a tactical RF communication architecture, but there are instances when a major change in topology is required. Furthermore, it should be realized that mobility in the tactical setting is not limited to individual nodes moving about, but that, in some cases, entire subnetworks may be moving. An example of this is a Navy ship with multiple LANs on board, moving through the domains of different RF networks. In some cases, the RF subnet will be moving, as in the case of an aircraft strike force, or Navy battlegroup. 4 (IPng Tactical Requirements)  FLOWS AND RESOURCE RESERVATION The tactical military has very real requirements for multi-media services across its shared and inter-connected RF networks. This includes applications from digital secure voice integrated with applications such as "white boards" and position reporting for mission planning purposes to low-latency, high priority tactical data messages (target detection, identification, location and heading information). Because of the limited capacity of tactical RF networks, resource reservation is extremely important to control access to these valuable resources. Resource reservation can play a role in "congestion avoidance" for these limited resources as well as ensuring that quality-of-service data delivery requirements are met for multi-media communication. Note there is more required here than can be met by simple quality-of-service (QoS) based path selection and subsequent source-routing to get real-time data such as voice delivered. For example, to support digital voice in the CSNI project, a call setup and resource reservation protocol was designed. It was determined that the QoS mechanisms provided by the CLNP specification were not sufficient for our voice application path selection. Voice calls could not be routed and resources reserved based on any single QoS parameter (e.g. delay, capacity, etc) alone. Some RF subnets in the CSNI test bed simply did not have the capability to support voice calls. To perform resource reservation for the voice calls, the CLNP cost metric was "hijacked" as essentially a Type of Service identifier to let the router know which datagrams were associated with a voice call. The cost metric, concatenated with the source and destination addresses were used to form a unique identifier for voice calls in the router and subnet state tables. Voice call paths were to be selected by the router (i.e. the "cost" metric was calculated) as a rule-based function of each subnet's capability to support voice, its delay, and its capacity. While source routing provided a possible means for voice datagrams to find their way from router to router, the network address alone was not explicit enough to direct the data to the correct interface, particularly in cases where there were multiple communication media interconnecting two routers along the path. Fortunately, exclusive use of the cost QoS indicator for voice in CSNI was able to serve as a flag to the router for packets requiring special handling. While a simple Type of Service field as part of an IPng protocol can serve this purpose where there are a limited number of well known services (CSNI has a single special service - 2400 bps digital voice), a more general technique such as RSVP's Flow Specification can support a larger set of such services. And a field, such as the one sometimes referred to as a Flow Identification (Flow ID), can play an important role in facilitating inter-networked data communication over these limited capacity networks. For example, the D/V ATD RF sub-network provides support for both connectionless datagram delivery and virtual circuit connectivity. To utilize this capability, an IPng could establish a virtual circuit connection across this RF subnetwork which meets the requirements of an RSVP Flow Specification. By creating an association between a particular Flow ID and the subnetwork header identifying the established virtual circuit, an IPng gateway could forward data across the low-capacity while removing most, if not all, of the IPng packet header information. The receiving gateway could re- construct these fields based on the Flow Specification of the particular Flow ID/virtual circuit association. 5 (IPng Tactical Requirements)  In summary, a field such as a Flow Identification can serve at least two important purposes: 1) It can be used by routers (or gateways) to identify packets with special, or pre-arranged delivery requirements. It is important to realize that it may not always be possible to "peek" at internet packet content for this information if certain security considerations are met (e.g. an encrypted transport layer). 2) It can aid mapping datagram services to different types of communication services provided by specialized subnet/data link layer protocols. MULTICAST Tactical military communication has a very clear requirement for multicast. Efficient dissemination of information to distributed warfighting participants can be the key to success in a battle. In modern warfare, this information includes imagery, the "tactical scene" via tactical data messages, messaging information, and real-time interactive applications such as digital secure voice. Many of the tactical RF communication media are broadcast by nature, and multicast routing can take advantage of this topology to distribute critical data to a large number of participants. The throughput limitations imposed by these RF media and the physics of potential electronic counter measures (ECM) dictate that this information be distributed efficiently. A multicast architecture is the general case for information flow in a tactical internetwork. QUALITY OF SERVICE AND POLICY-BASED ROUTING Quality of service and policy based routing are of particular importance in a tactical environment with limited communication resources, limited bandwidth, and possible degradation and/or denial of service. Priority is a very important criteria in the tactical setting. In the tactical RF world of limited resources (limited bandwidth, radio assets, etc) there will be instances when there is not sufficient capacity to provide all users with their perception of required communication capability. It is extremely important for a shared, automated communication system to delegate capacity higher priority users. Unlike the commercial world, where everyone has a more equal footing, it is possible in the military environment to assign priority to users or even individual datagrams. An example of this is the tactical data exchange. Tactical data messages are generally single-datagram messages containing information on the location, bearing, identification, etc of entities detected by sensors. In CSNI, tactical data messages were assigned 15 different levels of CLNP priority. This ensured that important messages, such as a rapidly approaching enemy missile's trajectory, were given priority over less important messages, such as a friendly, slow-moving tanker's heading. 6 (IPng Tactical Requirements)  APPLICABILITY There will be a significant amount of applicability to tactical RF networks. The current IP and CLNP protocols are being given considerable attention in the tactical RF community as a means to provide communication interoperability across a large set of heterogeneous RF networks in use by different services and countries. The applicability of IPng can only improve with the inclusion of features critical to supporting QoS and Policy based routing, security, real-time multi-media data delivery, and extended addressing. It must be noted that it is very important that the IPng protocol headers not grow overly large. There is a sharp tradeoff between the value added by these headers (interoperability, global addressing, etc) and the degree of communication performance attainable on limited capacity RF networks. Regardless of the data rate that future RF networks will be capable of supporting, there is always a tactical advantage in utilizing your resources more efficiently. DATAGRAM SERVICE The datagram service paradigm provides many useful features for tactical communication networks. The "memory" provided by datagram headers, provides an inherent amount of survivability essential to the dynamics of the tactical communication environment. The availability of platforms for routing and relaying is never 100% certain in a tactical scenario. The efficiency with which multi-cast can be implemented in a connectionless network is highly critical in the tactical environment where rapid, efficient information dissemination can be a deciding factor. And, as has been proven, with several different Internet applications and experiments, a datagram service is capable of providing useful connection-oriented and real-time communication services. Consideration should be given in IPng to how it can co-exist with other architectures such as switching fabrics which offer demand-based control over topology and connectivity. The military owns many of its own communication resources and one of the large problems in managing the military communication infrastructure is directing those underlying resources to where they are needed. Traditional management (SNMP, etc) is of course useful here, but RF communication media can be somewhat dynamically allocated. Circuit switching designs offer some advantages here. Dial-up IP routing is an example of an integrated solution. The IPng should be capable of supporting a similar type of operation. SUPPORT OF COMMUNICATION MEDIA The tactical communication environment includes a very broad spectrum of communication media from shipboard fiber-optic LANs to very low data rate (<2400 bps) RF links. Many of the RF links, even higher speed ones, can exhibit error statistics not necessarily well-serviced by higher layer reliable protocols (i.e. TCP). In these cases, efficient lower layer protocols can be implemented to provide reliable datagram delivery at the link layer, but at the cost of highly variable delay performance. 7 (IPng Tactical Requirements)  It is also important to recognize that RF communication cannot be viewed from the IPng designer as simple point-to-point links. Often, highly complex, unique subnetwork protocols are utilized to meet requirements of survivability, communications performance with limited bandwidth, anti- jam and/or low probability of detection requirements. In some of these cases IPng will be one of several Layer 3 protocols sharing the subnetwork. It is understood that IPng cannot be the panacea of Layer 3 protocols, particularly when it comes to providing special mechanisms to support the endangered-specie low data rate user. However, note that there are many valuable low data rate applications useful to the tactical user. And low user data rates, coupled with efficient networking protocols can allow many more users share limited RF bandwidth. As a result, any mechanisms which facilitate compression of network headers can be considered highly valuable in an IPng candidate. 8 (IPng Tactical Requirements) Brian ___________________________________________________________________ R. Brian Adamson Information Technology Division adamson@itd.nrl.navy.mil Naval Research Laboratory NRL Code 5523 Washington, DC 20375 From adamson@itd.nrl.navy.mil Fri Apr 8 15:37:44 1994 Return-Path: adamson@itd.nrl.navy.mil Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA02368 for ; Fri, 8 Apr 1994 15:38:20 -0400 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA06043; Fri, 8 Apr 1994 15:41:46 -0400 Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA11007; Fri, 8 Apr 94 15:37:45 EDT Date: Fri, 8 Apr 94 15:37:44 EDT Message-Id: <9404081937.AA11007@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng-wp@harvard.edu From: adamson@itd.nrl.navy.mil (Brian Adamson) Subject: "References" addendum to Tactical RF Req. Status: O Below is a short addendum containing references for the IPng Tactical RF Requirements white paper submitted earlier. thanks, Brian Adamson ----------------------------CUT HERE---------------------------------- REFERENCES [1] Miller, P. "CSNI VOICE Protocol", CSNI/Task2.B/UK/05 rev 1, August 1993. [2] Communication System Branch, Information Technology Division of the Naval Research Laboratory, "Data and Voice Integration Advanced Technology Demonstration (ATD) Execution Plan", June, 1992. [3] Space and Naval Warfare Systems Command, "Communication Support System Architecure Executive Summary- Version 1.0 Draft", March 1994. [4] Thoet, William A., Baker, Dennis J., McGregor, Dennis N., "A Multichannel Architecture for Naval Task Force Communication", NRL/FR/5520-94-9703, January 30, 1994. [5] ISO, Protocol for Providing the Connectionless-mode Network Service: Protocol Specification, ISO/IEC 8473, 1992 [6] Deering, Stephen E., "SIP: Simple Internet Protocol", IEEE Network Magazine Vol. 7 No. 3, 16-28, May 1993. From sob@hsdndev.harvard.edu Fri Apr 8 19:16:24 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA03539 for ; Fri, 8 Apr 1994 19:16:32 -0400 Date: Fri, 8 Apr 94 19:16:24 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404082316.AA11134@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil, lkeiper@IETF.CNRI.Reston.VA.US Subject: Re: IPng Teleconference Cc: lkeiper@cnri.reston.va.us Status: O humm, I thought I also said yes? Scott From Robert_Ullmann.LOTUS@CRD.lotus.com Fri Apr 8 21:54:12 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA03986 for ; Fri, 8 Apr 1994 21:48:40 -0400 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA02049; Fri, 8 Apr 94 21:50:10 EDT Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA08662; Fri, 8 Apr 94 21:54:12 EDT Date: Fri, 8 Apr 94 21:54:12 EDT Message-Id: <9404090154.AA08662@Mail.Lotus.com> Received: by DniMail (v1.0); Fri Apr 8 21:54:06 1994 EDT To: UNIXML::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Re: Brian's Comment Status: O Craig: " First, I'll note that twenty years of work on protocol conversion have resulted, almost without exception in failure. Is tunnelling an acceptable solution? Since the statement is "interconnect CLNP islands", I assume direct connectivity between CLNP hosts and IPng hosts is not required?" Um, as of a time early in this century, 500 years of attempts to build a working helicopter resulted, almost without exception, in failure. In spite of the fact that the Chinese had a working toy model in the 15th century. Point being that prior failure is useless as an argument. Cheers, Rob From brian@dxcoms.cern.ch Sun Apr 10 13:49:28 1994 Return-Path: brian@dxcoms.cern.ch 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 HAA01838 for ; Sun, 10 Apr 1994 07:50:04 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA15140; Sun, 10 Apr 1994 13:49:30 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19614; Sun, 10 Apr 1994 13:49:28 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404101149.AA19614@dxcoms.cern.ch> Subject: 2 requirements documents? To: ipng@cmf.nrl.navy.mil Date: Sun, 10 Apr 1994 13:49:28 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 651 Status: O I've just read the chain of messages following Eric's kind posting of my CLNP requirement. This, plus my dislike of a section being named "non-goals" in the requirements draft, suggests rather strongly to me that we actually need two documents: IPng protocol requirements (this is the current document) IPng environment requirements (this is the "non goals" part of the current document, plus API stuff, plus things like the CLNP islands requirement, plus stuff we still have to think of.) You can argue, I think, that the first document is used to select the protocol, and the second one to guide the IETF through implementing it. Brian From brian@dxcoms.cern.ch Sun Apr 10 14:04:15 1994 Return-Path: brian@dxcoms.cern.ch 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 IAA01863 for ; Sun, 10 Apr 1994 08:04:30 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA19572; Sun, 10 Apr 1994 14:04:17 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA19924; Sun, 10 Apr 1994 14:04:16 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404101204.AA19924@dxcoms.cern.ch> Subject: Brian's Comment revisited To: ipng@cmf.nrl.navy.mil Date: Sun, 10 Apr 1994 14:04:15 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1664 Status: O > > Brian Carpenter is now on a week's vacation. I'm back. I can confirm that it does sometimes rain in the Pacific North West :-) Here is a modified version of the text: "It must be possible from day one to interconnect CLNP islands (which have NSAP addresses) via the IP and IPng Internet (i.e., during transition). The addressing structure of the CLNP islands is arbitrary. There is no requirement for CLNP to IPng interworking at the datagram level, and tunnelling or encapsulation is an acceptable approach" (The last clause is strictly redundant; as somebody pointed out, the word "via" is crucial.) I have actually come to agree with Frank that the convergence statement has no place being mixed in with this technical requirement. I think that the Directorate should develop a separate statement on this. If people agree with my previous suggestion that we need two documents, then convergence is a proper topic for the "environment" document. > > By asking me to post this item to the list Brian is also asking for > the group to word-smith or debate any item. Both he and I believe > that convergence between the protocols is A Good Thing (in the general > case) and an important technical requirement component of IPng (especially > vis-a-vis CLNP and possibly IPX as well). Both Brian and I feel that the > current criteria should reflect this orientation and make this requirement > be a explicit criteria to be used during our evaluation of the proposals. > Yes, but I now see it more as a constraint on the environment than on the protocol. Eric, can you draft the convergence requirement more precisely? Brian From smb@research.att.com Sun Apr 10 10:26:47 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA02036 for ; Sun, 10 Apr 1994 10:26:59 -0400 From: smb@research.att.com Message-Id: <199404101426.KAA02036@picard.cmf.nrl.navy.mil> Received: by toucan; Sun Apr 10 10:26:49 EDT 1994 To: Stephen D Crocker cc: sob@hsdndev.harvard.edu (Scott Bradner), galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Subject: Re: IPng security workshop Date: Sun, 10 Apr 94 10:26:47 EDT Status: O CNRI is fine with me. May is generally ok. I'm scheduled to for a trip May 10-12. What dates are you thinking of for the retreat? Want to do it at the beginning and have the results available for the rest of the retreat, or do it afterwards with questions and/or constraints in hand from the retreat? (My guess is it'll be more useful before, but I see pros and cons either way.) If the schedule has not yet been set, does it make sense to poll key people for availability? Steve I'll be at the Oakland conference May 16-18. I know Phil Karn will be, as well, and possibly other security folks. You're tied up the second week in May, and Interop is the first week, which I believe rules out some other folks... From crocker@tis.com Sun Apr 10 10:49:06 1994 Return-Path: crocker@tis.com Received: from relay.tis.com (firewall_user@relay.tis.com [192.94.214.100]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA02067 for ; Sun, 10 Apr 1994 10:50:46 -0400 Received: by relay.tis.com; id AA07907; Sun, 10 Apr 94 10:51:03 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma007893; Sun Apr 10 10:50:02 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA19315; Sun, 10 Apr 94 10:49:10 EDT Message-Id: <9404101449.AA19315@tis.com> To: smb@research.att.com Cc: sob@hsdndev.harvard.edu (Scott Bradner), galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Subject: Re: IPng security workshop In-Reply-To: Your message of "Sun, 10 Apr 94 10:26:47 EDT." <9404101428.AA07829@relay.tis.com> Date: Sun, 10 Apr 94 10:49:06 -0400 From: Stephen D Crocker Status: O I'm thinking seriously of trying to get out of the trip on May 10-12; I'll let you all know if I succeed. Steve From bound@zk3.dec.com Mon Apr 11 00:06:35 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA04116 for ; Mon, 11 Apr 1994 00:10:09 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA22957; Sun, 10 Apr 94 21:06:42 -0700 Received: by xirtlu.zk3.dec.com; id AA06791; Mon, 11 Apr 1994 00:06:40 -0400 Message-Id: <9404110406.AA06791@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: 2 requirements documents? In-Reply-To: Your message of "Sun, 10 Apr 94 13:49:28 +0200." <9404101149.AA19614@dxcoms.cern.ch> Date: Mon, 11 Apr 94 00:06:35 -0400 X-Mts: smtp Status: O Brian, > IPng protocol requirements (this is the current document) > IPng environment requirements (this is the "non goals" part > of the current document, plus API stuff, plus things like the > CLNP islands requirement, plus stuff we still have to think of.) >You can argue, I think, that the first document is used to select >the protocol, and the second one to guide the IETF through implementing >it. I agree with the second set of requirements. But if a proposal does not meet the envirment requirements that are needed. I think we will know that before selection. /jim From lkeiper@IETF.CNRI.Reston.VA.US Mon Apr 11 10:15:33 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA06226 for ; Mon, 11 Apr 1994 10:16:47 -0400 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa04395; 11 Apr 94 10:15 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Apr 1994 10:15:33 +0100 To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference Cc: lkeiper@cnri.reston.va.us Message-ID: <9404111015.aa04395@IETF.CNRI.Reston.VA.US> Status: O FINAL*** The names marked with an asterisk are those who have confirmed participation for the IPng teleconference sheduled for Monday, April 11, 1994 11:30 - 1:30pm EST. Please contact me with any changes @lkeiper.cnri.reston.va.us. ?J. Allard 206-936-9031? *Scott Bradner 617-495-3864* *Steve Bellovin 908-582-5886* *Jim Bound 603-465-3130* ?Ross Callon 508-436-3936? *Brian Carpenter +41 227 674 967* ?Dave Clark 617-253-6003? -Steve Coya REGRETS *Jon Crowcroft +44 713 807 296* ?John Curran 617-873-4398? *Steve Deering 415-812-4839* *Dino Farinacci 408-226-6870* *Eric Fleischman 206-957-5334* -Paul Frances REGRETS ?Daniel Karrenberg +31 205 925 065? *Frank Kastenholz 508-685-4000* ?Mark Knopper 313-741-5445? *Allison Mankin 202-404-7030* *Greg Minshall will call in* ?Paul Mockapetris 310-822-1511? *Craig Partridge 415-326-4541* *Rob Ullmann 617-693-1315* *Lixia Zhang 415-812-4415* If you need to be added to the call in progress, Please call 1-800-232-1234 or for international particpants, 516-424-3151. The call can be referenced by the confirmation number ER43333 in the orginators name, Steve Coya. Many thanks, Lois From brian@dxcoms.cern.ch Mon Apr 11 16:10:31 1994 Return-Path: brian@dxcoms.cern.ch 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 KAA06149 for ; Mon, 11 Apr 1994 10:11:09 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06397; Mon, 11 Apr 1994 16:10:31 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA24441; Mon, 11 Apr 1994 16:10:31 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404111410.AA24441@dxcoms.cern.ch> Subject: The dream ticket? To: ipng@cmf.nrl.navy.mil Date: Mon, 11 Apr 1994 16:10:31 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 556 Status: O On reflection I don't think that Turnipp is the dream ticket. It seems too easy to be true; also I like its address structure less than any of the others. Isn't this a possible dream ticket: SIPP without IPAE, but with a TUBA (or AEIOU) like transition. EON updated for SIPP to interconnect CLNP islands. TUBA and CATNIPP (note two P's) as optional interworking standards. By the way, I think we should take Noel's list of Nimrod requirements very seriously; it would be nice if the Internet could get a routing architecture some day :-) Brian From kasten@mailserv-D.ftp.com Mon Apr 11 10:50:46 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA06544 for ; Mon, 11 Apr 1994 10:51:47 -0400 Received: from ftp.com by ftp.com ; Mon, 11 Apr 1994 10:51:45 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 11 Apr 1994 10:51:45 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA29403; Mon, 11 Apr 94 10:50:46 EDT Date: Mon, 11 Apr 94 10:50:46 EDT Message-Id: <9404111450.AA29403@mailserv-D.ftp.com> To: lkeiper@IETF.CNRI.Reston.VA.US Subject: Re: IPng Teleconference From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 204 Status: O > ?Dave Clark 617-253-6003? lois i believe that dave is on vacation this week. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From bound@zk3.dec.com Mon Apr 11 11:09:24 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA06744 for ; Mon, 11 Apr 1994 11:14:21 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA05082; Mon, 11 Apr 94 08:09:34 -0700 Received: by xirtlu.zk3.dec.com; id AA24143; Mon, 11 Apr 1994 11:09:31 -0400 Message-Id: <9404111509.AA24143@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: The dream ticket? In-Reply-To: Your message of "Mon, 11 Apr 94 16:10:31 +0200." <9404111410.AA24441@dxcoms.cern.ch> Date: Mon, 11 Apr 94 11:09:24 -0400 X-Mts: smtp Status: O Brian, Isn't this a possible dream ticket: > SIPP without IPAE, but with a TUBA (or AEIOU) like transition. I do not think becauase of translation IPAE should be thrown out. That is its weak point. I also would like to see a review of the assumptions for transition. IPAE has done an extensive job in that area and can be tested against any proposal. In addition I think IPv4 compatible addresses for transition are a good idea which is proposed in IPAE and indirectly in AEIOU. TUBA has only said here use a dual stack and that is not enough data for me to parse its worth or ability to provide a transition plan. I really want to see extensive detailed technical discussion on this issue. That has not been done. > EON updated for SIPP to interconnect CLNP islands. I think we should look at GRE. > TUBA and CATNIPP (note two P's) as optional interworking standards. What does this mean technically I need more details with such a statement? >By the way, I think we should take Noel's list of Nimrod >requirements very seriously; it would be nice if the Internet >could get a routing architecture some day :-) I agree and spent the weekend with the 1MB working group archive and clearing up my understanding of NIMROD with Noel. I especially like the EID and Locator differentiation. /jim From rcallon@pobox.wellfleet.com Mon Apr 11 11:18:37 1994 Return-Path: rcallon@pobox.wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA06950 for ; Mon, 11 Apr 1994 11:25:54 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA19896; Mon, 11 Apr 94 11:07:22 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA22070; Mon, 11 Apr 94 11:18:37 EDT Date: Mon, 11 Apr 94 11:18:37 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9404111518.AA22070@pobox.wellfleet> To: lkeiper@IETF.CNRI.Reston.VA.US Subject: Re: IPng Teleconference Cc: ipng@cmf.nrl.navy.mil Status: O ?Ross Callon 508-436-3936? Well, I haven't been called yet, but I am here (I will need to leave at 1:00 sharp). Ross From mankin@cmf.nrl.navy.mil Mon Apr 11 11:32:23 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id LAA07037 for ; Mon, 11 Apr 1994 11:32:36 -0400 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id LAA12921 for ipng; Mon, 11 Apr 1994 11:32:23 -0400 Date: Mon, 11 Apr 1994 11:32:23 -0400 From: Allison J Mankin Message-Id: <199404111532.LAA12921@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: Today's conference Status: O Ross says > (I will need to leave at 1:00 sharp). Our plan is to make the conference short this time, since we are having two weeks in a row. Should go just to 12:30. From brian@dxcoms.cern.ch Mon Apr 11 17:40:12 1994 Return-Path: brian@dxcoms.cern.ch 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 LAA07134 for ; Mon, 11 Apr 1994 11:40:39 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA26580; Mon, 11 Apr 1994 17:40:14 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA26999; Mon, 11 Apr 1994 17:40:12 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404111540.AA26999@dxcoms.cern.ch> Subject: Re: The dream ticket? To: bound@zk3.dec.com Date: Mon, 11 Apr 1994 17:40:12 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <9404111509.AA24143@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Apr 11, 94 11:09:24 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: 1373 Status: O Jim, > > > SIPP without IPAE, but with a TUBA (or AEIOU) like transition. > > I do not think becauase of translation IPAE should be thrown out. That > is its weak point. I also would like to see a review of the assumptions > for transition. IPAE has done an extensive job in that area and can be > tested against any proposal. In addition I think IPv4 compatible > addresses for transition are a good idea which is proposed in IPAE and > indirectly in AEIOU. TUBA has only said here use a dual stack and that > is not enough data for me to parse its worth or ability to provide a > transition plan. I really want to see extensive detailed technical > discussion on this issue. That has not been done. > Yes, it is the translation bit of IPAE that I dislike, for reasons given in my white paper (and in the IPAE session in Seattle). There is a lot of good stuff in the IPAE transition document. The only TUBA transition that makes sense to me is where the IPv4 address is embedded in the NSAPA ID field. > > EON updated for SIPP to interconnect CLNP islands. > > I think we should look at GRE. Ignorance attack. Wot's that? > > > TUBA and CATNIPP (note two P's) as optional interworking standards. > > What does this mean technically I need more details with such a > statement? > I will think this hasty statement through and get back to you. Brian From sob@hsdndev.harvard.edu Mon Apr 11 12:13:13 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA07473 for ; Mon, 11 Apr 1994 12:13:40 -0400 Date: Mon, 11 Apr 94 12:13:13 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404111613.AA23645@hsdndev.harvard.edu> To: brian@dxcoms.cern.ch Subject: Re: The dream ticket? Cc: ipng@cmf.nrl.navy.mil Status: O > I think we should look at GRE. Ignorance attack. Wot's that? draft-hanks-gre-00.txt draft-hanks-ip-gre-00.txt Scott From ericf@atc.boeing.com Mon Apr 11 11:23:45 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA08632 for ; Mon, 11 Apr 1994 14:21:53 -0400 Received: by atc.boeing.com (5.57) id AA29690; Mon, 11 Apr 94 11:23:45 -0700 Date: Mon, 11 Apr 94 11:23:45 -0700 From: Eric Fleischman Message-Id: <9404111823.AA29690@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: Convergence Status: O Dear Brian, Welcome back. I missed your input on our discussions of the past week. This reply is concerning your request: >Yes, but I now see it more as a constraint on the environment than >on the protocol. Eric, can you draft the convergence requirement more >precisely? I don't seem to be thinking well just now, but here is a "straw man" convergence statement: We desire the selected IPng protocol to be able to technically serve as a convergence protocol from many different network layer protocols in addition to IPv4. For this reason, we require that the selected IPng protocol have adequate addressing capabilities to be able to "support" the transition addressing structures of other existing network layer protocols (e.g., IPX, CLNP) should they wish to transition to IPng. I realize that this is not perfect by a long shot, but it is certainly a statement which can be "torn apart". :-) It also has the core idea of what I am after which can be summed up as "one protocol to bind them all". Sincerely yours, --Eric Fleischman From sob@hsdndev.harvard.edu Mon Apr 11 14:49:02 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA08835 for ; Mon, 11 Apr 1994 14:49:07 -0400 Date: Mon, 11 Apr 94 14:49:02 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404111849.AA07521@hsdndev.harvard.edu> To: ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil Subject: Re: Convergence Status: O > have adequate addressing capabilities might add flexabilities Scott From bound@zk3.dec.com Mon Apr 11 23:56:53 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA11200 for ; Tue, 12 Apr 1994 00:00:38 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA24544; Mon, 11 Apr 94 20:57:01 -0700 Received: by xirtlu.zk3.dec.com; id AA11216; Mon, 11 Apr 1994 23:56:59 -0400 Message-Id: <9404120356.AA11216@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: The dream ticket? In-Reply-To: Your message of "Mon, 11 Apr 94 16:10:31 +0200." <9404111410.AA24441@dxcoms.cern.ch> Date: Mon, 11 Apr 94 23:56:53 -0400 X-Mts: smtp Status: O Brian, >By the way, I think we should take Noel's list of Nimrod >requirements very seriously; it would be nice if the Internet >could get a routing architecture some day :-) After seeing Paul's message I wanted to add that if one looks at the SIPP ROAD spec they will see the parts of PIP that extended SIPP and also EIDs and Locators in the abstract. One needs to view the SIPP Spec and Discovery to get the whole picture and then SIPP autoconfiguration spec. /jim From MAILER-DAEMON Tue Apr 12 00:30:47 1994 Return-Path: MAILER-DAEMON Received: from localhost (localhost) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with internal id AAA11434; Tue, 12 Apr 1994 00:30:47 -0400 Date: Tue, 12 Apr 1994 00:30:47 -0400 From: Mail Delivery Subsystem Subject: Returned mail: warning: cannot send message for 4 hours Message-Id: <199404120430.AAA11434@picard.cmf.nrl.navy.mil> To: ipng-request MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="AAA11434.766125047/picard.cmf.nrl.navy.mil" Status: O This is a MIME-encapsulated message --AAA11434.766125047/picard.cmf.nrl.navy.mil ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Mon, 11 Apr 1994 20:28:38 -0400 from mail.ntt.jp [192.5.216.174] ----- The following addresses had delivery problems ----- minshall@novell.com (transient failure) (expanded from: :include:/afs/cmf/users/mankin/.ipng_area_list) ----- Transcript of session follows ----- minshall@novell.com... Deferred: Connection refused by ns.novell.com. Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old ----- Original message follows ----- --AAA11434.766125047/picard.cmf.nrl.navy.mil Content-Type: message/rfc822 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id UAA10665 for ; Mon, 11 Apr 1994 20:28:38 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 12 Apr 1994 09:24:01 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA07111; Tue, 12 Apr 1994 09:24:00 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA18247; Tue, 12 Apr 94 09:24:01 JST Date: Tue, 12 Apr 94 09:24:01 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404120024.AA18247@cactus.slab.ntt.jp> To: Brian.Carpenter@cern.ch, bound@zk3.dec.com Subject: Re: The dream ticket? Cc: ipng@cmf.nrl.navy.mil > > >By the way, I think we should take Noel's list of Nimrod > >requirements very seriously; it would be nice if the Internet > >could get a routing architecture some day :-) > Dammit, we have a routing architecture. It may not have all the power of some fancy source routing architecture, but it is simple (well, as simple as it can be) and it works at some level. Surely some of you remember the long and arduous discussions that went on more than five years ago--about interior routes and exterior routes and tree topologies and mesh topologies and all kinds of things--and more than a decade ago (I wasn't around then, but I've read the paper trail) of many of the same issues debated today--hierarchical addresses and source routes and etc. The current routing architecture is not ad hoc....perhaps it's just been taken for granted.... PF --AAA11434.766125047/picard.cmf.nrl.navy.mil-- From brian@dxcoms.cern.ch Tue Apr 12 08:23:59 1994 Return-Path: brian@dxcoms.cern.ch 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 CAA11816 for ; Tue, 12 Apr 1994 02:24:26 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA15773; Tue, 12 Apr 1994 08:24:00 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13764; Tue, 12 Apr 1994 08:23:59 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404120623.AA13764@dxcoms.cern.ch> Subject: Re: The dream ticket? To: francis@cactus.slab.ntt.jp (Paul Francis) Date: Tue, 12 Apr 1994 08:23:59 +0200 (MET DST) Cc: Brian.Carpenter@cern.ch, bound@zk3.dec.com, ipng@cmf.nrl.navy.mil In-Reply-To: <9404120024.AA18247@cactus.slab.ntt.jp> from "Paul Francis" at Apr 12, 94 09:24:01 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: 1611 Status: O Paul, I didn't mean to insult the work aleady done on routing architecture. I don't mean to imply that I or anybody else could have done any better. My comment was a :-) after all. To be more specific about what I mean: the original IPv4 design certainly did not include a routing architecture. The interior/exterior design copes well with a model with a single backbone, less well with multiple backbones, and even less well when the backbones overlap geographically and organisationally. BGP4/IDRP do not fully resolve the needs of multiple providers and policy routing. So we need what Nimrod is aiming to do. Sorry if I upset you or anybody else. Brian >--------- Text sent by Paul Francis follows: > > > > > >By the way, I think we should take Noel's list of Nimrod > > >requirements very seriously; it would be nice if the Internet > > >could get a routing architecture some day :-) > > > > Dammit, we have a routing architecture. It may not have all > the power of some fancy source routing architecture, but it is > simple (well, as simple as it can be) and it works at some level. > > Surely some of you remember the long and arduous discussions that > went on more than five years ago--about interior routes and exterior > routes and tree topologies and mesh topologies and all kinds of > things--and more than a decade ago (I wasn't around then, but I've > read the paper trail) of many of the same issues debated today--hierarchical > addresses and source routes and etc. The current routing architecture > is not ad hoc....perhaps it's just been taken for granted.... > > PF > From brian@dxcoms.cern.ch Tue Apr 12 09:01:22 1994 Return-Path: brian@dxcoms.cern.ch 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 DAA11887 for ; Tue, 12 Apr 1994 03:01:56 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24326; Tue, 12 Apr 1994 09:01:24 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA14971; Tue, 12 Apr 1994 09:01:22 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404120701.AA14971@dxcoms.cern.ch> Subject: Re: The dream ticket? To: ipng@cmf.nrl.navy.mil Date: Tue, 12 Apr 1994 09:01:22 +0200 (MET DST) In-Reply-To: <9404120634.AA21822@cactus.slab.ntt.jp> from "Paul Francis" at Apr 12, 94 03:34:58 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 812 Status: O Paul, > > So we need what Nimrod is aiming to do. > > Perhaps so. I think that nimrod is overkill and that the provider selection > bit of SIPP, plus perhaps the rare usage of a longer policy route, will > handle just about everybody's needs. > Integrating this, Eric's comments on the need for geographical addressing, and the mail I just sent to big-i, I conclude that we do need both provider and geographical fields in the address format. They are orthogonal and not mutually exclusive. NSAPAs can do this of course. I can't see any reason why a SIPP address can't do it too. All you need to do is adopt a geographical interpretation of the subscriber/subnet fields - this seems to be feasible to me, and I don't see that it interferes with anything else. Well, I have to do my day job now. Brian From francis@cactus.slab.ntt.jp Tue Apr 12 09:24:01 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id UAA10665 for ; Mon, 11 Apr 1994 20:28:38 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 12 Apr 1994 09:24:01 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA07111; Tue, 12 Apr 1994 09:24:00 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA18247; Tue, 12 Apr 94 09:24:01 JST Date: Tue, 12 Apr 94 09:24:01 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404120024.AA18247@cactus.slab.ntt.jp> To: Brian.Carpenter@cern.ch, bound@zk3.dec.com Subject: Re: The dream ticket? Cc: ipng@cmf.nrl.navy.mil Status: O > > >By the way, I think we should take Noel's list of Nimrod > >requirements very seriously; it would be nice if the Internet > >could get a routing architecture some day :-) > Dammit, we have a routing architecture. It may not have all the power of some fancy source routing architecture, but it is simple (well, as simple as it can be) and it works at some level. Surely some of you remember the long and arduous discussions that went on more than five years ago--about interior routes and exterior routes and tree topologies and mesh topologies and all kinds of things--and more than a decade ago (I wasn't around then, but I've read the paper trail) of many of the same issues debated today--hierarchical addresses and source routes and etc. The current routing architecture is not ad hoc....perhaps it's just been taken for granted.... PF From brian@dxcoms.cern.ch Tue Apr 12 14:03:32 1994 Return-Path: brian@dxcoms.cern.ch 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 IAA12488 for ; Tue, 12 Apr 1994 08:03:56 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08693; Tue, 12 Apr 1994 14:03:33 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA23415; Tue, 12 Apr 1994 14:03:32 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404121203.AA23415@dxcoms.cern.ch> Subject: Re: The dream ticket? To: ipng@cmf.nrl.navy.mil Date: Tue, 12 Apr 1994 14:03:32 +0200 (MET DST) In-Reply-To: <9404120840.AA22979@cactus.slab.ntt.jp> from "Paul Francis" at Apr 12, 94 05:40:26 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1524 Status: O >--------- Text sent by Paul Francis follows: > > > > > NSAPAs can do this of course. I can't see any reason why a SIPP > > address can't do it too. All you need to do is adopt a geographical > > interpretation of the subscriber/subnet fields - this seems > > to be feasible to me, and I don't see that it interferes with anything > > else. > > SIPP's addresses were originally (back when it was SIP) had both > encodings, though it was basically geographical with provider-rooted > as an add-on. I think it's better as provider-based with geographical as an optional add-on. > Geographical was found to be problematic because it > isn't clear who has authority to assign the prefixes, how providers > would organize to create the required connectivity within geographic > areas, and so on. Exactly, hence my above comment. Delegate the authority as low as possible. Create connectivity at inter-provider level. > > An IETF BOF was held a year or more ago (by me) on this topic, with > inconclusive results (of course, but it was a fun BOF). I have a paper > in the upcoming INET conference that describes and contrasts provider- > rooted and geographic addresses. It is roughly the same content as > the I-D I did on same topic. I'd be happy to post it if folks have > any interest. > The topic is interesting but I tend to think we should defer it a few months. It doesn't seem to be a real differentiator between TUBA/CATNIP and SIPP. However I'd be glad to add your paper to my reading stack. Brian From crocker@tis.com Tue Apr 12 08:56:16 1994 Return-Path: crocker@tis.com Received: from relay.tis.com (firewall_user@relay.tis.com [192.94.214.100]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA12716 for ; Tue, 12 Apr 1994 08:57:45 -0400 Received: by relay.tis.com; id AA22117; Tue, 12 Apr 94 08:58:02 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3mjr) id sma022111; Tue Apr 12 08:57:18 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA26910; Tue, 12 Apr 94 08:56:21 EDT Message-Id: <9404121256.AA26910@tis.com> To: smb@research.att.com Cc: sob@hsdndev.harvard.edu (Scott Bradner), galvin@tis.com, ipng@cmf.nrl.navy.mil, jis@mit.edu, sandy@tis.com Subject: Re: IPng security workshop In-Reply-To: Your message of "Sun, 10 Apr 94 10:26:47 EDT." <9404101428.AA07829@relay.tis.com> Date: Tue, 12 Apr 94 08:56:16 -0400 From: Stephen D Crocker Status: O This just arrived from Robert Glenn. I notice it's addressed to tuba, ipsec and big-internets, so it might not have gotten to all of you. My apologies if it's redundant. Steve > From: glenn@osi.ncsl.nist.gov (Robert Glenn) > To: big-Internet@munnari.oz.au > cc: ipsec@ans.net, tuba@lanl.gov, glenn@osi.ncsl.nist.gov > Date: Tue, 12 Apr 1994 08:34:12 -0400 (EDT) > Subject: Re: IPng and security > > > > > There has been some recent discussion suggesting that the TUBA WG has > taken a passive view on IPng security concerns. For example, at the > SAAG meeting it was initially assumed that TUBA was going to use ISO > NLSP to provide security services. As pointed out in "TUBA as IPng: A > White Paper", we've been actively participating in the IPSEC WG to > contribute to the development of an IPv4 security protocol that > would/could also be used to provide the same security services for > CLNP, figuring that a common security protocol could only benefit the > transition from IPv4 to IPng. > > Due to the approaching July "decision point" and the lack of closure in > the IPSEC WG, I've drafted a security protocol for TUBA based on the > requirements and work that has already been accomplished by IPSEC. The > initial premise used to devise this protocol was to keep it as simple > as possible and only address those security concerns that, 1) could be > effectively addressed by a network layer security protocol, and 2) > provided protection for the areas that require security the most. By > following this approach, a secure encapsulation protocol for CLNP and > IPv4 to provide confidentiality and integrity has been drafted. As > soon as the draft is finished it will be posted as an I-D. > > From francis@cactus.slab.ntt.jp Tue Apr 12 15:34:58 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id CAA11834 for ; Tue, 12 Apr 1994 02:38:59 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 12 Apr 1994 15:34:59 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id PAA12899; Tue, 12 Apr 1994 15:34:59 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA21822; Tue, 12 Apr 94 15:34:58 JST Date: Tue, 12 Apr 94 15:34:58 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404120634.AA21822@cactus.slab.ntt.jp> To: Brian.Carpenter@cern.ch, francis@dxcoms.cern.ch Subject: Re: The dream ticket? Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Status: O > > Paul, I didn't mean to insult the work aleady done on routing > architecture. I don't mean to imply that I or anybody else > could have done any better. My comment was a :-) after all. Probably I owe you an apology. I saw your smiley face but responded as though there wasn't one. If we were in person, I would have used mad words in a not-mad tone of voice, which I don't know how to portray in text. > > To be more specific about what I mean: the original IPv4 design certainly > did not include a routing architecture. The interior/exterior design But this is what I disagree with. I think the original architects had a very good idea of how far their model would take them.... > copes well with a model with a single backbone, less well with > multiple backbones, and even less well when the backbones overlap > geographically and organisationally. BGP4/IDRP do not fully resolve > the needs of multiple providers and policy routing. > So we need what Nimrod is aiming to do. Perhaps so. I think that nimrod is overkill and that the provider selection bit of SIPP, plus perhaps the rare usage of a longer policy route, will handle just about everybody's needs. To tell you the truth, I generally see (to the extent that I follow it) on the nimrod mailing list rehashes of discussions I was involved in 5 years ago at (of all places) ANSI meetings. This isn't to say that the discussions on nimrod aren't useful--the topic has to be revisited in light of current usage. I am just rather skeptical about what nimrod will give us..... PF From francis@cactus.slab.ntt.jp Tue Apr 12 17:40:26 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id EAA12095 for ; Tue, 12 Apr 1994 04:40:57 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Tue, 12 Apr 1994 17:40:26 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id RAA14577; Tue, 12 Apr 1994 17:40:26 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA22979; Tue, 12 Apr 94 17:40:26 JST Date: Tue, 12 Apr 94 17:40:26 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404120840.AA22979@cactus.slab.ntt.jp> To: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: The dream ticket? Status: O > > NSAPAs can do this of course. I can't see any reason why a SIPP > address can't do it too. All you need to do is adopt a geographical > interpretation of the subscriber/subnet fields - this seems > to be feasible to me, and I don't see that it interferes with anything > else. SIPP's addresses were originally (back when it was SIP) had both encodings, though it was basically geographical with provider-rooted as an add-on. Geographical was found to be problematic because it isn't clear who has authority to assign the prefixes, how providers would organize to create the required connectivity within geographic areas, and so on. An IETF BOF was held a year or more ago (by me) on this topic, with inconclusive results (of course, but it was a fun BOF). I have a paper in the upcoming INET conference that describes and contrasts provider- rooted and geographic addresses. It is roughly the same content as the I-D I did on same topic. I'd be happy to post it if folks have any interest. PF From mark.taylor@airdata.com Wed Apr 13 10:18:41 1994 Return-Path: mark.taylor@airdata.com Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA22202 for ; Wed, 13 Apr 1994 14:03:02 -0400 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA02526; Wed, 13 Apr 1994 14:06:26 -0400 Received: from nwestmail by airdata.com (5.0/SMI-4.1) id AA11586; Wed, 13 Apr 94 11:02:20 PDT Received: from wddmacpo.nwest.airdata.com (wddmacsmtp.nwest.airdata.com) by nwestmail (5.0/McCaw Wireless SUN-RMR Mailer, SMI-4.1) id AA17500; Wed, 13 Apr 94 11:02:16 PDT Message-Id: <9404131802.AA17500@nwestmail> Date: 13 Apr 1994 10:18:41 U From: "Mark Taylor" Subject: FW: Mark's IPng - location To: gary_roshak@pactel.com, ipng-wp@harvard.edu, mankin@cmf.nrl.navy.mil, mohsen@neda.com, Radia_Perlman@novell.com, ROBERT.W.BRENNER@gte.sprint.com, sob@harvard.edu, "William Waung" Cc: "Brian Bailey" , "Chris Yonlick" , "Dave Deutschman" , "Jeff Brown" , "Larry Corvari" , mark.taylor@airdata.com, "Rayna Liekweg" , "Thomas Trinneer" , dan.cruz@airdata.com, dave.brandos@airdata.com, mary.jesse@airdata.com, paul.stolarski@airdata.com, rob.mechaley@airdata.com Content-Length: 7094 Status: O Folks: Here is our white paper submitted to the IETF IPng area in response to RFC 1550. Mark Taylor ---Cut Here---- INTERNET-DRAFT Mark S. Taylor CDPD Consortium April, 1994 A cellular industry view of IPng Status of this Memo: This document was submitted to the IETF IPng area in response to RFC 1550 Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract: This memo is a response to RFC 1550, IP: Next Generation (IPng) White Paper Solicitation. The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cellular industry, the Cellular Digital Packet Data (CDPD) consortium of service providers or any of its constituent companies. #012# INTERNET-DRAFT A cellular industry view of IPng April, 1994 Introduction This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers. As the leading service providers for this nascent technology, which will provide the capability for mobility of native mainstream connectionless network layer-based applications it is our intention to support whatever form IPng takes. However, there are several requirements which we feel IPng must meet. Mobility Since we will offer mobile services, our primary requirement is that IPng not inhibit our support of mobility. IPng must not impede devices from being able to operate anywhere anytime. Applications on these mobile devices must look and feel the same to the user regardless of location. NPDUs should be self-contained and not disallow the redirection inherent to our mobility solution, i.e., IPng must be connectionless. Further, since IPng provides an opportunity for design enhancements above and beyond IPv4, we propose that native support for mobility be regarded as an explicit IPng requirement. Local area and wide area wireless technology creates new opportunities for both TCP/IP and the Internet. Although the capability for mobility is orthogonal to the wired or wireless nature of the data link in use, the rapid deployment wireless technology amplifies the requirement for topological flexibility. As a by-product of mobility, the significance of "occasionally-connected hosts" increases. The ability to accommodate occasionally-connected hosts in IPng is a requirement. Scale In terms of scale, we envision some 20 to 40 million users by the year 2007. In this context a "user" can be anything from a vending machine to a "road warrior". These numbers are for North America alone. Worldwide, we anticipate that IPng should be able to support billions of "users". Of course, the sparseness of network address assignments which is necessary for subnetting, etc., dictates that IPng should support at least tens or hundreds of billions of addresses. Addressing In terms of addressing, we would expect addresses to be hierarchical. In addition, a node with multiple links should require only a single address although more than one address should also be possible. The mapping of names to addresses should be independent of location; an address should be an address, not a route. Variable-length addressing is also required to Mark S. Taylor [Page 2] #012# INTERNET-DRAFT A cellular industry view of IPng April, 1994 ensure continued protocol (IPng) extensibility. Administration of address assignments should be distributed and not centralized as it is now. Security IPng should also support security mechanisms which will grow increasingly important on the proverbial "information highway" for commercial users. Security services which may optionally be expected from a Layer 3 entity such as IPng include peer entity authentication, data confidentiality, traffic flow confidentiality, data integrity and location confidentiality. Accounting The ability to do accounting at Layer 3 is a requirement. The CDPD specification can be used as a model of the type of accounting services that we need. Route Selection In the voice communications arena, "equal access" and choice of an "interexchange carrier (IXC)" are issues that must be addressed. Similar requirements for data may also exist. Source- and policy-based routing for inter-domain traffic can address this requirement. IPng must allow the selection of at least the first transient network service provider based on the source host. Data Efficiency The bandwidth of wide area wireless networks is a precious resource, the use of which must be optimized. IPng must allow optimal use of the underlying Layer 2 medium. Layer 3 Protocol Control Information (PCI) should be as condensed as possible. The protocol should be optimized for data efficiency. Packet prioritization must also be supported by IPng in order to optimize the use of low speed networks. This requirement includes both class and grade of service definitions for flexibility. Transition The final requirement for IPng is that it must interoperate with IP for the foreseeable future. Bridging mechanisms must be supported and a strategy for the transition from IPv4 to IPng must be defined. Use of options fields, etc., are one mechanism to support the requirement for IPng protocols to support IP addresses and headers. Mark S. Taylor [Page 3] #012# INTERNET-DRAFT A cellular industry view of IPng April, 1994 Author's Address: Mark S. Taylor Director of System Development McCaw Cellular Communications, Inc. Wireless Data Division 10230 NE Points Drive Kirkland, WA 98033-7869 USA email: mark.s.taylor@airdata.com Mark S. Taylor [Page 4] From mark.taylor@airdata.com Wed Apr 13 10:18:41 1994 Return-Path: mark.taylor@airdata.com Received: from airdata.com (nwestwall.airdata.com [141.204.13.59]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA22213 for ; Wed, 13 Apr 1994 14:03:23 -0400 Received: from nwestmail by airdata.com (5.0/SMI-4.1) id AA11586; Wed, 13 Apr 94 11:02:20 PDT Received: from wddmacpo.nwest.airdata.com (wddmacsmtp.nwest.airdata.com) by nwestmail (5.0/McCaw Wireless SUN-RMR Mailer, SMI-4.1) id AA17500; Wed, 13 Apr 94 11:02:16 PDT Message-Id: <9404131802.AA17500@nwestmail> Date: 13 Apr 1994 10:18:41 U From: "Mark Taylor" Subject: FW: Mark's IPng - location To: gary_roshak@pactel.com, ipng-wp@harvard.edu, mankin@cmf.nrl.navy.mil, mohsen@neda.com, Radia_Perlman@novell.com, ROBERT.W.BRENNER@gte.sprint.com, sob@harvard.edu, "William Waung" Cc: "Brian Bailey" , "Chris Yonlick" , "Dave Deutschman" , "Jeff Brown" , "Larry Corvari" , mark.taylor@airdata.com, "Rayna Liekweg" , "Thomas Trinneer" , dan.cruz@airdata.com, dave.brandos@airdata.com, mary.jesse@airdata.com, paul.stolarski@airdata.com, rob.mechaley@airdata.com Content-Length: 7094 Status: O Folks: Here is our white paper submitted to the IETF IPng area in response to RFC 1550. Mark Taylor ---Cut Here---- INTERNET-DRAFT Mark S. Taylor CDPD Consortium April, 1994 A cellular industry view of IPng Status of this Memo: This document was submitted to the IETF IPng area in response to RFC 1550 Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract: This memo is a response to RFC 1550, IP: Next Generation (IPng) White Paper Solicitation. The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cellular industry, the Cellular Digital Packet Data (CDPD) consortium of service providers or any of its constituent companies. #012# INTERNET-DRAFT A cellular industry view of IPng April, 1994 Introduction This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers. As the leading service providers for this nascent technology, which will provide the capability for mobility of native mainstream connectionless network layer-based applications it is our intention to support whatever form IPng takes. However, there are several requirements which we feel IPng must meet. Mobility Since we will offer mobile services, our primary requirement is that IPng not inhibit our support of mobility. IPng must not impede devices from being able to operate anywhere anytime. Applications on these mobile devices must look and feel the same to the user regardless of location. NPDUs should be self-contained and not disallow the redirection inherent to our mobility solution, i.e., IPng must be connectionless. Further, since IPng provides an opportunity for design enhancements above and beyond IPv4, we propose that native support for mobility be regarded as an explicit IPng requirement. Local area and wide area wireless technology creates new opportunities for both TCP/IP and the Internet. Although the capability for mobility is orthogonal to the wired or wireless nature of the data link in use, the rapid deployment wireless technology amplifies the requirement for topological flexibility. As a by-product of mobility, the significance of "occasionally-connected hosts" increases. The ability to accommodate occasionally-connected hosts in IPng is a requirement. Scale In terms of scale, we envision some 20 to 40 million users by the year 2007. In this context a "user" can be anything from a vending machine to a "road warrior". These numbers are for North America alone. Worldwide, we anticipate that IPng should be able to support billions of "users". Of course, the sparseness of network address assignments which is necessary for subnetting, etc., dictates that IPng should support at least tens or hundreds of billions of addresses. Addressing In terms of addressing, we would expect addresses to be hierarchical. In addition, a node with multiple links should require only a single address although more than one address should also be possible. The mapping of names to addresses should be independent of location; an address should be an address, not a route. Variable-length addressing is also required to Mark S. Taylor [Page 2] #012# INTERNET-DRAFT A cellular industry view of IPng April, 1994 ensure continued protocol (IPng) extensibility. Administration of address assignments should be distributed and not centralized as it is now. Security IPng should also support security mechanisms which will grow increasingly important on the proverbial "information highway" for commercial users. Security services which may optionally be expected from a Layer 3 entity such as IPng include peer entity authentication, data confidentiality, traffic flow confidentiality, data integrity and location confidentiality. Accounting The ability to do accounting at Layer 3 is a requirement. The CDPD specification can be used as a model of the type of accounting services that we need. Route Selection In the voice communications arena, "equal access" and choice of an "interexchange carrier (IXC)" are issues that must be addressed. Similar requirements for data may also exist. Source- and policy-based routing for inter-domain traffic can address this requirement. IPng must allow the selection of at least the first transient network service provider based on the source host. Data Efficiency The bandwidth of wide area wireless networks is a precious resource, the use of which must be optimized. IPng must allow optimal use of the underlying Layer 2 medium. Layer 3 Protocol Control Information (PCI) should be as condensed as possible. The protocol should be optimized for data efficiency. Packet prioritization must also be supported by IPng in order to optimize the use of low speed networks. This requirement includes both class and grade of service definitions for flexibility. Transition The final requirement for IPng is that it must interoperate with IP for the foreseeable future. Bridging mechanisms must be supported and a strategy for the transition from IPv4 to IPng must be defined. Use of options fields, etc., are one mechanism to support the requirement for IPng protocols to support IP addresses and headers. Mark S. Taylor [Page 3] #012# INTERNET-DRAFT A cellular industry view of IPng April, 1994 Author's Address: Mark S. Taylor Director of System Development McCaw Cellular Communications, Inc. Wireless Data Division 10230 NE Points Drive Kirkland, WA 98033-7869 USA email: mark.s.taylor@airdata.com Mark S. Taylor [Page 4] From bound@zk3.dec.com Tue Apr 12 23:10:27 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA18553 for ; Tue, 12 Apr 1994 23:20:01 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94) id AA29296; Tue, 12 Apr 94 20:11:56 -0700 Received: by xirtlu.zk3.dec.com; id AA11595; Tue, 12 Apr 1994 23:10:34 -0400 Message-Id: <9404130310.AA11595@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Good Example of the Detailed Standards work on APIs fyi Date: Tue, 12 Apr 94 23:10:27 -0400 X-Mts: smtp Status: O ------- Forwarded Message Return-Path: us2rmc::jak@mentat.com Received: by xirtlu.zk3.dec.com; id AA05195; Tue, 12 Apr 1994 16:06:17 -0400 Date: Tue, 12 Apr 1994 16:06:17 -0400 Message-Id: <9404122006.AA05195@xirtlu.zk3.dec.com> From: us2rmc::jak@mentat.com (Jim Krupp) To: xoxti@xopen.co.uk Subject: (XoXTI 433) in.h and xti.h conflicts In reviewing the latest POSIX 1003.12 draft, I came across references to in.h and xti.h header files which seem not to address problems we are currently experiencing. These are: 1. Symbols appear in both in.h and xti.h. 2. Symbols in xti.h (in.h) are given values which have a different symbol defined in in.h (xti.h). 3. POSIX (at least) requires both of these files and makes no statement about what the defined values should be. 4. A TCP STREAMS module wishing to support both socket and XTI semantics needs both of these files. These problems all occur with symbols related to option management (surprise!) Additional name collisions occur with SO_xxx names used for get[set]sockopt() under sockets. I am sure these problems have been addressed (and resolved?) Am I missing something obvious? It is currently impossible to use the published xti.h with in.h as found on several existing UNIX SVR4 systems. Note that binary compatibility constraints with existing in.h/socket.h files makes changing code in these files impractical. Comments? Help? Thanks in advance. - ------------------------------------------------------------------------ Jim Krupp Mentat Inc. jak@mentat.com 1145 Gayley Ave, Suite 315 voice: (310)208-2650, ext 23 Los Angeles, CA 90024 fax: (310)208-3724 USA - ------------------------------------------------------------------------ % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from inet-gw-3.pa.dec.com by us2rmc.bb.dec.com (5.65/rmc-22feb94) id AA16747; Tue, 12 Apr 94 16:02:53 -040 % Received: from xopen.xopen.co.uk by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA01766; Tue, 12 Apr 94 13:04:16 -070 % Received: by xopen.xopen.co.uk (1.36.108.3/15.6) id AA19324; Tue, 12 Apr 94 20:41:57 +010 % Received: from leo.mentat.com ([192.88.122.132]) by mentat.com (4.1/SMI-4.1) id AA12932; Tue, 12 Apr 94 12:41:31 PD % Date: Tue, 12 Apr 94 12:41:31 PDT % From: jak@mentat.com (Jim Krupp) % Message-Id: <9404121941.AA12932@mentat.com> % To: xoxti@xopen.co.uk % Subject: (XoXTI 433) in.h and xti.h conflicts % Sender: XoXTI-request@xopen.co.uk % Comments: (XoXTI 433) ------- End of Forwarded Message From sob@hsdndev.harvard.edu Wed Apr 13 10:03:32 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA20668 for ; Wed, 13 Apr 1994 10:03:37 -0400 Date: Wed, 13 Apr 94 10:03:32 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404131403.AA06122@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: fyi Status: O >From J.Houldsworth@ste0906.wins.icl.co.uk Wed Apr 13 09:18:29 1994 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA29613; Wed, 13 Apr 1994 09:21:38 -0400 X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=GB/; Relayed; Wed, 13 Apr 1994 14:16:36 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Wed, 13 Apr 1994 14:07:43 +0100 Date: Wed, 13 Apr 1994 14:07:43 +0100 X400-Originator: J.Houldsworth@ste0906.wins.icl.co.uk X400-Recipients: sob@harvard.edu X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700002616] Original-Encoded-Information-Types: ia5 text (2),undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 2616 From: J.Houldsworth@ste0906.wins.icl.co.uk Message-Id: <"2616*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: sob@harvard.edu In-Reply-To: <9404111604.AA01141@WC.Novell.COM> Subject: What have/are NSAPs allocated for? Status: R ------------------------------ Start of body part 1 Here is some general info. on NSAPs which I sent to Greg Minshall on his request. Perhaps others in the IPng group would be interested in this background because I think that there is a general perception that NSAPs are specific to the CLNP protocol and, hence, the TUBA option. Jack Houldsworth ------------------------------ Start of body part 2 Specimen NSAP Allocations The Initial Domain Part (IDP) is split into Authority and Format Identifier (AFI) followed by the Initial Domain Identifier (IDI). This combination is followed by the Domain Specific Part and allocation in that bit is domain specific. The following should give you an inkling of current allocations: ISO DCC Scheme AFI = decimal 38 or binary 39 = ISO Data Country Code Scheme. ADI = 3 decimal or binary digits specifying the country. ISO allocate the country codes. The DSP is administered by the standards authority for that country. In the UK, British Standards have delegated administration to the Electronic Industries Association but that's only because they volunteered! The UK DSP is split into a single digit UK Format Indicator (UKFI) which indicates large, medium or small organisation rather like IP addressing and a UK Domain Identifier (UKDI). Using decimal examples only (there are binary equivalents UKFI = 0 is reserved UKFI = 1, UKDI = nnn, UK Domain Specific Part = 31 digits. UKFI = 2, UKDI = nnnnn, UKDSP = 29 digits max. UKFI = 3, UKDI = nnnnnnnn, UKDSP = 26 digits max. UKFI = 4 to 9 reserved (so there are plenty of options left!) The UK Government have, of course been allocated a UKDI in the UKFI = 1 (large organisation) format and have specified a breakdown of the Government Domain Specific Part with sub domain addresses followed by a station ID (which could be a MAC address) and a selector (which could be a TSAP selection). ITU-T X.121 AFI = decimal 36 or 52, binary 37 or 53 indicates that the IDI is a 14 digit max X.121 International Numbering Plan address (prefix, 3 digit Data Country Code, dial up data network number). The full X.121 address indicates who controls the formatting of the DSP. ITU-T F.69 AFI = 40,54 or binary 41,55 indicates that the IDI is a telex number up to 8 digits long. ITU-T E.163 AFI = 42,56 or binary 43,57 indicates that the IDI is a normal telephone number up to 12 digits long. ITU-T E.164 AFI = 44,58 or binary 45,59 indicates that the IDI is an ISDN number up to 15 digits long. ISO 6523-ICD AFI = 46 or binary 47 indicates that the IDI is an International Code Designator allocated according to ISO 6523. You have to be a global organisation to get one of these. The Organisation to which the ISO 6523 designator is issued specifies the DSP allocation. Feasible for Internet to get one and then you can specify the allocation of the DSP where DSP = Internet. However, there may be better ways of skinning the cat. You should shoot for a primary AFI allocation like the others. Shouldn't be a problem. There is more but this should give you the gist of things. Jack ------------------------------ End of body part 2 From scoya@CNRI.Reston.VA.US Wed Apr 13 14:11:59 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA22307 for ; Wed, 13 Apr 1994 14:12:48 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08751; 13 Apr 94 14:12 EDT To: ipng@cmf.nrl.navy.mil Subject: Retransmission of March 14 Minutes Date: Wed, 13 Apr 94 14:11:59 -0400 From: Steve Coya Message-ID: <9404131412.aa08751@IETF.CNRI.Reston.VA.US> Status: O DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference March 14, 1993 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES --------- Scott Bradner / Harvard Allison Mankin / NRL Steve Bellovin / AT&T Jim Bound / DEC Ross Callon / Wellfleet Brian Carpenter / CERN Jon Crowcroft / UCL John Curran / NEARnet Dino Farinacci / Cisco Eric Fleischman / Boeing Frank Kastenholz / FTP Mark Knopper / Ameritech Paul Mockapetris / ISI Craig Partridge / BBN Lixia Zhang / Xerox PARC Regrets ------- J Allard / Microsoft Dave Clark / MIT Steve Deering /Xerox PARC Paul Francis / NTT Daniel Karrenberg / RIPE Greg Minshall / Novell Rob Ullmann / Lotus 1. The minutes from the January 25 meeting (held over the MBone) were approved. Coya to place in public Shadow directories. 2. The minutes from the February 14 Teleconference were approved. Coya to place in the public Shadow directories. 3. Craig Partridge invited everyone to the second integrated services bof meeting during the Seattle IETF meeting, which will be discussing integrated service requirements for IPNG. 4. The potential impact on the directorate of the IAB/IESG Nominating Committe results were discussed, noting the original restriction that no IAB or IESG members would sit on the IPNG Directorate. A number of people voiced the opinion that the affected folks be permitted to stay (grandfathered). The consensus was that this question be brought up to the full IETF plenary during the Monday morning session at Seattle. 5. Scott reviewed the status of the white paper reviews. Will be drafting a disclaimer to be used and will send to the IPNG Directorate for review. 6. Frank reminded everyone that the March 10 version is the document that should be reviewed. Frank reviewed some of the document changes being added, and will include a change log in subsequent versions of the document. The directorate then discussed various sections of the document, offering comments and suggestions. It was reiterated that this document will eventually become the IPNG Directorate Requirements document, and that the White Paper submissions will be reviewed against it. It was suggested that the requirements document needs to be reviewed on a "line-by-line (or item-by-item)" basis by the entire directorate prior to the Seattle meeting. The only real option is the teleconfernce scheduled for March 21. The current version of the document criteria.txt, can be retrieved from research.ftp.com in the pub/ip7reqs directory. From scoya@CNRI.Reston.VA.US Wed Apr 13 14:13:08 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA22349 for ; Wed, 13 Apr 1994 14:15:36 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08807; 13 Apr 94 14:13 EDT To: ipng@cmf.nrl.navy.mil Subject: Retransmission of march 21 minutes Date: Wed, 13 Apr 94 14:13:08 -0400 From: Steve Coya Message-ID: <9404131413.aa08807@IETF.CNRI.Reston.VA.US> Status: O DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference March 21, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES --------- Scott Bradner / Harvard Allison Mankin / NRL J Allard / Microsoft Jim Bound / DEC Dave Clark / MIT Eric Fleischman / Boeing Frank Kastenholz / FTP Greg Minshall / Novell Paul Mockapetris / ISI Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets ------- Steve Bellovin / AT&T Ross Callon / Wellfleet Brian Carpenter / CERN Jon Crowcroft / UCL John Curran / NEARnet Steve Deering / Xerox PARC Dino Farinacci / Cisco Paul Francis / NTT Daniel Karrenberg / RIPE Mark Knopper / Ameritech Craig Partridge / BBN 1. Scott and Allison will attempt to organize a dinner for the IPNG Directorate members on Thursday, following the IESG Plenary, during the Seattle IETF meeting. 2. The list of IPNG presentations that are to take place Monday morning in Seattle were reviewed. The breakdown is as follows: a. Allison and Scott - IPNG status b. Dave Clark - status of the External Review Panel c. Frank Solensky - Report from the ALE WG d. Jon Crowcroft and/or Frank Kastenholz - Report on the IPNG Requirements document 3. Coya to prepare an IPNG track for Seattle and send to Scott and Allison. Coya to send message to the IPNG list soliciting the formal set of documents from each of the groups. 4. The text of the disclaimer written by Allison and Scott, which is to be included in IPNG documents, was read to the directorate. No requests for changes were made. 5. Allison conducted a full review of the Criteria section of the requirements document. Request changes include: a. In the section on scale, the phrase "up to" should be replaced with "at least" A notation that "another 3 orders of magnitude might be needed" will be added. b. All references to the big-internet list should include the list address. c. In the discussion on scale, change "whole purpose" to "initial motivating purpose" d. Replace "very very very" by "extremely" It was mentioned " the diameter of Internet will grow very very very large.." and that to scale might require a hierarchy in network topology, and for a global system, there is a requirement for guidance in topological engineering. e. The character string to use is IPng, not IP:NG. f. The requirement that multiple IPNG protocols co-exist needs to be reworded as there will only be one (1) IPNG protocol. Will be reworded to require that multiple versions of IPNG need to co-exist on the network. g. On the section on Media, expand "VJ-like" to "Van Jacobson-like" h. It was requested that the requirements include "the ability to send an IP datagram as large as allowed by the inter-network layer (assuming, of course, that the recipient is able to accept a datagram that large). The topic of fragmentation was raised, but discussion was deferred. i. In the section on Configuration, Admin, and OPS, it should be added that "nothing in the proposal should inhibit a future requirement for auto registration." j. It was suggested that the IAB report from the Security W/S might provide text for the security section of the requirements document. Coya to send to the IPNG list, Kastenholz to review. k. In the section on unique naming, use the phrase "multicast addresses" l. In the section on extensibility, reiterate the need to run multiple versions on IPNG over the same wire. m. In the section on non-goals, it was suggested that the section on IPv4 and IPng Communication be removed as it was not needed in the requirements document. It was suggested that the discussion on fragmentation should mention the experience with IPv4 fragmentation (i.e. negative impact on network performance). n. Might be able to incorporate some ideas, concepts and text from the IAB report or the recently published RFC on Firewall in the section on Firewalls in the requirements document. o. There is a need to clarify what is meant by "accounting" in the section on non-goals. Kastenholz will reword. p. In the section on robust service, it was stated that host performance should not decrease (below the level of IPv4), and that the protocol should not, due to its complexity or other features, increase the liklihood of poor implementation on host platforms, especially with respect to performance. From brian@dxcoms.cern.ch Thu Apr 14 13:31:29 1994 Return-Path: brian@dxcoms.cern.ch 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 HAA27468 for ; Thu, 14 Apr 1994 07:32:03 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23962; Thu, 14 Apr 1994 13:31:30 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28876; Thu, 14 Apr 1994 13:31:29 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404141131.AA28876@dxcoms.cern.ch> Subject: Re: Convergence To: ipng@cmf.nrl.navy.mil Date: Thu, 14 Apr 1994 13:31:29 +0200 (MET DST) In-Reply-To: <9404111823.AA29690@atc.boeing.com> from "Eric Fleischman" at Apr 11, 94 11:23:45 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: 1301 Status: O Eric, It took a couple of days to get to this: > > We desire the selected IPng protocol to be able to technically serve > as a convergence protocol from many different network layer protocols > in addition to IPv4. For this reason, we require that the selected > IPng protocol have adequate addressing capabilities to be able to > "support" the transition addressing structures of other existing network > layer protocols (e.g., IPX, CLNP) should they wish to transition to IPng. > If I remember my OSIese, a convergence sublayer protocol is the shim inserted between two layers to make them fit (e.g. the CONS convergence sublayer that allows you to layer COTS over X.25). Was it in fact this highly technical meaning of "convergence" that Jack Houldsworth meant, or was he speaking generically? In any case, I think the above text needs a slight change to avoid this interpretation. I suggest * as a protocol to which many different network layer protocols, not only * IPv4, can converge. For this reason, we require that the selected Do we have to add anything about functionality? The CATNIP analysis seems to show that the functionalities are more or less equivalent anyway. However we could add * IPng should not lack any significant functionality of such existing * protocols. Brian From brian@dxcoms.cern.ch Thu Apr 14 13:36:03 1994 Return-Path: brian@dxcoms.cern.ch 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 HAA27483 for ; Thu, 14 Apr 1994 07:36:27 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24967; Thu, 14 Apr 1994 13:36:04 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28933; Thu, 14 Apr 1994 13:36:03 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404141136.AA28933@dxcoms.cern.ch> Subject: 2 requirements documents? (fwd) To: ipng@cmf.nrl.navy.mil Date: Thu, 14 Apr 1994 13:36:03 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 398 Status: O I didn't get much response to the suggestion that we need a second document: > > IPng environment requirements (this is the "non goals" part > of the current document, plus API stuff, plus things like the > CLNP islands requirement, plus stuff we still have to think of.) > Do people want this? I can start building a framework for it as a background job, but not if it is unwanted. Brian From sob@hsdndev.harvard.edu Thu Apr 14 08:11:48 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA27643 for ; Thu, 14 Apr 1994 08:11:56 -0400 Date: Thu, 14 Apr 94 08:11:48 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404141211.AA15671@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: CLNP migration Status: O fyi - from Jack REQUIREMENTS FOR IPng As discussed in Seattle, the IT community requires a migration route from both IP and CLNP to IPng whatever the decision turns out to be and this should be taken into account in the decision process - at least in transition planning, at best when making the fundamental choice. If a migration route from CLNP to IPng exists, there is a chance of persuading ISO/IEC that IPng is a sensible common goal for the future network layer for OSI. There is also a chance that they could put in place migration from Transport Class 4 to TCP. Clearly, it would be suicidal for ISO to do either of these things if transition is not possible. Transition from CLNP to IPng could enrich the Internet Protocol Suite by adding OSI applications to the IPS portfolio in due course. Market forces would determine which OSI applications survived. Transition capability would convince the European GOSIP organisations, which are currently against including TCP/IP in mandatory procurement, that including TCP/IP is not a threat which will condemn them to permanent dual stacking and they may relent. With a route forward to IPng, all the CLNP LAN traffic, a lot of which currently runs over X.25, becomes potential internet traffic. The ideal solution is TUBA, which has a guaranteed transition route, but perhaps the key factor is the adoption of NSAP addressing. It is hard to see a clear migration route from CLNP without it. Is everyone aware that NSAPs are used by both ITU-T and ISO/IEC and cover data, telephone, TELEX etc. Remember, TUBA would be under Internet change control and not an ISO standard. Therefore, it does not represent capitulation. It is also well tried and tested. It would be a pity to force the IT world towards a protocol which does not have a long testing history - you have to get it right this 'last time'. Regards Jack From kasten@mailserv-D.ftp.com Thu Apr 14 09:12:42 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA28174 for ; Thu, 14 Apr 1994 09:13:42 -0400 Received: from ftp.com by ftp.com ; Thu, 14 Apr 1994 09:13:40 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 14 Apr 1994 09:13:40 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA29835; Thu, 14 Apr 94 09:12:42 EDT Date: Thu, 14 Apr 94 09:12:42 EDT Message-Id: <9404141312.AA29835@mailserv-D.ftp.com> To: sob@hsdndev.harvard.edu Subject: Re: CLNP migration From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 8167 Status: O > > fyi - from Jack Presumably Houldsworth? In general, I am against including anything along the lines of transition from CLNP. I feel that we as the IETF, should concern ourselves with standardizing on and for our own, Internet protocols and technologies. I believe that when we (the IETF) get involved with using other standards the possibilities for 'disagreement' and 'confrontation' are extraordinarily high (I have been burned twice here). I would rather that we, the IETF, stick to developing protocols and technologies for the Internet. I do not see things like IP over as falling in this category since we are not taking the other standard and incorporating it in our work. If the Internet grows and prospers, then that should be reason enough for the CLNP islands of the world to 'bite the bullet' and change to the Internet protocols. I view this as a very high bar over which we, the Internet Protocol Community, must jump in that it is up to us to develop a network infrastructure and protocol family for which there are such tremendous benefits of 'joining' that the costs of these transitions are well worth the benefit of being a part of the community. If there are not plain, obvious, and significant benefits to using the Internet protocols and joining the Internet then I do not see the real 'benefit' of migrating to IP(ng or not) -- why not migrate to CLNP (or CLNPng)? I understand and sympathize with the needs of operators to try and reduce the administrative and operational burdens of a multi-protocol environment. I have two comments to make in this area: 1. I imagine that the big win in doing this reduction will not come by providing a way for CLNP systems to migrate to IP. The big win will come if Novell migrates to IP. Every time I look at the 'number of nodes in the world running protocol X' I find that Netware is #1 by far, followed by TCP/IP. If Netware can be moved to IP then the win for multi-protocol shops will be much greater. 2. The need to run multi-protocol shops will never go away. We could reasonably argue, today, that TCP/IP is the 'protocol of choice'. However, we find that there are still systems out there which run something else. The cost of change is simply too high. It might be because the installed base is huge (e.g. netware, though I believe that Novell are biting the bullet on this one and will change to IP), or because the payback of change is too small -- that is, legacy systems. These latter systems will never change, they will always be there and people will always have to deal with them. Now, finally, I do not see development of a migration path from CLNP as 'evil' or something to be avoided. I see it as something that simply is not needed for an Internet Protocol and, therefore, is not something that should be in a requirements document for an Internet Protocol. The Directorate can develop their own, broader, set of requirements which may include something like a CLNP Migration Path. However, I see the document that Craig and I are writing as requirements for a protocol for The Internet and I do not see that a CLNP Migration Path is necessary for a protocol for The Internet. Others, presumably, will have differing opinions and all I can say is that we will have to agree to disagree. > If a migration route from CLNP to IPng exists, there is a > chance of persuading ISO/IEC that IPng is a sensible common > goal for the future network layer for OSI. There is also a > chance that they could put in place migration from Transport > Class 4 to TCP. Clearly, it would be suicidal for ISO to do > either of these things if transition is not possible. Does RFC1006(?) meet these needs? Presumably some bright person, if s/he saw the need, would write RFC1006ng.... > Transition from CLNP to IPng could enrich the Internet > Protocol Suite by adding OSI applications to the IPS > portfolio in due course. Market forces would determine > which OSI applications survived. There are some people who see this as a strong reason to specifically not develop CLNP migration -- in fact, they may claim that we should be CLNP-Hostile... I do not see that bringing OSI applications into the Internet as a major 'carrot' for us. There have been things like RFC1006 and ISODE that have let people do this for a long time, and none have caught on. I do not have the 'CLNP-Hostile' attitude, but I also do not see a compelling reason for us to go out of our way to be 'CLNP-Friendly' in order to bring ISO applications into the Internet either -- I guess I am 'CLNP-Neutral' :-) > Transition capability would convince the European GOSIP > organisations, which are currently against including TCP/IP > in mandatory procurement, that including TCP/IP is not a > threat which will condemn them to permanent dual stacking > and they may relent. The US GOSIP is changing to recognize that IP is the protocol of choice today. Surely the European GOSIP people can do the same thing. I do not see any reason why the Internet should cater to people who are not entirely within this space-time continuum. > The ideal solution is TUBA, which has a guaranteed > transition route, but perhaps the key factor is the adoption > of NSAP addressing. It is hard to see a clear migration > route from CLNP without it. Is everyone aware that NSAPs > are used by both ITU-T and ISO/IEC and cover data, > telephone, TELEX etc. I find the requirement that IPng use NSAP addressing (which is how I read this) to be unnecessarily constraining upon the development of IPng technologies. Presumably (and this is a very large guess on my part) this requirement also includes that we must adhere to the various rules on NSAP formatting. To require a specific addressing format may hinder the development of the technology needed to deal with things like huge networks (e.g. the 10**12/10**15 numbers), policy and provider selection, resource control, and so on. It is not clear to me that we can adequately build highly scalable, highly functional, routing systems which are 'pre-constrained' in these manners. > > Remember, TUBA would be under Internet change control and > not an ISO standard. Therefore, it does not represent > capitulation. It is also well tried and tested. It would > be a pity to force the IT world towards a protocol which > does not have a long testing history - you have to get it > right this 'last time'. I read this as saying that use of CLNP/TUBA is required. I get this from the phrase 'pity to force the IT world towards a protocoal which does not have a long testing history'. For all intents and purposes, there are 3 protocols which have a 'long testing history' -- IPv4 (which seems to insufficient), Novell/XNS (which no one is proposing modulo SIP's lineage from Xerox/Parc :-), and CLNP... Unfortunately, many of the problems with which IPng is supposed to grapple are very very new technology and do not seem to suit themselves well to the 'old' technologies such as IPv4 OR CLNP. As I recall history, the original proposal for CLNP was IPv4; the ISO people didn't like that idea, so the second proposal was IPv4 with the fields rearranged and larger addresses... Unfortunately, CLNP is pretty much IPv4 with large address fields. However, our current problems are more and more indicating that we need new technologies, and, to me, the 'old' protocols and architectures represent the old technologies. We can probably keep extending and patching the old technologies (e.g. by adding more header options or things like that) but this eventually turns into an exercise showing the laws of diminishing returns... Sorry to go on so long about this. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From sob@hsdndev.harvard.edu Thu Apr 14 09:49:03 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA28542 for ; Thu, 14 Apr 1994 09:49:00 -0400 Date: Thu, 14 Apr 94 09:49:03 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404141349.AA04324@hsdndev.harvard.edu> To: kasten@ftp.com Subject: Re: CLNP migration Cc: ipng@cmf.nrl.navy.mil Status: O Frank, I forwarded Jack's document because we had asked him for it and because he had produced it. Just like any other document that we get there is no implicit endorcement that should be assumed by the act of forwarding it. I don't disagree about putting a "requirement" for a CLNP->IPng trensition plan into the technical requirements document. Brian has suggested that we need a 2nd requirements document that is not focused on the technical issues but more on the "other issues". Some mention of a CLNP->IPng trensition plan could go there. It could also be seen as a task for the TACIT WG. What I have suggested was that we have stated somewhere that we (the IETF & IPng area somehow) should facilliate (sp) the production of transition plans from a number of existing network protocols to IPng, including CLNP & IPX. My thinking is twofold: 1/ it makes it easer for someone in the condition you note to think about moving to IPng if they can see a path and a transition plan can show a way (there may be other ways but telling people about at least one in a carefull way will help) 2/ it produces an immage of the IETF as an organization that understands that there are other things in the world than IP and gives people in other standards organizations a feeling that we are welcoming them rather than ignoring them or worse. 2.5/ it gives us something specific to say to those people pushing for convergence. If we show them that we can define ways for IP to get to IPng & we can define ways for CLNP (...) to get to IPng, we have defined a path for convergence, i.e. a way for everyone (for some definition of everyone) to migrate to the same protocol. Again, I don't think this is something specific for the technical requirements document other than along the lines that have been developing saying that an IPng should not lack functionality now in other protocols. Scott From bound@zk3.dec.com Thu Apr 14 11:33:06 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA29442 for ; Thu, 14 Apr 1994 11:37:50 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA11685; Thu, 14 Apr 94 08:33:19 -0700 Received: by xirtlu.zk3.dec.com; id AA04956; Thu, 14 Apr 1994 11:33:12 -0400 Message-Id: <9404141533.AA04956@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil Subject: Re: CLNP migration In-Reply-To: Your message of "Thu, 14 Apr 94 09:12:42 EDT." <9404141312.AA29835@mailserv-D.ftp.com> Date: Thu, 14 Apr 94 11:33:06 -0400 X-Mts: smtp Status: O I agree with everything Frank said. But will add that the tunneling requirement may need some specific protocol examples in each of the proposals. Also whether we like it or not OSI could be dying and this is just the wake and emotions are running high. OSI has not been a big effector of revenue generation but IP has. Hence there is a business reason to support Franks mention of why we are focusing on our Internet protocols. If by chance CLNP continues to expand more than today then we can address integration. The only other caveat is that we are having an integrated routing discussion on Big-I. If this would work then we would afford a long term migration to IPng via that vehicle not just for CLNP but many protocols. Or at least a routing interface for the customer. Also to add to Franks mention of NSAPs they don't really buy us anything technically at all. /jim From sob@hsdndev.harvard.edu Fri Apr 15 08:09:48 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA02930 for ; Fri, 15 Apr 1994 08:09:57 -0400 Date: Fri, 15 Apr 94 08:09:48 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404151209.AA09997@hsdndev.harvard.edu> To: Brian.Carpenter@cern.ch Subject: Re: Convergence (fwd) Cc: ipng@cmf.nrl.navy.mil Status: O Well, I like this, it helps put the IPng effort as a logical endpoint for people who want to move off of other protocols. Scott 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. From ericf@atc.boeing.com Fri Apr 15 06:26:05 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA03379 for ; Fri, 15 Apr 1994 09:24:26 -0400 Received: by atc.boeing.com (5.57) id AA11712; Fri, 15 Apr 94 06:26:05 -0700 Date: Fri, 15 Apr 94 06:26:05 -0700 From: Eric Fleischman Message-Id: <9404151326.AA11712@atc.boeing.com> To: Brian.Carpenter@cern.ch, sob@hsdndev.harvard.edu Subject: Re: Convergence (fwd) Cc: ipng@cmf.nrl.navy.mil Status: O Dear Directorate, I like this text (below) too. Does anybody on this list have a different opinion? --Eric > 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. From bound@zk3.dec.com Fri Apr 15 09:51:54 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA03729 for ; Fri, 15 Apr 1994 09:56:01 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA01812; Fri, 15 Apr 94 06:52:01 -0700 Received: by xirtlu.zk3.dec.com; id AA27754; Fri, 15 Apr 1994 09:52:00 -0400 Message-Id: <9404151352.AA27754@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: ipng@cmf.nrl.navy.mil Subject: Re: Convergence (fwd) In-Reply-To: Your message of "Fri, 15 Apr 94 06:26:05 PDT." <9404151326.AA11712@atc.boeing.com> Date: Fri, 15 Apr 94 09:51:54 -0400 X-Mts: smtp Status: O this sounds fine to me as an objective. /jim From jcurran@nic.near.net Fri Apr 15 10:59:30 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA04570 for ; Fri, 15 Apr 1994 11:00:28 -0400 Received: from platinum.near.net by nic.near.net id aa03172; 15 Apr 94 11:00 EDT To: kasten@ftp.com cc: ipng@cmf.nrl.navy.mil Subject: Re: Convergence (fwd) In-reply-to: Your message of Fri, 15 Apr 1994 09:24:31 -0400. <9404151324.AA13542@mailserv-D.ftp.com> Date: Fri, 15 Apr 1994 10:59:30 -0400 From: John Curran Message-ID: <9404151100.aa03172@nic.near.net> Status: O -------- From: Frank Kastenholz Subject: Re: Convergence (fwd) Date: Fri, 15 Apr 94 09:24:31 EDT >I am a firm believer that the IPng should be "one protocol to bind them >all". I would therefore would like convergence (where the word is I'm getting really tired of this. I keep reading an implication into the phrase ("one protocol...") that Craig and I meant that there should be only one Internet-layer protocol in the world. This is completely and utterly wrong. Our intent is that the Internet layer is to be the common layer among all hosts on the Internet. When building an internetwork one must choose some point in the protocol stack which is the point of commonality, the point where service is available all over the internetwork. We believe that the Internet layer (i.e. the layer where IP and IPng reside) is the point where there should be common service across an internetwork; specifically, The Internet. While I understand the position of "one network-layer protocol", I will note that the vast majority of applications do not directly use IP services, but use UDP or TCP instead. There are other options. For instance, the common point could be at the data link layer. The more militant proponents of ATM see a single ATM fabric spanning the entire world; the common layer all over would, in this case, be the datalink layer. It is also possible that the network could grow by building application-layer gateways (and this has seriously been suggested as one growth path that The Internet may wish to take, instead of 'fixing' IP). We (Craig and I) believe that the right spot in the network protocol hierarchy for this common service is the Internet Layer. ... There's another possibility (rather than uniformity at the application or data-link layer), that is, agreement on all-pervasive transport protocols (such as UDP, TCP, and ) with their own identifier space which can then run over multiple network layers... This then makes some interesting requirements on the IP, such as it must scale to be able to cover any and all forseen hosts (eg 10**15 end systems), that it must be relatively efficient to implement (so that it can run on both Cray's and light-switches), and so on. I find an variety of data-link specifications to be very useful in serving diverse network needs. I'm rather happy that ethernet, 10baseT, FDDI, HDLC, and ATM did not have to each meet the complete set of possible data-link needs. I can imagine that the ability to have multiple network-layer protocols (each focused on a particular set of requirements) make for network services which better address the requirements than a single network-layer protocol which provides "least common denominator" service. Alternative: we use many options to make IPng serve all possible applications... we may end up with a single network protocol with 35 RFCs for specification. Needless to say, this is entirely philosophical discussion. The current IPng process is based around the assumption of "one network layer", and I do not believe that we have the freedom to revisit that assumption without disfranchising the IETF community. I just hope that IPng is settled, we have some way of keeping IPng locators separate from transport EIDs. To consider imbedding network-layer information in the transport namespace again is simply irresponsible. /John From kasten@mailserv-D.ftp.com Fri Apr 15 13:33:45 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA06294 for ; Fri, 15 Apr 1994 13:34:46 -0400 Received: from ftp.com by ftp.com ; Fri, 15 Apr 1994 13:34:44 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 15 Apr 1994 13:34:44 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA18061; Fri, 15 Apr 94 13:33:45 EDT Date: Fri, 15 Apr 94 13:33:45 EDT Message-Id: <9404151733.AA18061@mailserv-D.ftp.com> To: jcurran@nic.near.net Subject: Re: Convergence (fwd) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 2860 Status: O > While I understand the position of "one network-layer protocol", > I will note that the vast majority of applications do not directly > use IP services, but use UDP or TCP instead. Yup. The point was that the point of commonality could be anywhere, and since Craig and I wrote the paper, and since we both think it should be at the IP layer, that's where the paper says it should be (which ought not to be a surprise :-) >I can imagine that the ability to have multiple network-layer protocols (each >focused on a particular set of requirements) make for network services which >better address the requirements than a single network-layer protocol which >provides "least common denominator" service. Alternative: we use many options >to make IPng serve all possible applications... we may end up with a single >network protocol with 35 RFCs for specification. This brings up an interesting line of thought. In my review of the white papers several weeks ago I started turning over the various requirements that were in the papers and started mixing it together with things like the Information Superhighway and so on. I started asking myself whether IPng wants to be all protocols to all potential users, or should we target it more specifically. As I was reading the cable TV paper, for instance, I started wondering if the requirements of that industry really were suited for a general purpose protocol or whether they were specific to cable. That is, should the cable TV people start using a protocol that is specifically tuned to their requirements (giving them the benefits of getting everyting exactly the way they want it) and, therefore, we would not need to make IPng suitable to their needs (meaning that we would not have to 'load up' IPng with as many features, etc). Now, I don't mean to pick, specifically, on the Cable white paper since I really started thinking this way with regard to all of the white papers (at least the well written, well thought out ones). I started wondering whether IPng should be optimized towards the kind of networking that we do today (general purpose computer to g.p. computer) and have these other niches go off and do their own protocols, more specifically tailored to their needs. Then I started thinking more about it and realized that most, if not all, of those highly specific requirements were readily generalizable (?) into requirements that could fit a more 'tradtional' model of internetworking so the question passed from my mind. But I still, occasionally, wonder whether I made the right decision or not... Grrrrrrrrr. > To > consider imbedding network-layer information in the transport namespace > again is simply irresponsible. I'd be tempted to use a somewhat more forceful term... -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From sob@hsdndev.harvard.edu Fri Apr 15 13:57:51 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA06452 for ; Fri, 15 Apr 1994 13:58:09 -0400 Date: Fri, 15 Apr 94 13:57:51 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404151757.AA21121@hsdndev.harvard.edu> To: kasten@ftp.com Subject: Re: Convergence (fwd) Cc: ipng@cmf.nrl.navy.mil Status: O Frank, I think if we do not aim high (i.e. generalize those requirements into what we are working to) we may find that the thing we chose is seen as irrelevant by many people (and in partiicular, those that make development investment decisions). The cable TV like groups will convince the less than withit press that we did not cover their needs and therefor they will do their own thing in an industry group (there are some trying to do that now). If this sort of thing happens then the vendors will chase the $ and IPng will go the way of XNS. Scott From jcurran@nic.near.net Fri Apr 15 14:15:16 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA06656 for ; Fri, 15 Apr 1994 14:16:10 -0400 Received: from platinum.near.net by nic.near.net id aa22066; 15 Apr 94 14:16 EDT To: Robert_Ullmann.LOTUS@crd.lotus.com, Frank Kastenholz cc: ipng@cmf.nrl.navy.mil Subject: Re: Independence of transport EIDs In-reply-to: Your message of Fri, 15 Apr 1994 12:12:10 -0400. <9404151612.AA07550@Mail.Lotus.com> Date: Fri, 15 Apr 1994 14:15:16 -0400 From: John Curran Message-ID: <9404151416.aa22066@nic.near.net> Status: O -------- ] From: Robert_Ullmann.LOTUS@crd.lotus.com ] Subject: Independence of transport EIDs ] Date: Fri, 15 Apr 94 12:12:10 EDT ] ... ] In fact, it could run ] on any of the existing [IPv4, CLNP, IPX, AT] just as well; all it needs ] is a TLPID/NSEL code point assignment. Even if the endpoints (possibly ] multiple, in the case of an mcast transport) are on different N-layer ] protocols. Like with CATNIP. ] ] So go do it already. :-) Sorry, I just buy and deploy this stuff... there are many folks who are actually qualified to design such protocols, and I don't necessarily include myself in that list. I'd be happy with even the vestiges of transport-independence in the new IPng suite. This could be done by actually including the transport ID's during encapsulation into IPng, and an algorithmic mapping between transport EID's to IPng locators (e.g. EID = 32 bits of zero + IPng locator). At least in this manner, a subsequent mapping service could be feasibly deployed once available. On the other hand, anything that we accomplish with EIDs can probably be handled with source-routing and encapsulation (as several IP WG's are demonstrating) so it's quite unlikely that any concessions purely for architectural reasons will prevail... ] From: Frank Kastenholz ] Date: Fri, 15 Apr 94 13:33:45 EDT ] Subject: Re: Convergence (fwd) ] Content-Length: 2860 ] ... ] I started wondering whether IPng should be optimized towards the kind ] of networking that we do today (general purpose computer to g.p. ] computer) and have these other niches go off and do their own ] protocols, more specifically tailored to their needs. Then I started ] thinking more about it and realized that most, if not all, of those ] highly specific requirements were readily generalizable (?) into ] requirements that could fit a more 'tradtional' model of ] internetworking so the question passed from my mind. But will the resulting IPng which correctly handles the "fully generalized" requirements still work in a wall socket application? What if said wall socket _does_ want to use the security code and the service class code? Isn't it possible that wall sockets or supercomputers or atm networks will at some point need capabilities (or _lack_ of capabilities) that we just can't reconcile with IPng? For some strange reason, I can imagine that we will invent new network layers which are better at certain things than IPng, and it certainly would be convenient to let them carry the Internet's TCP and UDP traffic even if such protocols weren't IPng. ] > To consider imbedding network-layer information in the transport namespace ] > again is simply irresponsible. ] ] I'd be tempted to use a somewhat more forceful term... I was trying to be nice... ;-) /John From bound@zk3.dec.com Fri Apr 15 23:24:10 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA08870 for ; Fri, 15 Apr 1994 23:25:31 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA21527; Fri, 15 Apr 94 20:24:22 -0700 Received: by xirtlu.zk3.dec.com; id AA11961; Fri, 15 Apr 1994 23:24:16 -0400 Message-Id: <9404160324.AA11961@xirtlu.zk3.dec.com> To: Robert_Ullmann.LOTUS@CRD.lotus.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Independence of transport EIDs In-Reply-To: Your message of "Fri, 15 Apr 94 12:12:10 EDT." <9404151612.AA07550@Mail.Lotus.com> Date: Fri, 15 Apr 94 23:24:10 -0400 X-Mts: smtp Status: O I support Rob and John on this and agree. /jim From J.Crowcroft@cs.ucl.ac.uk Sat Apr 16 12:42:34 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA09952 for ; Sat, 16 Apr 1994 07:43:07 -0400 Message-Id: <199404161143.HAA09952@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 16 Apr 1994 12:42:38 +0100 To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of "Sat, 16 Apr 94 01:10:43 EDT." <9404160510.AA12662@xirtlu.zk3.dec.com> Date: Sat, 16 Apr 94 12:42:34 +0100 From: Jon Crowcroft Status: O >I would like to make a point about listening and respecting the input of >the market. My position is different. As a point of principle, I believe we should choose/design the very best technical IPng, and it should not be a compromise between operational requirements for migration/interworking legacy of other peoples protocols market forces convergence with other substandard protocols etc once we have a best technical IPng, these other things may or may not happen if they do, we can (as with IPv4) say aha, we were right if they don't, we can as engineers, shake our heads sadly and say too bad... if we don't design/choose the best technical protocol, we are guilty of ISO-morphism, committee/consensus engineering: a very bad thing. The very opposite of what the internet ENGINEERING task force was all about sincerely jon From bound@zk3.dec.com Sat Apr 16 23:35:36 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA11831 for ; Sat, 16 Apr 1994 23:41:33 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA25433; Sat, 16 Apr 94 20:35:44 -0700 Received: by xirtlu.zk3.dec.com; id AA23791; Sat, 16 Apr 1994 23:35:42 -0400 Message-Id: <9404170335.AA23791@xirtlu.zk3.dec.com> To: Jon Crowcroft Cc: ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-Reply-To: Your message of "Sat, 16 Apr 94 12:42:34 BST." <9404161143.AA17344@decvax.dec.com> Date: Sat, 16 Apr 94 23:35:36 -0400 X-Mts: smtp Status: O >I would like to make a point about listening and respecting the input of >the market. >My position is different. As a point of principle, I believe we should >choose/design the very best technical IPng, and it should not be a >compromise between >operational requirements for migration/interworking >legacy of other peoples protocols >market forces >convergence with other substandard protocols >etc I said listen and respect not do exactly what they said or throw our technical brains away. Geeezzz... >once we have a best technical IPng, these other things may or may not >happen >if they do, we can (as with IPv4) say aha, we were right Well I would like to avoid a plane crash if at all possible as a pilot. There is this huge mountain range I need to avoid so I don't crash and burn and its called proprietary protocol proliferation, government mandates, and multiprotocol routing. >if they don't, we can as engineers, shake our heads sadly and say >too bad... Well if that happens then the IETF is history in my opinion even though they have done great things if this gets screwed up in the international scheme of things I believe the IETF will become extinct. This is to important. >if we don't design/choose the best technical protocol, we are guilty >of ISO-morphism, committee/consensus engineering: a very bad thing. >The very opposite of what the internet ENGINEERING task force was all >about I agree with you. I have seen this with UNIX already. We started out as hackers and followed the greatest hackers in the world and even had buttons and live free or die UNIX signs. But then UNIX became a big business and needed many features that were not in a research OS tool. The Internet is becoming the Super Information Highway and that is far beyond any expectations the Internet had as UNIX has gone far beyond where its authors perceived too. You don't have to listen to requirements as an individual but I do and if any proposal does not support the customers needs then I won't support that proposal with my work on implementations and go support the proposal that will. If you really want to be totally anarchist about this. I will also not support that proposal for rough consensus in the IETF as a member of that community. Of course I am not a researcher and would look at it differently if that was my role here. I tried to address that role took but it must not have been clear. I am bummed out about that as I really tried. /jim sincerely jon From J.Crowcroft@cs.ucl.ac.uk Sun Apr 17 10:58:18 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id FAA12601 for ; Sun, 17 Apr 1994 05:58:41 -0400 Message-Id: <199404170958.FAA12601@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 17 Apr 1994 10:58:24 +0100 To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of "Sat, 16 Apr 94 23:35:36 EDT." <9404170335.AA23791@xirtlu.zk3.dec.com> Date: Sun, 17 Apr 94 10:58:18 +0100 From: Jon Crowcroft Status: O >>if they don't, we can as engineers, shake our heads sadly and say >>too bad... >Well if that happens then the IETF is history in my opinion even though >they have done great things if this gets screwed up in the international >scheme of things I believe the IETF will become extinct. This is to >important. i have no problem with the IETF becoming history... >You don't have to listen to requirements as an individual but I do and >if any proposal does not support the customers needs then I won't >support that proposal with my work on implementations and go support the >proposal that will. we in the UK explicitly moved from ISO to IP. we now have 150,000 DNS registered hosts, and around 300,000 non registered, where 3-4 years ago we had 2. (that _is_ two hosts) we moved because IPv4 was the best, cheapest option... we know a lot about what makes people migrate. jon From J.Crowcroft@cs.ucl.ac.uk Sun Apr 17 11:51:29 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id GAA12681 for ; Sun, 17 Apr 1994 06:51:52 -0400 Message-Id: <199404171051.GAA12681@picard.cmf.nrl.navy.mil> Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 17 Apr 1994 11:51:36 +0100 To: Tony Li cc: ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-reply-to: Your message of "Sun, 17 Apr 94 02:45:04 PDT." <199404170945.CAA04492@lager.cisco.com> Date: Sun, 17 Apr 94 11:51:29 +0100 From: Jon Crowcroft Status: O >First and foremost, I would like to point out that with the advent of >Turnipp, I have a massive conflict of interest in being part of the review >team. what advent of turnipp? - its just a suggestion, isn't it - or do you have pilot implementations like the TUBA and SIPP people do? >I've also come to the private conclusion that a requirements document and >much of the process involved is wholly unnecessary, and that the real IPng >selection will come through mergers, not through selection. this is a very interesting point - i agree that fostering this process could benefit more in the end than the document...actually, if cisco would invest a bit in IPng products, i'm sure we'd all be most pleased... >I believe that either of the above should be sufficient for you to wholly >discount my comments. actually, the presence of a large body of input from an employee of a particular router vendor, and little from other router vendors, or more importantly, host vendors, always bothered me:-) for example, position statements like "you can't use that packet format coz it will hurt my performance, but i can't tell you why my next generation router hardware wont perform well with that format rather than this one, as its under wraps", are not at all helpful - in fact, i really don't care about this - i care about host performance - we buy a lot more hosts than routers, and can stamnd double the router cost - in fact, the UK 140 Mbps backbone costs dwarf the router costs.... luckily we have some operators contributing, though their input can also be one sided - i certainly listen to the _users_ more carefully than to any other input... >Section 4.5 (Cooperative Anarchy): One of the principles that is not >discussed here is that this principle simply does not scale. i think you misinterpret this - cooperative anarchy, in my reading, refers to how we plug the internet together hop by hop, incrementally, without having to do an n**2 agreement before attaching a new site at any edge...or a new regional to a backbone, or a new backbone to another backbone...the phone net does not have this property, and so cost a lot more andf took a lot longer to get as big as it is... >as alternative technologies are developed in a single area, you get into >the N^2 problem of their interaction. We see this frequently in routing >protocols. i don't think we are advocateing anarchic development of technology - just the facility to manage the net this way, as opposed to the expensive way the telcos do it. >Section 5.1 (Scaling): In the criteria for scaling, I feel that the >criteria for describing scalable routing is vastly underplayed. Given the >discussion in this section that projects 10**12 networks, how many routes >do we actually have to scale to? What is a technically achievable routing >table in the future? Let me toss some wild-assed numbers at you: today we >have approximately 2*10**6 hosts, with 2*10**4 routes. If routing scales >linearly from where we are, then 10**12 networks implies 10**10 routing >table entries, which is clearly intractable. However, if hierarchical >routing does apply, then the routing table should grow logarithmically with >the size of the network. This would certainly be wonderful. However, true >hierarchy does not exist and there will be noise in the routing system. I >would guesstimate that in twenty years we might make router capable of >2*10**6 routes. I believe that a proposal should have a strong explanation >of how it will manage to achieve this. at 128 bytes per routing entry, that is 256 Mbytes of routing tabler. just exactly what is the difficulty of this? my workstation has that much RAM...this year...we have 3000 workstations here and only 22 routers - where is the cost problem? >Section 5.2 (Toplogical Flexibility): I believe that this is a Motherhood >checklist item and can be related until later in the discussion, if not >wholly eliminated as being completely assumed as we're following the IPv4 >model. In fact, I believe that you should take IPv4 as a baseline >throughout the document. All proposals must be functionally equivalent to >IPv4 Plus meet these criteria... i think the SIPP work on policies and mobility ought to be a good example of topological flexibility that is hard or impossible to do in IPv4 - the policies in our part of the world are bizarre - i see no reason not to expect them to continue being bizarre...i can give you papers on european policy routing if you like... >Section 5.3 (Performance): Again a Motherhood issue. I suggest that this >be at least rewritten as "no impediments to perfomance". that is a router person speaking - i want no unjustified host costs in constructing bizarre ipng headers to suit forwarding constraints either... >Section 5.4 (Robust Service): Motherhood. I believe that the timeframe for >Byzantine failure protection is overly ambitious. Given that we're trying >to do IPng architecture at the same time, it's absurd. perlman's thesis on byzantine failure has been around longer than multicast - does you mean it is too hard for router people to implement? >Section 5.6 (Media Independence): Motherhood. Perhaps this is an >appropriate place to require that there not be an analog of the IPv4 subnet >model. i think it was menat as a warning shot to atm people...maybe it should be more clear about IPng operating _over_ large (VC) clouds as well as standard stuff... >Section 5.7 (Unreliable Datagram Service): Motherhood. I'll stop now. well, it isn't motherhood to 150 people in BT that i've just been explaing the internet too - they said, "but why don't you just buy a managed ATM service end 2 end".... i think the document has a "publicity" purpose...as well as its ostensible technical one.. >Section 5.12 (Multicast): Part of me, deep down, really wonders whether >"multicast addressing" isn't an oxymoron. In many cases, the multicast >address isn't an "address" at all in that it has no topological >signifigance. no topological significance _yet_. also, it must be an entity that operates much as a unicast address in the API, at the very least, since that is how all the mbone applications switch between unicast and multicast.,. i agree scoping needs thinking about... >Section 5.15 (Mobility): Clue: your time line is unimportant as this will >be driven by the market. this "market view" renders the process pointless if you buy it: since i don't agree that there is any evidence the market has intelligence, i see this is completely pointless remark >Section 5.17 (Tunneling): This is NOT a requirement. In fact, given >section 5.7, it's already allowed. actually, i think it should be removed as its a technique, not a requirement - the requirement is that a) you can build virtual private internets on the internet (c.f. mbone) b) you can build virtual private any-nets o nthe internet (c.f. clnp/decnet use in the UK, which is largely tunneled over the IP backbone) - other techniques could solve the problem, so this should be restated in terms of recursive internet services jon oh, by the way, when advising BT about what they should do w.r.t internet business, i suggested they should consider buying cisco outright..... you shares will do quite well then:-) From sob@hsdndev.harvard.edu Sun Apr 17 08:19:29 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA12832 for ; Sun, 17 Apr 1994 08:19:46 -0400 Date: Sun, 17 Apr 94 08:19:29 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404171219.AA06681@hsdndev.harvard.edu> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: Criteria review comments Cc: ipng@cmf.nrl.navy.mil Status: O Jon, I had not seen your comments when I sent my note about the review comments but it is what I was talking about. I think your comments were very good but could you just send them to the ipng list until we have figgured out how to respond to these reviewers. Sorry if it sounded like a poke at you. Scott From jcurran@nic.near.net Sun Apr 17 09:35:56 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA12961 for ; Sun, 17 Apr 1994 09:36:54 -0400 Received: from platinum.near.net by nic.near.net id aa11862; 17 Apr 94 9:36 EDT To: Jon Crowcroft cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of Sun, 17 Apr 1994 10:58:18 +0100. <199404170958.FAA12601@picard.cmf.nrl.navy.mil> Date: Sun, 17 Apr 1994 09:35:56 -0400 From: John Curran Message-ID: <9404170936.aa11862@nic.near.net> Status: O -------- ] From: Jon Crowcroft ] Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... ] Date: Sun, 17 Apr 94 10:58:18 +0100 ] ] >You don't have to listen to requirements as an individual but I do and ] >if any proposal does not support the customers needs then I won't ] >support that proposal with my work on implementations and go support the ] >proposal that will. ] ] we in the UK explicitly moved from ISO to IP. we now have 150,000 ] DNS registered hosts, and around 300,000 non registered, where 3-4 ] years ago we had 2. (that _is_ two hosts) ] ] we moved because IPv4 was the best, cheapest option... Depending on your criteria, that could easily be true. Have you told these folks that they're going to migrate to another protocol (IPng) yet? Sorry, "best" is rather subjective. I know companies that right now would like to deploy very large networks, and IPv4 is "second-best" or "third-best" in their scheme of things. We'd like a very flexible IPng which can handle future (yet unconceived) needs for addressing, routing, resource allocation, etc. Each IPng proposal offers different degrees of flexibility in different areas. Achieving true flexibility in all aspects is generally ruled out by chanting "performance" over and over... All the performance in the world doesn't help if the protocol has to be abandoned because it cannot adapt. Can you say "IPv4", boys and girls? ] we know a lot about what makes people migrate. Do you honestly believe that migrating to IPng will be cheaper and more functional than running IPv4 (and potentially NAT) for the average Internet site? I'd love to hear the reasoning, but I honestly cannot forsee IPng being adopted by anyone... DNS security and key exchange, mobility, and multicasting all appear to be making significant progress as IPv4 initiatives. /John From J.Crowcroft@cs.ucl.ac.uk Sun Apr 17 14:40:32 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA12968 for ; Sun, 17 Apr 1994 09:40:50 -0400 Message-Id: <199404171340.JAA12968@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 17 Apr 1994 14:40:33 +0100 To: John Curran cc: ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of "Sun, 17 Apr 94 09:35:56 EDT." <9404170936.aa11862@nic.near.net> Date: Sun, 17 Apr 94 14:40:32 +0100 From: Jon Crowcroft Status: O >Depending on your criteria, that could easily be true. Have you told >these folks that they're going to migrate to another protocol (IPng) yet? yes. they want something that does better bandwidth enforcement, multicast, realtime, and so on.... >Sorry, "best" is rather subjective. I know companies that right now would >like to deploy very large networks, and IPv4 is "second-best" or "third-best" >in their scheme of things. true... >] we know a lot about what makes people migrate. > >Do you honestly believe that migrating to IPng will be cheaper and >more functional than running IPv4 (and potentially NAT) for the average >Internet site? I'd love to hear the reasoning, but I honestly cannot >forsee IPng being adopted by anyone... DNS security and key exchange, >mobility, and multicasting all appear to be making significant progress >as IPv4 initiatives. depends on your timescales - if you keep them short enough or long enough nothing is worth doing coz it either costs to much, or someone else (the 'market':-) will do it if you set them about right, you & others can profit... jon From jcurran@nic.near.net Sun Apr 17 10:20:11 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA13052 for ; Sun, 17 Apr 1994 10:21:03 -0400 Received: from platinum.near.net by nic.near.net id aa13002; 17 Apr 94 10:21 EDT To: Jon Crowcroft cc: ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of Sun, 17 Apr 1994 14:40:32 +0100. <9404170940.aa12031@nic.near.net> Date: Sun, 17 Apr 1994 10:20:11 -0400 From: John Curran Message-ID: <9404171021.aa13002@nic.near.net> Status: O -------- ] From: Jon Crowcroft ] Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... ] Date: Sun, 17 Apr 94 14:40:32 +0100 ] ] >Depending on your criteria, that could easily be true. Have you told ] >these folks that they're going to migrate to another protocol (IPng) yet? ] ] yes. they want something that does better bandwidth enforcement, ] multicast, realtime, and so on.... Are we assured of getting any of these sooner in IPng than IPv4? ] >Do you honestly believe that migrating to IPng will be cheaper and ] >more functional than running IPv4 (and potentially NAT) for the average ] >Internet site? I'd love to hear the reasoning, but I honestly cannot ] >forsee IPng being adopted by anyone... DNS security and key exchange, ] >mobility, and multicasting all appear to be making significant progress ] >as IPv4 initiatives. ] ] depends on your timescales - if you keep them short enough or long ] enough nothing is worth doing coz it either costs to much, or someone ] else (the 'market':-) will do it Agreed. We do face a predicament, in that: o To avoid the proliferation of a generally-agreed-inferior service model (Balkanization and NAT boxes), we need to get an IPng deployed in the medium-term future. o As much as we'd like to think that people will "do the right thing" and deploy an IPng simply because it prevents address depletion, past experience with subnet & multicast & cidr deployment clearly shows that nothing drives deployment of new infrastructure except serious market demand. o Serious market demand can only be achieved by delivering an IPng which addresses many different marketplace concerns and the IETF is not known for being considerate to any needs outside of a rather closed community. Respecting other groups needs (including market and political needs) does not seem to be a priority for the infamous "600 pound gorilla". We've already seen a preview (from Eric) of one possible reaction to IPng from the large corporate environment. Personally, I'm going to find it very hard to explain to such companies why we intentionally ignore one of the major problems facing them today: the need for convergance between IP and CLNP. If someone wants to explain why IPng shouldn't accomodate addresses of NSAP length, I'd like to hear it. The only reasons that I can possibly come up with are: "We don't consider organizations using CLNP to be future IPng users" -or- "We do consider IPng as a future option for such firms, and we expect them to renumber one weekend to our improved format." It can't be for performance reasons: even a SIPP ASEQ is >160 bits. /John From J.Crowcroft@cs.ucl.ac.uk Sun Apr 17 15:25:52 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA13067 for ; Sun, 17 Apr 1994 10:26:08 -0400 Message-Id: <199404171426.KAA13067@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 17 Apr 1994 15:25:57 +0100 To: John Curran cc: ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of "Sun, 17 Apr 94 10:20:11 EDT." <9404171021.aa13002@nic.near.net> Date: Sun, 17 Apr 94 15:25:52 +0100 From: Jon Crowcroft Status: O >] >Depending on your criteria, that could easily be true. Have you told >] >these folks that they're going to migrate to another protocol (IPng) yet? >] yes. they want something that does better bandwidth enforcement, >] multicast, realtime, and so on.... >Are we assured of getting any of these sooner in IPng than IPv4? if IPv4 has these, it _is_ ipng... & we have no problems:-) jon From bound@zk3.dec.com Sun Apr 17 13:42:22 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA13482 for ; Sun, 17 Apr 1994 13:46:01 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA02863; Sun, 17 Apr 94 10:42:32 -0700 Received: by xirtlu.zk3.dec.com; id AA05787; Sun, 17 Apr 1994 13:42:28 -0400 Message-Id: <9404171742.AA05787@xirtlu.zk3.dec.com> To: John Curran Cc: Jon Crowcroft , bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-Reply-To: Your message of "Sun, 17 Apr 94 09:35:56 EDT." <9404170936.aa11862@nic.near.net> Date: Sun, 17 Apr 94 13:42:22 -0400 X-Mts: smtp Status: O John, I think your missing Jon's point about IPv4. Why do you insist on forgetting about what these customers like about the IPv4 infrastructure and the way it works today. Do you want to change the way these customers work today with IPv4? Do you believe as a provider you have the right to do this? Or is this a political issue we need to deal with for international internetworking? I am not following your objections and questions to Jon's explanation of what is today. thanks /jim From tli@cisco.com Sun Apr 17 12:30:22 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id PAA13779 for ; Sun, 17 Apr 1994 15:31:09 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA22474; Sun, 17 Apr 1994 12:30:22 -0700 Date: Sun, 17 Apr 1994 12:30:22 -0700 From: Tony Li Message-Id: <199404171930.MAA22474@lager.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk Cc: ipng@cmf.nrl.navy.mil In-Reply-To: Jon Crowcroft's message of Sun, 17 Apr 94 11:51:29 +0100 <199404171051.DAA05384@hubbub.cisco.com> Subject: Criteria review comments Status: O what advent of turnipp? - its just a suggestion, isn't it - or do you have pilot implementations like the TUBA and SIPP people do? I wasn't aware that pilot implementation was necessary for anyone to take you seriously. Does this mean that CATNIP is disqualified as well? I'm told that my "suggestion" at least has the appearance of a proposal and thus this at least has the appearance of a conflict of interest. this is a very interesting point - i agree that fostering this process could benefit more in the end than the document...actually, if cisco would invest a bit in IPng products, i'm sure we'd all be most pleased... We've already shipped IPng. It's called Tuba. You should try it out. ;-) whp4-ags#do-dah Trying DO-DAH (47.0005.80ff.ef00.0000.0001.6c07.1311.0800.7024.06)... Open User Access Verification Password: actually, the presence of a large body of input from an employee of a particular router vendor, and little from other router vendors, or more importantly, host vendors, always bothered me:-) I see. So we're to blame for contributing. ;-) for example, position statements like "you can't use that packet format coz it will hurt my performance, but i can't tell you why my next generation router hardware wont perform well with that format rather than this one, as its under wraps", are not at all helpful - Sorry. Life in the business world. Gotta wait for the patent to file. Mebbe next week. in fact, i really don't care about this - i care about host performance - we buy a lot more hosts than routers, and can stamnd double the router cost - in fact, the UK 140 Mbps backbone costs dwarf the router costs.... A fine opinion, which I do respect. luckily we have some operators contributing, though their input can also be one sided - i certainly listen to the _users_ more carefully than to any other input... Yes, please. i think you misinterpret this - cooperative anarchy, in my reading, refers to how we plug the internet together hop by hop, incrementally, without having to do an n**2 agreement before attaching a new site at any edge...or a new regional to a backbone, or a new backbone to another backbone...the phone net does not have this property, and so cost a lot more andf took a lot longer to get as big as it is... Well, for example, you bring up another example of why it doesn't scale. How do you support all of this fancy packet forwarding that you want to do that isn't hop-by-hop under the cooperative anarchy model? Given this anarchy, some site can simply refuse to ever deploy flow setup or policy routing. Everyone downstream of them is screwed. Or do you claim that the market will fix this too? [Yes, in the evolutionary time frame, the market fixes everything.] i don't think we are advocateing anarchic development of technology - just the facility to manage the net this way, as opposed to the expensive way the telcos do it. ??? It certainly seems that way from the way the criteria is written. Perhaps you need to clarify this. at 128 bytes per routing entry, that is 256 Mbytes of routing tabler. just exactly what is the difficulty of this? my workstation has that much RAM...this year...we have 3000 workstations here and only 22 routers - where is the cost problem? Why do you assume that you're only going to hold 128 bytes per routing entry? Why do you ignore all of the other state in the routers that these requirements dictate (e.g., flow state). I admit that I'm probably being conservative. Even so, add another order of magnitude or two. It's still tough to have a scalable routing architecture unless you specify HOW it scales. i think the SIPP work on policies and mobility ought to be a good example of topological flexibility that is hard or impossible to do in IPv4 - the policies in our part of the world are bizarre - i see no reason not to expect them to continue being bizarre...i can give you papers on european policy routing if you like... Fine. How does this relate to the Motherhood and Apple Pie language found here? that is a router person speaking - i want no unjustified host costs in constructing bizarre ipng headers to suit forwarding constraints either... Sigh. I see that I wear a sterotype here. This is really beneath you, Jon. As a router person, I need the hosts to perform well too. I have to make the customer happy no matter where the bottleneck is. Now I don't claim expertise on HOW to make the host run fast. But I think I've shown a reasonable amount of sensitivity to the input that I've received. perlman's thesis on byzantine failure has been around longer than multicast - does you mean it is too hard for router people to implement? No. I think that it's too expensive for you to buy. You may recall that it quickly becomes outrageous in its overhead. And the thing that Radia didn't point out was that the same implementation bug replicated in all boxes in the domain will defeat even her schemes. >Section 5.6 (Media Independence): Motherhood. Perhaps this is an >appropriate place to require that there not be an analog of the IPv4 subnet >model. i think it was menat as a warning shot to atm people...maybe it should be more clear about IPng operating _over_ large (VC) clouds as well as standard stuff... Clarification is then in order. well, it isn't motherhood to 150 people in BT that i've just been explaing the internet too - they said, "but why don't you just buy a managed ATM service end 2 end".... i think the document has a "publicity" purpose...as well as its ostensible technical one.. Well, not being a marketing person, I will only make technical comments. I presume that the publicity managers will mangle them (as usual). no topological significance _yet_. Do you propose to restrict multicast addresses to having topological significance? This seems to be backwards. also, it must be an entity that operates much as a unicast address in the API, at the very least, since that is how all the mbone applications switch between unicast and multicast.,. Designing requirements to fit today's code? You wouldn't let me get away with that. What makes you think I'll let you get away with it? ;-) i agree scoping needs thinking about... >Section 5.15 (Mobility): Clue: your time line is unimportant as this will >be driven by the market. this "market view" renders the process pointless if you buy it: since i don't agree that there is any evidence the market has intelligence, i see this is completely pointless remark The market has no "intelligence" in that it does not learn (e.g., 16Mbit Token Ring). However, it does "evolve" in the sense that it tries things until the problem is solved. As there is considerable motivation from the market to have a solution to the mobility problem, one will (eventually) appear. And the timeline mentioned here is not a factor in that. actually, i think it should be removed as its a technique, not a requirement - the requirement is that Agreed. a) you can build virtual private internets on the internet (c.f. mbone) b) you can build virtual private any-nets o nthe internet (c.f. clnp/decnet use in the UK, which is largely tunneled over the IP backbone) - other techniques could solve the problem, so this should be restated in terms of recursive internet services These sound more like requirements on policy than on technical development. oh, by the way, when advising BT about what they should do w.r.t internet business, i suggested they should consider buying cisco outright..... you shares will do quite well then:-) Thank you for thinking of us. ;-) Please get them to hurry. I'd like to retire by age 35. ;-) Tony From craig@aland.bbn.com Sun Apr 17 13:43:44 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA14036 for ; Sun, 17 Apr 1994 16:45:39 -0400 Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA18473 for ipng@cmf.nrl.navy.mil; Sun, 17 Apr 94 16:45:26 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id NAA03199; Sun, 17 Apr 1994 13:43:45 -0700 Message-Id: <199404172043.NAA03199@aland.bbn.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: Convergence (fwd) In-Reply-To: Your message of Fri, 15 Apr 94 08:09:48 -0400. <9404151209.AA09997@hsdndev.harvard.edu> From: Craig Partridge Date: Sun, 17 Apr 94 13:43:44 -0700 Sender: craig@aland.bbn.com Status: O 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. Scott: I don't want to derail emerging concensus since I think this is actually a constructive way to think about the problem (making IPng the core protocol by helping folks to move their protocols to it). But this paragraph gives me heartburn. In particular, there's a big problem. Some of the popular protocols of today, most notably Appletalk, although I've heard it said of IPX, work wonderfully on local networks and scale very poorly to WANs. Part of this has to do with the fact that LANs let you do things that WANs don't (like leave out checksums, and assume that loss is low, and broadcasting to everyone is a good way to do address allocation and defense). I suppose one might just change the last sentence to say: IPng should not lack any significant WAN functionality of such existing protocols. but I'm not sure that's the right answer. Craig PS: I'm slowly catching up but may get blown away again during this week. From craig@aland.bbn.com Sun Apr 17 13:45:55 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA14041 for ; Sun, 17 Apr 1994 16:47:47 -0400 Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA18691 for ipng@cmf.nrl.navy.mil; Sun, 17 Apr 94 16:47:35 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id NAA03211; Sun, 17 Apr 1994 13:45:56 -0700 Message-Id: <199404172045.NAA03211@aland.bbn.com> To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Convergence (fwd) In-Reply-To: Your message of Fri, 15 Apr 94 09:24:31 -0400. <9404151324.AA13542@mailserv-D.ftp.com> From: Craig Partridge Date: Sun, 17 Apr 94 13:45:55 -0700 Sender: craig@aland.bbn.com Status: O Given my last note, in which I said I liked the convergence approach, I thought I'd better also say that Frank's note (below) correctly summarizes what he and I are trying to say in the requirements document. Craig >I am a firm believer that the IPng should be "one protocol to bind them >all". I would therefore would like convergence (where the word is I'm getting really tired of this. I keep reading an implication into the phrase ("one protocol...") that Craig and I meant that there should be only one Internet-layer protocol in the world. This is completely and utterly wrong. Our intent is that the Internet layer is to be the common layer among all hosts on the Internet. When building an internetwork one must choose some point in the protocol stack which is the point of commonality, the point where service is available all over the internetwork. We believe that the Internet layer (i.e. the layer where IP and IPng reside) is the point where there should be common service across an internetwork; specifically, The Internet. There are other options. For instance, the common point could be at the data link layer. The more militant proponents of ATM see a single ATM fabric spanning the entire world; the common layer all over would, in this case, be the datalink layer. It is also possible that the network could grow by building application-layer gateways (and this has seriously been suggested as one growth path that The Internet may wish to take, instead of 'fixing' IP). We (Craig and I) believe that the right spot in the network protocol hierarchy for this common service is the Internet Layer. This then makes some interesting requirements on the IP, such as it must scale to be able to cover any and all forseen hosts (eg 10**15 end systems), that it must be relatively efficient to implement (so that it can run on both Cray's and light-switches), and so on. We specifically say that we do not (repeat DO NOT) believe that there will be only one internetwork layer protocol. The Internet is now, and probably will always be a multi-protocol network. Please go back and re-read the section of the requirements document. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From craig@aland.bbn.com Sun Apr 17 15:57:17 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA14372 for ; Sun, 17 Apr 1994 18:59:06 -0400 Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA02545 for ipng@cmf.nrl.navy.mil; Sun, 17 Apr 94 18:58:58 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id PAA03603; Sun, 17 Apr 1994 15:57:18 -0700 Message-Id: <199404172257.PAA03603@aland.bbn.com> To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-Reply-To: Your message of Sun, 17 Apr 94 13:42:22 -0400. <9404171742.AA05787@xirtlu.zk3.dec.com> From: Craig Partridge Date: Sun, 17 Apr 94 15:57:17 -0700 Sender: craig@aland.bbn.com Status: O I'd like to jump back to Jim's initial point about needing to listen to the market, because I have a slightly different view. I think our task is to listen to the market as it will be in 3 to 5 years. Realistically, picking an IPng this summer is simply one of the major steps in getting it deployed over the next few years. So the mass-market IPng impact (when almost everyone's got it) probably won't hit until around 1997. And it is what folks want then that we'd better hit. Of course, if we can meet market needs *now*, then it hastens the deployment of IPng by a year or two. (Look at how fast Van's TCP mods got around, vs how long it has taken for IP multicast. Folks desperately needed Van's mods. Multicast looked nice but not essential to them). This is an intensely tricky business, but critical. (Consider if we were building PCs, and decided to design a new PC to meet today's market needs. When our new PC hit the market in 18 months, we'd find that no one would buy it. Ditto for IPng.) And this is where a lot of engineering comes in. What problems can we have solved in the next two years that the market is likely to want us to have solved (two years isn't much time, so damn few, but a few). And which problems of today may go by the wayside? (SNA convergence perhaps?) So I agree with Jim that we listen to the market -- and since tomorrow's market largely isn't available to listen to, we must listen to today's market, but with our futurist hats on. Craig From jcurran@nic.near.net Sun Apr 17 20:57:02 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA14643 for ; Sun, 17 Apr 1994 20:57:55 -0400 Received: from platinum.near.net by nic.near.net id ab10996; 17 Apr 94 20:57 EDT To: bound@zk3.dec.com cc: Jon Crowcroft , ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of Sun, 17 Apr 1994 13:42:22 -0400. <9404171742.AA05787@xirtlu.zk3.dec.com> Date: Sun, 17 Apr 1994 20:57:02 -0400 From: John Curran Message-ID: <9404172057.ab10996@nic.near.net> Status: O -------- ] From: bound@zk3.dec.com ] Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... ] Date: Sun, 17 Apr 94 13:42:22 -0400 ] ] John, ] ] I think your missing Jon's point about IPv4. Why do you insist on ] forgetting about what these customers like about the IPv4 infrastructure ] and the way it works today. Do you want to change the way these ] customers work today with IPv4? Do you believe as a provider you have ] the right to do this? Or is this a political issue we need to deal with ] for international internetworking? I am not following your objections ] and questions to Jon's explanation of what is today. Jim, Simply put: IPng will need more "thrust" (in the words of an ol' boy) in order to reach market acceptance. In the absence of a clear argument to the contrary, I believe IPng will have capabilities which are equal to IPv4 from an end-user perspective. From looking at the current CIDR deployment, we see that sites want to do the absolute minimum to proceed "as is". (Yes, there are exceptions, but the Internet is increasingly made up of folks who really don't know and couldn't care what happens once they hit return...) In such organizations, consideration of IPng will be extremely short-lived. Unless vendors are prepared to ship IPng-ONLY software, IPv4 will be around for some time, and no amount of vendor posturing or trade articles is going to cause sites to upgrade to IPng. Hence, I am very aggressively looking into _any_ possible IPng motivators, with the hope that we can get an IPng deployed despite the extremely poor market conditions compared to IPv4. One of the more interesting factors which could motivate deployment (particularly among large, non-Internet-connected networks such as banking, traffic control, and other high- consequence networks) would be the knowledge that IPng could be used with their existing NSAP addressing scheme. This is a technical capability for political reasons. I'm not advocating CLNP or OSI protocols, simply an addressing model which would make IPng palatable to current CLNP users. Hence, my reason for asking why IPng candidates do not simply handle such addresses. Since the ability to process such addresses could be very useful in getting IPng adopted in some environments, it's probably worth considering. There are probably other interesting IPng motivators that we should to consider, but I'm starting with "viable replacement for CLNP" as my first potential addition. If folks honestly believe that we can "build it, and they will come", that's great. When balkanized IPv4 internets arrive due to lack of IPng acceptance, you can rest easy knowing that the IETF produced a technically superior (even if not market-ready) solution. /John From jcurran@nic.near.net Sun Apr 17 21:01:22 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA14658 for ; Sun, 17 Apr 1994 21:02:27 -0400 Received: from platinum.near.net by nic.near.net id aa11188; 17 Apr 94 21:02 EDT To: Craig Partridge cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of Sun, 17 Apr 1994 15:57:17 -0700. <199404172257.PAA03603@aland.bbn.com> Date: Sun, 17 Apr 1994 21:01:22 -0400 From: John Curran Message-ID: <9404172102.aa11188@nic.near.net> Status: O -------- ] From: Craig Partridge ] Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... ] Date: Sun, 17 Apr 94 15:57:17 -0700 ] ... ] I think our task is to listen to the market as it will be in 3 to 5 years. ] Realistically, picking an IPng this summer is simply one of the major steps ] in getting it deployed over the next few years. So the mass-market IPng ] impact (when almost everyone's got it) probably won't hit until around 1997. ] And it is what folks want then that we'd better hit. Agreed. ] Of course, if we can meet market needs *now*, then it hastens the deployment ] of IPng by a year or two. (Look at how fast Van's TCP mods got around, vs ] how long it has taken for IP multicast. Folks desperately needed Van's mods. ] Multicast looked nice but not essential to them). ] ] This is an intensely tricky business, but critical. (Consider if we were ] building PCs, and decided to design a new PC to meet today's market needs. ] When our new PC hit the market in 18 months, we'd find that no one would ] buy it. Ditto for IPng.) More agreement. ] And this is where a lot of engineering comes in. What problems can we ] have solved in the next two years that the market is likely to want us ] to have solved (two years isn't much time, so damn few, but a few). ] And which problems of today may go by the wayside? (SNA convergence perhaps?) ] ] So I agree with Jim that we listen to the market -- and since tomorrow's ] market largely isn't available to listen to, we must listen to today's ] market, but with our futurist hats on. Basically, I agree with all of the above. I would ask that the directorate consider the full range of market needs (which includes non-IETF activities such as IPX, CLNP, and SNA) in its deliberations. /John From bound@zk3.dec.com Sun Apr 17 23:45:43 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA15003 for ; Sun, 17 Apr 1994 23:51:02 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA28496; Sun, 17 Apr 94 20:45:51 -0700 Received: by xirtlu.zk3.dec.com; id AA09111; Sun, 17 Apr 1994 23:45:49 -0400 Message-Id: <9404180345.AA09111@xirtlu.zk3.dec.com> To: Craig Partridge Cc: ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-Reply-To: Your message of "Sun, 17 Apr 94 15:57:17 PDT." <199404172257.PAA03603@aland.bbn.com> Date: Sun, 17 Apr 94 23:45:43 -0400 X-Mts: smtp Status: O Craig, That was really good. I think it adds a piece necessary to what I said and put it in a better context of the existing market and our future hats, as you stated. I also like the point by Tony Li in his response to Jon about the market will eventually evolve to the correct technology. thanks /jim From bound@zk3.dec.com Sun Apr 17 23:54:08 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA15030 for ; Sun, 17 Apr 1994 23:56:25 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA28877; Sun, 17 Apr 94 20:54:15 -0700 Received: by xirtlu.zk3.dec.com; id AA09177; Sun, 17 Apr 1994 23:54:14 -0400 Message-Id: <9404180354.AA09177@xirtlu.zk3.dec.com> To: John Curran Cc: bound@zk3.dec.com, Jon Crowcroft , ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-Reply-To: Your message of "Sun, 17 Apr 94 20:57:02 EDT." <9404172057.ab10996@nic.near.net> Date: Sun, 17 Apr 94 23:54:08 -0400 X-Mts: smtp Status: O John, OK I understand the issue your raising. We have to make this so good people want to use it and spend money. I am wondering if people will be able to afford to move to IPng now with the economy at present. New stacks with IPng I doubt will be free, except as upgrades or new purchases and this is the service business and not free (also called add on business). /jim From crb@faline.bellcore.com Mon Apr 18 08:03:55 1994 Return-Path: crb@faline.bellcore.com Received: from faline.bellcore.com (faline.bellcore.com [128.96.39.9]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id IAA16183 for ; Mon, 18 Apr 1994 08:04:38 -0400 Received: from localhost (localhost [127.0.0.1]) by faline.bellcore.com (8.6.7/8.6.6) with SMTP id IAA02333; Mon, 18 Apr 1994 08:03:57 -0400 Message-Id: <199404181203.IAA02333@faline.bellcore.com> X-Authentication-Warning: faline.bellcore.com: Host localhost didn't use HELO protocol To: Brian.Carpenter@cern.ch Subject: Re: IPng/ATM requirements paper cc: ipng@cmf.nrl.navy.mil In-reply-to: Your message of Mon, 18 Apr 94 13:42:40 +0200. <9404181142.AA11807@dxcoms.cern.ch> Date: Mon, 18 Apr 94 08:03:55 -0400 From: Chris Brazdziunas Status: O brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) writes: > > Thanks for the IPng/ATM white paper which I found very clear. Thanks for taking the time in reading it! :) > One point is that I think you should refer to Bob Cole's > "Framework" paper; to a first approximation that paper is > independent of IPv4 and could equally apply to IPng. > That paper is an Internet Draft (draft-ietf-atm-framework-doc-00.ps > or draft-ietf-atm-framework-doc-00.txt). Yup, I agree with that. I willl make that change. > I would also suggest that your paper should be sent to the > IP over ATM list for comments. Good point. I will post it this week. That is an excellant place to get feedback (since the readership is huge). > My main observation is that none of the issues raised in Chapter 4 > (which are all valid) actually change the known requirements for > IPng. The tricky part is how to use the signalling phase of > a connection-oriented infrastructure to establish and manage > connections to be used by a connectionless protocol. If we can > solve this for IPv4, we can solve for it any datagram IPng. Oh really? Hmm, hard for me to comment. If this already reiterates a known requirement well then that's great. I understand that this IPng requirement implicitly existed but not necessarily explicitly (i.e. there wasn't a white paper submitted). Is there a white paper that was submitted that states this very same requirement? (just curious) > Oh, a detail: the "Classical" draft is now RFC 1577. Will make that change as well. Appreciate the comments, :) chris ------------ Christina Brazdziunas crb@faline.bellcore.com From brian@dxcoms.cern.ch Mon Apr 18 14:09:56 1994 Return-Path: brian@dxcoms.cern.ch 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 IAA16208 for ; Mon, 18 Apr 1994 08:10:29 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11084; Mon, 18 Apr 1994 14:09:57 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA12675; Mon, 18 Apr 1994 14:09:56 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404181209.AA12675@dxcoms.cern.ch> Subject: Re: IPng/ATM requirements paper To: crb@faline.bellcore.com (Chris Brazdziunas) Date: Mon, 18 Apr 1994 14:09:56 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <199404181203.IAA02333@faline.bellcore.com> from "Chris Brazdziunas" at Apr 18, 94 08:03:55 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: 638 Status: O > > connections to be used by a connectionless protocol. If we can > > solve this for IPv4, we can solve for it any datagram IPng. > > Oh really? Hmm, hard for me to comment. If this already reiterates a > known requirement well then that's great. I understand that this IPng > requirement implicitly existed but not necessarily explicitly (i.e. there > wasn't a white paper submitted). Is there a white paper that was submitted > that states this very same requirement? (just curious) > Not really. I think your paper is useful; it is good news that it does not raise a whole set of new requirements for the IPng header. Brian From bound@zk3.dec.com Mon Apr 18 10:19:39 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA17123 for ; Mon, 18 Apr 1994 10:20:57 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA24724; Mon, 18 Apr 94 07:19:47 -0700 Received: by xirtlu.zk3.dec.com; id AA18429; Mon, 18 Apr 1994 10:19:45 -0400 Message-Id: <9404181419.AA18429@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-Reply-To: Your message of "Mon, 18 Apr 94 08:56:46 +0200." <9404180656.AA02299@dxcoms.cern.ch> Date: Mon, 18 Apr 94 10:19:39 -0400 X-Mts: smtp Status: O Brian, Well said Sir, /jim From scoya@CNRI.Reston.VA.US Mon Apr 18 10:20:13 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA17139 for ; Mon, 18 Apr 1994 10:24:40 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa29255; 18 Apr 94 10:20 EDT To: ipng@cmf.nrl.navy.mil Subject: IPNG Retreat Date: Mon, 18 Apr 94 10:20:13 -0400 From: Steve Coya Message-ID: <9404181020.aa29255@IETF.CNRI.Reston.VA.US> Status: O One of the action items from the April 11 telechat was for me to poll each of the IPNG members to see who would attend the face-to-face meeting on May 19-20 at a facility in O'Hare airport. Please send me a note as to whether or not you will attend. I will consolidate the responses. Steve From kasten@mailserv-D.ftp.com Mon Apr 18 10:33:20 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA17274 for ; Mon, 18 Apr 1994 10:34:26 -0400 Received: from ftp.com by ftp.com ; Mon, 18 Apr 1994 10:34:24 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 18 Apr 1994 10:34:24 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19927; Mon, 18 Apr 94 10:33:20 EDT Date: Mon, 18 Apr 94 10:33:20 EDT Message-Id: <9404181433.AA19927@mailserv-D.ftp.com> To: jcurran@nic.near.net Subject: Re: Independence of transport EIDs From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 2564 Status: O Yeah. Perhaps we want IPng to be subsetable in some manner. There would be a core set of functions that all IPng machines must handle. Then, as needs vary, one could implement/not-implement different additional features. There are two downsides to this: 1. This sort of subsetting could lead to non-interoperable subsets. If we request/allow subsetting, we should adamantly demand that all possible subsets be interoperable. The protocol specifications would have to define all the mappings and transformations needed when going from one subset to another. This gets pretty hairy. 2. All of the things outside of the core-set of functions could be viewed as nice, but not necessary, elements of the protocol. That is, they are optional in some manner. One could then argue that these things are not needed for interoperability. Furthermore, one could argue that given that these are all optional elements, any node can not be 100% certain that any other node will implement the element so no node will use depend or rely on the element (this is the argument used in SNMP-land against optional variables), therefore why not leave the feature out? > ] From: Frank Kastenholz > ] I started wondering whether IPng should be optimized towards the kind > ] of networking that we do today (general purpose computer to g.p. > ] computer) and have these other niches go off and do their own > ] protocols, more specifically tailored to their needs. Then I started > ] thinking more about it and realized that most, if not all, of those > ] highly specific requirements were readily generalizable (?) into > ] requirements that could fit a more 'tradtional' model of > ] internetworking so the question passed from my mind. > > But will the resulting IPng which correctly handles the "fully generalized" > requirements still work in a wall socket application? What if said wall > socket _does_ want to use the security code and the service class code? > Isn't it possible that wall sockets or supercomputers or atm networks will > at some point need capabilities (or _lack_ of capabilities) that we just > can't reconcile with IPng? > > For some strange reason, I can imagine that we will invent new network > layers which are better at certain things than IPng, and it certainly > would be convenient to let them carry the Internet's TCP and UDP traffic > even if such protocols weren't IPng. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From kasten@mailserv-D.ftp.com Mon Apr 18 10:33:33 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA17277 for ; Mon, 18 Apr 1994 10:34:44 -0400 Received: from ftp.com by ftp.com ; Mon, 18 Apr 1994 10:34:37 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 18 Apr 1994 10:34:37 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19942; Mon, 18 Apr 94 10:33:33 EDT Date: Mon, 18 Apr 94 10:33:33 EDT Message-Id: <9404181433.AA19942@mailserv-D.ftp.com> To: ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 6140 Status: O Tony Li's comments.... > ---------------------------------------------------------------------- > Technical stuff: > > Section 4.5 (Cooperative Anarchy): One of the principles that is not > discussed here is that this principle simply does not scale. The point of the principle is that different administrative/technical domains of The Internet should have as much freedom as possible to build and operate their networks. Another way of looking at it is that only a minimum amount of centralized 'operations' and domain-to- domain cooperation should be required. Perhaps this keeps the requirements pretty high... > Section 5.1 (Scaling): In the criteria for scaling, I feel that the > criteria for describing scalable routing is vastly underplayed. Given the > discussion in this section that projects 10**12 networks, how many routes > do we actually have to scale to? Tony is a router vendor. He is asking, as a router vendor, "How much ram should I put in my routers?". The number of routes in the routing table depends on the number of destination networks, how one deals with QOS/etc, and how well a routing architecture can do things like aggregation of routes. It is conceivable that every router must have O(#networks in the net) routes in it, it is also not absolutely inconceivable that every router merely needs to have O(#interfaces on the router) routes in it. To me, specifying the number of routes is starting to get close to specifying a solution, so I am averse to adding such a specification. (On the other hand, adding text to the req's that say why we are not specifying this is fine...) > Section 5.2 (Toplogical Flexibility): I believe that this is a Motherhood > checklist item and can be related until later in the discussion, if not > wholly eliminated as being completely assumed as we're following the IPv4 > model. In fact, I believe that you should take IPv4 as a baseline > throughout the document. All proposals must be functionally equivalent to > IPv4 Plus meet these criteria... I do not believe this to be motherhood. There has been talk in certain proposals of the actual protocol constraining the topology in certain ways (some of the discussions on geographic-based addressing come to mind). I do not feel that an IP should constrain the physical topology. Re motherhood in general -- some of the things that Tony calls motherhood may, in fact, be motherhood. But mentioning them will certainly remind us that, while motherhood, they still need to be dealt with. Also, some of the motherhood requirements set fairly high detailed requirements (such as Byzantine Failure Protection in 'Robust Service', and some of the performance numbers). This is, in part, Dave Clark's principle of 'In Your Face Requirements', and in part that there must be a benefit to IPng and by raising the level of requirements as we have, we will get IPng to be a lot more than "IPv4 with Larger Addresses". > Section 5.6 (Media Independence): Motherhood. Perhaps this is an > appropriate place to require that there not be an analog of the IPv4 subnet > model. I think that what he wants to say is that the addressing hierarchy not have hard and fast limits (ala the 32 bit ip address with its fixed address classes, etc). I think that we cover this in things like topological flexibility. > Section 5.8 (Config, Admin & Ops): Autoconfiguration must be given a much > more significant role. As I pointed out at one ROAD meeting, the number of > network nerds needed to run the Internet is NOT boundless and are harder to > acquire than really big routers. I agree. I do not know how to write this in the requirements document (put a phrase such as "we think that this is really really important" in the text.... not). Suggestions are solicited (though see my next comment). > My feeling is that autoconfiguration is > the number three requirement for IPng (behind scaling and security). At one point we (Craig and I) tried to make this an ordered list of requirements (and I thought it went pretty well). The current list is not ordered. We can certainly do this again, though the discussion and debate may certainly be spirited and lively... > Section 5.10 (Unique Naming): I suggest you add the requirement that the > architecture specifically allow the naming of interfaces AND nodes. We say that you must be able to name all IP-Layer objects. I assume this includes interfaces. I can add some clarification text. > Section 5.12 (Multicast): Part of me, deep down, really wonders whether > "multicast addressing" isn't an oxymoron. In many cases, the multicast > address isn't an "address" at all in that it has no topological > signifigance. It IS however, a name for a multicast group. Perhaps you > should not dissuade this alternate path of thought and should instead > concentrate on multicast naming. You should take the words "network" and > "subnetwork" out of your vocabulary. They have too much baggage and > confusion. He is absolutely correct. We have been a bit loose with our wording in some places. I think, however, that the intent of the section is clear. If I get a chance I can try to update the text a bit. > The discussion of multicast scoping capabilities needs much > more work. How? What? > Section 5.13 (Extensibility): Please remove the discussion of IPv4 options. > It's wholly inaccurate. Anyone who doens't understand that this is a > chicken and egg problem is welcome to come discuss this with me. The text that I can find is 'the use of options has proven less than entirely satisfactory since options have tended to be inefficient to process' We do not prohibit options. We do point out (in a suitably vague manner I believe) that options are not perfect and that there have been problems with them. A protocol designer should consider carefully how options are to be implemented and processed if that designer's protocol uses them. (perhaps adding this type of text to the document will be satisfactory...) -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From kasten@mailserv-D.ftp.com Mon Apr 18 10:33:40 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA17280 for ; Mon, 18 Apr 1994 10:34:45 -0400 Received: from ftp.com by ftp.com ; Mon, 18 Apr 1994 10:34:43 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 18 Apr 1994 10:34:43 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19945; Mon, 18 Apr 94 10:33:40 EDT Date: Mon, 18 Apr 94 10:33:40 EDT Message-Id: <9404181433.AA19945@mailserv-D.ftp.com> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: Criteria review comments From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 2507 Status: O > >Section 4.5 (Cooperative Anarchy): One of the principles that is not > >discussed here is that this principle simply does not scale. > > i think you misinterpret this - cooperative anarchy, in my reading, > refers to how we plug the internet together hop by hop, incrementally, > without having to do an n**2 agreement before attaching a new site at > any edge...or a new regional to a backbone, or a new backbone to > another backbone...the phone net does not have this property, and so > cost a lot more andf took a lot longer to get as big as it is... > > >as alternative technologies are developed in a single area, you get into > >the N^2 problem of their interaction. We see this frequently in routing > >protocols. > > i don't think we are advocateing anarchic development of technology - > just the facility to manage the net this way, as opposed to the > expensive way the telcos do it. yup > >Section 5.6 (Media Independence): Motherhood. Perhaps this is an > >appropriate place to require that there not be an analog of the IPv4 subnet > >model. > > i think it was menat as a warning shot to atm people...maybe it should > be more clear about IPng operating _over_ large (VC) clouds as well as > standard stuff... how do you mean? > >Section 5.12 (Multicast): Part of me, deep down, really wonders whether > >"multicast addressing" isn't an oxymoron. In many cases, the multicast > >address isn't an "address" at all in that it has no topological > >signifigance. > i agree scoping needs thinking about... how? what? > >Section 5.17 (Tunneling): This is NOT a requirement. In fact, given > >section 5.7, it's already allowed. > > actually, i think it should be removed as its a technique, not a > requirement - the requirement is that > a) you can build virtual private internets on the internet (c.f. > mbone) > b) you can build virtual private any-nets o nthe internet (c.f. > clnp/decnet use in the UK, which is largely tunneled over the IP > backbone) - I think that this is a better way to state why we put tunneling into the document. Tunneling can then be mentioned in the discussion section as how it is done today. (sometimes it's easier to first mention the desired solution and then reason backwards to the requirement for that solution.). How does the group feel about changing the requirement in this manner? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From kasten@mailserv-D.ftp.com Mon Apr 18 10:33:46 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA17289 for ; Mon, 18 Apr 1994 10:35:18 -0400 Received: from ftp.com by ftp.com ; Mon, 18 Apr 1994 10:34:49 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 18 Apr 1994 10:34:49 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19950; Mon, 18 Apr 94 10:33:46 EDT Date: Mon, 18 Apr 94 10:33:46 EDT Message-Id: <9404181433.AA19950@mailserv-D.ftp.com> To: tli@cisco.com Subject: Re: Criteria review comments From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: J.Crowcroft@cs.ucl.ac.uk, ipng@cmf.nrl.navy.mil Content-Length: 1573 Status: O > at 128 bytes per routing entry, that is 256 Mbytes of routing > tabler. just exactly what is the difficulty of this? my workstation > has that much RAM...this year...we have 3000 workstations here and > only 22 routers - where is the cost problem? > > Why do you assume that you're only going to hold 128 bytes per routing > entry? Why do you ignore all of the other state in the routers that > these requirements dictate (e.g., flow state). I admit that I'm > probably being conservative. Even so, add another order of magnitude > or two. It's still tough to have a scalable routing architecture > unless you specify HOW it scales. Tony. In the requirements document we've tried to word it so that we specify the problems that need to be solved, and not specifying the solutions. If we start specifying solutions then we really start to specify the protocol and that is not what our goal is. You are right. Specifying how the routing architecture scales is critical. In fact, if I were king, I'd absolutely require that any proposal have a detailed specification showing this. However, specifying how a routing architecture scales is a part of the solution -- some people may wish to use very hierarchical addressing, some may wish to have very flat addressing with mongo thrust in the routers. I do not think that we can say, in the requirements document, that routing must scale in such and such a manner. We can say only that it must scale. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From bound@zk3.dec.com Mon Apr 18 11:00:29 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA17501 for ; Mon, 18 Apr 1994 11:07:17 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA26646; Mon, 18 Apr 94 08:00:41 -0700 Received: by xirtlu.zk3.dec.com; id AA19886; Mon, 18 Apr 1994 11:00:36 -0400 Message-Id: <9404181500.AA19886@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: J.Crowcroft@cs.ucl.ac.uk, ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-Reply-To: Your message of "Mon, 18 Apr 94 10:33:40 EDT." <9404181433.AA19945@mailserv-D.ftp.com> Date: Mon, 18 Apr 94 11:00:29 -0400 X-Mts: smtp Status: O ================================================= > >Section 5.17 (Tunneling): This is NOT a requirement. In fact, given > >section 5.7, it's already allowed. > > actually, i think it should be removed as its a technique, not a > requirement - the requirement is that > a) you can build virtual private internets on the internet (c.f. > mbone) > b) you can build virtual private any-nets o nthe internet (c.f. > clnp/decnet use in the UK, which is largely tunneled over the IP > backbone) - I think that this is a better way to state why we put tunneling into the document. Tunneling can then be mentioned in the discussion section as how it is done today. (sometimes it's easier to first mention the desired solution and then reason backwards to the requirement for that solution.). How does the group feel about changing the requirement in this manner? ====================================================== Fine by me. I also agree with your logic regarding solution and then reasons. /jim From bound@zk3.dec.com Mon Apr 18 11:05:48 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA17522 for ; Mon, 18 Apr 1994 11:11:49 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA26938; Mon, 18 Apr 94 08:05:55 -0700 Received: by xirtlu.zk3.dec.com; id AA19957; Mon, 18 Apr 1994 11:05:54 -0400 Message-Id: <9404181505.AA19957@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-Reply-To: Your message of "Mon, 18 Apr 94 10:33:33 EDT." <9404181433.AA19942@mailserv-D.ftp.com> Date: Mon, 18 Apr 94 11:05:48 -0400 X-Mts: smtp Status: O ================================================================== > ---------------------------------------------------------------------- > Technical stuff: > > Section 4.5 (Cooperative Anarchy): One of the principles that is not > discussed here is that this principle simply does not scale. The point of the principle is that different administrative/technical domains of The Internet should have as much freedom as possible to build and operate their networks. Another way of looking at it is that only a minimum amount of centralized 'operations' and domain-to- domain cooperation should be required. Perhaps this keeps the requirements pretty high... ================================================================= I think this is important to add to the reqs discussion. I think explaining how the telcos do it and how its done today for IP would be a valuable point of reference for readers. For example when I present how IP works to folks who don't know I get into this anarchy discussion and its a key point for folks to understand. In this doc its key that folks understand as much as possible why we have made this requirement. thanks /jim From ericf@atc.boeing.com Mon Apr 18 09:44:09 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA18167 for ; Mon, 18 Apr 1994 12:43:07 -0400 Received: by atc.boeing.com (5.57) id AA27611; Mon, 18 Apr 94 09:44:09 -0700 Date: Mon, 18 Apr 94 09:44:09 -0700 From: Eric Fleischman Message-Id: <9404181644.AA27611@atc.boeing.com> To: J.Crowcroft@cs.ucl.ac.uk, bound@zk3.dec.com Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... Cc: ipng@cmf.nrl.navy.mil Status: O Dear Jon, Jim wasn't arguing for ISO-morphism. Nobody (that I know of) in this community would argue for such a thing. He was rather arguing for two things: 1) We all need to be honest, impartial, and ego-less in our IPng efforts. We must not become emotionally attached to anything. We must be always open to logic and truth -- whether we "like" what it is saying or not. 2) All engineering efforts come with requirements. Customers provide "working engineers" [as distinct from researchers -- no attempt at pejoratativeness in the term, only a native inability on my part to speak English] with our requirements. We must not "pick and choose" our customers to only choose those who agree with us. To do so is to cripple the IPng before it is ever deployed. Requirements must be real and reflective of the actual market. Sincerely yours, --Eric Fleischman > From: Jon Crowcroft > if we don't design/choose the best technical protocol, we are guilty > of ISO-morphism, committee/consensus engineering: a very bad thing. > The very opposite of what the internet ENGINEERING task force was all > about From ericf@atc.boeing.com Mon Apr 18 10:09:02 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA18610 for ; Mon, 18 Apr 1994 13:07:44 -0400 Received: by atc.boeing.com (5.57) id AA00329; Mon, 18 Apr 94 10:09:02 -0700 Date: Mon, 18 Apr 94 10:09:02 -0700 From: Eric Fleischman Message-Id: <9404181709.AA00329@atc.boeing.com> To: J.Crowcroft@cs.ucl.ac.uk, tli@cisco.com Subject: Re: Criteria review comments Cc: ipng@cmf.nrl.navy.mil Status: O Dear Group, Tut, Tut. I assume that the smiley face of this comment was inadvertently omitted. That is, it is obvious to so many of us that Cisco and many other companies are investing a great deal of money in IPng already. I certainly am grateful for the time and expense these companies are expending. Anyway, a company would be taking a big risk to have "IPng products" on the market now since IPng has not yet been defined enough for productization. Even should IPng be defined it still may be unfeasible from a product and marketing perspective to construct and market such products. In any case, please let's try to keep such unfair "ad hominem" statements out of our comments. Sincerely yours, --Eric Fleischman > could benefit more in the end than the document...actually, if cisco > would invest a bit in IPng products, i'm sure we'd all be most > pleased... From ericf@atc.boeing.com Mon Apr 18 11:20:34 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA19422 for ; Mon, 18 Apr 1994 14:19:39 -0400 Received: by atc.boeing.com (5.57) id AA08172; Mon, 18 Apr 94 11:20:34 -0700 Date: Mon, 18 Apr 94 11:20:34 -0700 From: Eric Fleischman Message-Id: <9404181820.AA08172@atc.boeing.com> To: craig@aland.bbn.com, jcurran@nic.near.net Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Status: O Dear Group, I agree with John's response below -- except for his last line which says that we should be concerned about SNA. I believe that we (the IETF re. IPng) should ONLY be concerned with convergence for widely deployed CONNECTIONLESS NETWORK PROTOCOLS. This does not include SNA which is (simplistically put) connection-oriented [actually, the connection is at the data link layer, the network layer (i.e., Path Control Layer) is almost null -- and WAS null back when it was originally defined in the '70s -- see Cypser 1978]. I am, of course, speaking about what most people think of when they say SNA: SNA as per "3270 Data Streams" and "5250 Data Streams" (including LU 0, 1, 2, 3, 4, 6, 6.1, and 7), SNA LU 6.2 (including APPC), and APPN. I am, of course, not speaking about MPTN which which is essentially transport independent and will handle IPng -- whatever it will prove to be, since it already handles (theoretically, at least) IPv4, CLNP, and IPX. Sincerely yours, --Eric Fleischman ========================== from John Below +++++++++++++++++++++ Date: Sun, 17 Apr 1994 21:01:22 -0400 From: John Curran Message-Id: <9404172102.aa11188@nic.near.net> Status: RO -------- ] From: Craig Partridge ] Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... ] Date: Sun, 17 Apr 94 15:57:17 -0700 ] ... ] I think our task is to listen to the market as it will be in 3 to 5 years. ] Realistically, picking an IPng this summer is simply one of the major steps ] in getting it deployed over the next few years. So the mass-market IPng ] impact (when almost everyone's got it) probably won't hit until around 1997. ] And it is what folks want then that we'd better hit. Agreed. ] Of course, if we can meet market needs *now*, then it hastens the deployment ] of IPng by a year or two. (Look at how fast Van's TCP mods got around, vs ] how long it has taken for IP multicast. Folks desperately needed Van's mods. ] Multicast looked nice but not essential to them). ] ] This is an intensely tricky business, but critical. (Consider if we were ] building PCs, and decided to design a new PC to meet today's market needs. ] When our new PC hit the market in 18 months, we'd find that no one would ] buy it. Ditto for IPng.) More agreement. ] And this is where a lot of engineering comes in. What problems can we ] have solved in the next two years that the market is likely to want us ] to have solved (two years isn't much time, so damn few, but a few). ] And which problems of today may go by the wayside? (SNA convergence perhaps?) ] ] So I agree with Jim that we listen to the market -- and since tomorrow's ] market largely isn't available to listen to, we must listen to today's ] market, but with our futurist hats on. Basically, I agree with all of the above. I would ask that the directorate consider the full range of market needs (which includes non-IETF activities such as IPX, CLNP, and SNA) in its deliberations. /John From ericf@atc.boeing.com Mon Apr 18 11:27:49 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA19544 for ; Mon, 18 Apr 1994 14:26:17 -0400 Received: by atc.boeing.com (5.57) id AA09037; Mon, 18 Apr 94 11:27:49 -0700 Date: Mon, 18 Apr 94 11:27:49 -0700 From: Eric Fleischman Message-Id: <9404181827.AA09037@atc.boeing.com> To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments Status: O Jim, When we evaluate the IPng proposals we must do so in terms of the requirements. The requirements must be written down. If we don't write "political things" into the requirements then we must not use "political things" as a determining factor between IPng alternatives. Everything must be "above board" and "with a clear paper trail". --Eric From sob@hsdndev.harvard.edu Mon Apr 18 14:34:26 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA19589 for ; Mon, 18 Apr 1994 14:35:09 -0400 Date: Mon, 18 Apr 94 14:34:26 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404181834.AA15551@hsdndev.harvard.edu> To: craig@aland.bbn.com, ericf@atc.boeing.com, jcurran@nic.near.net Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Status: O yeh, it is a bit of a strech to see that IPng could support transition from SNA real easy other than in the way that MPTN does it. In addition to the connection-oriented assumptions there are a lot of pritorization tweaks that would be quite hard to support. Scott From sob@hsdndev.harvard.edu Mon Apr 18 14:36:51 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA19644 for ; Mon, 18 Apr 1994 14:37:28 -0400 Date: Mon, 18 Apr 94 14:36:51 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404181836.AA15593@hsdndev.harvard.edu> To: bound@zk3.dec.com, ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments Status: O does this produce another argument for Brian's suggestion of a 2nd document? Scott >From ipng-request@cmf.nrl.navy.mil Mon Apr 18 14:32:49 1994 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA10490; Mon, 18 Apr 1994 14:36:26 -0400 Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA19544 for ; Mon, 18 Apr 1994 14:26:17 -0400 Received: by atc.boeing.com (5.57) id AA09037; Mon, 18 Apr 94 11:27:49 -0700 Date: Mon, 18 Apr 94 11:27:49 -0700 From: Eric Fleischman Message-Id: <9404181827.AA09037@atc.boeing.com> To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments Status: R Jim, When we evaluate the IPng proposals we must do so in terms of the requirements. The requirements must be written down. If we don't write "political things" into the requirements then we must not use "political things" as a determining factor between IPng alternatives. Everything must be "above board" and "with a clear paper trail". --Eric From ericf@atc.boeing.com Mon Apr 18 11:50:09 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA19758 for ; Mon, 18 Apr 1994 14:48:33 -0400 Received: by atc.boeing.com (5.57) id AA12108; Mon, 18 Apr 94 11:50:09 -0700 Date: Mon, 18 Apr 94 11:50:09 -0700 From: Eric Fleischman Message-Id: <9404181850.AA12108@atc.boeing.com> To: bound@zk3.dec.com, ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: Criteria review comments Cc: ericf Status: O Dear Scott, I agree with you: we either need to construct a second "political" requirements document an adjunct for Frank's "technical" IPng requirements doc (as per Brian's original suggestion) or else we need to have Frank add these consensus-ized matters into his document. In my own mind the latter is the preferable approach because I see having a single document as preferable to having two documents -- and these so-called "political" things are demonstrably as technical as the so-called "technical" things already in his document. This, anyway, is my personal opinion. --Eric Fleischman =================================== >From sob@hsdndev.harvard.edu Mon Apr 18 11:39:09 1994 does this produce another argument for Brian's suggestion of a 2nd document? Scott >From ipng-request@cmf.nrl.navy.mil Mon Apr 18 14:32:49 1994 From: Eric Fleischman To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments Jim, When we evaluate the IPng proposals we must do so in terms of the requirements. The requirements must be written down. If we don't write "political things" into the requirements then we must not use "political things" as a determining factor between IPng alternatives. Everything must be "above board" and "with a clear paper trail". --Eric From tli@cisco.com Mon Apr 18 11:55:31 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id OAA19794 for ; Mon, 18 Apr 1994 14:56:18 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA18676; Mon, 18 Apr 1994 11:55:31 -0700 Date: Mon, 18 Apr 1994 11:55:31 -0700 From: Tony Li Message-Id: <199404181855.LAA18676@lager.cisco.com> To: kasten@ftp.com Cc: J.Crowcroft@cs.ucl.ac.uk, ipng@cmf.nrl.navy.mil In-Reply-To: Frank Kastenholz's message of Mon, 18 Apr 94 10:33:46 EDT <9404181433.AA19950@mailserv-D.ftp.com> Subject: Criteria review comments Status: O Tony. In the requirements document we've tried to word it so that we specify the problems that need to be solved, and not specifying the solutions. If we start specifying solutions then we really start to specify the protocol and that is not what our goal is. You are right. Specifying how the routing architecture scales is critical. In fact, if I were king, I'd absolutely require that any proposal have a detailed specification showing this. However, specifying how a routing architecture scales is a part of the solution -- some people may wish to use very hierarchical addressing, some may wish to have very flat addressing with mongo thrust in the routers. I do not think that we can say, in the requirements document, that routing must scale in such and such a manner. We can say only that it must scale. Frank, You're missing the point. You have not specified what a "solution" looks like. Routing which scales "much less than linearly" is NOT an adequate characterization. Think of this as an RFP. How do you tell if someone is compliant or not? You must supply at least an upper bound on how routing should scale. Devil's advocate position: Pre-CIDR IPv4 routing "scales" well enough to meet the criteria in the document. Tony From craig@aland.bbn.com Mon Apr 18 12:06:50 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA19908 for ; Mon, 18 Apr 1994 15:09:22 -0400 Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA14165 for ipng@cmf.nrl.navy.mil; Mon, 18 Apr 94 15:08:45 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id MAA04426; Mon, 18 Apr 1994 12:06:52 -0700 Message-Id: <199404181906.MAA04426@aland.bbn.com> To: ipng@cmf.nrl.navy.mil Subject: what the req doc tries to do Reply-To: Craig Partridge From: Craig Partridge Date: Mon, 18 Apr 94 12:06:50 -0700 Sender: craig@aland.bbn.com Status: O Hi folks: I'm only skimming notes, but I'm getting worried by a trend in some of the discussion... There seems to be a notion that the requirements document ennumerates all the requirements for IPng. I have two serious problems with that idea: 1. It wasn't what the requirements document set out to do. In particular, what Frank and I were trying to was establish sort of the minimum set of requirements to even be considered. (I.e., you have to be this tall to ride on the amusement park ride). 2. It is a process method I think doesn't work. Because what inevitably happens is that the writing of the requirements becomes the decision process. (I.e., someone wants requirement Y, others resist because it blows away a proposal they treasure). And the requirements process is a terrible way to make the final decision. I can't rationally write a requirement that says "the IPng forwarding code must be less than 10 instructions long" -- too arbitrary -- yet, in the final process, you may want to consider the fact that say, RUTABEGA (a yet undeveloped proposal), does IPng in 10 instructions and thus looks nice and lean and mean. And the requirements document can't balance out notions like proposal A has outstanding support for feature F but not for feature G, while proposal B has outstanding support for feature G and not F. What I'd much prefer to see is the following: A. We keep the requirements document largely as is. Frank and I need to polish up the wording -- it is clear to me that readers are misunderstanding pieces of it, and we should try to fix that. B. The requirements document is the standard of entry. (If you pass these tests, we'll consider you). It admits of different technical solutions C. If there are larger, political goals, those are separate (guides to the final decision process). D. Folks seriously work to compare and contrast the strengths and weaknesses of the viable proposals (and require enough material from the different proposals that this is feasible -- for instance, I'm afraid I think TURNIP is currently too vaporware-ish for consideration). Craig E-mail: craig@aland.bbn.com or craig@bbn.com From craig@aland.bbn.com Mon Apr 18 12:14:02 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA20112 for ; Mon, 18 Apr 1994 15:20:44 -0400 Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA15108 for ipng@cmf.nrl.navy.mil; Mon, 18 Apr 94 15:16:00 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id MAA04505; Mon, 18 Apr 1994 12:14:04 -0700 Message-Id: <199404181914.MAA04505@aland.bbn.com> To: Tony Li Cc: kasten@ftp.com, J.Crowcroft@cs.ucl.ac.uk, ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-Reply-To: Your message of Mon, 18 Apr 94 11:55:31 -0700. <199404181855.LAA18676@lager.cisco.com> From: Craig Partridge Date: Mon, 18 Apr 94 12:14:02 -0700 Sender: craig@aland.bbn.com Status: O You're missing the point. You have not specified what a "solution" looks like. Routing which scales "much less than linearly" is NOT an adequate characterization. Think of this as an RFP. How do you tell if someone is compliant or not? You must supply at least an upper bound on how routing should scale. Tony: But this is not an RFP. Think of this as a BAA. If you can show us credibly that you've got a proposal that appears to meet these requirements bring it forward. Detailed proposals will then be required of those who are actually deemed to fit the need. Craig From tli@cisco.com Mon Apr 18 12:41:36 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id PAA20304 for ; Mon, 18 Apr 1994 15:43:26 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA22169; Mon, 18 Apr 1994 12:41:36 -0700 Date: Mon, 18 Apr 1994 12:41:36 -0700 From: Tony Li Message-Id: <199404181941.MAA22169@lager.cisco.com> To: craig@aland.bbn.com Cc: kasten@ftp.com, J.Crowcroft@cs.ucl.ac.uk, ipng@cmf.nrl.navy.mil In-Reply-To: Craig Partridge's message of Mon, 18 Apr 94 12:14:02 -0700 <199404181914.MAA04505@aland.bbn.com> Subject: Criteria review comments Status: O But this is not an RFP. Think of this as a BAA. If you can show us credibly that you've got a proposal that appears to meet these requirements bring it forward. Detailed proposals will then be required of those who are actually deemed to fit the need. Argh. You're still missing the point. Would it help if I screamed? ;-) THE REQUIREMENT FOR ROUTING SCALABILITY IS UNDERSPECIFIED. Whew. That's better. ;-) This is not about my proposal or anyone else's proposal. The point is that the requirements document is a yardstick. You've drawn a line and said "you must be at least this tall". Unfortunately, where you've drawn that line in the routing scalability is 1'2" tall. The fact is that the real requirement is about 4', so that the seatbelt will at least hold. The requirements as written could conceivably permit a 2' tall proposal to be accepted. One way of satisfying my comment would be to put a firm metric on HOW well routing must scale. Tony From bound@zk3.dec.com Mon Apr 18 17:54:44 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA00283 for ; Mon, 18 Apr 1994 17:56:12 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA17387; Mon, 18 Apr 94 14:54:55 -0700 Received: by xirtlu.zk3.dec.com; id AA28410; Mon, 18 Apr 1994 17:54:50 -0400 Message-Id: <9404182154.AA28410@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-Reply-To: Your message of "Mon, 18 Apr 94 11:27:49 PDT." <9404181827.AA09037@atc.boeing.com> Date: Mon, 18 Apr 94 17:54:44 -0400 X-Mts: smtp Status: O Eric, >When we evaluate the IPng proposals we must do so in terms of the >requirements. The requirements must be written down. If we don't >write "political things" into the requirements then we must not use >"political things" as a determining factor between IPng alternatives. >Everything must be "above board" and "with a clear paper trail". I agree completely. But what about the technical parts that are not in the requirements. For example which proposal processes options better, how each proposals address strategy is handled by a host in my case, and the affect of one proposal aligning fields in the header the other not. These are all pieces that will affect my selection input as an idividual to the group, but these are not in the requirements document. But I don't want to do this in a vaccum and then just say I am for proposal X. I want to see technical discussion of each proposals technical components and its overall approach at the detail level. This is not written in the requirements. I have kept saying all the time on the telechats how do we discuss (based on what fulcrum) technical implementation effects of each proposal. These are not political issues but technical ones. p.s. later this week I will send out a short analysis on these subjects for discussion too. I think its high time we had a little bit of honest to goodness technical discussion in addition to all this process work. /jim From bound@zk3.dec.com Mon Apr 18 18:05:32 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA00436 for ; Mon, 18 Apr 1994 18:11:51 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA17991; Mon, 18 Apr 94 15:05:39 -0700 Received: by xirtlu.zk3.dec.com; id AA28571; Mon, 18 Apr 1994 18:05:38 -0400 Message-Id: <9404182205.AA28571@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-Reply-To: Your message of "Mon, 18 Apr 94 14:36:51 EDT." <9404181836.AA15593@hsdndev.harvard.edu> Date: Mon, 18 Apr 94 18:05:32 -0400 X-Mts: smtp Status: O >does this produce another argument for Brian's suggestion of a 2nd >document? I think my follow up to Eric does and maybe is my answer but the problem with what I am concerned with will be that I am getting at the nasty parts of IPng and they will definitely give us red meat to chew on and will not be good for the weak at heart. Kind of like assembly code vs high level code. The requirements are the high level code and the implementation issues are the assembly code. But now I am wondering if my issues can be discussed as a sub-category under Robustness? But I think the political issues should not be called Environment Issues but Political Issues so its very clear thats what the discusssion is all about. Its very bad to mix technical and political discussions. For example. Using NSAPs can be technical and political. NSAPs could provide a very nice way of handling an address structure but not use the ISO form or definitions. But whether to use ISO or GOSIP could be a political discussion. For example the present 20 octet format is not a power of 2. This is very nasty technically in my view of the world and I have even come up with work arounds. But then you may need a political discussion of not using the ISO strategy. Its ABSOLUTELY critical to separate the two discussions. This will foster a good debate and keep folks focused. I would be very annoyed though if all we talk about are the political issues for example with NSAPs and not the technical ones. Unless we differentitate the two discussions I have learned that too often the political discussion over rules the debate. This is not good and can be avoided by calling it out for what it is )---> political. This is not my idea but one of those group dynamics courses I took in life during my career. Its seems to be useful finally. /jim From bound@zk3.dec.com Mon Apr 18 18:14:57 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA00496 for ; Mon, 18 Apr 1994 18:21:44 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA18605; Mon, 18 Apr 94 15:15:05 -0700 Received: by xirtlu.zk3.dec.com; id AA28653; Mon, 18 Apr 1994 18:15:03 -0400 Message-Id: <9404182215.AA28653@xirtlu.zk3.dec.com> To: Craig Partridge Cc: ipng@cmf.nrl.navy.mil Subject: Re: what the req doc tries to do In-Reply-To: Your message of "Mon, 18 Apr 94 12:06:50 PDT." <199404181906.MAA04426@aland.bbn.com> Date: Mon, 18 Apr 94 18:14:57 -0400 X-Mts: smtp Status: O +++++++++++++++++++++++++++++++++++++++++++++++ What I'd much prefer to see is the following: A. We keep the requirements document largely as is. Frank and I need to polish up the wording -- it is clear to me that readers are misunderstanding pieces of it, and we should try to fix that. B. The requirements document is the standard of entry. (If you pass these tests, we'll consider you). It admits of different technical solutions C. If there are larger, political goals, those are separate (guides to the final decision process). D. Folks seriously work to compare and contrast the strengths and weaknesses of the viable proposals (and require enough material from the different proposals that this is feasible -- for instance, I'm afraid I think TURNIP is currently too vaporware-ish for consideration). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I agree 100% lets just do this OK. My point is addressed with section D. This needs to be done and I am doing it now. I can't wait any longer because in addition to Directorate work and IETF work I have to do AD work too. I am using the requirements too but it does not mean I can ignore section D. I already gave my view on mergers. It has nothing to do with Turnip I am just going to be hardlined here. If we can get a merger going lets do it or just forget it. We need CATNIP, SIPP, and TUBA to do this and we can provide the leadership to move it to fruition. But we are not doing this except off line. Its needs to be brought onlne. I am willing to bring in my off line work for a merger if everyone else is? /jim From bound@zk3.dec.com Mon Apr 18 18:22:20 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA00515 for ; Mon, 18 Apr 1994 18:26:17 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA19007; Mon, 18 Apr 94 15:22:28 -0700 Received: by xirtlu.zk3.dec.com; id AA28710; Mon, 18 Apr 1994 18:22:26 -0400 Message-Id: <9404182222.AA28710@xirtlu.zk3.dec.com> To: Tony Li Cc: ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-Reply-To: Your message of "Mon, 18 Apr 94 12:41:36 PDT." <199404181941.MAA22169@lager.cisco.com> Date: Mon, 18 Apr 94 18:22:20 -0400 X-Mts: smtp Status: O Tony, Would you be willing to write a short example of how the requirement should look? thanks /jim From tli@cisco.com Mon Apr 18 18:42:05 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA01164 for ; Mon, 18 Apr 1994 21:46:29 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA17406; Mon, 18 Apr 1994 18:42:05 -0700 Date: Mon, 18 Apr 1994 18:42:05 -0700 From: Tony Li Message-Id: <199404190142.SAA17406@lager.cisco.com> To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil In-Reply-To: bound@zk3.dec.com's message of Mon, 18 Apr 94 18:22:20 -0400 <9404182222.AA28710@xirtlu.zk3.dec.com> Subject: Criteria review comments Status: O Would you be willing to write a short example of how the requirement should look? Certainly: 5.1. Scale CRITERION The IPng Protocol must scale to allow the identification and addressing of 10**12 end systems. The IPng Protocol, and its associated routing protocols and architecture must allow for at least 10**9 individual networks. The routing schemes must scale at a rate that is less than the square root of the number of constituent networks. BTW, the sqare root is not wholly random. I spent some time playing. It works rather nicely: sqrt(10^12) 1000000 sqrt(10^15) 31622776 sqrt(2*10^6) 1414 sqrt(10^9) 31622 sqrt(10^8) 10000 Tony From brian@dxcoms.cern.ch Tue Apr 19 08:52:11 1994 Return-Path: brian@dxcoms.cern.ch 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 CAA01973 for ; Tue, 19 Apr 1994 02:52:45 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16200; Tue, 19 Apr 1994 08:52:13 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09362; Tue, 19 Apr 1994 08:52:11 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404190652.AA09362@dxcoms.cern.ch> Subject: Route scaling [was: Criteria review comments] To: tli@cisco.com (Tony Li) Date: Tue, 19 Apr 1994 08:52:11 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <199404190142.SAA17406@lager.cisco.com> from "Tony Li" at Apr 18, 94 06:42:05 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1158 Status: O Tony, Good. Now tell us whether this is actually a constraint on the choice of IPng address and packet format, or only a constraint on the future development of route aggregation mechanisms. That is, are there route aggregation mechanisms that don't care about address format, but scale like sqrt(allocated nets). BTW does CIDR scale as good as that? Brian >--------- Text sent by Tony Li follows: > > > Would you be willing to write a short example of how the requirement > should look? > > Certainly: > > 5.1. Scale > > CRITERION > The IPng Protocol must scale to allow the identification > and addressing of 10**12 end systems. The IPng Protocol, > and its associated routing protocols and architecture > must allow for at least 10**9 individual networks. The > routing schemes must scale at a rate that is less than the square > root of the number of constituent networks. > > BTW, the sqare root is not wholly random. I spent some time playing. > It works rather nicely: > > sqrt(10^12) > 1000000 > sqrt(10^15) > 31622776 > sqrt(2*10^6) > 1414 > sqrt(10^9) > 31622 > sqrt(10^8) > 10000 > > Tony > From brian@dxcoms.cern.ch Tue Apr 19 09:01:06 1994 Return-Path: brian@dxcoms.cern.ch 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 DAA01997 for ; Tue, 19 Apr 1994 03:01:46 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA17064; Tue, 19 Apr 1994 09:01:08 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09642; Tue, 19 Apr 1994 09:01:06 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404190701.AA09642@dxcoms.cern.ch> Subject: Re: what the req doc tries to do To: ipng@cmf.nrl.navy.mil Date: Tue, 19 Apr 1994 09:01:06 +0200 (MET DST) In-Reply-To: <9404182215.AA28653@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Apr 18, 94 06:14:57 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2183 Status: O I fully support Craig and Jim, and for once disagree with Eric. Please let's try to get closure on the document as is in the next seven days, and then write the political requirements document if we have to. I have been trying to think about the merger/compromise/dream ticket approach. If I can write something coherent I will do so, after devoting a few minutes to my day job :-) Brian >--------- Text sent by bound@zk3.dec.com follows: > > > +++++++++++++++++++++++++++++++++++++++++++++++ > What I'd much prefer to see is the following: > > A. We keep the requirements document largely as is. Frank and I need > to polish up the wording -- it is clear to me that readers are > misunderstanding pieces of it, and we should try to fix that. > > B. The requirements document is the standard of entry. (If you pass > these tests, we'll consider you). It admits of different technical > solutions > > C. If there are larger, political goals, those are separate (guides > to the final decision process). > > D. Folks seriously work to compare and contrast the strengths and > weaknesses of the viable proposals (and require enough material from > the different proposals that this is feasible -- for instance, > I'm afraid I think TURNIP is currently too vaporware-ish for > consideration). > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > I agree 100% lets just do this OK. My point is addressed with section > D. This needs to be done and I am doing it now. I can't wait any > longer because in addition to Directorate work and IETF work I have to > do AD work too. I am using the requirements too but it does not mean I > can ignore section D. > > I already gave my view on mergers. It has nothing to do with Turnip I > am just going to be hardlined here. If we can get a merger going lets > do it or just forget it. We need CATNIP, SIPP, and TUBA to do this and > we can provide the leadership to move it to fruition. But we are not > doing this except off line. Its needs to be brought onlne. I am > willing to bring in my off line work for a merger if everyone else is? > > /jim > From tli@cisco.com Tue Apr 19 00:08:57 1994 Return-Path: tli@cisco.com Received: from lager.cisco.com (lager.cisco.com [131.108.11.55]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id DAA02013 for ; Tue, 19 Apr 1994 03:09:34 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA28728; Tue, 19 Apr 1994 00:08:57 -0700 Date: Tue, 19 Apr 1994 00:08:57 -0700 From: Tony Li Message-Id: <199404190708.AAA28728@lager.cisco.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil In-Reply-To: Brian Carpenter CERN-CN's message of Tue, 19 Apr 1994 08:52:11 +0200 (MET DST) <9404190652.AA09362@dxcoms.cern.ch> Subject: Route scaling [was: Criteria review comments] Status: O Good. Now tell us whether this is actually a constraint on the choice of IPng address and packet format, or only a constraint on the future development of route aggregation mechanisms. That is, are there route aggregation mechanisms that don't care about address format, but scale like sqrt(allocated nets). I believe that there aren't any aggregation mechanisms that don't care about the address format. Much less ones that scale well. In any case, the selection process is about a integrated proposal, not about bits and pieces (would that it were ;-). This is a constraint on the addressing and routing architecture, which is a _fundamental_ part of the proposal. BTW does CIDR scale as good as that? CIDR the book or CIDR the movie? In CIDR the book (the theoretical deployment), there is one route per Internet service provider. In the US, there are about a hundred service providers. Extrapolating to the rest of the world, let's call it 300 service providers. Following the square root metric, this would support 10**5 networks. My wild-assed guess is that we have more than that. In CIDR the movie (how it stands today), we have 2*10**4 routes. That should be enough to support 4*10**8 networks. I'm pretty certain that we haven't deployed that many yet. Does anyone have real figures on how many networks (actually, subnetworks) there are in the Internet right now? Tony From brian@dxcoms.cern.ch Tue Apr 19 13:31:46 1994 Return-Path: brian@dxcoms.cern.ch 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 HAA02526 for ; Tue, 19 Apr 1994 07:32:21 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11677; Tue, 19 Apr 1994 13:31:47 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA17643; Tue, 19 Apr 1994 13:31:46 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404191131.AA17643@dxcoms.cern.ch> Subject: New requirement :-) To: ipng@cmf.nrl.navy.mil Date: Tue, 19 Apr 1994 13:31:46 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 748 Status: O It seems that we must require IPng to be immune to The Real Thing. This happened here this weekend: > > > > > I notice that your system has been constantly sending out broadcast > > > packets on the CERN ethernet: these seem to be Address Resolution Protocol > > > (ARP) packets searching for a different system (PTSUN03) > > > > This machine was off over the weekend because I spilled coke on the > > keyboard and it started sending characters continuously to the machine > > which was then beeping all the time. So that solves the mystery... > > > > I'm sorry for the trouble; there just wasn't anything else I could do > > about it during the weekend. Situation was fixed first thing Monday > > morning, as you may have noticed. Brian From kasten@mailserv-D.ftp.com Tue Apr 19 09:22:08 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA03124 for ; Tue, 19 Apr 1994 09:23:14 -0400 Received: from ftp.com by ftp.com ; Tue, 19 Apr 1994 09:23:11 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 19 Apr 1994 09:23:11 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA03512; Tue, 19 Apr 94 09:22:08 EDT Date: Tue, 19 Apr 94 09:22:08 EDT Message-Id: <9404191322.AA03512@mailserv-D.ftp.com> To: Brian.Carpenter@cern.ch Subject: Re: New requirement :-) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 1025 Status: O no. the next job is to develop a coke-wall for keyboards which will prevent unauthorized entry of coke into one's network... > It seems that we must require IPng to be immune to The Real Thing. > This happened here this weekend: > > > > > > > > I notice that your system has been constantly sending out broadcast > > > > packets on the CERN ethernet: these seem to be Address Resolution Protocol > > > > (ARP) packets searching for a different system (PTSUN03) > > > > > > This machine was off over the weekend because I spilled coke on the > > > keyboard and it started sending characters continuously to the machine > > > which was then beeping all the time. So that solves the mystery... > > > > > > I'm sorry for the trouble; there just wasn't anything else I could do > > > about it during the weekend. Situation was fixed first thing Monday > > > morning, as you may have noticed. > > Brian > -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From scoya@CNRI.Reston.VA.US Tue Apr 19 09:33:45 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA03723 for ; Tue, 19 Apr 1994 10:45:15 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa01312; 19 Apr 94 9:33 EDT To: bound@zk3.dec.com cc: Eric Fleischman , ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-reply-to: Your message of "Mon, 18 Apr 94 17:54:44 EDT." <9404182154.AA28410@xirtlu.zk3.dec.com> Date: Tue, 19 Apr 94 09:33:45 -0400 From: Steve Coya Message-ID: <9404190933.aa01312@IETF.CNRI.Reston.VA.US> Status: O Folks, Forgive me for jumping in with my 2 cents worth (I know, but there's this thing called inflation :-), but I'm a little confused about something. I was under the impression that the directorate came to the conclusion/perspective that the requirements document is NOT the one and only evaluation criteria to be utilized in the selection process, but that it should be viewed as, in my own words, an initial hurdle. As I recall, the idea was for each of the IPNG candidates to defend their proposals against the background of the requirements document. It seems to me that "there is more to the [selection] process than evaluating against the requirements document" is shared by many/all, but the confusion seems to be on where to place the "other" criteria: add to the requirements document or create a new document with "the rest of the story." There is, of course, the other problem of identifying the "other criteria" as well. Unfortunately, moving ahead on the other criteria seems to be stuck on the title or label associated with this group: Political, Environmental, robustness, etc. Perhaps focusing on the criteria under a generic "Label to be determined" title will move the focus away from the categorizing and onward towards the other criteria. Just some ramblings.... Steve From bound@zk3.dec.com Tue Apr 19 10:56:02 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA03845 for ; Tue, 19 Apr 1994 11:02:09 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA12583; Tue, 19 Apr 94 07:56:12 -0700 Received: by xirtlu.zk3.dec.com; id AA11350; Tue, 19 Apr 1994 10:56:08 -0400 Message-Id: <9404191456.AA11350@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: New requirement :-) In-Reply-To: Your message of "Tue, 19 Apr 94 09:22:08 EDT." <9404191322.AA03512@mailserv-D.ftp.com> Date: Tue, 19 Apr 94 10:56:02 -0400 X-Mts: smtp Status: O the real thing is intense stuff. one time i spilled some and it went under my workstation. i cleaned it up etc but I had spilled it at my desk while leaving and did not know it and came back about 3 hours later and cleaned it up. well a few weeks later my system would not boot. and it turns out it soaked through the vents and hit my mother board. had to replace it. the field guy told me it wasn't the coke but then he was not sure. i cant believe i drink it. hmmmm but now i am paranoid and keep it on t shelf. also the only time i ever lost my ethernet address too for the autoconfig solve mac layer issues type person in 14 years. /jim From bound@zk3.dec.com Tue Apr 19 11:27:08 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA12720 for ; Tue, 19 Apr 1994 11:32:13 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA14530; Tue, 19 Apr 94 08:27:16 -0700 Received: by xirtlu.zk3.dec.com; id AA12041; Tue, 19 Apr 1994 11:27:14 -0400 Message-Id: <9404191527.AA12041@xirtlu.zk3.dec.com> To: Tony Li Cc: ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-Reply-To: Your message of "Mon, 18 Apr 94 18:42:05 PDT." <199404190142.SAA17406@lager.cisco.com> Date: Tue, 19 Apr 94 11:27:08 -0400 X-Mts: smtp Status: O Tony, thanks I am running behind on my threads... >CRITERION > The IPng Protocol must scale to allow the identification > and addressing of 10**12 end systems. The IPng Protocol, > and its associated routing protocols and architecture > must allow for at least 10**9 individual networks. The > routing schemes must scale at a rate that is less than the square > root of the number of constituent networks. >BTW, the sqare root is not wholly random. I spent some time playing. >It works rather nicely: Yep I just tried other functions and this seems to be the most realistic too. Using your figures as a metric not knowing all the time/space/bandwith contraints you used. /jim From scoya@CNRI.Reston.VA.US Tue Apr 19 11:29:12 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA02987 for ; Tue, 19 Apr 1994 18:35:07 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04140; 19 Apr 94 11:29 EDT To: ipng@cmf.nrl.navy.mil Subject: DRAFT minutes from March 31 Dinner meeting Date: Tue, 19 Apr 94 11:29:12 -0400 From: Steve Coya Message-ID: <9404191129.aa04140@IETF.CNRI.Reston.VA.US> Status: O Sorry for the delay... I thought I'd already send them out. Steve ========================================== DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference Narch 31, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES --------- Scott Bradner / Harvard Allison Mankin / NRL J Allard / Microsoft Jim Bound / DEC Ross Callon / Wellfleet Brian Carpenter / CERN Dave Clark / MIT John Curran / NEARnet Steve Deering / Xerox PARC Dino Farinacci / Cisco Eric Fleischman / Boeing Paul Francis / NTT Mark Knopper / Ameritech Greg Minshall / Novell Frank Solensky / FTP Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets ------- Steve Bellovin / AT&T Jon Crowcroft / UCL Frank Kastenholz / FTP Daniel Karrenberg / RIPE Craig Partridge / BBN Note: This was a dinner meeting held durinr the Seattle IETF meeting 1. The idea of an IPNG directorate reteat was discussed, and it was agreed that not only was it a good idea, it was necessary. It was also suggested that the retreat include non-Directorate invitees (Hinden and Ford we mentioned as examples). 2. A round of "for he's a jolly good fellow" was sung for Scott Bradner (not sure why, though it may be due to his moving tables :-) 3. It was suggested that the Requirements document should NOT be considered as a checklist (missing architectural overviews), but it would be a good idea to have the IPng candidates defend their proposals against the framework of the requirements document. 4. Eric proposed a list of 6 procedural steps or viewpoints that could be taken towards a resolution of the selection process. The six steps are: 1) "Spec Check": compare IPng alternatives to requirements doc 2) Enumerate the real technical differences between proposals in regards to the requirements 3) Enumerate the real operational differences between the proposals 4) Address real deployment and transition plans: contrast dual stack and IPAE transition scenarios 5) Proof of concept: what has actual "running code" to date demostrated about the approach -- address scalability issues if possible. 6) Identify the incentives provided by each approach for users to deploy that option. A comment was made that this list, while good, could not be accomplished in 3-4 months (by the July IETF meeting in Toronto). It was suggested that after item 1 was completed, the entire directorate should review the responses (to #1) as a group, probably at the retreat. 5. There was some spirited discussions on the fact that each proposal had both good and bad points, and it was suggested that a merger of the proposal features might still be possible in the timeframe, and be able to offer an attractive answer. 6. Steve collected the money and paid the bill. No one sang :-) From Robert_Ullmann.LOTUS@CRD.lotus.com Tue Apr 19 12:06:16 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA16277 for ; Tue, 19 Apr 1994 12:00:46 -0400 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com by lotus.com (4.1/SMI-4.1) id AA05035; Tue, 19 Apr 94 12:02:14 EDT Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA02321; Tue, 19 Apr 94 12:06:16 EDT Date: Tue, 19 Apr 94 12:06:16 EDT Message-Id: <9404191606.AA02321@Mail.Lotus.com> Received: by DniMail (v1.0); Tue Apr 19 12:06:13 1994 EDT To: UNIXML::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Re: Criteria review comments Status: O Hi, I exchanged some private mail with Tony Li re "Turnipp". I will try not say anything about his (private) responses, but I would like to repeat here what *I* said there in part. I was disturbed to see TURNIPP suddenly appear on the list; far from being a merger, it has evey indications of trying to be the 4th protocol. It also seemed very familiar, and I asked Tony why he had not made any technical comments on CATNIP, since with his input, it might be tweaked to look almost exactly like TURNIPP (if that was technically the right thing to do, of course :-). It appears he had not read the current CATNIP draft, which explains TURNIPP re-inventing some things. I completely discount his characterization of TURNIPP as a merger proposal; if it had been, I expect he would have discussed it privately with the SIPP/TUBA/CATNIP proponents? In at least one case he did not: I was blind-sided by the appearance of the thing on the mailing list. It is simply unacceptable for a member of the review panel to make a (public) proposal. (I find the idea rather inconceivable, and would not have credited it had I not seen it myself!) ---- An observation, for what it is worth: Apparently there is a perception "outside" of a group roughly corresponding to the IPng directorate that the proposals are in the sort of violent and useless confrontation typical of the usual IETF "open" process. This has not been my experience; I have (as I have said previously) participated in and observed much effort to find common ground, with the rather extraordinary number of mergers (think about it!) being entirely satisfactory evidence that the process has quietly worked. Any attempt to force a merger, in particular any attempt to force a merger to avoid the difficulty of actually making a decision, will be conterproductive; it runs a substantive risk of causing the entire process to fail. With my best regards, Robert From lkeiper@IETF.CNRI.Reston.VA.US Tue Apr 19 17:23:10 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id WAA04160 for ; Tue, 19 Apr 1994 22:31:51 -0400 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa12308; 19 Apr 94 17:22 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Apr 1994 17:23:10 +0100 To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: Re: Ipng Teleconference, April 25, 1994 Cc: lkeiper@IETF.CNRI.Reston.VA.US Message-ID: <9404191722.aa12308@IETF.CNRI.Reston.VA.US> Status: O >>ANNOUNCEMENT > >> >>The names marked with an asterisk are those who have confirmed participation >>for the IPng teleconference scheduled for April 25, 1994 at 11:30 - 1:30 >>EDT. It is very important that I receive your regret/RSVP so accurate >>arrangements can be made with AT&T. It is most appreciated. Thank you. >> >> >> >> >> J. Allard 206-936-9031 >> Steve Bellovin 908-582-5886 >> Jim Bound 603-881-0400 >> Scott Bradner 617-495-3864 >> Ross Callon 508-436-3936 > Brian Carpenter +41 22 767 4967 >> Dave Clark 617-253-6003 > John Crowcroft +44 71 380 7296 >> Steve Coya 703-620-8990* >> John Curran 617-873-4398 >> Steve Deering 415-812-4839 >> Dino Farinacci 408-668-4696 >> Eric Fleischman 206-957-5334 >> Paul Francis +81 33 928 0408 > Frank Kastenholz 508-685-4000 >> Daniel Karrenberg +31 20 592 5065 >> Mark Knopper 313-741-5445 > Craig Partridge 415-812-4415 >> Allison Mankin 202-404-7030 >> Greg Minshall 510-975-4507 > Rob Ullmann 617-693-1315 >> Lixia Zhang 415-812-4415 >> >> >>If you need to be added to the teleconference call in progress, please call >>1-800-232-1234 or for the international participants, 516-424-3151. The call >>can be referenced by the confirmation number -ER90059 in the orginators name, >>Steve Coya. >> >>Thanks >> >> >>Lois >> >> >> > >Lois J. Keiper >IETF Secretariat Lois J. Keiper IETF Secretariat From bound@zk3.dec.com Tue Apr 19 12:37:26 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA19939 for ; Tue, 19 Apr 1994 12:41:53 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA18745; Tue, 19 Apr 94 09:37:34 -0700 Received: by xirtlu.zk3.dec.com; id AA13151; Tue, 19 Apr 1994 12:37:32 -0400 Message-Id: <9404191637.AA13151@xirtlu.zk3.dec.com> To: Steve Coya Cc: ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-Reply-To: Your message of "Tue, 19 Apr 94 09:33:45 EDT." <9404190933.aa01312@IETF.CNRI.Reston.VA.US> Date: Tue, 19 Apr 94 12:37:26 -0400 X-Mts: smtp Status: O Steve, Good points. I think your hitting the heart of the matter. thanks /jim From deering@parc.xerox.com Tue Apr 19 09:37:45 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA19768 for ; Tue, 19 Apr 1994 12:39:59 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14572(5)>; Tue, 19 Apr 1994 09:37:54 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 19 Apr 1994 09:37:50 -0700 To: ipng@cmf.nrl.navy.mil Cc: Robert_Ullmann.LOTUS@crd.lotus.com, deering@parc.xerox.com Subject: Re: Criteria review comments In-reply-to: Robert_Ullmann.LOTUS's message of Tue, 19 Apr 94 09:06:16 -0800. <9404191606.AA02321@Mail.Lotus.com> Date: Tue, 19 Apr 1994 09:37:45 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Apr19.093750pdt.12171@skylark.parc.xerox.com> Status: O I agree entirely with Rob's message, re Turnipp and mergers. (Mind you, whenever I have agreed with Rob in the past, it has been due to my misunderstanding what he was saying. So I will rephrase the above to say: I agree entirely with what I think Rob's message said.) Steve From bound@zk3.dec.com Tue Apr 19 13:05:21 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA22530 for ; Tue, 19 Apr 1994 13:12:25 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20409; Tue, 19 Apr 94 10:05:31 -0700 Received: by xirtlu.zk3.dec.com; id AA13752; Tue, 19 Apr 1994 13:05:27 -0400 Message-Id: <9404191705.AA13752@xirtlu.zk3.dec.com> To: Steve Deering Cc: ipng@cmf.nrl.navy.mil Subject: Re: Criteria review comments In-Reply-To: Your message of "Tue, 19 Apr 94 09:37:45 PDT." <94Apr19.093750pdt.12171@skylark.parc.xerox.com> Date: Tue, 19 Apr 94 13:05:21 -0400 X-Mts: smtp Status: O I agree with Rob too. My reasons are similar and this is not a negative reflection on Tony at all. I think Tony is trying to do the right thing. But the IPng authors and groups have done some good work and we may see ideas shared between them I hope more than the common ground Rob pointed out too if thats possible. But jump to loc via an interrupt and then a shift left logical to our Ipng efforts will make us loose ground not gain ground here. Also to be direct on another issue. Rob has given the community a real nice way of looking at NSAPs generically in CATNIP. This is a great contribution to the IETF in my mind. If this should move forward in any way I really want to hear before I would buy into any of it what Rob thinks as he has spent a lot of time on this. I am not saying we have consensus or even a belief about NSAPs being used but that it is being discussed in many places as a possilbe address structure for IPng and has been for some time. My team is looking at it with me technically right now. I have a rough memo to come to you I hope late this week discussing some key Host issues for addresses and alignment of the header. I wanted my team to critique it first. /jim From pvm@ISI.EDU Tue Apr 19 18:06:09 1994 Return-Path: pvm@ISI.EDU Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA03762 for ; Tue, 19 Apr 1994 21:14:59 -0400 Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 19 Apr 1994 18:08:05 -0700 Message-Id: <199404200108.AA08128@zephyr.isi.edu> To: Eric Fleischman Cc: J.Crowcroft@cs.ucl.ac.uk, bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Reply-To: pvm@ISI.EDU Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-Reply-To: Your message of Mon, 18 Apr 1994 09:44:09 -0700. <9404181644.AA27611@atc.boeing.com> Date: Tue, 19 Apr 94 18:06:09 PDT From: Paul Mockapetris Status: O One perplexing aspect of this (at least to me) is understanding how one could claim to meet the requirements of the market 3-5 years from now. I haven't even seen a hard assesment of today's market, nevermind the market of 3-5 years from now. What percentage of networing is IP? TCP? SMTP? Do we have this data? paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From jcurran@nic.near.net Tue Apr 19 21:55:43 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA03983 for ; Tue, 19 Apr 1994 21:55:51 -0400 Received: from nic.near.net by nic.near.net id aa15359; 19 Apr 94 21:55 EDT To: pvm@isi.edu cc: Eric Fleischman , J.Crowcroft@cs.ucl.ac.uk, bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of Tue, 19 Apr 1994 18:06:09 -0700. <199404200108.AA08128@zephyr.isi.edu> Date: Tue, 19 Apr 1994 21:55:43 -0400 From: John Curran Message-ID: <9404192155.aa15359@nic.near.net> Status: O -------- ] From: Paul Mockapetris ] Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... ] Date: Tue, 19 Apr 94 18:06:09 PDT ] ] One perplexing aspect of this (at least to me) is understanding how ] one could claim to meet the requirements of the market 3-5 years from ] now. I haven't even seen a hard assesment of today's market, ] nevermind the market of 3-5 years from now. I don't know about anyone else, but it's my job to understand at least the Internet portion of the marketplace... ] What percentage of networing is IP? TCP? SMTP? Do we have this data? Yes. WWW will soon own the Internet... it very nicely went from 269GB bytes of traffic in January to more than 518GB in March. It should overtake telnet this month and has good chances of overtaking both SMTP and USENET this summer. Enjoy, /John +----------------------------------------------------------------------------+ /nsfnet/statistics/1994/nsf-9401.highlights NSFNET Traffic Distribution Highlights January 1994 Packet Total: 55,305,691,300 Byte Total: 10,294,076,393,700 Service Name Port Rank Packet Count % Pkts Rank Byte Count % Byts ============ ==== ==== ============ ====== ==== ============= ====== ftp-data 20 1 11821361950 21.375 1 4243108439200 41.219 telnet 23 2 8500414200 15.370 4 601958681450 5.848 nntp 119 3 4847057650 8.764 2 1060704491400 10.304 smtp 25 4 4100307150 7.414 3 658742838150 6.399 domain 53 5 3171676250 5.735 7 291003684550 2.827 icmp -1 6 2003299150 3.622 9 172115071800 1.672 ip -4 7 1595424200 2.885 6 366228809450 3.558 irc 6667 8 1384962300 2.504 10 143662278350 1.396 gopher 70 9 1383479450 2.502 5 374680912550 3.640 ftp 21 10 1111098750 2.009 13 82018088600 0.797 www 80 11 822317950 1.487 8 269129084100 2.614 talk 517 12 736104850 1.331 14 76383585100 0.742 X0 6000 13 438462650 0.793 12 82136810650 0.798 finger 79 14 352819650 0.638 17 27214906200 0.264 vmnet 175 15 351597000 0.636 11 125151410050 1.216 login/who 513 16 308290550 0.557 16 34099214400 0.331 (unknown) 1023 17 267015300 0.483 18 26168689500 0.254 snmp 161 18 161021550 0.291 22 16647386200 0.162 ntp 123 19 155449500 0.281 26 11669593800 0.113 (unknown) 1022 20 108616550 0.196 23 15548569300 0.151 ... --- /nsfnet/statistics/1994/nsf-9403.highlights NSFNET Traffic Distribution Highlights March 1994 Packet Total: 69,552,904,950 Byte Total: 14,024,028,116,050 Service Name Port Rank Packet Count % Pkts Rank Byte Count % Byts ============ ==== ==== ============ ====== ==== ============= ====== ftp-data 20 1 14394123450 20.695 1 5172361872350 36.882 telnet 23 2 9441381850 13.574 5 709310604550 5.058 nntp 119 3 5912849550 8.501 3 1303252804200 9.293 smtp 25 4 5728083300 8.236 4 924617904400 6.593 domain 53 5 3804373500 5.470 8 361196649600 2.576 ip -4 6 3638524900 5.231 2 1309607300850 9.338 icmp -1 7 2827675200 4.066 9 299207268200 2.134 irc 6667 8 1844284450 2.652 10 194778026800 1.389 gopher 70 9 1757346750 2.527 7 480689687200 3.428 www 80 10 1597847800 2.297 6 518083617700 3.694 ftp 21 11 1298729800 1.867 13 104064300800 0.742 X0 6000 12 589419900 0.847 12 129882940050 0.926 vmnet 175 13 441726650 0.635 11 160490243700 1.144 (unknown) 1023 14 340553200 0.490 15 41823940600 0.298 login/who 513 15 338249000 0.486 16 38709987400 0.276 talk 517 16 277395250 0.399 17 28646912050 0.204 snmp 161 17 237883700 0.342 19 26023876200 0.186 finger 79 18 226327400 0.325 18 26116233150 0.186 ntp 123 19 174427550 0.251 31 12988969200 0.093 cmd/syslog 514 20 166404750 0.239 14 49148886250 0.350 ... --- /nsfnet/statistics/history.ports NSFNET History of Usage by Service Percentage of Packets File Networked Inter- Name Other Non- Exchange Mail active Lookup TCP/UDP TCP/UDP Services Services 1989 Aug 20 28 22 15 11 4 Sep 20 31 22 13 11 3 Oct 20 29 22 14 12 3 Nov 19 29 21 16 12 3 Dec 21 27 20 15 13 4 1990 Jan 26 26 19 14 12 3 Feb 25 27 18 13 13 4 Mar 25 27 18 12 13 5 Apr 25 28 20 13 8 6 May 26 26 17 10 16 5 Jun 25 25 18 12 14 6 Jul 25 24 20 12 15 4 Aug 27 24 20 11 15 3 Sep 28 23 19 11 16 3 Oct 23 22 19 14 19 3 Nov 24 23 20 9 22 2 Dec 23 22 18 12 22 3 1991 Jan 22 21 19 11 21 6 Feb 23 23 18 8 25 3 Mar 25 23 19 8 23 2 Apr 23 21 19 8 26 3 May 24 21 17 8 22 8 Jun 26 22 18 8 23 3 Jul 25 20 18 9 25 3 Aug 26 20 17 9 26 2 Sep 27 21 17 8 24 3 Oct 26 20 16 7 28 3 Nov 26 20 15 8 29 2 Dec 28 19 15 9 27 2 1992 Jan 28 21 15 7 27 2 Feb 27 20 15 7 29 2 Mar 29 21 14 7 27 2 Apr 30 19 13 7 29 2 May 31 19 12 10 26 2 --- -- -- -- -- -- - Nov 25 16 16 5 36 2 Dec 26 17 15 6 34 2 1993 Jan 27 17 16 6 32 2 Feb 26 17 17 5 33 2 Mar 26 17 16 5 34 2 Apr 25 16 17 5 34 3 May 26 17 17 5 31 4 Jun 24 17 17 5 32 5 Jul 24 17 18 5 29 7 Aug 26 17 19 5 27 6 Sep 24 17 18 6 29 6 Oct 23 17 17 5 30 8 Nov 24 17 17 5 31 6 Dec 24 17 16 5 29 9 1994 Jan 23 17 16 6 31 7 Feb 23 17 16 6 31 7 Mar 23 17 14 5 31 10 Percentage of Bytes File Networked Inter- Name Other Non- Exchange Mail active Lookup TCP/UDP TCP/UDP Services Services 1990 Oct 45 27 7 9 11 1 Nov 46 28 7 5 13 1 Dec 45 26 7 7 13 2 1991 Jan 43 26 7 6 13 5 Feb 44 27 7 4 15 3 Mar 47 27 7 4 14 1 Apr 47 26 7 4 14 2 May 45 24 6 4 13 8 Jun 50 25 6 4 14 1 Jul 48 23 6 5 16 2 Aug 49 22 6 5 17 1 Sep 50 24 6 4 15 1 Oct 48 23 6 4 18 1 Nov 48 23 6 4 18 1 Dec 51 22 5 4 17 1 1992 Jan 50 23 5 4 17 1 Feb 50 22 6 4 17 1 Mar 52 22 5 4 16 1 Apr 52 20 5 3 19 1 May 53 20 4 5 17 1 --- -- -- - - -- - Nov 46 18 6 2 27 1 Dec 47 18 6 3 25 1 1993 Jan 48 18 6 3 24 1 Feb 47 19 7 3 23 1 Mar 46 18 6 3 26 1 Apr 45 17 6 3 26 3 May 45 18 6 3 24 4 Jun 44 18 6 2 25 5 Jul 43 18 6 3 22 8 Aug 44 18 7 2 21 8 Sep 42 18 7 3 22 8 Oct 39 17 6 2 23 13 Nov 42 18 7 2 24 7 Dec 42 17 6 2 24 9 1994 Jan 42 18 6 3 25 6 Feb 40 18 6 3 25 8 Mar 38 17 5 3 25 12 File exchange ftp: data and control (tcp ports 20, 21) Networked mail smtp, nntp, vmnet, uucp (tcp ports 25, 119, 175, 540) Interactive telnet, finger, who, login (tcp ports 23, 79, 513, udp port 513) Name lookup domain name service (udp port 53, tcp port 53) Other TCP/UDP services all tcp/udp ports not included above (e.g. irc, talk, X-windows, appletalk) Non-TCP/UDP services Internet Protocols other than tcp or udp (e.g. icmp, igmp, egp, hmp, ax.25, etc.) More detailed information is available in the ports files in the yearly subdirectories. For example, detailed information about March '93 usage can be found via anonymous FTP to nic.merit.edu in the file nsfnet/statistics/1993/nsf-9303.ports. NOTES: October, 1990: Distribution by bytes is now available. September, 1991: Begin using sampling method to collect statistics. November, 1991: Begin migrating production traffic to T3 backbone. Late May, 1992: Majority of traffic now moved to T3 backbone. Jun-Oct, 1992: No information available for either T1 or T3 backbones. November, 1992: Beginning with November '92, all numbers reflect T3 backbone traffic. From J.Crowcroft@cs.ucl.ac.uk Wed Apr 20 09:35:33 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from haig.cs.ucl.ac.uk (haig.cs.ucl.ac.uk [128.16.6.8]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA05547 for ; Wed, 20 Apr 1994 04:50:37 -0400 Message-Id: <199404200850.EAA05547@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Wed, 20 Apr 1994 09:36:54 +0100 To: John Curran cc: pvm@isi.edu, Eric Fleischman , bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of "Tue, 19 Apr 94 21:55:43 EDT." <9404192155.aa15359@nic.near.net> Date: Wed, 20 Apr 94 09:35:33 +0100 From: Jon Crowcroft Status: O >Yes. WWW will soon own the Internet... the growth of mbone traffic and now the grwoth of WWW traffic are cited as succcesses. actually, we have now reduced the mbone traffic by better engineering (pruning) the sooner the WWW folks sort this out, the better too the web source information is largely human generated, and largely static multimedia. human generated static traffic is miniscule compared to computer generated, and continuous media, so the fact that the Web traffic is so high is a failure, noit a success i've said this before, and you've assured me folks are working on it good but evidence this be action soon, please! cheers jon From brian@dxcoms.cern.ch Wed Apr 20 11:22:04 1994 Return-Path: brian@dxcoms.cern.ch 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 FAA05644 for ; Wed, 20 Apr 1994 05:22:43 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14743; Wed, 20 Apr 1994 11:22:06 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA22576; Wed, 20 Apr 1994 11:22:04 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404200922.AA22576@dxcoms.cern.ch> Subject: Web traffic [was: Re: Egoless IPng...] To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Wed, 20 Apr 1994 11:22:04 +0200 (MET DST) Cc: jcurran@nic.near.net, pvm@isi.edu, ericf@atc.boeing.com, bound@zk3.dec.com, ipng@cmf.nrl.navy.mil In-Reply-To: <199404200850.EAA05547@picard.cmf.nrl.navy.mil> from "Jon Crowcroft" at Apr 20, 94 09:35:33 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: 1170 Status: O Jon, The networking people at CERN have been trying to persuade the Web people at CERN about this. However, the basic Web design is not friendly to duplicate copies, and the most widespread Web GUI appears to re-fetch even enormous files every time you click the same button. I am concerned that this problem will not be fixed very quickly. I think it's time to move this chain elsewhere Brian >--------- Text sent by Jon Crowcroft follows: > > > > >Yes. WWW will soon own the Internet... > > the growth of mbone traffic and now the grwoth of WWW traffic are > cited as succcesses. > > actually, we have now reduced the mbone traffic by better engineering > (pruning) > > the sooner the WWW folks sort this out, the better too > > the web source information is largely human generated, and largely > static multimedia. > human generated static traffic is miniscule compared to computer > generated, and continuous media, so the fact that the Web traffic is > so high is a failure, noit a success > > i've said this before, and you've assured me folks are working on it > > good > > but evidence this be action soon, please! > > cheers > jon > From brian@dxcoms.cern.ch Wed Apr 20 11:28:04 1994 Return-Path: brian@dxcoms.cern.ch 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 FAA05658 for ; Wed, 20 Apr 1994 05:28:39 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA15482; Wed, 20 Apr 1994 11:28:06 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA22732; Wed, 20 Apr 1994 11:28:05 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404200928.AA22732@dxcoms.cern.ch> Subject: CATNIPP [was: Re: Criteria review comments] To: ipng@cmf.nrl.navy.mil Date: Wed, 20 Apr 1994 11:28:04 +0200 (MET DST) In-Reply-To: <94Apr19.093750pdt.12171@skylark.parc.xerox.com> from "Steve Deering" at Apr 19, 94 09:37:45 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: 550 Status: O Robert, > I agree entirely with Rob's message, re Turnipp and mergers. > > (Mind you, whenever I have agreed with Rob in the past, it has been > due to my misunderstanding what he was saying. So I will rephrase the > above to say: I agree entirely with what I think Rob's message said.) > > Steve > I think I endorse both parts of Steve's message :-) Seriously, however, CATNIPP with two Ps might be worth some thought (i.e. CATNIP in a world where SIPP is in use). However, that should be discussed on the CATNIP list, not this one. Brian From jcurran@nic.near.net Wed Apr 20 07:59:19 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA06293 for ; Wed, 20 Apr 1994 08:00:22 -0400 Received: from platinum.near.net by nic.near.net id aa25323; 20 Apr 94 8:00 EDT To: Jon Crowcroft cc: pvm@isi.edu, Eric Fleischman , bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-reply-to: Your message of Wed, 20 Apr 1994 09:35:33 +0100. <199404200850.EAA05547@picard.cmf.nrl.navy.mil> Date: Wed, 20 Apr 1994 07:59:19 -0400 From: John Curran Message-ID: <9404200800.aa25323@nic.near.net> Status: O -------- ] From: Jon Crowcroft ] Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... ] Date: Wed, 20 Apr 94 09:35:33 +0100 ] ] >Yes. WWW will soon own the Internet... ] ] the growth of mbone traffic and now the grwoth of WWW traffic are ] cited as succcesses. Hmm... While some folks may have other opinions, I've never considered growth in multicast traffic to be a "success". I've never had a site ask for "multicast traffic", although I have had quite a few ask how to receive a given seminar or conference session. In general, these requests have been infrequent and do not appear to be increasing significantly. ] the sooner the WWW folks sort this out, the better too ] ] the web source information is largely human generated, and largely ] static multimedia. ] human generated static traffic is miniscule compared to computer ] generated, and continuous media, so the fact that the Web traffic is ] so high is a failure, noit a success DNS must be a failure as well... Largly static data with relatively high traffic rates. Is FTP a failure? ] i've said this before, and you've assured me folks are working on it Once we have an adaqaute namespace for resources (URNs, not URLS), then caching and replication are greatly simplified. Work is active in this area, and I am confident that progress and consensus will be achieved far faster than other IETF activities. (This is principally because these folks are driven by an active customer base looking over their shoulders, and have a healthly disrespect for contributions from arbitrary outsiders.) /John From bound@zk3.dec.com Wed Apr 20 12:52:45 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA08978 for ; Wed, 20 Apr 1994 13:07:19 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA16873; Wed, 20 Apr 94 09:52:57 -0700 Received: by xirtlu.zk3.dec.com; id AA11331; Wed, 20 Apr 1994 12:52:51 -0400 Message-Id: <9404201652.AA11331@xirtlu.zk3.dec.com> To: John Curran Cc: ipng@cmf.nrl.navy.mil Subject: Re: Egoless IPng Problem Solving Analysis has a Part too... In-Reply-To: Your message of "Wed, 20 Apr 94 07:59:19 EDT." <9404200800.aa25323@nic.near.net> Date: Wed, 20 Apr 94 12:52:45 -0400 X-Mts: smtp Status: O >Hmm... While some folks may have other opinions, I've never considered >growth in multicast traffic to be a "success". I've never had a site ask for >"multicast traffic", although I have had quite a few ask how to receive a >given seminar or conference session. In general, these requests have been >infrequent and do not appear to be increasing significantly. Well I don't know what you call it but I can't sell hosts today without in most accounts (I admit its a place holder in most cases), and customers want to be assured we will support Multicast in our routers as it evolves. >Once we have an adaqaute namespace for resources (URNs, not URLS), then >caching and replication are greatly simplified. Work is active in this >area, and I am confident that progress and consensus will be achieved far >faster than other IETF activities. (This is principally because these >folks are driven by an active customer base looking over their shoulders, >and have a healthly disrespect for contributions from arbitrary outsiders.) Well I think the work is still out on this work we all don't agree fyi. I am working off line with some folks now in the IETF to address dynamic BIND updates and autoregistration and we are now building the outline and discussing general architecture principles. And we have folks who write code with BIND too to keep it real and not lofty. We will probably have a BOF at Toronto. My point is that caching and replication are very complex and some things are just impossible to do with todays hosts. Thats all I will say for now. But we need BIND in this way now. There is no reason why BIND can not be used for resources if engineered differently. /jim From bound@zk3.dec.com Wed Apr 20 13:07:23 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id NAA09129 for ; Wed, 20 Apr 1994 13:24:12 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA17378; Wed, 20 Apr 94 10:07:35 -0700 Received: by xirtlu.zk3.dec.com; id AA11802; Wed, 20 Apr 1994 13:07:29 -0400 Message-Id: <9404201707.AA11802@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Cc: bound@zk3.dec.com Subject: Future of DECnet at University of Minnesota Paper Date: Wed, 20 Apr 94 13:07:23 -0400 X-Mts: smtp Status: O This is Connexions article. Release for me to forward first and then the paper from Craig Finseth. We will mostly likely get an ATM IPng paper from Craig too. /jim ------- Forwarded Message Return-Path: fin@unet.umn.edu Received: from decvax.zk3.dec.com by flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM) id AA15479; Wed, 20 Apr 1994 10:42:54 -0400 Received: from norge.unet.umn.edu by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA22627; Wed, 20 Apr 1994 10:42:49 -0400 Received: by norge.unet.umn.edu (5.65c) id AA10863; Wed, 20 Apr 1994 09:38:59 -0500 Date: Wed, 20 Apr 1994 09:38:59 -0500 From: "Craig A. Finseth" Message-Id: <199404201438.AA10863@norge.unet.umn.edu> To: bound@zk3.dec.com Cc: mogul@pa.dec.com, bound@zk3.dec.com In-Reply-To: bound@zk3.dec.com's message of Tue, 19 Apr 94 16:59:57 -0400 <9404192100.AA20692@xirtlu.zk3.dec.com> Subject: Future of DECnet at University of Minnesota - Paper Date: Tue, 19 Apr 94 16:59:57 -0400 From: bound@zk3.dec.com X-Mts: smtp Hi Craig, Jeff Mogul forward a copy of your Connexions paper. I am on the IETF's IP next generation (IPng) Directorate body reviewing this decision process and doing technical analysis (and in Digital's case prototyping) of the various proposals. We have had several Connexions papers sent to us on the Directorate. I think your paper would be very valuable to this body of thinkers on this subject. May I forward your paper to the Directorate and I believe it would be very appreciated by the IPng Directorate? Also there is time still to submit any requirements you or your colleagues see for IPng to the Directorate. Sincerely, /jim You are welcome to distribute the paper as widely as you like. It is up for FTP/Gopher/etc. on mail.unet.umn.edu in unet/info-decnet. As far as IPng, we are incorporating our thinking in that area into our ATM thinking. I am working on a paper in that area, and hope to have it out in a month or so. Don't know if this fits your schedule.... Craig ------------------------------------------------------------------  The Future of DECnet at the University of Minnesota University Networking Services +1 612 625 8888 130 Lind Hall unet@unet.umn.edu mail.unet.umn.edu:unet/info-decnet 1994-03-12 At this time, we support four network protocols on the University of Minnesota's data network: IP, AppleTalk, DECnet Phase IV, and Novell IPX. This list of protocols came from two sources. The first three protocols were called for in a report issued by a 1987 campus-wide committee[*] and the last one was added after a user survey identified a number of areas for improvement. Note that by "DECnet," we mean just that. Non-DECnet protocols such as MOP and LAT are not supported on our network. What is the status of these protocols? Due to its nature as a vendor-independent, open protocol, we consider IP to be the "flagship" protocol. This status also comes from IP's use on the worldwide Internet. Further, its requirement of fixed address assignments helps make it the basis of our network management system. At this time, virtually all hosts on our network can use IP for communication and we have assigned over 20,000 IP addresses. AppleTalk is closely tied to the Macintosh architecture. And, as we have several thousand such computers on our network, it is clear that there is a large demand for this protocol. At this time, AppleTalk is a more-or-less frozen protocol. We will continue to support it on a legacy basis. Apple has not announced plans for a replacement protocol, and it is by no means clear that we would ever support such a replacement protocol should one ever be announced. There are currently many thousands of computers on our network using the Novell IPX protocol. With the advent of Novell 4 and the use of IP as an alternate transport protocol, we are looking to extend the use of Novell to the Internet as a whole. After this change, we will offer basic naming and related services, but otherwise be "out" of the IPX routing business at the network level. (Our department will, of course, be involved with the protocol at the application level.) DECnet has very different usage patterns than the above protocols. First, there are a fairly small number of DECnet hosts on our network: something like 125 or so. Second, these computers tend to be multi-user machines, so the small number of computers nonetheless affects many users. Third, DECnet users tend to form visible clumps, where they communicate much more extensively _within_ each clump than among the clumps. Fourth, DECnet communication with the "outside world" is available on a limited basis. Many of the clumps communicate extensively with (their own separate) external clumps. There are a number of issues to our use of DECnet that affect it's long-term viability: 1) Scaleability. We have an assigned "block" of 1,024 DECnet addresses. Clearly, it is not feasible to provide DECnet access to all University hosts. Worse, DECnet Phase IV does not provide the equivalent of the DNS and other tools to help manage growth. (Imagine the logistics of keeping a 20,000 entry host table and distributing it regularly to 20,000 hosts.) For the long term, it is not clear that it makes sense to support a protocol on a University-wide basis that only a small number of people can use. 2) Effect on vendor choices. At this time, we support four protocol suites on the network. We must take all of these protocols into account when evaluating network equipment and devising network designs. For the long term, we have a desire to reduce the number of supported protocols as such a reduction would widen the choice of possible vendors and ease constraints on network design. 3) External connections. At this time, we obtain wide area connectivity to the NSI/D (area 7, via leased line) and HEPNET (area 46, via CICNET) networks. Those networks run DECnet Phase IV. The NSI/D connection is relatively simple: it is a leased line to the rest of the NSI/D network and affects only a few hosts in the Physics building. While it works quite well for now, in the long term, it should be practical to eliminate this line. Such an elimination would save money, reduce complexity, and improve reliability of the network. The HEPNET connection is more complex: it uses CICNET as a carrier and requires access to area 46 at a number of University of Minnesota sites, including Tower-Sudan. It is clear that most future wide-area network designs will not include DECNET Phasve IV, and so we would like to remove this constraint on our ability of adopt such designs. DECnet Phase IV requires that all areas be contiguous. This requirement makes it especially difficult to maintain these external connections. For these reasons, we would like to work with DECnet users to plan for the eventual elimination of DECnet support from our campus network. We cannot stress enough the phrase "work with users," as we believe that it is very important that users be able to do their work. One set of steps to achieve this goal is: - - Identify all users. - - Work with each user to identify the current DECnet uses. Create a plan for each user that spells out alternate technology to perform the current tasks as well or better than the use of DECnet Phase IV. - - Stop accepting new DECnet host registrations (this is a soft "stop," as we will be willing to accommodate emergencies). We will continue to indefinitely assign names and numbers for host configuration -- as opposed to networking -- purposes. - - Follow up with each user to ensure that the conversion plan has been followed. - - At this point, all users should be using other network technology such as IP. There should be _no_ use of DECnet Phase IV at this time. Therefore, it should be safe to stop routing DECnet Phase IV. There are many other methods that we could use. In all cases, we place a very high priority on ensuring that all users' needs are met. We deliberately omitted setting specific dates for these steps. However, it is probably realistic to have achieved the first two within a year. We clearly have a strong preference for using IP as the alternate network technology. However, it is worth discussing DECnet Phase V a little. Implementations of Phase V network applications are starting to appear. The current implementations use OSI network layers. At this time, we have no intention of supporting OSI as a network layer within our network. While this intention may change, it is unlikely to do so. However, DEC has also promised Phase V support using RFC 1006. In short, this means using IP as a transport layer. The use of DECnet Phase V over IP is a strong candidate for support. It is only considered a candidate as there are a number of related application-layer protocols that we must understand and possibly provide. For example, the Phase V DECnet naming scheme is not compatible with either X.500 or TCP/IP's DNS and we must evaluate what level of support is required for the naming scheme. Also, we support TCP/IP's NTP (Network Time Protocol) as a campus-wide timebase. That protocol is not compatible with DECnet's equivalent DTP. Again, we would have to evaluate the required level of support. There are quite likely other such application protocols to consider. We plan to work with DEC and other parties (such as HEPNET and NSI/D) to understand these requirements more fully. After we have such an understanding, we can make an informed decision whether to allow DECnet Phase V. We would like to say again that we encourage comments and questions on this document. [*] This committee was headed by Dr. Russell Hobbie and the report is usually referred to as the "Hobbie Report." This report set many of the directions of our campus network including the creating of University Networking Services in 1990. From Robert_Ullmann.LOTUS@CRD.lotus.com Wed Apr 20 20:23:59 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA13738 for ; Wed, 20 Apr 1994 20:18:23 -0400 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com by lotus.com (4.1/SMI-4.1) id AA07870; Wed, 20 Apr 94 20:19:49 EDT Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA00179; Wed, 20 Apr 94 20:23:59 EDT Date: Wed, 20 Apr 94 20:23:59 EDT Message-Id: <9404210023.AA00179@Mail.Lotus.com> Received: by DniMail (v1.0); Wed Apr 20 20:23:57 1994 EDT To: UNIXML::"ipng-request@cmf.nrl.navy.mil"@lotus.com Subject: Re: CATNIPP [was: Re: Criteria review comments] Status: O Hi, >I think I endorse both parts of Steve's message :-) >Seriously, however, CATNIPP with two Ps might be worth some >thought (i.e. CATNIP in a world where SIPP is in use). However, >that should be discussed on the CATNIP list, not this one. > Brian CATNIP (with one P) already discusses the world with SIPP in use. Has everyone on the directorate read the -03 draft? (or the WP?) I would welcome any discussion, here or on the CATNIP list. Best Regards, Robert From jallard@microsoft.com Thu Apr 21 14:10:18 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA21685 for ; Thu, 21 Apr 1994 17:16:06 -0400 From: jallard@microsoft.com Received: by netmail2.microsoft.com (5.65/25-eef) id AA16194; Thu, 21 Apr 94 13:17:25 -0700 Message-Id: <9404212017.AA16194@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 21 Apr 94 13:17:24 PDT To: ipng@cmf.nrl.navy.mil Subject: Re: Date: Thu, 21 Apr 94 14:10:18 Status: O >The IPng retreat will be held at the Bog-10 Conference Headquarters. what is the date/agenda for this event pls? something very, very bad has happened to my external email, the last message i saw from ipng was that this week's telechat was forgotten and would be rescheduled this coming week. i'm sure i've missed plenty. sorry for the broadcast, but i just wanted to let you know that my gateway went into hibernation so that anything important could be fwd'd. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From mankin@itd.nrl.navy.mil Thu Apr 21 15:38:31 1994 Return-Path: mankin@itd.nrl.navy.mil Received: from itd.nrl.navy.mil (itd.nrl.navy.mil [128.60.2.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA20557 for ; Thu, 21 Apr 1994 15:38:34 -0400 From: mankin@itd.nrl.navy.mil Received: from localhost.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA12692; Thu, 21 Apr 94 15:38:32 EDT Message-Id: <9404211938.AA12692@itd.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: A few thoughts about the retreat from your ADs. Cc: mankin@itd.nrl.navy.mil Date: Thu, 21 Apr 94 15:38:31 -0400 Status: O Since the last telechat, Scott talked to Steve Crocker about the idea of an IPng security workshop. He conveyed the feeling of the directorate that while we would like input about IPng related security issues, we did not feel that we could take the time to work on the issue as a group activity. Steve was quite understanding and has offered to host a separate IPng security workshop (with a small group of attendees) at TIS the week before our retreat. He will prepare a report and forward it to the directorate for consideration. Those directorate members who would like to take part should contact Steve. One or both of us will try to be at TIS on each of the planned two days. The last discussion seemed to resolve that we should spend a chunk of the retreat doing a careful technical review of any problem areas in each of the proposals. (No, we do not consider turnipp to be a formal IPng proposal). (Yes, we are finally going to do some actual technical work). A main aim of the review is to attempt to resolve any technical issues with each of the proposals. The result should be a better understanding of the proposals and a better set of proposals. Each proposal should invite whoever they think would help in this process. (Bob Hinden and Peter Ford are two people that have been mentioned). Let us know who as soon as possible. The retreat should not be seen as an attempt to produce a merged IPng candidate but if common solutions to parts of the problem set should develop out of the review process, it can help in the defining the final recommendation In addition to the technical review, it will be time to evaluate each proposal's ability to meet the requirements set forth in the requirements document. We will separately review transition plans in these discussion as well, keeping the view that we have discussed that they can be separated to some extent from the proposals. We have two rooms reserved. As a topic on Monday or in email (private to us is fine too), please give us your ideas about constructive ways to form two groups for parallel processing. The above is our current thinking about the retreat and we welcome your input to further define the agenda and aims. Scott is going to send the hotel/convention center information to the list. Both are very near O`Hare and are inexpensive. More on those details soon. The dates as stated before will be May 19 and 20. Allison & Scott From deering@parc.xerox.com Thu Apr 21 13:44:17 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA21157 for ; Thu, 21 Apr 1994 16:45:28 -0400 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14671(6)>; Thu, 21 Apr 1994 13:44:36 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 21 Apr 1994 13:44:20 -0700 To: mankin@itd.nrl.navy.mil Cc: ipng@cmf.nrl.navy.mil Subject: Re: A few thoughts about the retreat from your ADs. In-reply-to: mankin's message of Thu, 21 Apr 94 12:38:31 -0800. <9404211938.AA12692@itd.nrl.navy.mil> Date: Thu, 21 Apr 1994 13:44:17 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Apr21.134420pdt.12171@skylark.parc.xerox.com> Status: O > ...Steve was quite understanding and has offered to host a separate IPng > security workshop (with a small group of attendees) at TIS the week before > our retreat. What city is TIS in? Steve From mankin@itd.nrl.navy.mil Thu Apr 21 16:47:49 1994 Return-Path: mankin@itd.nrl.navy.mil Received: from itd.nrl.navy.mil (itd.nrl.navy.mil [128.60.2.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA21185 for ; Thu, 21 Apr 1994 16:48:11 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14649; Thu, 21 Apr 94 16:47:49 EDT Date: Thu, 21 Apr 94 16:47:49 EDT From: mankin@itd.nrl.navy.mil (Allison Mankin) Message-Id: <9404212047.AA14649@itd.nrl.navy.mil> To: deering@parc.xerox.com Subject: re: TIS Cc: ipng@cmf.nrl.navy.mil Status: O TIS is in the DC area (in Olney MD). From scoya@CNRI.Reston.VA.US Thu Apr 21 16:56:57 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA21789 for ; Thu, 21 Apr 1994 17:33:42 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19965; 21 Apr 94 16:57 EDT To: Steve Deering cc: mankin@itd.nrl.navy.mil, ipng@cmf.nrl.navy.mil Subject: Re: A few thoughts about the retreat from your ADs. In-reply-to: Your message of "Thu, 21 Apr 94 13:44:17 PDT." <94Apr21.134420pdt.12171@skylark.parc.xerox.com> Date: Thu, 21 Apr 94 16:56:57 -0400 From: Steve Coya Message-ID: <9404211657.aa19965@IETF.CNRI.Reston.VA.US> Status: O >> What city is TIS in? Glenwood, Maryland (D.C. area) From sob@hsdndev.harvard.edu Thu Apr 21 16:57:08 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA21411 for ; Thu, 21 Apr 1994 16:57:29 -0400 Date: Thu, 21 Apr 94 16:57:08 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404212057.AA21041@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: retreat info Status: O The IPng retreat will be held at the Bog-10 Conference Headquarters. The Big-10 Conference Headquarters and meeting facility is located at 1500 West Higgins Road, Park Ridge, Illinois (708) 696-1010. If you are flying into O'hare, we recommend taking the Marriott Shuttle to get there. Walk out of the lower level baggage claim area and wait in the hotel courtesy bus area on the median strip. There are two areas outside each terminal, located toward the ends of the terminals. Marriott advertises that the shuttle runs every 15 minutes. They stop at both the Suites and the Hotel. Marriott also has an arrangement with the Big-10. Ask the driver to let you off at the Big-10 facility, which is located between the Suites and the Hotel. The entrance to the facility is at the rear of the building. Usually the driver will stop at the entrance. However, if they are busy, the driver will stop in front of the building and you will have to make your way across the intersection, which is protected by a stop light, and around to the rear of the building. If you will be spending the night, we recommend that you stay at the Marriott O'Hare (NOT the Suites). Marriott O'Hare is within walking distance of the Big-10 Conference Center and offers a special rate of $78 for folks who will be using the Big Ten Conference Center. The reservations number is 1-800-228-9290 If you have any further questions concerning the hotel or Big Ten Conference Center, please let me know. Lisa Epps epps@cic.net 313-998-6103 From kasten@mailserv-D.ftp.com Thu Apr 21 17:10:54 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA21644 for ; Thu, 21 Apr 1994 17:12:22 -0400 Received: from ftp.com by ftp.com ; Thu, 21 Apr 1994 17:12:05 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 21 Apr 1994 17:12:05 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA15620; Thu, 21 Apr 94 17:10:54 EDT Date: Thu, 21 Apr 94 17:10:54 EDT Message-Id: <9404212110.AA15620@mailserv-D.ftp.com> To: ipng@cmf.nrl.navy.mil Subject: Re: retreat info From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 261 Status: O what times do you envision starting on thursday morning and ending on friday afternoon? will it be feasable to fly in thursday morning and leave friday afternoon? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From scoya@CNRI.Reston.VA.US Thu Apr 21 17:24:10 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id RAA21794 for ; Thu, 21 Apr 1994 17:34:01 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21006; 21 Apr 94 17:24 EDT To: jallard@microsoft.com cc: ipng@cmf.nrl.navy.mil Subject: Re: In-reply-to: Your message of "Thu, 21 Apr 94 14:10:18." <9404212017.AA16194@netmail2.microsoft.com> Date: Thu, 21 Apr 94 17:24:10 -0400 From: Steve Coya Message-ID: <9404211724.aa21006@IETF.CNRI.Reston.VA.US> Status: O >> what is the date/agenda for this event pls? The dates are May 19-20. Final Agenda: TBD From sob@hsdndev.harvard.edu Thu Apr 21 18:20:55 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA22275 for ; Thu, 21 Apr 1994 18:21:00 -0400 Date: Thu, 21 Apr 94 18:20:55 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404212220.AA13837@hsdndev.harvard.edu> To: kasten@ftp.com Subject: Re: retreat info Cc: ipng@cmf.nrl.navy.mil Status: O We should talk about the schedule for the retreat during the monday telechat but I (myself) woul like to start ~10am on thursday, that would let me fly in on thursday morning from Boston and I'd like to get out friday eve. Scott From kasten@mailserv-D.ftp.com Thu Apr 21 18:29:08 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA22380 for ; Thu, 21 Apr 1994 18:30:24 -0400 Received: from ftp.com by ftp.com ; Thu, 21 Apr 1994 18:30:22 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 21 Apr 1994 18:30:22 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA20103; Thu, 21 Apr 94 18:29:08 EDT Date: Thu, 21 Apr 94 18:29:08 EDT Message-Id: <9404212229.AA20103@mailserv-D.ftp.com> To: sob@hsdndev.harvard.edu Subject: Re: retreat info From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 444 Status: O > We should talk about the schedule for the retreat during the monday telechat > but I (myself) woul like to start ~10am on thursday, that would let > me fly in on thursday morning from Boston and I'd like to get out friday > eve. ditto - though there are probably flights early enough out of boston to let us start, maybe, at 930 or even 900. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From Robert_Ullmann.LOTUS@CRD.lotus.com Thu Apr 21 21:30:58 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id VAA23605 for ; Thu, 21 Apr 1994 21:25:17 -0400 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA09900; Thu, 21 Apr 94 21:26:46 EDT Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA21407; Thu, 21 Apr 94 21:30:58 EDT Date: Thu, 21 Apr 94 21:30:58 EDT Message-Id: <9404220130.AA21407@Mail.Lotus.com> Received: by DniMail (v1.0); Thu Apr 21 21:30:56 1994 EDT To: UNIXML::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Re: retreat info Status: O > ditto - though there are probably flights early enough out of boston to let > us start, maybe, at 930 or even 900. If I recall United's schedule correctly, I have no problem being at O'hare ready to go at 7:30 or so. Remember, you gain one hour from the east coast to Chicago; so if you leave Boston or NY or Washington DC by 6:30, you get there at ~7:30 (later from DC) (It is amusing to travel one zone west on business and get to the customer site before you normally get to work at home. Planes are real fast over "local" distances. Never mind I am 7.5 min from the airport, and can safely walk out of my apartment 20 min before a flight and be sure I will get on it. Ha! :-) It is the west coast people who are the limiting factor on the start time: they either have to get up the night before or arrive the night before. (SF or LA depart 10:00 local time, arrive in Chicago 5-6 AM. Want to arrive at 9? Get up at 2.) There is a good reason why Fedex set up their hub in Memphis. Rob From bound@zk3.dec.com Thu Apr 21 23:38:38 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA24580 for ; Thu, 21 Apr 1994 23:43:00 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA18538; Thu, 21 Apr 94 20:38:51 -0700 Received: by xirtlu.zk3.dec.com; id AA04722; Thu, 21 Apr 1994 23:38:45 -0400 Message-Id: <9404220338.AA04722@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: retreat info In-Reply-To: Your message of "Thu, 21 Apr 94 16:57:08 EDT." <9404212057.AA21041@hsdndev.harvard.edu> Date: Thu, 21 Apr 94 23:38:38 -0400 X-Mts: smtp Status: O Well I live in the woods of New Hampshire and am flying out of Manchester, NH airport. I think I can get there by 9:30 a.m. and have someone checking. I will take at flight at 5 pm. out or shortly after. I have to be back Friday night in that time frame and no choice on my end. So that means I think I would leave the meeting at 4 pm. /jim From bound@zk3.dec.com Fri Apr 22 00:21:47 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA24903 for ; Fri, 22 Apr 1994 00:28:22 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA20781; Thu, 21 Apr 94 21:22:28 -0700 Received: by xirtlu.zk3.dec.com; id AA08659; Fri, 22 Apr 1994 00:21:53 -0400 Message-Id: <9404220421.AA08659@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Cc: bound@zk3.dec.com Subject: Host: Options, Variable Addresses, and Alignment Date: Fri, 22 Apr 94 00:21:47 -0400 X-Mts: smtp Status: O Host Processing Options The way IPv4 options have to be processed today on a Host are horrible. The way SIPP has proposed it with Payload Type in the header is very good. It permits chaining efficiently when working with the header and is very fast. In other words I like Payload Type value in the header. Host Variable Addresses On a Host a variable address is a negative. First there are two types of variable addresses. The first one is bounded. You are given a max and the address can be variable up to that max. Then there is the unbounded and that means there is no max and you will not know the length until you look at the length field for the address. Either case is not good for a host, because when you build data structures to access the address or use the address as a key to access the data structure in a list (for example) you must use an instruction to get the length of the address first. So each time your Host networking subsystem does anything with addresses you must 'first' get the length. In some cases you also may need to grow memory not knowing ahead of time how much memory you need to support a data structure. Then for 'garbage collection' you need to return or efficiently reuse that memory. An advantage of SIPP is that the addresses are 64bits and the address can be extended to support multiple 64bits. This could be used very efficiently to support NIMROD EIDs and Locators from a software perspective in an implementation. The above permits implementors to use the bounded form of variable addresses as needed. For example the EID for the immediate future can be 64bits. These can support many globally unique addresses for a specific site including the Toasters and Cable Lines. Then additional 64bit addresses can be used to support the NIMROD locators (SIPP address sequence). The 64bits in this manner supports the existing sockets structure very well and can be implemented very efficiently. If NSAPs were the addressing structure of IPng the EID can be extended to support additional 64bit elements in the structure with a minimal change on Hosts. This is just a matter of structuring the NSAP to fit 64bit addresses. But I believe for a very long time 64bits per site is enough, and routing information can be supplied by additional 64bits as required. Using NSAPs might be an approach to supporting what I am calling the bounded variable address with a max. With this scheme we would have a max and could theoretically (I have not tested this and it would need much technical discussion) build the data structures on the host based on how much of the max was used on an incoming or outgoing connection. This would reduce determining the length instruction to one time to set up a list for that data structure using that address length. Fixed addresses at the transport layer and for the network subsystem structures on a host are very efficient, not using fixed addresses will have a great cost. This scheme also maintains differentiation between EIDs at the Transport. Host Alignment of Protocol Fields Alignment of fields on words, double words, or quad words are very important to a host for performance. Alignment of fields on 32bit boundaries are a good idea (for some a 64bit boundary is good too). For example a 64bit address can fit in a typedef of two int's or one long on a 64bit machine. If the address is not aligned then you have to force alignment or build a single structure to support a non-aligned address (especially if the address is not a power of 2 like the present GOSIP NSAP). This also means you need to take into consideration all the bit shifting operations and index operations on the address as you may have to parse it as in the case of IPv4 to determine the subnet ID in the address. Alignment has an affect on setting up the data structure lists discussed in the variable address discussion previously. Fields in IPng should be aligned on 32bit and 64bit boundaries. As Alex Conta pointed out too from Digital at the IETF SIPP implementors meeting it is also very important that placement of fields in headers do not cause additional instructions to access fields in a protocol stream. This resulted in several changes to where certain fields are located in two SIPP header options. A fixed length header for IPng network layer protocol is also a win for the Host. /jim From bound@zk3.dec.com Fri Apr 22 00:39:32 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA24953 for ; Fri, 22 Apr 1994 00:41:35 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94) id AA21653; Thu, 21 Apr 94 21:39:54 -0700 Received: by xirtlu.zk3.dec.com; id AA10967; Fri, 22 Apr 1994 00:39:39 -0400 Message-Id: <9404220439.AA10967@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Digest of Comments on Draft Firp Report Date: Fri, 22 Apr 94 00:39:32 -0400 X-Mts: smtp Status: O Ouch. Many are clueless about the IET. /jim ------------------------------------------------------------ DIGEST OF COMMENTS ON DRAFT FIRP REPORT Prepared for the Federal Internetworking Requirements Panel by David Wood, MITRE. 3/21/94 The Federal Internetworking Requirements Panel (FIRP) was established by the National Institute of Standards and Technology (NIST) to reassess federal requirements for open systems networks and to recommend policy on the Government's use of networking standards, particularly the Internet Protocol Suite (IPS) and the Open Systems Interconnection (OSI) protocol suite. The Panel's draft report was released by NIST for public comment on 14 January, 1994; comments were due by 18 February, 1994. A total of 77 comments were received. A list of commenters is at the end of this document. This document contains extracts from the comments of most of the substantive points, occasionally paraphrased, and sorted by topic. The order of topics is overall comments; major issues that do not correspond to a specific section of the draft report; the recommendations; and then by section of the draft report. The #s refer to the comment number in the index of comments at the end of this document. A companion document presents an analysis of commenters overall view of the draft report, and a summary of the major issues raised most frequently in the comments. The full set of public comments, totaling about 250 pages, are available on request from NIST. OVERALL COMMENTS - PRO I strongly support all 5 recommendations. (#4) Congratulations for the remarkable achievement. (#19) We applaud the directions recommended in the draft report. (#22) This report represents a substantial step forward for the U.S. Government. (#24) The FIRP report ... looks like being a breath of fresh air which will sweep across the national GOSIPs around the globe. (#26) I find it refreshing to read a government document that is relatively realistic. ... Heads should roll over GOSIP. (#27) We believe the FIRP report is a big step in the right direction. (#29) We would like to compliment the FIRP on the draft of its report to NIST (#32) We applaud the efforts of the panel to address a problem that is difficult both for the government and the vendor community. We agree with most of the conclusions in the draft report, especially section 6 "Economic Considerations" which is completely consistent with our experience in this market. (#43) I wish to support strongly the conclusions of the panel, and to observe that the conclusions do much to resolve tensions that have existed among the government and private sector players involved in the development of network standards. (#45) I applaud the FIRP panel for taking a sensible approach to this critical problem. (#49) This report represents the first realistic approach to the problems of networking within the Federal Government. I very strongly endorse the panel's conclusions and recommendations. (#50) Your document is the sanest thing I've ever seen from Washington, D.C. (#53) Overall, an excellent draft. (#55) The Department of Defense strongly supports the conclusions and recommendations of the draft FIRP report and endorses the concept of selecting standards based on requirements, interoperability, and economics. (#81) OVERALL COMMENTS - CON The report as currently written is very disappointing and does not address the central issues relating to the convergence within the network community. (#14) The Panel failed to meet its charter of addressing the future of interoperability and convergence. (#16) The FIRP report presents an inconistent, confused, and in several areas biased look at Federal networking today. (#52) I was appalled by the fact that the Panel failed to address the topic that caused the Panel to be formed. That the Panel has blatantly ignored it's charter and has, by it's existence, precluded others within the government from discussing the important topics it was formed to address, is a disgrace. The Panel members should be strongly chastised for their actions. (#58) We believe the conclusions and recommendations in the report will have adverse consequences on international communications and manufacturing enterprises in all regions. (#60) The FIRP report should have provided a strong argument in favour of worldwide convergence of internetworking solutions to support an international information infrastructure. (#63) I have been very disappointed by the draft FIRP report. I believe that the panel's recommendations could have been much more effective had they recommended a transition that chose a mix of the IPS and OSI standards as a long term goal rather than giving carte blance to all Federal agencies. (#65) I find it extremely hard to accept the fundamental thrust of this report, which is that GOSIP should not be mandated and affinity groups should be allowed to determine the appropriate internetworking strategies. (#71) We recommend that the U.S. Government not abandon or modify GOSIP at this time. Coexistence of TCP/IP and OSI can be provided by the continued and refined use of a waiver process, with clarified direction and migration strategies provided for continued GOSIP migration. The GOSIP mandate needs strengthened direction by policy endorsement and enforcement. (#74) We believe that, based on past history, it is unreasonable to conclude that a common vision and a set of guidelines will be sufficient to bring about the level of interoperability described as desirable in the report. (#78) CHARTER, SCOPE AND ORGANIZATION OF REPORT The 30 day review period was insufficient and should be extended to 90 days. (about 10 commenters) The report as currently written is very disappointing and does not address the central issues relating to the convergence within the network community. The recommendations presented in the report, and the associated text justifying the conclusions are outside the scope of the panel as indicated in the charter. The panel did not address the issues of convergence of the two competing protocol suites; nor did they address the pressing issues of changes to the IPS. The panel did not address the feasibility of alternative scenarios nor did it address the expected costs of alternative suites. The panel did not address the testing issues of the two protocol suites, the availability of conformance test labs, or certification. The panel did not address the non-technical issues of political in-fighting between the proponents of the different protocol suites; nor did it address the issue of Agencies struggling with competing requirements for use of both protocol suites. The panel did not address the issues of what can be done to make interworking easier; nor the selection of solutions which will ease the transition to a unified interworking environment. (#14) The panel failed to meet its charter of addressing the future of interoperablity and convergence. On the contrary the report has obfuscated the issues, principally proposes roles for Government departments and provides no concrete proposals for meeting the original goals of GOSIP. We believe the message that the panel is sending to both the national and international internetworking community is that standards compliance is local in nature. This is equivalent to advocating an electronic feudal system and in an era of electronic global trade, such a message should be rejected. (#16) The stated purpose of the panel is to recommend action to address long term issues of interoperability and convergence. The panel has completely failed to do so. Instead what has been recommended is a concept of "voluntary standards" which is tantamount to "anything goes" and undermines the whole notion of having standards at all. It is time for joint Government and industry leadership. (#16) The main recommendations do not cover all the FIRP panel charter items on coexistence, interoperability and convergence between OSI and IPS products or testing environments. Without these items, it is difficult to see how Recommendation 5 can be sustained. (#18) The accommodation of the Internet Standards brings policy into line with widespread practice and removes obstacles for rational management decisions in the future. However, it's worth examining the recommendations to ascertain if they are sufficient to avoid similar problems in the future. Recommendations that respond only to the current marketplace without also anticipating the future or without including the flexibility to follow the lead of the marketplace may lead to the convening of a similar panel in the not too distant future. (#24) While generally agreeing with the report, the logical flow could be improved: the report lacks focus, the conclusions are inadequately supported, and the recommendations do not follow from the analyses and conclusions. There are no "purpose" or "approach" sections, and the relationships between the sections is unclear. The report should explicitly address: has GOSIP achieved its objectives? Is it likely to in the near future? What alternative courses of action are there? What are the relative merits of these? Given an analysis of the alternatives, what specific course should the government take in the short term? What general guidance might be useful for the long term? Conclusions contained in section 2.6 and 3.6 don't seem to be supported by the analysis in the respective section. The recommendations don't flow from the conclusions scattered through the report. For example, one possible recommendation is to withdraw GOSIP as a FIPS and dismantle the associated bureaucracy, but recommendations 1 through 4 have the effect of increasing centralized involvement. (#25) Consideration should be given to something other than a FIPS for promulgating the modified GOSIP. A FIPS is intended to give very specific procurement guidance to agencies acquiring information processing capabilities, such as specification of a block multiplexor channel. The broader a FIPS becomes, and the more options it allows, the less useful it is for a procurment specification. It could be argued that the current GOSIP is already too broad to be a useful FIPS. (#25) The draft report and the curtailment of the comment period display every indication of undue haste. In finalizing the recommendations, we urge the panel to coordinate requirements with the affected organizations (including government agencies, the standards bodies, international organizations, and NIST who have contributed so much to these efforts in the past) and to take whatever time is needed to do the job properly. (#46) I was appalled by the fact that the Panel failed to address the topic that caused the Panel to be formed. Only one of the Panel's recommendations comes close to falling within the scope of recommendations that the Panel is empowered to make. That the Panel has blatently ignored it's charter and has, by its existence, precluded others within the government from discussing the important topics it was formed to address, is a disgrace. The Panel members should be strongly chastised for their actions. (#58) CCTA is puzzled and disappointed to find the report fails to deliver reasoned and justified recommendations to match the full scope of the Panel's charter. In particular there is neither an analysis of the economic impact of the recommendations, nor consideration of their impact on relationships and commitments to other entities (including Administrations outside the USA). If economic and practical internetworking to support federal government business is the goal, this draft report provides little by way of convincing direction. CCTA would expect the report to be rejected as incomplete unless consideration of the economic impact of the recommendations and the outcome of discussions with other major administrations, especially representatives of the European Union, were added. (#63) SINGLE STACK, INTEROPERABILITY AND CONVERGENCE ISSUES The report should explicitly state the logical result of the study. That TCP/IP should be "normally selected" as the government's transport interoperability protocol, and that the OSI transport and network protocols should be discouraged. (#8) The modifications to GOSIP are premature. The rationale for including alternate protocol stacks makes interworking more difficult instead of easier. The recommendations of the panel should address how the migration to a solution that eases interworking between protocol suites and moves towards convergence. The panel should investigate the need for changes in the IPS - including the potential of converging on a single protocol for internetworking. (#14) We concur with the appraisal of IPS, in particular that security and name space limitations are critical deficiencies. Continuing use of, and reliance upon, IPS is expected at NLM. This makes these issues ongoing concerns to us. It is our hope that some resolution of these issues will be given priority consideration if the GOSIP mandate is dropped and IPS endorsed. (#15) We concur with your recommendation for ending the GOSIP mandate while retaining the ultimate goals. The caveat is that the draft report sets out neither a process nor a means to ensure eventual achievement of the goals. It is our understanding that you intend to address this issue before completing your work; we believe this is extremely important. (#15) The many issues now facing the Internet community and limitations of IP in particular, provides an ideal opportunity for an energetic alliance to create the national uniform information superhighway. It is critically important that new requirements need to be achieved by convergence of efforts to develop additional standards. Security, directory services, network management, and the ability to support real-time applications in commerce and manufacturing are four examples of where new convergent standards efforts are essential to national competitiveness. Our society today enjoys the many fruits of infrastructure standards set in the past. Just as we could not accept multiple standards for the gauge of the nation's railways, electricity and telephony we can no longer accept multiple standards for information exchange. (#16) The panel should specifically identify new standards which are needed and where convergence should be given priority. (#16) For the panel's work to become useful, it would have to explicitly address the needs both long and short term, with consideration of national and international and public - private concerns. This must be in the form of clear actions that would achieve convergence on an interconnected, interoperable and standards based internetworking environment. (#16) The panel should advocate immediate resolution of convergence of the IPS and OSI suites at the IP and TCP transport level to provide a standard communications transport "superhighway" and propose the best means of achieving this. (#16) The document often states that the ultimate aim is to converge to a single, interconnected, interoperable standards based internetworking environment. The term "single" should be deleted from any such statements within the dosument. All previous attempts to force a single network or standard (e.g. FTS2000, GOSIP, etc.) have resulted in outmoded or constricted technological solutions for the government and have been overtaken by events in each case. One single network will not address the varied requirements of all agencies; however an interconnected and interoperable mesh of agency networks will provide the government with flexible solutions that meet each agency's specific requirements, yet forms an integrated seamless federal network. In addition, a single network is anti-competitive and will hinder the introduction of advanced technologies into both the federal and national marketplaces. (#17) The report correctly points out that the issue is not so much a choice between the IPS and OSI suites as the selection of the best and most appropriate combination of protocols for each application. The Internet currently makes use of protocols from both suites. (#22) The adoption of GOSIP has frightened suppliers enough that they are beginning to deliver products which are able to interoperate with other suppliers products. The FIRP is extremely naive to believe suppliers are providing interoperability with other suppliers products just becasue it is good for business. (#28) We agree with allowing the Government to procure both IPS and OSI at the upper layers. For the lower layers, specifically TP4, it does not make economic sense to procure OSI, except where interoperability with existing implementations are required, (which should be few to none). It is worthwhile to promote some of the upper layer protocols such as X.400 and X.500 over IPS because they provide features not available in equivalent IPS protocols. (#34) RFC-1006 was originally created to foster a testing atmosphere for OSI protocols (Transport and up) over the existing Internet. RFC-1006 specifies Transport class 0 over a TCP socket. RFC-1006 should go away. As upper layer protocols become more acceptable on the Internet such as X.400, they will run directly over TCP, obviating the need for RFC-1006 encapsulation. This is what NIST should be endorsing. (#34) NIST could best serve their customer/user needs in the communications profile standards arena by acting as an enabler and coordinator between the IPS and OSI communities. The panel should have invested additional effort on the IPS/OSI internetworking issue. Convergence on a common transport service (or a truly internetworking set of transport services) for IPS and OSI would be very beneficial to both groups as well as the public and private sectors. The panel should seize this opportunity to recommend that NIST, the Department of State, and the federal agencies work towards resolving the barriers to true internetworking. (#35) We endorse the panel's recommendation to include the IPS with the OSI in the Federal internetworking strategy. We agree that no single protocol suite now available meets all the Federal Government's internetworking requirements. The efforts now underway to harmonize TCP/IP and OSI should be encouraged. To require all Federal agencies to use any single protocol suite may be unrealistic. We are concerned, however, that the panel's recommendation to trust agencies to "do the right thing" to meet their mission objectives may be an equally extreme position. Without adequate technical and strategic guidelines and oversight, agencies would be free to optimize on meeting their short term solutions without due regard for the long term implications. (#40) The report should have emphasized the importance of linking the federal government to its citizens by means of public mail systems. X.400 has been widely deployed by PTTs and domestic common carriers throughout the nation and the world, and is commercially successful. X.400 should be mandatory for backbone electronic mail systems, albeit with PC LAN mail gateways and RFC-1006 permitted. This is quite practical and cost-effective, and will achieve a high degree of interoperability among government agencies and between government and public mail systems. This is a key enabling technology for "reinventing government". (#41) SCO intends to continue development of X.400, X.500, and EDI, but sees no economic incentive to update TP4/CLNP, VT or FTAM, or to provide a CMIP/CMIS product. (#43) Recommend a long-term convergence strategy for OSI and IPS, as required by the Panel charter. (#46) Recognize that, for wide connectivity and interworking, specifications must support an addressing scheme that is application- and protocol-independent. Use the purchasing power of the U.S. government to force convergence of the OSI and IPS network addressing. (#46) Recognize that X.400 and X.500 should be the major components of future e-mail systems. Make recommendations that will improve the cost-effectiveness of X.400 services. (#46) My one concern is that the need for interoperability be recognized more strongly. It is not sufficient to articulate a vision and assume that all federal procurement will work towards that vision if the decisions are left totally to individual department specialists. It is absolutely critical that all federal (and state and local) government on-line information systems be accessible to the broadest possible range of those connected to the NII. This means interoperability with not only federal systems but a huge number of commercial and public domain systems as well. (#49) Today's most popular internetworking standards includes many contributions from industry participants offering proporietary products. Network standards such as NDIS (Microsoft/3Com), and ODI (Novell) are for all practical purposes open standards specifying data-link layer implementation. Interestingly, vendors throughout the industry use these specifications to insure interoperability with their non-Novell and non-Microsoft products. Historically, the Government has chosen to stand clear of proprietary technologies, forfeiting an opportunity to promote Federal interoperability and a national technology/industrial policy. The Federal Government should seriously consider adopting a policy supporting and stimulating successsful pseudo-proprietary protocols in an effort to promote and protect the Nation's lead in software technology. Federal involvement might include providing funding or creating incentives for the development of a "Unified Packet Exchange" API (UPX) which is capable of properly routing traffic of differing origin and type up and down the most popular internetworking standards. The UPX would by definition be written to function with industry standard data-link drivers such as PDS, ODI, and NDIS. The standard might support both IP and CLNP. (#54) RFC 1006 has proven itself as a viable paradigm for providing ISO transport services on top of TCP. The Government may wish to provide incentives for further standardization of RFC 1006. (#54) For government to deploy a whole of government network that can internationally connect, be used for trade, banking, customs and immigration, police, health and taxation, etc and interface to the private sector, the network must conform to international (carrier based) standards and their addressing schemes. GOSIP specifies ISO/ITU-T protocols which carry globally specified addressing and this is GOSIP's main strength. GOSIP should not be seen as just the specification of "other communications protocols". But the foundation policy for the US's whole of government naming and addressing scheme, networking and agency interworking. Internationally administered addressing schemes and globally standardized naming, networking, routing, messaging and management functions which are supported by the world's carriers, are essential elements for large scale government networks. (#59) Government must identify interoperability standards for near-term requirements. We recommend the following standards for government information and service delivery systems: interagency data sharing, host access, network infrastructure, electronic commerce, and email exchange. (#61) Whilst the report advocates the adoption of the IPS alongside existing GOSIP, it does not convince the reader that convergence is to be achieved by taking the best that IPS and OSI can offer and implementing this in the NII. The absence of proposals for coexistence, interoperability and convergence (as required by the Panel's charter) makes it difficult to judge the real intent of the Panel. (#63) CCTA feels that one of the most important recommendations that should be made is to initiate work on coexistence of the two protocol suites as a planned prelude to convergence in a common global internetworking solution. Neither the IPS nor the OSI lobby should be allowed to dominate the way forward. There is now a strong requirement for interoperable hybrid solutions (eg, X.400 over TCP/IP) to be agreed across international procurement agencies. As an illustration of the problem faced today, at a recent UK meeting four suppliers suggested four different (non-interoperable) variations for implementing OSI over TCP/IP lower layers. (#63) It is unlikely that a single profile will accommodate all requirements of all Federal agencies, but it would seem that there could be a middle ground between requiring a single profile and allowing anything. (#65) If the panel believes that a mixed-stack architecture that allows OSI and IPS applications to run over TCP/IP is the means to achieve interoperability, they should so state. If the panel believes that Government-wide interoperability is achievable but the means by which this will occur are not obvious, they should recommend alternatives that will provide guidance to those agencies of the government tasked to regulate and mandate procurements. (#68) Suggested recommendation: That priority should be given to the convergence between the OSI and TCP/IP protocol suites, with a view to the coexistence of OSI and TCP/IP applications over a single internetworking protocol. A new internetworking protocol is required by the Internet, since the address space is near exhaustion. The new internetworking protocol should be the subject of collaboration between the Internet Society and ISO. There is a limited and possibly unique window of opportunity to effect the convergence of Internet and ISO-based standards. This could be regarded as "killing two birds with one stone". The Internet needs a new "standard" anyway, and the world would benefit most from one standard not two. This opportunity will be lost if instant recognition were to be given to the Internet "standards" without being put in the context of a clear convergence strategy. Any incentive to collaborate on a single world-wide standard would be removed. (#72) There are applications such as electronic mail, directory access, file transfer, security including digital signature, and EDI that require adherence to a specific set of standards to guarantee efficient cost-effective interchange. The scope of GOSIP should be limited to those protocols and interchange formats, e.g., messaging, digital signature, file transfer, which potentially require government-wide or government/public sector interoperability. These are not leading edge areas subject to frequent change; but rather core areas in which stability is a necessary characteristic. (#78) We believe that some level of convergence between these two dominant architectures is possible, is ultimately in the bests interests of vendors and users, and warrants immediate and urgent attention. (#79) Clarify how (and when) the process proposed in the FIRP will "... converge the Government to a single interconnected, interoperable standards-based internetworking environment." For example, how will interoperability across affinity groups be assured? A schedule should also be identified including an identification of when the current GOSIP policy will be modified. (#81) MANDATE VERSUS FIRST PREFERENCE The term "give preference" according to the hierarchy of standards should be changed to "strongly consider" or "first consider" in order to avoid the pitfalls that will arise from defining where standards and standards bodies fall in the classification hierarchy - yet still carries the same connotation as "gives preference". (#17) Broaden the mandate (by including IPS) but do not eliminate it. Trusting agencies to "do the right thing" within their own broadly stated mission objectives is unrealistic and will lead to short term non-interoperable solutions. Phase in changes over a realistic period of time. (#31) Unfortunately, this report is likely to have major negative ramifications throughout the open systems vendor community. The scope of the message contained within this report goes well beyond GOSIP, and applies to the majority of open systems standards, especially POSIX. Time and time again the Federal Government says it must have standards such as OSI protocols, POSIX, SQL, and security. But the reality of the situation is that nobody enforces such regulations. In fact, it becomes a self-defeating proposition for vendors because standards-based (conformance tested) products are inherently more expensive than proprietary products, so customers procure the less expensive non-compliant products. This is evident in the operating system world with the government buying Microsoft's NT which meets virtually none of the federal standards. We believe this report sets the tone for a major reversal in the open systems movement. It basically is an admission of failure in implementation of open systems acquisition practices and a self-justificiation for existing practices. (#34) Recommendation 5 appears to say "We couldn't get it to work, we don't know what to do next, so everybody do whatever you want based on your mission requirements." Isn't this how we started off in the '70's? (#34) We strongly support the panel's recommendation that profiles should no longer be viewed as mandates. (#35) We believe that a GOSIP program is a necessity, but without the mandate of a specific protocol suite. The name, GOSIP, may change and the structure and content of the GOSIP policy and program must change, but the need for Government-wide interoperability guidelines remains intact. The "GOSIP" program needs to be a structure of policies, guidelines, and procedures that encourage interoperability, both within government and between government and outside organizations. The direction of GOSIP must be changed if the intent of GOSIP - to promote network interoperabilty - is to be realized. (#57) Following the adoption in New Zealand of a form of GOSIP as a national standard, the Government declared that GOSIP was the preferred solution for Government agencies. There is no overwhelming compulsion for agencies to adhere to the GOSIP standard if other circumstances suggest otherwise. (#62) The report endorses anarchy. (#65) The fundamental problem with a mandated GOSIP adoption policy is the lack of a pragmatic approach to achieve the end goal of interoperability based on international standards. The rationale for GOSIP is to guide end users in the direction of a common government goal. The concept (of GOSIP) is so right that every major government has since followed the example. It must be remembered that even within GOSIP, agencies have had the waivers to procure what they want (this may be part of the problem). (#67) The Australian Government's GOSIP Statement of Direction issued in March 1993 reaffirmed that the ultimate goal was to adopt international standards in computing but endorsed the use of alternative standards "where international standards were not available or products based on them were demonstrated to be not cost effective". (#70) The GOSIP mandate should not be discontinued. The GOSIP waiver process should be better defined and provide more rigorous guidance to prevent random intermixtures of TCP/IP and OSI software, thereby avoiding implementation problems. The waiver process should require OSI migration plans as part of the justification. (#74) TRANSITION Phase in changes over a realistic period of time. Vendors have invested heavily in OSI. The Federal Government's leading role in promoting OSI was a key factor leading to that investment decision. Past versions of GOSIP have been phased in over a realistic time line, typically 18 months or more. We recommend a similar approach to allow time for the market to adapt. (#31) Several vendors have made major investments in GOSIP, totalling hundreds of millions of dollars, in a good-faith attempt to meet government requirements. If implemented immediately, the policy reversal recommended by the panel would be a serious breach of faith between government and private industry, and would cause considerable financial harm to to those vendors who have most earnestly supported the federal government standards program. This is not in the best interests of the federal government, the computer industry, or our national competitiveness. The existing GOSIP 2 mandate should remain in force for a minimum of 18 months after the revised networking policy is approved in order to permit vendors to recoup some portion of their investment. To do otherwise would seriously undermine the credibility of government procurement standards in the future. (#41) Suggested recommendation: All agencies will develop a transition strategy for implementing an Open Systems Environment (OSE). It is recognized that the transition to an OSE will be different for every agency. Mission-critical applications, management philosophy, available resources and other factors will impact how individual organizations plan for and implement OSE. (#61) NII ISSUES NIST APP/GOSIP systems should seamlessly interoperate with home and community NII systems. This suggests that NII should be based on APP/GOSIP with suitable extensions. NIST should therefore press for adoption and further development of OSI standards. Those standards which do not work should be fixed, primarily through new testbed implementations rather than lobbying in standards groups. Co-existence with TCP/IP should be written into the ISO/IEC/ITU standards texts, based on existing RFCs. (#3) The report accurately depicts the state of internetworking in the United States today, but seems to lack some foresight. FIPS 146-1 is pointing at tomorrow's goals. This is a very good way to further the propagation of the protocol suite of the future without eliminating the use of the protocol suite of yesterday. If the government wants to implement the information superhighway of the future it should ...select the protocol suite based on what the future requirements for networking will be, and create the backbone and infrastructure to connect the subnetworks. Build and support the system as vigorously as the Internet was supported. (#7) A key element, the non-suitability of IP, has not been fully discussed. With certain classes of IP addresses already depleted, and IP routing reaching critical mass, does anyone really believe that IP can be the basis of the information highway which "links all libraries, classrooms, and hospitals by the end of the decade". The network layer protocol of the future NII will not be IP, but will be CLNP/ES-IS/IS-IS or some equivalent look-alike. (#7) The NII Agenda for Action lists principles and objectives that include universal service, seamless operation, and access to government information. GOSIP provides for these objectives, but removing the GOSIP mandate and allowing each agency to adopt voluntary standards will lead to isolated islands. (#28) A common vision as to how the Federal Government should be interconnected within itself and with the public is paramount. The GOSIP mandate demonstrates how a dichotomy of public and private sector networking standards interferes with the Government's ability to efficiently co-exist with its constituency. Within the context of a NII, public policy should be based on the needs of industry and the public at large - and indeed should become a cornerstone of the Nation's industrial and technology policy. (#54) We recommend that an effective strategy would start with the development of a functional architecture for access to government information and services on the NII. Suggested recommendation: The government (federal, state, local) should develop an NII architecture that will link requirements and goals with technical options and opportunities for service delivery; identify key factors that need attention; and address such issues as user-friendliness, standards, cost, and inter-government cooperation (based on OTA report). An architecture for the NII would primarily address intergrated electronic access to Government information and services, as this will form the infrastructure to support the other six application specific initiatives identified in the NPR. (#61) The panel does not appear to have considered the question "If the IPS specifications and/or the Internet infrastructure are to increase still further their importance to the conduct of government business in the US, to what extent will the policies and approach of ISOC need to be tied to US policy and funding mechanisms and to the implementation of the NII?" (#63) Internetworking guidance for agency procurements in the form of specific technical standards is necessary to make Government networks an integral part of the NII. The elucidation of a "common vision" of how the Federal Government should be interconnected within itself and with the public should prove to be very helpful. This common vision should embrace not only the underlying networking facilities but also the more application-oriented services required to conduct commerce. (#79) INDUSTRY/PRIVATE SECTOR ISSUES The global air transport community is migrating to OSI. The Aeronautical Telecommunications Network (ATN), based on OSI, is designed to facilitate communications between aircraft and ground-based airline and air traffic control systems. It is an essential component of the ICAO's Future Air Navigation System (FANS). (#3) See also #74. During its work the panel provided for no private sector participation. The draft report pays scant attention to the needs and desires of the private sector, for instance there is only a passing reference to the work of the companies and US and foreign government departments which developed the first set of standards based on Industry - Government collaboration known as the Industry Government Open Systems Specification published as recently as December 1993. For the panel's work to become useful, it would have to reiterate the Government's continued support for the concept of a joint Industry - Government Open Systems Specifications with industry specific specialization. (#16) IGOSS The electric power industry is a major user of computing and communications and is fully committed to open systems. While the industry is today a heavy user of the IPS it is following a long term strategy based on international standards developed by ISO and CCITT and national standards developed by IEEE, ANSI and other standards bodies that employ formal review and voting procedures. Needs in all aspects of the electrical power enterprise are met more effectively by the current suite of OSI protocols and international standards under development. Therefore, EPRI's members developed the Utility Communications Architecture (UCA) specification for communications and the Database Access Integrated Services specification for data exchange both based on the OSI model and international standards. These specifications have been incorporated into the Industry Government Open Systems Specification (IGOSS). They are receiving favorable response and application by the industry and its suppliers as well as the support of the natural gas and waterworks industries. (#16) The European MAP/TOP User Group expresses concern about the impact of the recommendations on the future direction of IGOSS. Any endorsement of the addition of TCP/IP to IGOSS must be part of an OSI convergence strategy. (#18) GNMP The document makes no mention of the Government Network Management Protocol (GNMP), FIPS 179. As things stand at present, use of the GNMP will become compulsory and binding for use in all solicitations and contracts for new network management functions and services to be acquired 18 months after its date of publication (December 14, 1993). The same thought processes about GOSIP, FIPS 146-1, that is reflected in the FIRP report would appear to be equally applicable to the GNMP, FIPS 179. If the GNMP is allowed to become mandatory without being amended or rescinded, some government agencies might well be compelled to migrate from otherwise quite workable SNMP management systems to CMIP management. This does not appear to be in the Government's interest. Just as IPS protocol standards have more vitality and market acceptance than OSI protocols at present, SNMP management protocols have greater vitality and market acceptance than CMIP management protocols. (#11) FIPS 179 (GNMP) should have been put out for review and comment before becoming final, as was done with the FIRP document. FIPS 179 specifies use of seven OSI based network management services even though most of them are not stable enough for a production environment, they are not broadly available from commercial sources, and the suite does not appear to meet some agency needs. (#35) RESEARCH AND DEVELOPMENT Funding for research, development, and general maintenance of the two protocol suites must be equalized. All funding for ANY networking research funded by the Government must be equally divided between the two communities, with decisions made by a neutral agent. Decisions must be made with equal representation by proponents of each solution. (#14) The federal government could have funded R&D of OSI products, then placed the source code into the public domain. (#37) RECOMMENDATION 1, OMB The OMB should develop guidelines for measuring the performance of the assigned agencies and the attainment of the overall objectives. Although there is usually a preference to avoid duplication of activities, some degree of competition, exploration of alternative strategies and comparison of results is desirable because it tends to produce more cost effective products and services that are better matched to the needs of the users. (#24) Although recommending an OMB role of oversight and integration, the only specific recommendation is an annual report. Procedures for managing need to be defined as enterprise-wide networking requires close supervision. (#31) It is unclear to outside observers that OMB has the staffing, expertise, and organizatinal structure to handle such a charter. (#34) It is not clear that OMB would have any real enforcement authority to carry out its stated mission. Would this agency extend its purview to include application and related areas? (#40) Centralized federal oversight is essential to prevent the proliferation of non-interoperable proprietary networking protocols. The affinity groups will not be able to perform this function. The procurement of proprietary protocol products should require the approval of a centralized federal authority, such as NIST or OMB. (#41) Recognize that central agency guidance/coordination is an essential step in achieving internetworking. Do not rely on agencies to "do the right thing". (#46) The annual report should include specific performance measures as to how agencies are using information resources technology to improve service delivery or share resources (data, networks and access to information). (#61) OMB will need to lead from the front and control investment in diverging technical solutions which bear no relationship to the Federal internetworking goals, including convergence. (#63) Many agencies will want simple instructions as to which types of networking equipment to acquire. There is likely to be considerable confusion between the additional flexibility of choice and the long term goals of full internetworking. In fact, it is seldom the case that a new network is created from scratch. In almost all cases current networks are expanded and evolve to the desired state. Some strict interpretations of GOSIP would make it an all or nothing choice, whereas in reality there are applications and migration scenarios that will use only specific parts of OSI. What is needed is information on recommended ways to interwork between current and/or future communication protocols and migration scenarios of how to reach the desird goals over time. There should be a central source of this information which not only publishes current guidance but is available for consultation. (#74) More involvement of OMB in the policy and strategic planning area is a return to the structure that existed in the early 1970's. This structure was changed by congressional action, with the assignment of responsibilities added to the functions of GSA and NBS (now NIST). It is not clear that bringing OMB back into this arena will make any improvement to the situation, or that it would be different from what it used to be. The concept of an annual report from OMB does not justify a need for OMB involvement. To move internetworking forward, there is a need for some high level government oversight of internetworking with the authority and means to lead, to enforce policy, to provide incentives, to direct expenditure of government funds for development efforts, and to coordinate critical activities. These roles would be best filled by NIST and GSA, not OMB. (#74) The emphasis seems to be one of "internetworking" which may or may not include a broad range of application sevices necessary to conduct effective business among Government agencies and with industry. (#79) Add to recommendation: The Office of Management and Budget shall provide guidance to ensure monetary resources are available to carry out the plans and infrastructure required to achieve the objectives of the FIRP. (#81) Clarify the recommendation as to why OMB is providing technical guidance, how the guidance will fit in the budgetary cycle, and the technical support role of the Departments and Agencies in creating the guidance. (#81) RECOMMENDATION 2, DEPT OF COMMERCE Even if this recommendation is understood to be limited to refer to internal use of the U.S. Government, the recommendation is flawed. Within the Department of Commerce, NIST is the federal agency tasked with promoting and developing standards, but NIST and DoC have at least two difficulties to overcome. First, NIST has been the lead agency with respect to GOSIP. NIST will need to strengthen its staff and adjust its direction to move toward a stronger involvement in the Internet Standards activities. A significant part of this challenge is working in a standards arena in which the U.S. Government does not have de jure authority or veto power. Second, the DoC is heavily committed to a particular strategy with respect to cryptography that is currently in conflict with the forces in the marketplace. NIST is the lead agency involved in the promulgation of the Digital Signature Standard (DSS) and the "Clipper" escrowed-key encryption system. Both of these initiatives are meeting very strong resistance from industry and academia. (#24) "Expansion of activities across all internetworking stages..." seems to imply government intervention into the commercial marketplace (i.e., Clipper). "Particular emphasis should be placed on technology forecasting..." has a terrible history and track record associaated with it. There is no way that any central government organization can accurately forecast technology and correctly apply it to the numerous unique missions of customers within the federal government. NIST has done this very thing many times within the APP. When asked what was their decision process and quantitative analysis that lead to various decisions, there was silence. The Federal Government has many very competent end-user organizations fully capable of analyzing their needs and surveying the technology within that functional problem set. (#34) I'm not sure that the DoC is really the best place to handle the advanced R&D component. Other government agencies (both NSF and ARPA) have many years of experience, and a proven track record, at this delicate and subtle task. (#55) One of the problems with the IETF is the lack of resources to adequately support the standards development of what is rapidly changing from merely a significant business to a key component of the US (and global) information infrastructure. The Government should seriously consider increasing the financial support it offers to this worthy activity. (#55) The NIST process for developing FIPS and the length of time required before products implementing the standards are available is outdated (need standards online, reference immplementaions, timely conformance test suites, and register of all tested products). (#61) The Panel should give greater emphasis to ensuring that for emerging technologies vigorous action be taken by the Government to ensure that clearly defined specifications and standards are agreed and adopted before these achieve wide acceptance. (#70) RECOMMENDATION 3, INFRASTRUCTURE The panel should clarify what operations will be centralized vs. decentralized, available to the public vs. internal to the Government. (#16) We disagree with the view proposed in the report that one or two (e.g., GSA, DoD, etc.) "infrastructure" agencies should supply all of the remaining agencies their required services. History has shown that doing so results in higher costs and impedes the development and adoption of new technologies and applications. (#17) This recommendation suggests that each role and responsibility should be tasked to some specific agency. Apparently this is aimed at reducing duplication. While useful in principle, this approach is fragile. If the assigned agencies are incompetent or inefficient, everyone suffers. Decentralization should be emphasized. Wherever possible, multiple approaches and multiple agencies should be encouraged. Competition and comparison are enormously useful forces. (#24) The report could use some clarification in terms of the IITF and GITS organizations, what are their current charters, who are the members, etc. (#57 and others) Infrastructure development must be a joint effort between all levels of government and industry. (#61) The rationale for recommendation 3 needs further explanation. (#81) RECOMMENDATION 4, AFFINITY GROUPS The panel should demonstrate that public sector interests will be interpreted in a global rather than a parochial sense. In the broader interests of public-private interoperability, agency autonomy should only be within well defined standards framework. (#16) The formalization of affinity groups will tend to balkanize and hinder activities in these normally voluntary alignments. The additional bureaucracy and overhead will tend to hinder the very groups they seek to help. It would be best to provide area specific forums, via sponsored workshops and conferences, where interested parties can meet and keep the government in a background mode of facilitator. (#17) I praise the encouragement of affinity groups. (#38) We believe affinity groups, as identified in the report, would be a positive contribution to defining application services that go beyond the underlying internetworking architecture. (#40) Define the proposed responsibilities, accountability and reporting structure for Affinity Groups. (#46) We suggest the creation and role of these affinity groups be more clearly defined. This document should also list the existing groups recognized by the FIRP, specifically including those delineated in the NPR document, which are only obliquely referred to in this document. (#57) The company I work for will likely belong to several different affinity groups. How many different networking profiles does the Panel believe will have to be supported by General Motors in the course of its business dealings with the electronic government? (#58) Affinity groups must include state and local government entities for the development of infrastructure to support interoperability. The GITS working group must define the process and procedures for state and local government participation in the NII and the development of an architecture for the NII information and service delivery functions. (#61) There is a risk that two or more affinity groups will disagree and refuse to reach a common solution. It is suggested that all affinity groups be required to work from the starting point of the regional workshops' implementation agreements. (#63) The report's confidence in the use of affinity groups to achieve any kind of consensus is perplexing and frightening. (#65) The panel's recommendations to ... let agencies decide for themselves the best solution for their affinity groups comes short of advocating chaos. (#68) The draft report emphasizes the importance of individual affinity groups selecting consistent sets of standards for use within the affinity group. It seems to give far less weight to the importance of consistency between affinity groups in the selection and use of standards. Given the lack of any strong oversight/direction to motivate consistency across affinity groups, it is hard to see how convergence would come about, or how to avoid affinity groups tending to become non-interoperable islands. (#72) Affinity groups should be encouraged to adopt profiles which define how a group tailors a GOSIP standard and/or extends a GOSIP standard for mission-specific use. (#78) Revise the recommendation to read: The roles and responsibilities of interagency, government/public and government/private affinity groups should be defined, including how they are created and coordinated by the Government Information Technology Services (GITS) working group. The roles, creation, responsibilities, and coordination of intra-agency affinity groups should be the responsibility of the individual agencies. (#81) RECOMMENDATION 5, HIERARCHY ISSUES I disagree with the hierarchy of standards presented in Section 4.2 and in Recommendation 5. Section 4.2 asserts that a certain ordering of choices is required in order to meet the goals enunicated in Section 4.1, but nowhere is there any substantiation that the stated ordering is the best way to meet the goals or, in fact, that the given ordering will meet the goals at all. I believe that the stated hierarchy will not necessarily meet the goals, and that the appropriate hierarchy of choices must be quite different. The maximum attainment of the goals requires the use of solutions characterized by -actually working -in widespread use -implemented on multiple platforms -openly specified -provided by multiple sources with viable competition. The first choice of a standard is one which meets all 5 of these criteria. Second, third, etc. choices can be defined as meeting less of these criteria. (#5) International consortia are omitted from the order of standards preference. Are they in the second category, or in the first? (#11) Clarify circumstances in which proprietary standards may be selected, e.g., only when open international voluntary standards cannot be found that will help the agency accomplish its mission. (#12; also #57) It is crucial that proprietary standards not be "recognized". The use of proprietary protocols will continue as long as there are no international or defacto standards that address the area in question. The report should only note this situation and state that the use of proprietary protocols is permissible until such time when an international or defacto standard/protocol is available to satisfy the agency(ies)' requirements. (#17) The second choice in the hierarchy of standards is given as "national voluntary and consortia standards" in section 4.2, but as "national voluntary or consortia standards" in the recommendation. While the use of the word "or" rather than "and" may have been unintentional, the change is important since using "or" does not promote alignment of standards and standards-related efforts in the U.S. industry. This terminology could promote a philosophy that inhibits regional, e.g., NAFTA, and global, e.g., ITU, standards harmonization efforts. It is recommended that the second choice of the standards hierarchy consistently be stated as "national voluntary and consortia standards" and consideration be given to stressing the need for alignment between such groups. (#30) Reconsider the proposed standards hierarchy. At the second level, the panel chooses to equate "national" and "consortia" standards. National standards have an assurance of due process and consensus because of the ANSI accreditation system. Consortia standards have no such assurance and stability and openness varies from one group to another. Therefore, consortia standards should be the third level of the hierarchy. (#31) We are gravely concerned about the potentially restrictive impact of allowing proprietary protocols without the requirement for a clear plan to transition to open standards. Proprietary protocols by definition provide an unfair advantage to a specific vendor or limited number of vendors, and we strongly disagree with "multinational commercial prevalence" as the sole criteria for openness. (#31) We do not believe it is valuable to recognize consortia developed standards and specifications to be at the same level as national standards. The latter have been through open processes to ensure equitable consideration and consensus. Though consortia developed standards may have wide acceptance, they have not undergone the same rigorous development and scrutiny as national standards, and should therefore not be included in the same category as national standards. (#40) We believe it is dangerous for the Federal Government to consider using proprietary standards except in exceptional circumstances. Using proprietary standards gives special and unfair treatment to a single vendor or small group of vendors. We agree that criteria need to be developed to define these protocols as "open". However, using "multinational commercial prevalence" as this criteria is insufficient definition to ensure an open procurement process. We believe better definition needs to be developed. (#40) Do not simply endorse IPS (or any other) specifications. Define the basic conditions for consideration of standards and alternative specifications and the processes to be followed (such as the OSE workshop process) for the specifications to be included in GOSIP. (#46) Agencies may use proprietary specifications for internal systems only. All external interfaces and Wide Area Networks (WANs) must use approved standards. Change proprietary standards to public available specifications (see OIW agreement on use of PAS in the standards process). (#61) Standards New Zealand has strong misgivings regarding your proposal to treat non-ISO solutions with equal preference. This would undermine the global benefits of adherence to standards systems agreed by the international membership of ISO, IEC and ITU. We accept that non-ISO solutions may be necessary in some instances in the short term, until industry and service providers deliver a desired range of conformant products, but conformance to ISO should continue to be the objective ...(to achieve worldwide interoperability). (#62) In order to move forward in providing realistic advice on Open Systems to its customers, NIST, CCTA, and probably most other IPSIT members, need to identify and accommodate APPROPRIATE IPS specifications WITHIN their "GOSIP-like" guidance. Adoption of ALL IPS specifications should not be advocated, only those specificatons that are stable, readily available and "fit for purpose" - identified by looking at which IPS specifications have been readily adopted by Agencies. It is likely that there will need to be a profiling activity carried out at some point by NIST in order to convert the chosen IPS specificaations into procurement profiles/subprofiles - for this we would suggest the Panel direct NIST to the recent draft from the Department of Defense as a good source. (#63) The Australian Government's GOSIP has a similar preferred order of acceptance: 1. international standards 2. national standards 3. de facto/industry standards where the specifications are publicly available or are not owned by a single supplier (TCP/IP,X/OPEN,OSF) 4. de facto/industry standards where the specifications are publicly available and are widely accepted and adopted by many suppliers (MS-DOS, Microsoft Windows, UNIX, SNA) 5. remaining proprietary standards (#70) The value of this recommendation seems to rest to a large extent on the existence of clear unambiguous criteria which standards must meet in order to qualify as "open international voluntary standards" or as "consortia standards" etc. (#72) Insert the following after 3rd sentence, first paragraph: It is recommended that OMB task NIST to lead an intensive technical effort to resolve incompatibilities between IETF and GOSIP protocols, particularly at the network/transport layer. (#81) RECOMMENDATION 5, IETF RECOGNITION ISSUES The recommendation stating that the IETF should be recognized as an open, voluntary, international standards organization is seriously flawed. Until such time as the IETF produces rules and procedures, and adopts those procedures, that are consistent with an accreditation body such as ANSI, no work performed by that body should have such status. Further, Government funding for attendance at meetings of such an organization that does not adhere to such rules and procedures should be prohibited. (#14) The panel should recommend that the IETF adopt formal voting and testing procedures in order to gain international recognition. (#16) It would be prudent to change "recognize IETF standards as open international voluntary standards" to ensure that the government does not compromise itself with regards to the selection and recognition of the many bonafide technologically important standards bodies. In lieu of "recognizing the IETF", the Government could state that "the IETF standards, as a defacto set of interoperable standards that address agencies' requirements, may be used by agencies for their network activities. (#17) We (a European commenter) do not regard IETF standardization as international. (#18; also #42) We (another European commenter) have concerns about the international acceptability of de facto recognition by the US Government of IETF standards as open international voluntary standards. We believe it would be preferable to encourage the submission of these to the international voluntary process. (#20) It is not in the best interests of users or vendors to have a large number of peer organizations who can (and eventualy will) produce conflicting standards. Rather the Government should work towards convergence and harmonization to a single standard, using the existing international system of ISO, IEC, and ITU. The specific recommendation to grant the IETF status equivalent to ISO would set an undesirable precedent because there are many other groups who could meet the same objective criteria. (#31) Although we fully support recognition of IPS standards as not only acceptable, but a desirable element of internetworking federal agencies, we have a concern over recognition of IETF standards as "open international voluntary standards". A U.S. unilateral declaration of IETF as open and international will not change the facts and might even be detrimental. We suggest that the panel revisit this recommendation and suggest that IETF review the approach used by the IEEE whose standardized network services are currently the essence of the global internetworking that exist today. We believe that a more prudent course would be for the panel to recommend that the federal government support the formal accreditation processes of IETF. The suggested approach is to seek formal approval through existing standards processes (such as the ISO "fast track" process) for the stable and widely implemented IETF "Internet Standard" RFCs. Without formal accreditation of IETF, we believe their documents should not be classified as "open international voluntary standards". Rather, the IETF documents should be considered as preferable to limited scope national, consortia, or proprietary solutions. (#35) We are afraid that an unconditional endorsement of IPS would cause serious problems on interoperability and give negative influence on international standardization. In order to improve and ensure the interoperability, we believe that the following conditions are essential for endorsement of IPS: - Ultimate convergence of TCP/IP and OSI is attained with provision of solution of technical weaknesses of the current TCP/IP. - A world-wide open and fair formal review and balloting process is applied for authorization of IPS with concrete fixed documents. (#39) We do not believe broadening the criteria for international standards organization to include the IETF would be in the best interest of the Government or vendors. Each incremental addition to the ISO, IEC, and ITU as acceptable international standards organizations, adds to user confusion, introduces significant possibilities for multiple peer standards that are incompatible or in conflict with each other, makes achieving the Government's interoperability objectives more difficult, and undermines the effectiveness of the established and recognized standards organizations. By accepting the IETF, the door would be opened for other organizations to also be accepted as peers. Since the JTC1 is now working on ways to recognize and use the work of the IETF, it would seem to be premature for the U.S. Government to accept the IETF as a peer of the ISO/IEC until this work is complete. It is one thing to accept the IPS protocol suite to be on a par with the OSI, but an entirely different thing to accept the IETF to be a peer of the ISO, IEC, and ITU. The Federal Government should instead follow the panel's recommendation and focus its attention on harmonizing a single internetworking standard under the auspices of the established standards organizations. (#40) The Internet Society is viewed as a U.S. (rather than an international) organization by other countries. This perception was reinforced at the 1993 Amsterdam IETF meeting when it was made quite clear that major decisions would not be taken at meetings held outside the U.S. (#46,#63) We have strong misgivings regarding your proposal to treat non-ISO solutions with equal preference. This, we believe, would undermine the global benefits of adherence to standards systems agreed by the international membership of ISO, IEC, and ITU. (#62) It is not necessary to "recognize" the IPS to use it in guidance where appropriate in the UK. (#63) There is a much better and simpler way (than recognition of IETF) to promote the IETF specifications to the level of "open and international standards". This is to use the power and influence of the US industries and Government in forums like ISO and ITU to approve these (and maybe other) specifications as "open international standards", as is already done by some very well known organizations like IEC and IEEE. (#64) Whilst the Internet community has been highly successful in developing and deploying internetworking technology, recognizing it as a legitimate standards-making body is premature, given its lack of due process and formal voting procedures. It best serves the needs of the international community by progressing its technical work in a manner analogous to the equally successful IEEE, and feeding its technology into existing International Standards bodies, e.g., ISO/IEC and ITU-T, to achieve the appropriate level of international recognition. Whilst participation in the Internet community is broadening, it is currently heavily weighed towards U.S. opinion due to continued imbalance of U.S. participation vs the rest of the world. The question of adoption of standards for addressing schemes and administration over allocaton of addreses is extremely delicate. Only legally-recognized international and national organizations can be allowed to deal with such matters. To create yet another international standards organization is both unnecessary and counter-productive. (#72) Even if the U.S. Government recognizes the IPS as open international voluntary standards, there is no guarantee that the rest of the world would do likewise. If the U.S. formalizes acceptance of the IPS, it could result in a negative reaction in the world-wide standards community. (#74) CBEMA does not support interpretations of OMB Circular A-119 which extend the scope of "standards" included to cover specifications (consortia documents, proprietary protocols, etc) which have not been endorsed by the formal standards process. If recognition of IETF were undertaken, then there might well be hundreds of "open international voluntary standards" and the world would be faced with a myriad of standards. On the other hand, the emerging efforts on the part of both IETF and the ISO/IEC JTC1 community to seek ways to elevate IETF technology to ISO or JTC1 status must be explored further such that, where appropriate, IETF technology does indeed become elevated to official international standards status as a result of achieving a consensus of the materially interested parties. (#79) We are concerned about formal government recognition until ISOC receives such recognition by the appropriate organizations or convinces others that it fits the category of an open public standard setting body. (#80) 1.2 IPS This section on the TCP/IP protocol suite is short in comparison with section 1.1 on GOSIP. The term "Internet Protocol Suite" and the acronym IPS are invented in this report and are not common usage. Common useage is the TCP/IP Protocol Suite and the more general term Internet Standards, which embraces the full set of standards used in the Internet, including the OSI Protocol Suite. (2 commenters) (#24,#27) 1.3 BACKGROUND We take strong exception to the biased nature of the report in attributing Internet success to the IPS. We believe that the Internet's success is mainly based on the market acceptance of the many other rigorous technical standards such as IEEE's, and not on the merits of the IETF protocols and processes. (#16) The past investment of public funds in apparently competing approaches to programmes of similar technical scope is not reviewed or explained in the report. There are significant differences in the way public funds have been used - in developing and piloting protocols (IPS), in creating procurement rules and in providing support for the development of testing (OSI). (#63) 1.4 CURRENT SITUATION The Government lack of GOSIP enforcement coupled with continued Internet subsidy funding is at variance with stated policy of preference for international standards. By creating a form of welfare network this had resulted in market confusion which has undermined international standards and the companies which support them. Government subsidies have obscured the true costs of development and operation to the users. It is disingenuous for the panel to claim that Internet success has been a "marketplace decision". (#16) The fact that the IPS has major limitations as well as considerable merit is not often disputed. The report, however, says very little about limitations and the means of achieving resolution of them. The maxim if "pretty simple and pretty good" is insufficient for robust and secure commercial networks that the nation needs to compete successfully. The report is particularly negligent in acknowledging shortcomings that result from lack of rigor in protocol development and in proposing no firm remedies. (#16) It might also be useful to note that Government agencies expend a lot of effort to put GOSIP products on federal procurements, but seldom buy any. One has to question the purpose of NIST and FIPS if there is no government agency that makes sure that the FIPS compliant products are really procured. (#34) The report does not address some of the basic reasons for the lack of support by industry in developing products supporting OSI protocols. The fact that there is no government policing mechanism in place to enforce the GOSIP mandate, and the willingness on the part of government engineers and procuring officials to ignore he mandate has everything to do with the slow development of OSI products. (#74) 2.1 FUNCTIONAL MODES In addition to broadcasting, mention should be made of the very large distributed bulletin board like service known as Usenet. (#27) 3.0 INTERNATIONAL INTEROPERABILITY The analysis of the impact on international agreements and trade have not been performed. An analysis of Agency requirements as they relate to their international partners needs to be more fully specified. The Government should abide by the current agreements - whether they be OSI or IPS - and there should be no attempt to change the protocol suites already selected. (#14) 3.1 FORMAL INTERNATIONAL STANDARDS There has been little or no "due process" in formal international standards, since they are formulated and promulgated by appointees of governments, and by large telephony and telegraphy monopolies. (#38) 3.3 INTERNATIONAL INFRASTRUCTURE In many countries, like Brazil and most Latin American neighbors, there is not even a single commercial IPS network, and commercial and government traffic are not allowed in the academic IPS networks. In clear contrast, international standards like X.25 and X.400 are well available in many countries and represent an important backbone for international communications and business. They are provided by the public telecom operators at affordable prices and these X.25 and X.400 networks are indeed running business applications like EDI, funds transfer, export and import data, etc. (#64) 3.4 INTERNATIONAL OBLIGATIONS Any deviation from the current commitment to international standards based IT procurement and use will have a significant and negative effect on many aspects of inter-agency cooperation. In particular, the following agencies will be affected: NATO; the (Canadian) Departmant of National Defence/DoD; the (Canadian) Civil Aviation Authority/FAA; the (Canadian) National Library/Library of Congress; the (Canadian) Communications Security Estalishment/NSA; and the (Canadian) Department of Industry/Department of Commerce. (#46) In order to achieve a global data network, globally allocated addressing schemes (and the protocols that carry them) must be defined and used at the start. Those addressing schemes as defined by ISO and ITU-T (CCITT). For government to deploy a whole of government network tht can internationally connect, be used for trade, banking, customs and immigration, police, health and taxation, etc and interface to the private sector, the network must conform to international (carrier based) standards and their addressing schemes. GOSIP specifies ISO/ITU-T protocols which carry globally specified addressing and this is GOSIP's main strength. GOSIP should not be seen as just the specification of "other communications protocols". But the foundation for the US's whole of government naming and addressing scheme, networking and agency interworking. (#59) The draft report contains nothing on the question of collaboration between the authorities which maintain various equivalents of US GOSIP. The cost of procurement profiles, which add precision to agreed standards making them more suitable for the procurement of internetworking solutions and services, is one which can be shared among many national administrations. (#63) CCTA would expect the report to be rejected unless ... the outcome of discussions with other major administrations, especially representatives of the European Union, were added. (#63) A major concern is the disalignment of the US GOSIP in respect to other countries governmental policies (UK, Europe, Australia, Brazil, etc.) despite the intensive harmonization efforts that are being carried out by organizations like IPSIT and ISO itself. (#64) Several agencies, including the FAA, have developed major world wide standards and implementatons within their industry sectors (and their respective international standards organizations) based on OSI. The FAA has actively participated in development of international standards and implementation agreements under the International Civil Aviation Organization (ICAO), a very strong affinity group. This group has adopted a new data communications protocol architecture, based on the OSI protocols, known as the Aeronautical Telecommunications Network (ATN). This network design effort selected the OSI protocols for internetworking only after determining that the IPS protocols could not meet the requirements. (#74) 3.5 INTERNATIONAL TRADE The networking culture associated with the IPS is an important element of national competitiveness. (#4) For international trade, X,400, EDI, and X.500 are of paramount importance. (#18) In response to the invitation for comment with respect to trade implications, we encourage the government to buy from the "best qualified source", regardless of the country of origin. If the federal government wants to assist U.S. software and hardware developers, it should discontinue its export restrictions. (#27) Network standards such as NDIS (Microsoft/3Com) and ODI (Novell) are for all practical purposes open standards specifying data-link implementation. Interestingly, vendors throughout the industry use these specificatons to insure interoperability with their non-Novell and non-Microsoft products. Historically, the Government has chosen to stand clear of proprietary technologies, forfeiting an opportunity to promote Federal interoperability and a national technology/industrial policy. The Federal Government should seriously consider adopting a policy supporting and stimulating successful pseudo-proprietary protocols in an effort to promote and protect the Nation's lead in software technology. The Government may wish to exend this policy and support to include completely proprietary networking technologies including market leaders such as IPX/SPX (Novell Netware), Banyan IP (Banyan Vines) and Microsoft's LAN Manager protocols. The Federal Government uses these products extensively. It makes great sense to create policy aimed at defining the Government's use of these products, while using this experience to assist U.S. industry to compete abroad. Experience shows that it is virtually impossible to prevent Federal network administrators from purchasing and proliferating proprietary networks. It is somewhat obvious, then, that the Government should concentrate on recommending and managing the implementation of leading proprietary protocols. (#54) In a world economy where Government's subsidize their high-tech industries, the U.S. Federal Government must be careful not to restrict technologies based on the preferences of standards committees and affinity groups. The nation can no longer afford to separate internal and industrial policy. (#54) We do not believe (the conclusions and recommendations) will lead to necessary global harmonization and needed international communication standards or electronic commerce. (#60) Current crypto technology export restrictions will have a direct impact on global electronic commerce and NAFTA. (#61) Departure from international standards is in conflict with GATT Standards Code Clause 2.2, which allows departures only on good and sound reasons such as national security, prevention of deception, etc. (#62) There is danger that inappropriate conclusions may be drawn about the continuing commitment of the US to implement internationally agreed standards. This danger should be eliminated with a clear proposal for US implementation and trading policies and complementary detailed action plans. (#63) If the U.S. government simply adopts as an "open international standard" the IETF specifications, this could stimulate other countries to start their "own international forums" that will produce "open and international indigenous standards" creating nontariff barriers to trade, in clear disagreement with GATT decisions. (#64) The laws of the European Union are now applicable in Sweden. According to EU decision procurers have to refer to de jure standards. Statskontoret (Swedish representative in IPSIT) anticipates that a lot of communications between administrations in Europe will use X.400 communications. (#66) The European Union decides who are the standards bodies which have been given exemption from prosecution under competition legislation through definition in an annex to a decision implementing Article 5 of the Treaty of Rome. (#69) The FAA must be greatly concerned with interoperability with other international aviation entities. Watering down GOSIP would send the wrong signal concerning the U.S. commitment to OSI standards in the aviation community, and potentially weaken U.S. suppliers competing for foreign markets, where OSI is a firm requirement. (#74) 4.2 DEVELOPMENT AND USE OF STANDARDS The report might have wider international acceptability through omission of the last sentence of Section 4.2. (#20, #57) The last paragraph suggests that the replacement for IP should converge with the replacement for CLNP. It is not clear that any effort is underway in the ISO community to replace CLNP. (#24) The idea of converging SDOs into a single international standards forum, also mentioned in the last paragraph, is probably politically impossible. However, the formation of common working groups, whose output would be ratified by all three SDOs, may be practical. (#29) The process for selecting the replacement for IP is taking into account the same range of requirements that a process for selecting a replacement for CLNP would have to take into account. (#32) The OSI versus IPS debate is not as much a technology debate as it is a culture clash and process problem. The concept of developing and adopting "paper-proven" protocols versus "standardizing" existing protocols in the public domain tht have a proven implementation record in the same functional problem domain is at odds with what the marketplace really desires. (#34) The IETF, being a practical group, has often described how to use its protocols in the IEEE/CCITT/ISO environment, to work with industry consortia (the cellular telephone EIA/TIA is adopting IP for packet data), and to carry proprietary protocols (Novell and Apple). The contrary has generally not been true. The NIST should follow the lead of the IETF in encouraging efforts at functional interoperability. (#38) The report needs to be a bit more specific about its recommendations in respect to proprietary protocols. In NASA experience, proprietary protocols are the least desirable path for system-wide interoperability. The report needs to be much more cautionary when accepting the possibility of the use of proprietary protocols to achieve interoperability across even the smallest and most islated affinity group. (#57) 4.3 IETF STANDARDS The last sentence of the first paragraph, on the revision of the Internet Standards process, is misleading. The revision of the process is pretty well complete. Revision of the documentation is still underway, although its essentially complete too. (#24) If the definition of "open, international, voluntary standards" is to be interpreted to include the IETF process, why would it not also include OSF and IEEE? (#58) 4.4 FEDERAL INTERNETWORKING STANDARDS SELECTION I think that although the fees charged for ISO standards are far higher than the cost of dissemination, the report should not take an implied stand against use of ISO standards, when they are otherwise appropriate, based on the fees. (#5) I want to register strong agreement with the statement that all standards and profiles used in federal networking need to be widely available in electronic and paper form at low or no cost. (#9; also #74) The last paragraph of 4.4 suggests the use of technology forecasting. This should be reconsidered as the last time Commerce did this and bet on the OSI horse, the horse did make a showing, but it wasn't a clear winner. (#29) The price of standards should not be an issue, since the cost of standards is minimal compared to other costs and therefore should not be relevant to protocol selection. Since revenue from the sale of standards is significant for standards developers who are not subsidized by the Federal Government, advocating its elimination should be accompanied by alternative suggestions. (#31) Changing the GOSIP acronym would be an appropriate symbolic gesture. 'GPIN' is too awkward. (#43) Make concrete proposals to make standards and alternative specifications widely and cheaply available. (#46) The Federal Government should not base its operating procedures on emerging standards, international trends or a handful of supporting industrial participants. This again brings up the fierce issue of standards determination. The economics of technology and innovation suggest a cautious approach highly favorable to adopting industry-proven networking architectures. The Government should have four major roles in the determination of Federal internetworking standards and policy: 1) To study and evaluate emerging market technologies, 2) To recommend appropriate market leaders as Federal networking alternatives, 3) Provide funding for the integration of successful, complimentary and competing communications standards (i.e., ATM, NDIS (Microsoft/3Com), IP, X.400, etc.), and 4) Insure proper economic incentives for the development of enabling and enhancing technologies (e.g., 100 Mbps Ethernet). This "common vision" will most certainly enhance Federal internetworks while contributing to a pro-active, high-tech industrial policy. It is possible to achieve these goals through positive reinforcement as opposed to mandate. (#54) We suggest a better acronym for the new, improved GOSIP. It is "Government Open Systems Profile for Internetworking Leadership", or, the GOSPIL. (#57) Standards New Zealand adopted a form of GOSIP as a national standard in October 1991. The core document is a profile of international standards. We believe that making GOSIP a national standard has focused all IT sectors nationwide (not just government agencies, but also private enterprise). (#62) The name GOSIP is well known and any change may cause more confusion than enlightenment, especially in other countries who also have GOSIP requirements. (#74) 4.5 TESTING The tone of this paragraph is that interoperability testing is "real-world" testing and is to be preferred, while conformance testing is "ivory tower" and is of little consequence in the real world. Both are essential. (#1; also #72) The panel should emphasize continuation of the Government role in conformance and interoperability testing. (#16; also #58) The report produces an unbalanced view of the topics of conformance and interoperability. Conformance and interoperability testing should be regarded as complementary. (#20) Streamline conformance testing and add interoperability testing. Agencies should be allowed to choose from a (limited) range of quality assurance options based on their own needs. Both kinds of testing should be harmonized with European and Asian efforts. Conformance testing should be a post-award requirement in procurements rather than a prerequisite for bidding. (#31) Formal conformance testing is not always necessary. We do not see a need for formal conformance testing and registration of protocols nor a formal interoperability testing and registration process as being necessary for these protocols to work in the marketplace. The "wellness" and robustness of an implementation should be left up to the vendor. If a vendor sells a product that doesn't work properly, its reputation will be quickly tarnished and customers will stop buying. This is the way it is for most other aspects of a product. Needless testing adds needless costs. In many federal procurements, in order to bid, the vendor must undergo a very lengthy and expensive GOSIP testing process. Testing the basic stack can run into the multiple hundreds of thousand of dollars. This cost is incurred even before the contract is won. The fact is there are government agencies and private labs that make their whose living and careers off testing. It is not in their best interest to simplify life and let the market decide based on the reality of a product to meet the customer's mission, not a contrived test suite. (#34) The panel's emphasis on "pragmatic demonstration of real interoperation" is commendable. However, conformance testing using formal techniques is still essential to quality "reference" implementations and maintain the consistency of a standard and its implementation. (#35; also #37, #39, #56, #64) We agree that greater emphasis should be placed on interoperability testing, but not to the exclusion of conformance testing. Having a limited range of testing options, interoperability and conformance, available would permit agencies to specify the degree of conformance/interperability assurance they require. This would also permit vendors to limit their product testing time and expense to only what the agency required. (#40) Recognize the strategic importance of harmonized international test services and the need for North America to be a part of that process. (#46) The current GOSIP conformance testing should continue to be mandated and should be extended to mandatory interoperability testing. CDA (a NIST accredited U.S. GOSIP test laboratory) has not seen even one product complete the initial test campaign cleanly, with no bugs discovered. If the mandate is dropped, no vendors will voluntarily step up to conformance testing. CDA has not performed a single conformance test that was not mandated by the procuring agency. The current NIST GOSIP testing program is being looked up to as the model which other governments (including our own State governments) and private industry will use to influence their own purchasing policies. (#48) The UK CCTA is avoiding direct investment in testing to support UK GOSIP. It is encouraging the use of Supplier Declarations as the primary interface between customer anad provider. The supplier will determine and express the conformance characteristics and the interworking capability of systems and services proposed which can then be subject to warranty. (#63) The success of Internet is in part because it combines specification and testing with additional processes, such as reference implementations and reference systems. (#69) With the increasing commoditisation of software, we believe that testing, particularly conformance testing, is basically an industry matter and governments should not be directly involved in the process. Suppliers need to commit to the interoperability of their products on an ongoing basis and interoperability testing either between suppliers or through an independent testing capability should assist in achieving this. (#70) The federal Government should fund interoperability testing for GOSIP standards in the same way that it has contributed to testing within the Internet. (#78) 5.1 FUNCTIONAL COMPARISON Concerns about IP address space limitations were expresssed by many commenters. (#7,#15,#39,#41,#46,#51,#52,#59,#63,#65,#68,#70,#72,#75, #76,#79) While TP4/CLNP is mentioned, it should also be noted that OSI has 4 other transport protocols (TP0 through TP4). This adds an extra layer of INoperability. TP0 and TP2 over X.25 are quite popular in Europe. (#34) The FTAM protocol does not map well at all to widely used operating systems such as Unix and DOS. The sophisticated additional capabilities within FTAM are often unimplemented and rarely, if ever, used. (#34) X.400 offers some advantages over SMTP like the receipt notification, but the addresses are unwiedly. Almost no one carries an X.400 address on their business card. Many people put their Internet address on cards today. For those who do put their X.400 address on cards, most people would not know how to send them mail. If X.400 addresses are going to remain a reality, they are going to have to be radically simplified. There should be a government standard way to write an email address. Right now, the standard seems to be Internet style (user@host.agency.gov). (#34) The statement about IP being treated as flat identifiers is not really true. The statement that OSI protocols do not have these routing limitations is false; OSI protocols are more flatly routed than IP, partly because assignment has no topological planning. (#38) The report does not offer an unbiased analysis of OSI vs. TCP/IP. Transaction processing is excluded from the comparison. (#42) IPS at the IP level has a fundamental weakness, its addressing scheme. (IP is similar to ISO's CLNP except for its addressing scheme.) The IP "address" is not an address in fact, it is a limited length, randomly allocated number. It is physically and operationally impossible to build a global network using "addresses" which are a randomly allocated number. The route update traffic and the network's operational costs will kill such a network. (Note: that the carriers use structured addressing schemes in their global networks.) (#59) Is there an issue that the Internet group can in fact allocate sufficient IP addresses to the US government. Therefore network scaling and interconnection with TCP/IP will not be such of a problem to them. Certainly, the rest of the world does not have such control over TCP/IP address space allocation and so must either run the risk with TCP/IP using its address "left overs" or adopt GOSIP specified ISO/ITU-T addressing schemes. (#59) Directory services are critical to the success of "Integrated Electronic Access to Government and Services." The NIST "Functinal Comparison" overstates the evaluation of X.400. The evaluaton is based on the 1984 version that does not support directory services. (X.500). NIST should identify the projected dates for interoperability tested and registered X.500 products from vendors. NIST should reevaluate Gopher and World-Wide Web in light of their enormous growth. (#61) This report should make a solid recommendation that CLNP replace IP in the IPS, and soon. (#74) The report fails to recognize technical facts associated with the deficiencies of the IPS. (#74) Delete all of section 5.1, except for the first and last paragraph, and reword accordingly. The summary of the NIST functional comparison could be perceived as an incomplete and conflicting view. For example, the comparison of SNMP and CMIP is unfair and tends to favor the Internet solution. It would be better only to cite the NIST document. (#81) 5.2 SECURITY This paragraph is distorted enough that it needs to be rewritten. The OSI protocol stack is given "short shrift" in terms of security. On reading this section, a reader unfamiliar with both stacks would conclude that the two are roughly equivalent. The reality is that the OSI protocol stack is significantly better that IPS in this area. (#1) The report correctly points out that there are a number of unresolved security concerns that impede the full use of networking to achieve the goals of the U.S. Government. These issues transcend the specific protocol suite in use. (#22) The third paragraph, on the security of SMTP, doesn't accurately describe the situation. Privacy Enhanced Mail (PEM) protects mail against forgery, tampering, and unauthorized disclosure. (#24) See also comment from #24 under Recommendation 2 on role of NIST. The last paragraph, on the distribution of source code, should be revised to clarify the intended meaning, as to whether it is critical or supportive of the idea of distributing source code. Some argue that exposure of the source code is a mistake because it might aid a penetrator. Others argue that accessiblity of source code is ultimately an aid to finding and fixing security flaws. (#24) Security is an increasingly important area to both our government and commercial customers. Our commercial customers are looking for security standards for their messaging traffic, TCP/IP, and LANs. The panel must address the issues relating to key escrow policies if it intends to make recommendations concerning security standards. (#43) Recognize the importance of effective security to future networking and the role that the open systems security standards should play in ensuring that security is designed into systems. Make recommendations for the establishment of an appropriate infrastructure for the support of network security services. (#46) Suggested additional Recommendation: "A number of U.S. security policy issues affect the pace of security deployment in the Internet, since solutions need to be applicable worldwide. These policy issues include cryptography, key escrowing, export control, digital signature standards and patents." Current policies are not necessarily as helpful to the overall "national security" (which is now properly understood to be based, in the long term, on more than just deployed military and other security assets, but rather includes such things as overall industrial and technology base, etc) as they might be. In particular, the restrictions on some security-related technologies have been counter-productive, and, as the report properly notes, have had a severe negative impact on the ability to secure the Internet. For instance, the current set of wire-tapping attackers have been aided greatly by the lack of encrypted passwords on the network, which has been in large part caused by the inability of manufacturers to ship products with encryption included, even encryption technology readily available overseas. One of the Recommendations of the report should be that the Government should examine policy in this area with a view toward setting a policy which meets broad long-term national goals, not simply the short-term goals of the intelligence and law-enforcement community. (#55) Technology for an electronic signature is critical for government-wide email and electronic commerce. The NIST "Functional Comparison" does not identify the problems with the proposed FIPS. (#61) In OSI, unlike IPS, substantial progress has been made both in defining and implementing security for open systems. Particular examples include X.400, X.500, the Transport and Network Layer Security Protocols, the Security Frameworks, and the Generic Upper Layer Security work. (#73; also #39,#46,#79) 5.3 TECHNICAL SUFFICIENCY While the report acknowledges the importance of transaction processing (TP), the ISO TP standard is almost completely overlooked. On the other hand, TP is listed in section 4.2 as an example of one of the areas where proprietary standards might be used. Products based on ISO TP are on the market, and ISO TP has ben selected in the work of consortia, e.g., TxRPC in both X/Open and MIA, to provide a transactional RPC. (#29) Since OSI products are primarily available for hosts or workstations and not for PCs and Macs, the OSI product suite doesn't well address a LAN environment. Since PC/Mac based LANs have become the norm, the lack of standards or products to support the LAN environment significantly impacts the success of OSI. (#37) More emphasis should be placed on the need for an upper layer architecture. New applications to be developed on top of the network may make good use of a common upper layer structure. (#74) 5.6 TECHNICAL INFRASTRUCTURE General support for internetworking should be available from a common point and not distributed between several agencies. Information that should be available includes types of products available, guidance on migration issues, and information on testing. (#74) 6.0 ECONOMIC CONSIDERATIONS We agree with most of the conclusions in the report, especially Section 6 "Economic Considerations" which is completely consistent with our experience in this market. (#43) Section 6.0 is flawed by not listing the costs for NIST registered OSI products. (#61) 6.3 PRODUCT DEVELOPMENT SCO intends to coninue development of X.400, X.500, and EDI, but sees no economic incentive to update TP4/CLNP, VT or FTAM, or to provide a CMIP/CMIS product. (#43) Because TP4/CLNP provide little functional improvement over TCP/IP we do not forsee them ever replacing the IPS. We are therefore continuing to invest our networking development dollars on enhancing the IPS. (#77) 6.4 COST A chief contributor to the loss of marketplace momentum for OSI products was that (at least within DoD) there were significant procurement barriers. Specifically, neither the Desktop III or Desktop IV contract, nor the Navy LAN or Navy Companion contracts offered an OSI suite for the MS DOS based desktop. However, these contracts did offer IPS solutions. Further, when OSI based products were available (such as the OSI options for Novell Netware), they were frequently omitted from standard contracts and from GSA schedules - a significant barrier to procurement. (#37) _____________________________________________________________________ INDEX OF FIRP COMMENTS Organization Country (if not individual) (if not US) 1. Mike Medenis 2. Jon Postel 3. Paul Leopardi Australia 4. Cliff Bamford 5. Alex McKenzie 6. Bob Stine 7. Kirby Spencer 8. Donald Lanzinger 9. James H. Haynes 10. Greg Minshall 11. Scott Marcus 12. Bob Crispen 13. Tony Villasenor (empty) 14. James Moulton Open Network Solutions, Inc. 15. Roy Standing National Library of Medicine 16. Ron Skelton Electronic Power Research Inst. 17. Bob Aiken/ Dept. of Energy John Cavallin 18. Roy Cadwallader European MAP/TOP User Group 19. Tarvi Martens Estonia 20. Richard Carr National Computing Centre Ltd UK 21. Vinton G. Cerf Internet Society 22. Christian Huitema/ IAB/IETF Phillip Gross 23. Ron Skelton (same as #16) 24. Stephen D. Crocker 25. Randolph Mitchell 26. Geoff Huston AARN Australia 27. Robert M. Enger 28. Henry M. Hermetz 29. Henry Lowe OSF 30. Arthur K. Reilly Committee T1, Telecommunications 31. Stephen Oksala Unisys 32. Allison J. Mankin IETF IPng Arena 33. (part of #32) 34. Mark Harris Sun 35. Barbara K. Hoven Battelle Pacific Northwest Laboratory 36. Ed Lerner 37. Timothy Frichtel 38. Bill Simpson 39. Akifumi Kambara POSI/INTAP Japan 40. Joel Urman IBM 41. Bob Sieber 42. Ulrich Hartmann Siemens Nixdorf Information Sys Germany 43. Jay Heiser The Santa Cruz Operation, Inc. 44. Theodore Ts'o 45. David D. Clark 46. Mike Harrop OIMST, Canada Canada 47. Mike Harrop (continued) 48. Kevin Murray CDA Incorporated 49. David Wasley 50. Larry Dusold FDA 51. Han Q. Nguyen AT&T 52. Tony Hain 53. Larry S. Bartz 54. Michael E. Shatz 55. Noel Chiappa 56. Richard Bailly 57. Lynwood Randolph NASA 58. Gary Workman GM 59. Alan Lloyd Datacraft Limited Australia 60. Andrew McMillan World Federation of MAP/TOP Users Grp 61. Jerry Johnson State of Texas 62. Bruce Scott-Hill Standards New Zealand New Zealand 63. Mark Gladwyn UK CCTA UK 64. Paulo Francisco de Vilhena Toledo BRISA Brazil 65. John Day 66. Britta Johansson Statskontoret Sweden 67. Dan Young New Zealand 68. J. J. Cinecoe Boeing Information Services 69. Chris Cheetham BSI UK 70. Ann Whitehead Australian Government IESC Australia 71. Guptila de Silva Australia 72. Keith Knightson CIGOS, Canada Canada 73. Michael Harrop CAC/SGFS, Canada Canada 74. Theron Gray FAA 75. Leon Shameson NASA Ames 76. Daniel Nordell Northern States Power Company 77. Helen Bradley SunSoft 78. Henry Bayard MITRE 79. Rhett Dawson CBEMA 80. Earl Barbely Department of State 81. Emmett Paige Department of Defense From francis@cactus.slab.ntt.jp Fri Apr 22 10:23:08 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA23594 for ; Thu, 21 Apr 1994 21:23:49 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Fri, 22 Apr 1994 10:23:09 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA07463; Fri, 22 Apr 1994 10:23:09 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA07186; Fri, 22 Apr 94 10:23:08 JST Date: Fri, 22 Apr 94 10:23:08 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404220123.AA07186@cactus.slab.ntt.jp> To: ipng@cmf.nrl.navy.mil Subject: O'Hare Marriott Status: O > > If you will be spending the night, we recommend that you stay at > the Marriott O'Hare (NOT the Suites). Marriott O'Hare is within walking > distance of the Big-10 Conference Center and offers a special rate of > $78 for folks who will be using the Big Ten Conference Center. The > reservations number is 1-800-228-9290 > To actually get the low rate, you must call Marriott O'Hare directly, at +1-312-693-4444. PF From brian@dxcoms.cern.ch Fri Apr 22 11:50:21 1994 Return-Path: brian@dxcoms.cern.ch 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 FAA25706 for ; Fri, 22 Apr 1994 05:51:01 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA09403; Fri, 22 Apr 1994 11:50:22 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA10711; Fri, 22 Apr 1994 11:50:21 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404220950.AA10711@dxcoms.cern.ch> Subject: Re: A modest proposal To: ipng@cmf.nrl.navy.mil Date: Fri, 22 Apr 1994 11:50:21 +0200 (MET DST) In-Reply-To: <9404201208.13559@munnari.oz.au> from "Jon Crowcroft" at Apr 20, 94 01:07:14 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1214 Status: O Hmmm... The F field should be split in two, a Provider ID and a Subscriber ID. It then plays the same role as the Site Address in AEIOU; I think the transition plan would turn out very similar to AEIOU. That way we only get say 2**6 providers with 2**8 subscribers each. I don't think that lives very long. (AEIOU lives longer.) By extending the address, you change the API, so all Steve Deering's arguments against AEIOU apply equally against I PING. I was persuaded by the AEIOU BOF to put the idea aside for the next few months (until after Toronto). I am not convinced that FAT will work, but I don't have time to think about it. I do agree about incremental change being successful. That's exactly what led me to AEIOU. But I tend to think that the I PING increment is too small to be worthwhile. I propose the same action as for AEIOU. Where we really need an urgent incremental fix is route aggregation. I am not enough of a routing expert to make sensible proposals, but it is dangerous to sit back and rely on CIDR alone. Can somebody invent a way of (automatically?) identifying and announcing Route Aggregation Groups? Once you have them, I can easily imagine using GRE to exploit them. Brian From J.Crowcroft@cs.ucl.ac.uk Fri Apr 22 11:04:05 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id GAA25733 for ; Fri, 22 Apr 1994 06:04:43 -0400 Message-Id: <199404221004.GAA25733@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 22 Apr 1994 11:04:08 +0100 To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: A modest proposal In-reply-to: Your message of "Fri, 22 Apr 94 11:50:21 +0100." <9404220950.AA10711@dxcoms.cern.ch> Date: Fri, 22 Apr 94 11:04:05 +0100 From: Jon Crowcroft Status: O >That way we only get say 2**6 providers with 2**8 subscribers each. 2**8 providers with 2**6 * current number of subscribers each i.e. 256 providers and 128 million hosts per .... at current IPv4 usage - if cidr lets us push each F space to 10 million, that gets you enough hosts for 1 per person in each country quite happily... the header reqriting in a fat (hardly ever needed) is so minimal that it can be done at normal forwarding speeds easily, the code is very easy... the mutual use of IPv4 and I PING nets to carry each others traffic is a major deployment leverage compared to all and every other IPng proposal. It means that FATs can be absolutely deployed anywhere in the net whether in IPv4 or I PING land... jon From brian@dxcoms.cern.ch Fri Apr 22 13:56:13 1994 Return-Path: brian@dxcoms.cern.ch 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 HAA26093 for ; Fri, 22 Apr 1994 07:56:47 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08247; Fri, 22 Apr 1994 13:56:15 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA14933; Fri, 22 Apr 1994 13:56:13 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404221156.AA14933@dxcoms.cern.ch> Subject: Re: retreat info To: ipng@cmf.nrl.navy.mil Date: Fri, 22 Apr 1994 13:56:13 +0200 (MET DST) In-Reply-To: <9404212057.AA21041@hsdndev.harvard.edu> from "Scott Bradner" at Apr 21, 94 04:57:08 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 502 Status: O It is unlikely that I can make it to the retreat (no funding and no time, since I have to allow extra days for jet lag both ways). I'm investigating a possible funding source but I am not hopeful. I would appreciate it if you could set up a telechat on the Thursday at the usual time, for me and anyone else who can't make it, and maybe also another one on Friday. I guess you would need a speaker phone in Chicago. If I was the only remote participant it can just be a straight phone call. Brian From sob@hsdndev.harvard.edu Fri Apr 22 08:07:10 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA26159 for ; Fri, 22 Apr 1994 08:07:23 -0400 Date: Fri, 22 Apr 94 08:07:10 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404221207.AA10080@hsdndev.harvard.edu> To: Brian.Carpenter@cern.ch Subject: Re: retreat info Cc: ipng@cmf.nrl.navy.mil Status: O Brian, I expect that a telechat could be done & sounds like a good idea for those who can't make the meeting. Scott From sob@hsdndev.harvard.edu Fri Apr 22 08:42:07 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA26318 for ; Fri, 22 Apr 1994 08:42:15 -0400 Date: Fri, 22 Apr 94 08:42:07 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404221242.AA20262@hsdndev.harvard.edu> To: Brian.Carpenter@cern.ch Subject: Re: alignment Cc: ipng@cmf.nrl.navy.mil Status: O > I think we have to accept that using NSAPAs and insisting on 2**N alignment are incompatible requirements. NSAPAs are variable length. this is not the same thing as saying that IPng must not support NSAPs (fixed length) is it? Scott From brian@dxcoms.cern.ch Fri Apr 22 15:28:04 1994 Return-Path: brian@dxcoms.cern.ch 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 JAA26514 for ; Fri, 22 Apr 1994 09:28:38 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA28701; Fri, 22 Apr 1994 15:28:05 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA17662; Fri, 22 Apr 1994 15:28:04 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404221328.AA17662@dxcoms.cern.ch> Subject: Re: alignment To: sob@hsdndev.harvard.edu (Scott Bradner) Date: Fri, 22 Apr 1994 15:28:04 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <9404221242.AA20262@hsdndev.harvard.edu> from "Scott Bradner" at Apr 22, 94 08:42: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: 740 Status: O >--------- Text sent by Scott Bradner follows: > > > I think we have to accept that using NSAPAs and insisting > on 2**N alignment are incompatible requirements. NSAPAs are > variable length. > > this is not the same thing as saying that IPng must not support NSAPs > (fixed length) is it? > No. However, NSAPAs as deployed (for example) in the European CLNS pilot are variable length. I don't think you will satisfy the Jack Houldsworth convergence requirement if you restrict NSAPAs to a fixed length subset. Yakov has pointed out to me that you can use padding to align objects which follow a variable length NSAPA. True of course. Bandwidth used to transmit padding is a trade-off against performance gained by alignment. Brian From Robert_Ullmann.LOTUS@CRD.lotus.com Fri Apr 22 10:05:34 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA26759 for ; Fri, 22 Apr 1994 10:00:08 -0400 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA24044; Fri, 22 Apr 94 10:01:25 EDT Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA07385; Fri, 22 Apr 94 10:05:34 EDT Date: Fri, 22 Apr 94 10:05:34 EDT Message-Id: <9404221405.AA07385@Mail.Lotus.com> Received: by DniMail (v1.0); Fri Apr 22 10:05:32 1994 EDT To: UNIXML::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Re: Digest of Comments on Draft Firp Report Status: O No Jim, they aren't clueless at all. They are dead-on. They recognize the IETF for what it actually *is*, and are not deluded by what it pretends to be. Rob From scoya@CNRI.Reston.VA.US Fri Apr 22 10:07:15 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA26861 for ; Fri, 22 Apr 1994 10:08:48 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04952; 22 Apr 94 10:07 EDT To: ipng@cmf.nrl.navy.mil Subject: Agenda for April 25 IPNG Telechat Date: Fri, 22 Apr 94 10:07:15 -0400 From: Steve Coya Message-ID: <9404221007.aa04952@IETF.CNRI.Reston.VA.US> Status: O Greetings, Here is the agenda for Monday's telechat. Note the number of minutes which need to be approved prior to making them available in the shadow directories. In a seperate message following this agenda, I will resend all 4 sets of minutes. Your faithful scribe, Steve ========================================================== IPNG Directorate Teleconfence Agenda for April 25, 1994 1. Administrivia o Roll Call o Agenda bashing o Approval of minutes March 14 March 21 March 31 April 11 2. The IPNG Retreat Parallel processing agenda guests 3. Brian's proposed convergence requirement 4. Mergers & new Proposals (TURNIPP, Jon's IPNG) 5. External Review panel Procedures 6. Procedures for Reviewing Proposals Against Requirements 7. Roundtable List of those who have rsvped about the retreat Scott Bradner Yes Allison Mankin J Allard, Mircosoft Steve Bellovin, AT&T Yes Jim Bound, DEC Yes Ross Callon, Wellfleet Brian Carpenter, CERN No Dave Clark, MIT Jon Crowcroft, UCL John Curran, NEARnet Steve Deering, Xerox PARC Yes Dino Farinacci, Cisco Yes Eric Fleischman, Boeing Possibly Paul Francis, NTT Yes Daniel Karrenberg, RIPE No Frank Kastenholz, FTP Yes Mark Knopper, Ameritech Greg Minshall, Novell No Craig Partridge, BBN Rob Ullmann, Lotus Lixia Zhang, Xerox PARC Yes From scoya@CNRI.Reston.VA.US Fri Apr 22 10:08:24 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA26874 for ; Fri, 22 Apr 1994 10:09:54 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04989; 22 Apr 94 10:08 EDT To: ipng@cmf.nrl.navy.mil Subject: Set of minutes from the last 4 IPNG discussions Date: Fri, 22 Apr 94 10:08:24 -0400 From: Steve Coya Message-ID: <9404221008.aa04989@IETF.CNRI.Reston.VA.US> Status: O FYRP ------- Message 1 DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference March 14, 1993 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES - --------- Scott Bradner / Harvard Allison Mankin / NRL Steve Bellovin / AT&T Jim Bound / DEC Ross Callon / Wellfleet Brian Carpenter / CERN Jon Crowcroft / UCL John Curran / NEARnet Dino Farinacci / Cisco Eric Fleischman / Boeing Frank Kastenholz / FTP Mark Knopper / Ameritech Paul Mockapetris / ISI Craig Partridge / BBN Lixia Zhang / Xerox PARC Regrets - ------- J Allard / Microsoft Dave Clark / MIT Steve Deering /Xerox PARC Paul Francis / NTT Daniel Karrenberg / RIPE Greg Minshall / Novell Rob Ullmann / Lotus 1. The minutes from the January 25 meeting (held over the MBone) were approved. Coya to place in public Shadow directories. 2. The minutes from the February 14 Teleconference were approved. Coya to place in the public Shadow directories. 3. Craig Partridge invited everyone to the second integrated services bof meeting during the Seattle IETF meeting, which will be discussing integrated service requirements for IPNG. 4. The potential impact on the directorate of the IAB/IESG Nominating Committe results were discussed, noting the original restriction that no IAB or IESG members would sit on the IPNG Directorate. A number of people voiced the opinion that the affected folks be permitted to stay (grandfathered). The consensus was that this question be brought up to the full IETF plenary during the Monday morning session at Seattle. 5. Scott reviewed the status of the white paper reviews. Will be drafting a disclaimer to be used and will send to the IPNG Directorate for review. 6. Frank reminded everyone that the March 10 version is the document that should be reviewed. Frank reviewed some of the document changes being added, and will include a change log in subsequent versions of the document. The directorate then discussed various sections of the document, offering comments and suggestions. It was reiterated that this document will eventually become the IPNG Directorate Requirements document, and that the White Paper submissions will be reviewed against it. It was suggested that the requirements document needs to be reviewed on a "line-by-line (or item-by-item)" basis by the entire directorate prior to the Seattle meeting. The only real option is the teleconfernce scheduled for March 21. The current version of the document criteria.txt, can be retrieved from research.ftp.com in the pub/ip7reqs directory. ------- Message 2 DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference March 21, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES - --------- Scott Bradner / Harvard Allison Mankin / NRL J Allard / Microsoft Jim Bound / DEC Dave Clark / MIT Eric Fleischman / Boeing Frank Kastenholz / FTP Greg Minshall / Novell Paul Mockapetris / ISI Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets - ------- Steve Bellovin / AT&T Ross Callon / Wellfleet Brian Carpenter / CERN Jon Crowcroft / UCL John Curran / NEARnet Steve Deering / Xerox PARC Dino Farinacci / Cisco Paul Francis / NTT Daniel Karrenberg / RIPE Mark Knopper / Ameritech Craig Partridge / BBN 1. Scott and Allison will attempt to organize a dinner for the IPNG Directorate members on Thursday, following the IESG Plenary, during the Seattle IETF meeting. 2. The list of IPNG presentations that are to take place Monday morning in Seattle were reviewed. The breakdown is as follows: a. Allison and Scott - IPNG status b. Dave Clark - status of the External Review Panel c. Frank Solensky - Report from the ALE WG d. Jon Crowcroft and/or Frank Kastenholz - Report on the IPNG Requirements document 3. Coya to prepare an IPNG track for Seattle and send to Scott and Allison. Coya to send message to the IPNG list soliciting the formal set of documents from each of the groups. 4. The text of the disclaimer written by Allison and Scott, which is to be included in IPNG documents, was read to the directorate. No requests for changes were made. 5. Allison conducted a full review of the Criteria section of the requirements document. Request changes include: a. In the section on scale, the phrase "up to" should be replaced with "at least" A notation that "another 3 orders of magnitude might be needed" will be added. b. All references to the big-internet list should include the list address. c. In the discussion on scale, change "whole purpose" to "initial motivating purpose" d. Replace "very very very" with "extremely extremely extremely" :-) Ok, maybe only need one extremely... just wanted to see who's reading these minutes. e. The character string to use is IPng, not IP:NG (5 points to those who recall why the colon was there in the first place, 5 bonus points to whomever knows the entire history (with dates)! f. The requirement that multiple IPNG protocols co-exist needs to be reworded as there will only be one (1) IPNG protocol. Will be reworded to require that multiple versions of IPNG need to co-exist on the network. g. On the section on Media, expand "VJ-like" to "Van Jacobson-like" h. It was requested that the requirements include "the ability to send an IP datagram as large as allowed by the inter-network layer (assuming, of course, that the recipient is able to accept a datagram that large). The topic of fragmentation was raised, but discussion was deferred. i. In the section on Configuration, Admin, and OPS, it should be added that "nothing in the proposal should inhibit a future requirement for auto registration." j. It was suggested that the IAB report from the Security W/S might provide text for the security section of the requirements document. Coya to send to the IPNG list, Kastenholz to review. k. In the section on unique naming, use the phrase "multicast addresses" l. In the section on extensibility, reiterate the need to run multiple versions on IPNG over the same wire. m. In the section on non-goals, it was suggested that the section on IPv4 and IPng Communication be removed as it was not needed in the requirements document. n. Might be able to incorporate some ideas, concepts and text from the IAB report or the recently published RFC on Firewall in the section on Firewalls in the requirements document. o. There is a need to clarify what is meant by "accounting" in the section on non-goals. Kastenholz will reword. p. In the section on robust service, it was stated that host performance should not decrease (below the level of IPv4), and that the protocol should not, due to its complexity or other features, increase the liklihood of poor implementation on host platforms, especially with respect to performance. ------- Message 3 DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference March 31, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES - --------- Scott Bradner / Harvard Allison Mankin / NRL J Allard / Microsoft Jim Bound / DEC Ross Callon / Wellfleet Brian Carpenter / CERN Dave Clark / MIT John Curran / NEARnet Steve Deering / Xerox PARC Dino Farinacci / Cisco Eric Fleischman / Boeing Paul Francis / NTT Mark Knopper / Ameritech Greg Minshall / Novell Frank Solensky / FTP Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets - ------- Steve Bellovin / AT&T Jon Crowcroft / UCL Frank Kastenholz / FTP Daniel Karrenberg / RIPE Craig Partridge / BBN Note: This was a dinner meeting held durinr the Seattle IETF meeting 1. The idea of an IPNG directorate reteat was discussed, and it was agreed that not only was it a good idea, it was necessary. It was also suggested that the retreat include non-Directorate invitees (Hinden and Ford we mentioned as examples). 2. A round of "for he's a jolly good fellow" was sung for Scott Bradner (not sure why, though it may be due to his moving tables :-) 3. It was suggested that the Requirements document should NOT be considered as a checklist (missing architectural overviews), but it would be a good idea to have the IPng candidates defend their proposals against the framework of the requirements document. 4. Eric proposed a list of 6 procedural steps or viewpoints that could be taken towards a resolution of the selection process. The six steps are: 1) "Spec Check": compare IPng alternatives to requirements doc 2) Enumerate the real technical differences between proposals in regards to the requirements 3) Enumerate the real operational differences between the proposals 4) Address real deployment and transition plans: contrast dual stack and IPAE transition scenarios 5) Proof of concept: what has actual "running code" to date demostrated about the approach -- address scalability issues if possible. 6) Identify the incentives provided by each approach for users to deploy that option. A comment was made that this list, while good, could not be accomplished in 3-4 months (by the July IETF meeting in Toronto). It was suggested that after item 1 was completed, the entire directorate should review the responses (to #1) as a group, probably at the retreat. 5. There was some spirited discussions on the fact that each proposal had both good and bad points, and it was suggested that a merger of the proposal features might still be possible in the timeframe, and be able to offer an attractive answer. 6. Steve collected the money and paid the bill. No one sang :-) ------- Message 4 DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference April 11, 1994 Reported by: Steve Coya This report contains IPNG Directorate meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. ATTENDEES - --------- Scott Bradner / Harvard Allison Mankin / NRL Steve Bellovin / AT&T Jim Bound / DEC Ross Callon / Wellfleet Brian Carpenter / CERN Steve Deering / Xerox PARC Dino Farinacci / Cisco Eric Fleischman / Boeing Frank Kastenholz / FTP Greg Minshall / Novell Craig Partridge / BBN Lixia Zhang / Xerox PARC Regrets - ------- J Allard / Microsoft Dave Clark / MIT Jon Crowcroft / UCL John Curran / NEARnet Paul Francis / NTT Daniel Karrenberg / RIPE Mark Knopper / Ameritech Rob Ullmann / Lotus 1. Steve Coya was asked to resend the minutes from the March 14 and March 21 teleconferences. Steve still needs to write up his notes from the dinner meeting held during the Seattle IETF. 2. Frank and Craig summarized the discussions that occurred during the Requirements WG meeting that was held in Seattle. Scott and Allison will set set the schedule and specific requests for the EXRP review of the requirements document. 3. Jim Bound summarized the meeting of the TACIT BOF from the Seattle IETF meeting. 4. Steve Deering, Jim, and Ross commented on the SIPP meeting in Seattle. There was a significant amount of discussion on the IPAE portion of the SIPP meetings, especially on the number of folks who either did not read, or did not understand the specification. 5. Jim reported on the Tuba meeting as Mark Knopper was unable to participate in the teleconference. 6. The directorate tentatively agreed to hold their retreat in a meeting room at O'Hare airport May 19-20. Coya to poll directorate members to see who will attend. ------- End of Forwarded Messages From sob@hsdndev.harvard.edu Fri Apr 22 10:28:19 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA27147 for ; Fri, 22 Apr 1994 10:28:27 -0400 Date: Fri, 22 Apr 94 10:28:19 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404221428.AA17640@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: Re: alignment Status: O > NSAPAs to a fixed length subset just to continue the nits, how about a fixed length superset? e.g. left justified in space will null padding if required. Scott From brian@dxcoms.cern.ch Fri Apr 22 16:40:05 1994 Return-Path: brian@dxcoms.cern.ch 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 KAA27267 for ; Fri, 22 Apr 1994 10:40:39 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16025; Fri, 22 Apr 1994 16:40:06 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20222; Fri, 22 Apr 1994 16:40:06 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404221440.AA20222@dxcoms.cern.ch> Subject: Re: alignment To: ipng@cmf.nrl.navy.mil Date: Fri, 22 Apr 1994 16:40:05 +0200 (MET DST) In-Reply-To: <9404221427.AA17531@hsdndev.harvard.edu> from "Scott Bradner" at Apr 22, 94 10:27:53 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: 333 Status: O Yes that's doable. But some people will say it is highly undesirable (just too many bytes). Brian >--------- Text sent by Scott Bradner follows: > > > NSAPAs to a fixed length subset > > just to continue the nits, how about a fixed length superset? > e.g. left justified in space will null padding if required. > > Scott > From J.Crowcroft@cs.ucl.ac.uk Fri Apr 22 15:53:26 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA27409 for ; Fri, 22 Apr 1994 10:54:20 -0400 Message-Id: <199404221454.KAA27409@picard.cmf.nrl.navy.mil> Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 22 Apr 1994 15:53:27 +0100 To: Steve Coya cc: ipng@cmf.nrl.navy.mil Subject: Re: Agenda for April 25 IPNG Telechat In-reply-to: Your message of "Fri, 22 Apr 94 10:07:15 EDT." <9404221007.aa04952@IETF.CNRI.Reston.VA.US> Date: Fri, 22 Apr 94 15:53:26 +0100 From: Jon Crowcroft Status: O >4. Mergers & new Proposals (TURNIPP, Jon's IPNG) > Jon Crowcroft, UCL i am definitely tied up on monday, so canmnot be in this. I have had several favourable comments and one negative one about my proposal. I do not intend to do any work on it (but if i get a spare weekend, i might implement the host part...) - it was partly meant to prompt people that there are two conflicting desires 1. any change has to be tested - if its smaller, its easier to implement and test/proove 2. if we change at all it would be nice if the change incoprorated the all bells & whistles of everyone's attempt to be the Next Internet's Architect with the benefit of 15 yrs experience, 1 tends to work better than 2... cheers jon From sobel@rintintin.Colorado.EDU Fri Apr 22 13:14:11 1994 Return-Path: sobel@rintintin.Colorado.EDU Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA00115 for ; Fri, 22 Apr 1994 15:14:59 -0400 Received: by netop3.harvard.edu (5.65/DEC-Ultrix/4.3) id AA15285; Fri, 22 Apr 1994 15:18:11 -0400 Received: (from sobel@localhost) by rintintin.Colorado.EDU (8.6.8.1/8.6.6/CNS-3.5) id NAA21876; Fri, 22 Apr 1994 13:14:13 -0600 From: Alan Sobel Message-Id: <199404221914.NAA21876@rintintin.Colorado.EDU> Subject: Request for Information To: ipng-wp@harvard.edu Date: Fri, 22 Apr 1994 13:14:11 -0600 (MDT) Cc: sobel@rintintin.Colorado.EDU (Alan Sobel) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 770 Status: O I wonder if you could help me please. I'm a grad student in Telecom at the University of Colorado. I've been getting interested in routing issues lately. I'd like to get connected with the processes now going on to select a new IP and new routing procedures. I understand there are currently three choices for IPng: TUBA, SIPP and CATNIP. I also thought there was at least one additional one: PIP. Can you tell me about the selection process so far, ie, why is PIP no longer a candidate? Is there a document that speaks to this? Is there a mailing list or announcement list for these kinds of issues. I would appreciate any help or pointers you could give me about where to keep up with these matters. Thank you very much. Alan Sobel sobel@rtt.colorado.edu From Greg_Minshall@Novell.COM Fri Apr 22 15:08:11 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA01844 for ; Fri, 22 Apr 1994 18:09:47 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA20134; Fri, 22 Apr 94 16:14:26 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA00826; Fri, 22 Apr 94 15:08:12 PDT Date: Fri, 22 Apr 94 15:08:11 PDT Message-Id: <9404222208.AA00826@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: Re: alignment Status: O Brian, >Yes that's doable. But some people will say it is highly >undesirable (just too many bytes). I won't! I won't! I won't! I won't! (Which is to say, if you are *already* going to be sending 20 bytes, go ahead and send 24.) Greg From Greg_Minshall@Novell.COM Fri Apr 22 16:13:41 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA02039 for ; Fri, 22 Apr 1994 19:15:10 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA23590; Fri, 22 Apr 94 17:19:53 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB01008; Fri, 22 Apr 94 16:13:41 PDT Date: Fri, 22 Apr 94 16:13:41 PDT Message-Id: <9404222313.AB01008@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: bound@zk3.dec.com From: Greg Minshall Subject: Re: Host: Options, Variable Addresses, and Alignment Cc: ipng@cmf.nrl.navy.mil Status: O Jim, >The way IPv4 options have to be processed today on a Host are horrible. >The way SIPP has proposed it with Payload Type in the header is very >good. It permits chaining efficiently when working with the header and >is very fast. In other words I like Payload Type value in the header. Why are IPv4 options horrible for hosts today? (I agree they are horrible for routers, mainly because even if none of the options have anything to do with routers, they have to look at each and every one.) >On a Host a variable address is a negative. First there are two types of >variable addresses. The first one is bounded. You are given a max and >the address can be variable up to that max. Then there is the unbounded >and that means there is no max and you will not know the length until >you look at the length field for the address. Either case is not good >for a host, because when you build data structures to access the address >or use the address as a key to access the data structure in a list (for >example) you must use an instruction to get the length of the address >first. So each time your Host networking subsystem does anything with >addresses you must 'first' get the length. In some cases you also may >need to grow memory not knowing ahead of time how much memory you need >to support a data structure. Then for 'garbage collection' you need to >return or efficiently reuse that memory. I would say that some bounded number would work. This is sort of like the systems which used to set TTL to 32 (in a #define compiled into the kernel). Those systems eventually broke, but somehow the world managed to upgrade. (Though, for toasternet, etc., maybe things won't be so easy.) >An advantage of SIPP is that the addresses are 64bits and the address >can be extended to support multiple 64bits. This could be used very >efficiently to support NIMROD EIDs and Locators from a software >perspective in an implementation. The above permits implementors to >use the bounded form of variable addresses as needed. For example the >EID for the immediate future can be 64bits. These can support many >globally unique addresses for a specific site including the Toasters and >Cable Lines. Then additional 64bit addresses can be used to support the >NIMROD locators (SIPP address sequence). Isn't this the worst (in your view): unbounded variable length addresses? I don't know what the NIMROD references mean, but i probably don't care right now. However, i doubt that 64 bits is a long term EID. >The 64bits in this manner supports the existing sockets structure very >well and can be implemented very efficiently. If NSAPs were the addressing >structure of IPng the EID can be extended to support additional 64bit elements >in the structure with a minimal change on Hosts. This is just a matter >of structuring the NSAP to fit 64bit addresses. But I believe for a >very long time 64bits per site is enough, and routing information can be >supplied by additional 64bits as required. 64 bits, maybe. But, what about 128 bits (which SIPP addresses can be)? Or, 192 bits? >This scheme also maintains differentiation between EIDs at the >Transport. Huh? Which scheme? What EIDs at the Transport? >Host Alignment of Protocol Fields Yes. >A fixed length header for IPng network layer protocol is also a win for >the Host. I don't know any of the current IPng proposals which has a fixed header length. Greg From J.Crowcroft@cs.ucl.ac.uk Sun Apr 24 15:05:08 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA05939 for ; Sun, 24 Apr 1994 10:07:22 -0400 Message-Id: <199404241407.KAA05939@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 24 Apr 1994 15:05:15 +0100 to: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: Digest of Comments on Draft Firp Report In-reply-to: Your message of "Fri, 22 Apr 94 00:39:32 EDT." <9404220439.AA10967@xirtlu.zk3.dec.com> Date: Sun, 24 Apr 94 15:05:08 +0100 From: Jon Crowcroft Status: O jim, thanks for forwarding this i think a lot of the comments are useful in 4 different ways > DIGEST OF COMMENTS ON DRAFT FIRP REPORT 1. now we know who "they" are 2. I would distinguish as "they" anyone who saw fit to contribute here, but not to the original input (and Milo assured us the call was very wide!) 3. I would further distinguish those who comment here fro mthose who did not see fit to comment on IPng via the white paper process 4. I agree the UK CCTA comment that the document is seriously flawed in calling for US to look at ISO and IP[S], while not either a) listing all other open standards or b) listing none of the above the tellign phrase they use (and we have to use in the UK/Europe to justify any acquisition) is "fit for purpose" if the purpose is described as 'open communication', in such a way as to describe function., but not form, and to exclude any possible restraint of trade implied in products provided for the purpose, then you don't need to say IP or ISO... i think it is a strategic error to name names... on the question of convergence, in this document, i think the responses concerning a mature approach to mixing approporiate technoloy are encouragign (c.f. use of X>400 over internet - both from technical, vendors and others) - the non-technical dismissal of rfc1006 seems a little harsh... as far as i'm concerned, in addressing the convergence question, we want convergence on a technically feasible, cost effective solution that can be contracted for - thats all that is needed - convergence at a given protocol at a given layer is part of that, but convergence on a particular stack is not. i.e. use of CLNP is not called for necessarily, but has some benefits, except for some vendors, and most host acquistion at the momnent. Use of IP and x.400 as a mix is. rfc1006 is one convergencve technology - there are other possibilities (mentioned in these respnses) by the way, on the quesiton of multiple IPngs coexisting, i have no problem, so long as convergence techniques provide interworking for the users - i.e. we use x.400 mail, but interwork with smtp where need be... has anyone tried drawing up a table of convergence, and whether adoption of, say, SIPP and TUBA actually causes more or less problems? and if the adoption of medium term techniques like two tier, NAT and other non-global address approaches, and intermediate approaches like aeuou and i-ping, actually make the whole choice near to a non-problem? cheers jon From bound@zk3.dec.com Sun Apr 24 10:17:38 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA05982 for ; Sun, 24 Apr 1994 10:20:59 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA03005; Sun, 24 Apr 94 07:17:52 -0700 Received: by xirtlu.zk3.dec.com; id AA00457; Sun, 24 Apr 1994 10:17:44 -0400 Message-Id: <9404241417.AA00457@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: sob@hsdndev.harvard.edu (Scott Bradner), ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: alignment In-Reply-To: Your message of "Fri, 22 Apr 94 15:28:04 +0200." <9404221328.AA17662@dxcoms.cern.ch> Date: Sun, 24 Apr 94 10:17:38 -0400 X-Mts: smtp Status: O Padding fields does not fix the performance problem of variable addresses on hosts. We need to be careful here not to get off track and keep the issues separate, which are variable address strategies and alignment. These are two different issues. NSAPs can be made to support fixed length addresses. /jim From sob@hsdndev.harvard.edu Sun Apr 24 10:19:31 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA05978 for ; Sun, 24 Apr 1994 10:20:51 -0400 Date: Sun, 24 Apr 94 10:19:31 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404241419.AA02905@hsdndev.harvard.edu> To: J.Crowcroft@cs.ucl.ac.uk, bound@zk3.dec.com Subject: Re: Digest of Comments on Draft Firp Report Cc: ipng@cmf.nrl.navy.mil Status: O > has anyone tried drawing up a table of convergence This is something that I think we need to do at some point, anyone have any specific ideas? Scott From bound@zk3.dec.com Sun Apr 24 10:22:40 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA05991 for ; Sun, 24 Apr 1994 10:25:42 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA03279; Sun, 24 Apr 94 07:22:51 -0700 Received: by xirtlu.zk3.dec.com; id AA02873; Sun, 24 Apr 1994 10:22:46 -0400 Message-Id: <9404241422.AA02873@xirtlu.zk3.dec.com> To: Robert_Ullmann.LOTUS@CRD.lotus.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Digest of Comments on Draft Firp Report In-Reply-To: Your message of "Fri, 22 Apr 94 10:05:34 EDT." <9404221405.AA07385@Mail.Lotus.com> Date: Sun, 24 Apr 94 10:22:40 -0400 X-Mts: smtp Status: O >No Jim, they aren't clueless at all. They are dead-on. I don't agree with you. >They recognize the IETF for what it actually *is*, and are >not deluded by what it pretends to be. The most widely deployed open system protocol suite in the world that is not under the control of a singler vendor. Thats what they don't understand or like. They tried building one and it did not work and is still not deployed on a wide scale. /jim From sob@hsdndev.harvard.edu Sun Apr 24 10:26:25 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA05997 for ; Sun, 24 Apr 1994 10:28:23 -0400 Date: Sun, 24 Apr 94 10:26:25 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404241426.AA03417@hsdndev.harvard.edu> To: Brian.Carpenter@cern.ch, bound@zk3.dec.com Subject: Re: alignment Cc: ipng@cmf.nrl.navy.mil Status: O Jim, Humm, I was sorta thinking about padding 'variable' length addresses to produce fixed length addresses that would be treated as fixed length. Scott From J.Crowcroft@cs.ucl.ac.uk Sun Apr 24 15:31:57 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA06011 for ; Sun, 24 Apr 1994 10:34:35 -0400 Message-Id: <199404241434.KAA06011@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 24 Apr 1994 15:32:00 +0100 To: sob@hsdndev.harvard.edu (Scott Bradner) cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Digest of Comments on Draft Firp Report In-reply-to: Your message of "Sun, 24 Apr 94 10:19:31 EDT." <9404241419.AA02905@hsdndev.harvard.edu> Date: Sun, 24 Apr 94 15:31:57 +0100 From: Jon Crowcroft Status: O >> has anyone tried drawing up a table of convergence >This is something that I think we need to do at some point, anyone have >any specific ideas? Scott first thing, at internet layer, is a simple taxonomy of schemes IPngs basically increase the address space. IPv4 workarounds use 1 or both of: a) header adress replacement b) non unique address schemes (dynamic assignment) stack convergence is done at some layer or other, either by protocol translation, or by service translation: 3. CLNP <-> IP header re-writing 4. CLNP + IP ships in night, with TCP/TUBA dual stack end systems 5. TP4 and TCP and rfc1006 interworking boxes in fact, you can probably pull them all togerther into some nice abstract model, with an algebra of interworking (commutes, associates, distributes, etc - a layer over another layer is just F(G(x)), so there's obviously going to be some simple model that allows you to decide which convolutions will interwork (c.f. domains and ranges being big enough etc) good topic for a PhD - a formal model of convergent networking.... meanwhile, back to trying to get PPP working on my pc... jon From bound@zk3.dec.com Sun Apr 24 11:29:35 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA06142 for ; Sun, 24 Apr 1994 11:31:11 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA06720; Sun, 24 Apr 94 08:29:46 -0700 Received: by xirtlu.zk3.dec.com; id AA03948; Sun, 24 Apr 1994 11:29:41 -0400 Message-Id: <9404241529.AA03948@xirtlu.zk3.dec.com> To: Greg Minshall Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Host: Options, Variable Addresses, and Alignment In-Reply-To: Your message of "Fri, 22 Apr 94 16:13:41 PDT." <9404222313.AB01008@WC.Novell.COM> Date: Sun, 24 Apr 94 11:29:35 -0400 X-Mts: smtp Status: O Greg, >>The way IPv4 options have to be processed today on a Host are horrible. >>The way SIPP has proposed it with Payload Type in the header is very >>good. It permits chaining efficiently when working with the header and >>is very fast. In other words I like Payload Type value in the header. >Why are IPv4 options horrible for hosts today? (I agree they are horrible >for routers, mainly because even if none of the options have anything to do >with routers, they have to look at each and every one.) IPv4 options are not known in each successive header option. With a payload type I know what the next optiion will be as I process that option. This affords me to build recursive routines to process the internetwork packet. The use of payload type also permits me to absorb new options into the recursive routines in the future. By having a priori knowledge any time in my software engineering paradigm its good. I guess I believe 'hints' are a good thing. Good point on the router too. I had not even considered that. This is specified better in the SIPP spec. >>On a Host a variable address is a negative. First there are two types of >>variable addresses. The first one is bounded. You are given a max and >>the address can be variable up to that max. Then there is the unbounded >>and that means there is no max and you will not know the length until >>you look at the length field for the address. Either case is not good >>for a host, because when you build data structures to access the address >>or use the address as a key to access the data structure in a list (for >>example) you must use an instruction to get the length of the address >>first. So each time your Host networking subsystem does anything with >>addresses you must 'first' get the length. In some cases you also may >>need to grow memory not knowing ahead of time how much memory you need >>to support a data structure. Then for 'garbage collection' you need to >>return or efficiently reuse that memory. >I would say that some bounded number would work. This is sort of like the >systems which used to set TTL to 32 (in a #define compiled into the >kernel). Those systems eventually broke, but somehow the world managed to >upgrade. (Though, for toasternet, etc., maybe things won't be so easy.) Yes I am saying a bounded number would work too. But I am also driving at that 64bits if used for only one domain (.dec.com, ibm.com, novell.com, or toasters.com) provide 1.8**19 nodes. Thats an awful lot. I am assuming there is no routing state in the 64bit address which makes it a NIMROD EID. The NIMROD locators would be the address sequence to support routing et al. I am talking to Noel about this now trying to verify my idea. >>An advantage of SIPP is that the addresses are 64bits and the address >>can be extended to support multiple 64bits. This could be used very >>efficiently to support NIMROD EIDs and Locators from a software >>perspective in an implementation. The above permits implementors to >>use the bounded form of variable addresses as needed. For example the >>EID for the immediate future can be 64bits. These can support many >>globally unique addresses for a specific site including the Toasters and >>Cable Lines. Then additional 64bit addresses can be used to support the >>NIMROD locators (SIPP address sequence). >Isn't this the worst (in your view): unbounded variable length addresses? What I am saying above is that the 64bit address is the ONLY address I care about for the application, transport layer, network layer address to the transport layer, and that the address sequence is part of the routing layer (in the abstract sense) and not part of the identification of the node (in my case a host as we know it in my other mail etc.). But the socket structure can 'hold' the entire address sequence of 64bits even though only one 64bit address is needed for applications or the transport layer for the host. In the future if we need 128bits or 192bits you shift the number of bits used to identify the host at the transport. Then in the advent that 64bits (1.8**19) are blown away in the future we can add an additional 64bits in the year 2020 to increase the address space for a node. The address sequence can be whatever we need into the future. >I don't know what the NIMROD references mean, but i probably don't care >right now. However, i doubt that 64 bits is a long term EID. If an EID is JUST FOR ONE site why is not 1.8**19 not enough addresses for any entity (I hate this word) we know of or can think of right now? >>The 64bits in this manner supports the existing sockets structure very >>well and can be implemented very efficiently. If NSAPs were the addressing >>structure of IPng the EID can be extended to support additional 64bit elements >>in the structure with a minimal change on Hosts. This is just a matter >>of structuring the NSAP to fit 64bit addresses. But I believe for a >>very long time 64bits per site is enough, and routing information can be >>supplied by additional 64bits as required. >64 bits, maybe. But, what about 128 bits (which SIPP addresses can be)? >Or, 192 bits? There will be a SIPP API spec out I hope this week extended from Bob Gilligans work per Bob, Ramesh Govidan, Sue Thomson and myself. Here is the structure you will see in that document. Each sipp_addr element is 64bits. I am saying there is a separation between the transport node address and the routing sequence. And your right SIPP could be 192bits. This is why the SIPP addr can support easily an NSAP address that is a power of 2 (I would like to see an NSAP address be a power of 2 in length). ============================================================== 4.2. Socket address structure The sockaddr_in structure is used in the socket system calls to pass IPv4 addresses between the application and the kernel. This structure is insufficient for conveying SIPP address sequences, so we define a new sockaddr_sipp structure: struct sockaddr_sipp { short ss_family; /* AF_SIPP */ u_short ss_port; u_short ss_reserved; u_short ss_len; /* Number of SIPP addresses */ struct sipp_addr ss_addr[7]; /* SIPP Addr Seq */ }; The value of the ss_family field must be AF_SIPP. "Struct sipp_addr" defines a single 64-bit SIPP address. The ss_addr field contains the SIPP address sequence in ascending order of addresses: that is, ss_addr[0] contains the identifying address (see [2]), ss_addr[1] contains the next higher-order address and so on. It is unlikely that more than seven addresses will be required to represent source and destination address sequences. ================================================================ >>This scheme also maintains differentiation between EIDs at the >>Transport. >Huh? Which scheme? What EIDs at the Transport? It separates the transport address for a node (discussed in previous text to your response) and routing sequence used to connect the internetwork topology (whatever that is to be). >>A fixed length header for IPng network layer protocol is also a win for >>the Host. >I don't know any of the current IPng proposals which has a fixed header length. I did not say fixed header 'length' I said fixed length header. SIPP is (24 bytes) and CATNIP would be fixed too if NSAPs addresses were not unbounded. /jim From bound@zk3.dec.com Sun Apr 24 12:15:23 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA06239 for ; Sun, 24 Apr 1994 12:21:18 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA08984; Sun, 24 Apr 94 09:15:38 -0700 Received: by xirtlu.zk3.dec.com; id AA04202; Sun, 24 Apr 1994 12:15:29 -0400 Message-Id: <9404241615.AA04202@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: Brian.Carpenter@cern.ch, bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: alignment In-Reply-To: Your message of "Sun, 24 Apr 94 10:26:25 EDT." <9404241426.AA03417@hsdndev.harvard.edu> Date: Sun, 24 Apr 94 12:15:23 -0400 X-Mts: smtp Status: O Scott, > Humm, I was sorta thinking about padding 'variable' length >addresses to produce fixed length addresses that would be treated as fixed >length. Yes this is my bounded (no pun intended) case. After we agree on this then we need to ask 'why is there padding'. But in my case I am saying the transport address should be 64bits all the time. For example getting an ID in an NSAP that is sometimes 11bytes and then 13 bytes is bogus and should not be necessary. Making an NSAP 24 octets provides a multiple of 64bits which I find very nice. But I am getting more and more convinced for 'IPng' that having authority and routing state in the address structure for the transport is something we should change while we have the chance. Using 128bits for state and 64bits for node identification at the transport and for applications to me seems like a great idea. There is a cost to associated transport addresses with routing state in the implementations and this needs to be discussed if it were to be considered. /jim From jcurran@nic.near.net Sun Apr 24 20:00:34 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA07323 for ; Sun, 24 Apr 1994 20:01:34 -0400 Received: from platinum.near.net by nic.near.net id aa11827; 24 Apr 94 20:01 EDT To: bound@zk3.dec.com cc: Greg Minshall , ipng@cmf.nrl.navy.mil Subject: Re: Host: Options, Variable Addresses, and Alignment In-reply-to: Your message of Sun, 24 Apr 1994 11:29:35 -0400. <9404241529.AA03948@xirtlu.zk3.dec.com> Date: Sun, 24 Apr 1994 20:00:34 -0400 From: John Curran Message-ID: <9404242001.aa11827@nic.near.net> Status: O -------- ] From: bound@zk3.dec.com ] Subject: Re: Host: Options, Variable Addresses, and Alignment ] Date: Sun, 24 Apr 94 11:29:35 -0400 ] ... ] What I am saying above is that the 64bit address is the ONLY ] address I care about for the application, transport layer, network layer ] address to the transport layer, and that the address sequence is part of ] the routing layer (in the abstract sense) and not part of the ] identification of the node (in my case a host as we know it in my other ] mail etc.). But the socket structure can 'hold' the entire address ] sequence of 64bits even though only one 64bit address is needed for ] applications or the transport layer for the host. In the future if we ] need 128bits or 192bits you shift the number of bits used to identify ] the host at the transport. ] ] Then in the advent that 64bits (1.8**19) are blown away in the future we ] can add an additional 64bits in the year 2020 to increase the address ] space for a node. The address sequence can be whatever we need into the ] future. Very useful. Certainly beats using a single 64-bit address space and setting up our great-grandchildren for another amazing renumbering... ] There will be a SIPP API spec out I hope this week extended from Bob ] Gilligans work per Bob, Ramesh Govidan, Sue Thomson and myself. Here is ] the structure you will see in that document. Each sipp_addr element is ] 64bits. I am saying there is a separation between the transport ] node address and the routing sequence. And your right SIPP could be ] 192bits. This is why the SIPP addr can support easily an NSAP address ] that is a power of 2 (I would like to see an NSAP address be a power of ] 2 in length). ] ] ============================================================== ] 4.2. Socket address structure ] ] The sockaddr_in structure is used in the socket system calls to pass ] IPv4 addresses between the application and the kernel. This structure ] is insufficient for conveying SIPP address sequences, so we define a ] new sockaddr_sipp structure: ] ] struct sockaddr_sipp { ] short ss_family; /* AF_SIPP */ ] u_short ss_port; ] u_short ss_reserved; ] u_short ss_len; /* Number of SIPP addresses */ ] struct sipp_addr ss_addr[7]; /* SIPP Addr Seq */ ] }; ] ] ] The value of the ss_family field must be AF_SIPP. "Struct sipp_addr" ] defines a single 64-bit SIPP address. The ss_addr field contains the ] SIPP address sequence in ascending order of addresses: that is, ] ss_addr[0] contains the identifying address (see [2]), ss_addr[1] ] contains the next higher-order address and so on. It is unlikely ] that more than seven addresses will be required to represent source ] and destination address sequences. ] ================================================================ ] ] ... ] It separates the transport address for a node (discussed in previous ] text to your response) and routing sequence used to connect the ] internetwork topology (whatever that is to be). I'm a big fan for the separation of eid's from locators (look for expired ID draft-curran-tune-00.txt at your nearest internet draft site). When looking into some of the issues, the most difficult one to solve was always how to determine the appropriate locator (ASEQ, in SIPP's case) to use for a given locator. Do you know how this will be handled in SIPP? Is this covered in a draft that I somehow missed? /John From bound@zk3.dec.com Sun Apr 24 23:45:26 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA08017 for ; Sun, 24 Apr 1994 23:50:57 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA01345; Sun, 24 Apr 94 20:45:38 -0700 Received: by xirtlu.zk3.dec.com; id AA08121; Sun, 24 Apr 1994 23:45:32 -0400 Message-Id: <9404250345.AA08121@xirtlu.zk3.dec.com> To: John Curran Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Host: Options, Variable Addresses, and Alignment In-Reply-To: Your message of "Sun, 24 Apr 94 20:00:34 EDT." <9404242001.aa11827@nic.near.net> Date: Sun, 24 Apr 94 23:45:26 -0400 X-Mts: smtp Status: O >I'm a big fan for the separation of eid's from locators (look for expired ID >draft-curran-tune-00.txt at your nearest internet draft site). When looking >into some of the issues, the most difficult one to solve was always how to >determine the appropriate locator (ASEQ, in SIPP's case) to use for a given >locator. Do you know how this will be handled in SIPP? Is this covered >in a draft that I somehow missed? No its not in any draft and right now and in my mind only. Basically I see this big train coming called variable addresses. For a Host I do not think this is a good train to ride. Hence, I have figured out that SIPP with its ASEQ strategy can be altered to support EIDs and Locators very easily in the specifications. This is my own personal opinion at this point in time. I will send something to the SIPP Chairs. But my point on this list is that I don't want to see variable addresses at the host. What is OK is to have a fixed address for end system identification that contains no routing state. I am also saying that I believe 64bits is enough for JUST SITE WIDE deployment. Then additional 64bit addresses can be used for routing. If someday a site out grows 64bits we just do a software shift to the next 64bits (though I will probably be retired working on a PC and fishing in the woods and raising German Shepherds). So what I am saying now is that we can have a bounded variable address and that one of its parts is a FIXED 64bit address used as an end system identifier. Additional 64bit addresses can become locators for routing. I don't really care how this is structured and could be a 24byte (192bit) NSAP address template. This would affect: 1. Transition between legacy and new hosts (use John Crowcofts I PING issues for IPng). 2. Cache state at the network layer for on LAN or off-LAN determination. 3. Autoconfiguration because now the identifier does not have network state for routing. 4. Existing routing protocols. 5. System Discovery model in the sense there is no subnet in the address (IPv4 notion of subnet). 6. DNS would stay the same but the part used by applications and routing would change (new IPng RRs though). 7. Accessing services across the network. The changes would require new algorithms to the above. /jim From francis@cactus.slab.ntt.jp Mon Apr 25 09:55:10 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id UAA07528 for ; Sun, 24 Apr 1994 20:55:15 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 25 Apr 1994 09:55:11 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id JAA17793; Mon, 25 Apr 1994 09:55:10 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA28666; Mon, 25 Apr 94 09:55:10 JST Date: Mon, 25 Apr 94 09:55:10 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404250055.AA28666@cactus.slab.ntt.jp> To: ipng@cmf.nrl.navy.mil, scoya@cnri.reston.va.us Subject: Re: Agenda for April 25 IPNG Telechat Status: O sorry to send this to the whole list, but because of time zone differences, I might not get the info if I ask Coya directly. Could somebody send me the information necessary to join tonight's teleconference? (IE, the AT&T 800 number plus the conference code)? I *might* want to join in.... PF From kasten@mailserv-D.ftp.com Mon Apr 25 10:06:41 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA10698 for ; Mon, 25 Apr 1994 10:07:50 -0400 Received: from ftp.com by ftp.com ; Mon, 25 Apr 1994 10:07:48 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 25 Apr 1994 10:07:48 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA06688; Mon, 25 Apr 94 10:06:41 EDT Date: Mon, 25 Apr 94 10:06:41 EDT Message-Id: <9404251406.AA06688@mailserv-D.ftp.com> To: bound@zk3.dec.com Subject: Re: Host: Options, Variable Addresses, and Alignment From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 1417 Status: O > >I would say that some bounded number would work. This is sort of like the > >systems which used to set TTL to 32 (in a #define compiled into the > >kernel). Those systems eventually broke, but somehow the world managed to > >upgrade. (Though, for toasternet, etc., maybe things won't be so easy.) > > Yes I am saying a bounded number would work too. But I am also driving > at that 64bits if used for only one domain (.dec.com, ibm.com, > novell.com, or toasters.com) provide 1.8**19 nodes. Thats an awful > lot. I normally try to stay out of directorate discussion that does not pertain to the requirements document, but there is a bit of incorrect information here... An EID is not mapped one-to-one to a network node. A given node will have at least one unique EID, and can have 'many' unique EIDs. So, a 64-bit EID space would give a MAXIMUM of 1.8**19 (assuming the math is right) nodes. My gut feeling is that nodes will quite commonly have multiple EIDs (only a gut feeling, I can't justify it). Also, EIDs are to be globally unique. That is, EIDs would not be unique 'only' within ibm.com or toasters.com. This is a very important property of EIDs. Endpoints can 'move', they can move from ibm.com to toasters.com. However, the endpoint must retain the same name (that is, EID) as it does. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From bound@zk3.dec.com Mon Apr 25 10:36:04 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA11029 for ; Mon, 25 Apr 1994 10:42:07 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA24756; Mon, 25 Apr 94 07:36:15 -0700 Received: by xirtlu.zk3.dec.com; id AA19209; Mon, 25 Apr 1994 10:36:10 -0400 Message-Id: <9404251436.AA19209@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Host: Options, Variable Addresses, and Alignment In-Reply-To: Your message of "Mon, 25 Apr 94 10:06:41 EDT." <9404251406.AA06688@mailserv-D.ftp.com> Date: Mon, 25 Apr 94 10:36:04 -0400 X-Mts: smtp Status: O > >I would say that some bounded number would work. This is sort of like the > >systems which used to set TTL to 32 (in a #define compiled into the > >kernel). Those systems eventually broke, but somehow the world managed to > >upgrade. (Though, for toasternet, etc., maybe things won't be so easy.) > > Yes I am saying a bounded number would work too. But I am also driving > at that 64bits if used for only one domain (.dec.com, ibm.com, > novell.com, or toasters.com) provide 1.8**19 nodes. Thats an awful > lot. >I normally try to stay out of directorate discussion that does not pertain >to the requirements document, but there is a bit of incorrect information >here... FLAME.... Nothing attached in your mail makes anything I stated incorrect. You added more context and that is all. I think its pretty darn arrogant of you to state I am incorrect and then not justify it. Do you think your the only computer scientist on this list. Stop coming off holier than now. You talk to many of us in this manner and I suggest you cool it so we can get something done here. I don't mind constructive discussion but I have no time or cycles for arrogance. You did it publicly so did I. Scott and Allison I don't want to hear about this flame!!!!!!! FLAME OFF ... But I am glad your responding on this and all Directorate mail. >An EID is not mapped one-to-one to a network node. A given node will >have at least one unique EID, and can have 'many' unique EIDs. So, a >64-bit EID space would give a MAXIMUM of 1.8**19 (assuming the math >is right) nodes. My gut feeling is that nodes will quite commonly >have multiple EIDs (only a gut feeling, I can't justify it). Type it in your calculator. >ZAlso, EIDs are to be globally unique. That is, EIDs would not be >unique 'only' within ibm.com or toasters.com. This is a very >important property of EIDs. Endpoints can 'move', they can move from >ibm.com to toasters.com. However, the endpoint must retain the same >name (that is, EID) as it does. This is the part I disagree with in NIMROD and others. This is a mobile issue and one that would need to be discussed. It could affect the 64bit limit. /jim From bound@zk3.dec.com Mon Apr 25 10:54:25 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA11354 for ; Mon, 25 Apr 1994 10:55:47 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA26117; Mon, 25 Apr 94 07:54:35 -0700 Received: by xirtlu.zk3.dec.com; id AA20501; Mon, 25 Apr 1994 10:54:31 -0400 Message-Id: <9404251454.AA20501@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: EIDs )---> IPng and IPv4 Only could be result Date: Mon, 25 Apr 94 10:54:25 -0400 X-Mts: smtp Status: O If we buy into removing routing state from the transport address this means new sites like GTE and Cable might by pass IPv4 and transition completely and go directly to IPng (given they can get vendors to give them the software and with a big enough P.O. they can). This would mean that we will see IPng ONLY and IPv4 ONLY data paths and required. GTE and Cable would need to have these NEW IPng systems speak with their legacy IPv4 systems. They may not have IPv4 on these new systems depending on how the development cycle goes in engineering at vendors for IPng. /jim From brian@dxcoms.cern.ch Tue Apr 26 17:52:29 1994 Return-Path: brian@dxcoms.cern.ch 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 LAA21188 for ; Tue, 26 Apr 1994 11:59:43 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA19191; Tue, 26 Apr 1994 17:52:39 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA27117; Tue, 26 Apr 1994 17:52:30 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404261552.AA27117@dxcoms.cern.ch> Subject: CYA requirement To: ipng@cmf.nrl.navy.mil Date: Tue, 26 Apr 1994 17:52:29 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1217 Status: O This is to try and write down what I think both Scott and I were trying to say in yesterday's telechat about CYA (Clnp Yucky Addresses). Some organisations (including governmental organisations, and international user communities) have already allocated, and started using, NSAPAs. The allocation schemes vary and are potentially unfriendly to routing algorithms. (DECnet Phase V is generally routing-friendly, though.) However, they exist and designing new allocation schemes is certainly viewed as a hurdle in some of these communities. Therefore, an important step towards convergence of these communities and the IPng community would be the ability of IPng to support arbitrary NSAPAs in some way, perhaps inefficiently. This is not a requirement that IPng use NSAPAs as its primary address architecture. [On inefficiency: if a particular NSAPA allocation scheme is a pig to route using CLNP, it will be a pig to route using IPng, and vice versa. In relation to Steve Deering's concerns, I don't see that CYA penalises anybody more than they will be penalised anyway. If IDRP, IS-IS and ES-IS work for CLNP they work for IPng with CYA. If they don't work for CLNP, they don't work for IPng with CYA.] Brian From Greg_Minshall@Novell.COM Tue Apr 26 21:53:43 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.4.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA27416 for ; Wed, 27 Apr 1994 00:55:29 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA09395; Tue, 26 Apr 94 23:00:15 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB10480; Tue, 26 Apr 94 21:53:43 PDT Date: Tue, 26 Apr 94 21:53:43 PDT Message-Id: <9404270453.AB10480@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: CYA requirement Cc: ipng@cmf.nrl.navy.mil Status: O Brian, I tend to agree with your thinking, but i have one question... >Some organisations (including governmental organisations, and >international user communities) have already allocated, and started >using, NSAPAs. The allocation schemes vary and are potentially >unfriendly to routing algorithms. (DECnet Phase V is generally >routing-friendly, though.) However, they exist and designing new >allocation schemes is certainly viewed as a hurdle in some of these >communities. How extensive are these NSAP allocation activities? Jack H.'s (ISO guy) list was not as extensive as i had thought it might be... Greg From brian@dxcoms.cern.ch Wed Apr 27 08:38:21 1994 Return-Path: brian@dxcoms.cern.ch 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 CAA27778 for ; Wed, 27 Apr 1994 02:38:55 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22930; Wed, 27 Apr 1994 08:38:23 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA08293; Wed, 27 Apr 1994 08:38:21 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404270638.AA08293@dxcoms.cern.ch> Subject: Re: CYA requirement To: ipng@cmf.nrl.navy.mil Date: Wed, 27 Apr 1994 08:38:21 +0200 (MET DST) In-Reply-To: <9404270453.AB10480@WC.Novell.COM> from "Greg Minshall" at Apr 26, 94 09:53:43 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: 810 Status: O Good question Greg. If I had the answer I would give it. Anybody else? Shall we ask Lyman? Brian >--------- Text sent by Greg Minshall follows: > > Brian, > > I tend to agree with your thinking, but i have one question... > > >Some organisations (including governmental organisations, and > >international user communities) have already allocated, and started > >using, NSAPAs. The allocation schemes vary and are potentially > >unfriendly to routing algorithms. (DECnet Phase V is generally > >routing-friendly, though.) However, they exist and designing new > >allocation schemes is certainly viewed as a hurdle in some of these > >communities. > > How extensive are these NSAP allocation activities? Jack H.'s (ISO guy) > list was not as extensive as i had thought it might be... > > Greg > > From brian@dxcoms.cern.ch Wed Apr 27 08:47:19 1994 Return-Path: brian@dxcoms.cern.ch 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 CAA27810 for ; Wed, 27 Apr 1994 02:47:53 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23860; Wed, 27 Apr 1994 08:47:21 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA08603; Wed, 27 Apr 1994 08:47:20 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404270647.AA08603@dxcoms.cern.ch> Subject: IPng document lists To: ipng@cmf.nrl.navy.mil Date: Wed, 27 Apr 1994 08:47:19 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 205 Status: O Dear IPng WG chairs, It would be very handy to have a re-post of the lists of today's current docs for CATNIP, SIPP and TUBA (but only ones that are in the rfc or i-drafts directories). Thanx Brian From kasten@mailserv-D.ftp.com Wed Apr 27 08:21:04 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA29082 for ; Wed, 27 Apr 1994 08:22:14 -0400 Received: from ftp.com by ftp.com ; Wed, 27 Apr 1994 08:22:12 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 27 Apr 1994 08:22:12 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA05129; Wed, 27 Apr 94 08:21:04 EDT Date: Wed, 27 Apr 94 08:21:04 EDT Message-Id: <9404271221.AA05129@mailserv-D.ftp.com> To: ipng@cmf.nrl.navy.mil Subject: requirements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 682 Status: O hi we talked, monday, on getting the requirements out for a last call on monday. however, my learned co-author is in england (or maybe, right now in a plane someplace between england and home), and it will probably be a day or two before i can get his feedback. so, i suggest that getting general community feedback by 5 may (which was the original target date) is going to be less than totally realistic. perhaps, once we get our authorial butts in gear, we should shoot for general community feedback by 10 may, which is when the external review panel are supposed to also finish? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From brian@dxcoms.cern.ch Wed Apr 27 14:40:29 1994 Return-Path: brian@dxcoms.cern.ch 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 IAA29225 for ; Wed, 27 Apr 1994 08:41:06 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06937; Wed, 27 Apr 1994 14:40:31 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16830; Wed, 27 Apr 1994 14:40:29 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404271240.AA16830@dxcoms.cern.ch> Subject: Re: requirements To: ipng@cmf.nrl.navy.mil Date: Wed, 27 Apr 1994 14:40:29 +0200 (MET DST) In-Reply-To: <9404271221.AA05129@mailserv-D.ftp.com> from "Frank Kastenholz" at Apr 27, 94 08:21:04 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: 71 Status: O I agree, the 10th is more realistic. But let's not miss it. Brian From mankin@cmf.nrl.navy.mil Wed Apr 27 09:14:21 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id JAA29437 for ; Wed, 27 Apr 1994 09:14:23 -0400 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id JAA20771 for ipng; Wed, 27 Apr 1994 09:14:21 -0400 Date: Wed, 27 Apr 1994 09:14:21 -0400 From: Allison J Mankin Message-Id: <199404271314.JAA20771@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: Review of the Proposals Status: O Directorate, We determined at Monday's telechat that the time is now for the directorate to do their full reviews of the three sets of proposal specs. Scott and I request that you do written reviews by Sunday, May 8 (midnight). This is what the directorate has been trained, honed and deeply invested in every sense to accomplish. We need this review to begin the next stage in the process, we need it to be already done and in good shape as the basis for our retreat discussions. As we discussed on Monday, send these reviews to the ipng list. As always, it is your option to discuss separate or private concerns with Scott and/or I. Where possible we want these reviews to be among the directorate, but we discussed that some of the directorate members are concerned with their employer's sensitivities. All reviews that enter into Scott's and my deliberations will be discussed in the directorate, private ones without attribution. Scott and Allison From francis@cactus.slab.ntt.jp Wed Apr 27 16:02:08 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id DAA27858 for ; Wed, 27 Apr 1994 03:02:22 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Wed, 27 Apr 1994 16:02:09 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id QAA24902; Wed, 27 Apr 1994 16:02:09 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA27325; Wed, 27 Apr 94 16:02:08 JST Date: Wed, 27 Apr 94 16:02:08 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404270702.AA27325@cactus.slab.ntt.jp> To: brian@dxcoms.cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: CYA requirement Status: O > > Good question Greg. If I had the answer I would give it. > Anybody else? Shall we ask Lyman? > > Brian > I've been wanting the NSAP allocation info for another reason. I plan to ask Houldsworth, but asking Lyman is also a good idea. I'll ask both, and post the results to the list. PF From scoya@CNRI.Reston.VA.US Wed Apr 27 11:10:05 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA00348 for ; Wed, 27 Apr 1994 11:10:49 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06356; 27 Apr 94 11:10 EDT To: ipng@cmf.nrl.navy.mil Subject: Reading List Date: Wed, 27 Apr 94 11:10:05 -0400 From: Steve Coya Message-ID: <9404271110.aa06356@IETF.CNRI.Reston.VA.US> Status: O Here's what I have... SIPP S. Deering, "Simple Internet Protocol Plus (SIPP) Specification", Internet Draft, draft-ietf-sipp-spec-00.txt, February, 1994. S. Deering, et al, "Simple Internet Protocol Plus (SIPP): Routing and Addressing", Internet Draft, draft-ietf-sip- routing-addr-01.txt, February, 1994. P. Francis, "Simple Internet Protocol Plus (SIPP): Unicast Hierarchical Address Assignment", Internet Draft, , January 1994. R. Gilligan, et al, " IPAE: The SIPP Interoperability and Transition Mechanism", Internet Draft, draft-ietf-sipp-ipae- transition-01.txt, March 1994. R. Govindan, S. Deering, "ICMP and IGMP for the Simple Internet Protocol Plus (SIPP)", draft-ietf-sipp-icmp-igmp-00.txt, Internet Draft, March 1994 S. Thomson, C. Huitema, "DNS Extensions to support Simple Internet Protocol Plus (SIPP), Internet Draft, draft-ietf-sipp- dns-01.txt, March 1994. P. Francis, "OSPF for SIPP", Internet Draft, draft-ietf-sip- ospf-00.txt, February 1994. R. Atkinson, "SIPP Security Architecture", Internet Draft, draft-ietf-sipp-sa-01.txt, January, 1994. R. Atkinson, "SIPP Authentication Header", Internet Draft, draft-ietf-sipp-ap-01.txt, January, 1994. R. Atkinson, "SIPP Encapsulating Security Payload (ESP)", Internet Draft, draft-ietf-sip-esp-00.txt, January, 1994. W. Simpson, "SIPP Neighbor Discovery", Internet Draft, draft- ietf-sipp-discovery-04.txt, March 1994. W. Simpson, "SIPP Neighbor Discovery -- ICMP Message Formats", Internet Draft, draft-ietf-sipp-discovery-formats-00.txt March 1994. S. Thomson, "Simple Internet Protocol Plus (SIPP): Automatic Host Address Assignment", Internet Draft, draft-ietf-sipp-auto- addr-00.txt, March 1994. G. Malkin, C. Huitema, "SIP-RIP", Internet Draft, draft-ietf- sip-rip-00.txt, March 1993. S. Hares, "IDRP for SIP", Internet Draft, draft-ietf-ipidrp- sip-01.txt, November 1993. R. Hinden, "Simple Internet Protocol Plus White Paper," Internet-Draft, draft-ietf-sipp-whitepaper-00.txt, March 1994 CATNIP: R. Ullmann, "Common Architecture for Next-generation Internet Protocol", Internet Draft, draft-ietf-catnip-base-03.txt, March 1994 TUBA: [1] Callon, R., TCP/UDP over Bigger Addresses (TUBA), RFC 1347, May 1992. [2] Piscitello, D., Use of ISO CLNP in TUBA environments, RFC 1562, December 1993. [3] ISO/IEC 8348-1992. International Standards Organization- -Data Communications--OSI Network Layer Service and Addressing. [4] Colella, R., E. Gardner, and R. Callon, Guidelines for OSI NSAP Allocation in the Internet, RFC 1237, July 1991 (note obsolete by [37]). [5] ISO/IEC 8473. International Standards Organization -- Data Communications -- Protocol for Providing the Connectionless-mode Network Service, ISO/IEC 8473:1992, Edition 2. [6] Callon, R., "A proposal for adding flow support to CLNP", Internet-Draft [7] Marlow, D., "Host group extensions for CLNP Multicast", Internet-Draft [8] ISO/IEC 9542. International Standards Organization -- Telecommunications and Information Exchange between Systems -- End System to intermediate system routeing exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO/IEC 8473), ISO 9542:1988. [9] ISO/IEC 10589, Intermediate system to intermediate system routeing exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO/IEC 8473), ISO 10589:1992. [10] ISO/IEC 10747, Protocol for exchange of interdomain routeing information among intermediate systems to support forwarding of ISO/IEC 8473 PDUs, ISO /IEC 10747:1992. [11] Piscitello, D., Assignment of System Identifiers for TUBA/CLNP hosts, RFC 1526, November 1993. [12] Katz, D., Tunneling the OSI Network Layer over CLNP (EON), Internet-draft. [13] Hanks. S, T. Li, D. Farinacci, P. Traina, Generic Routing Encapsulation over IPv4 networks, Internet- draft, September 1993. [14] Hanks. S, T. Li, D. Farinacci, P. Traina, Generic Routing Encapsulation, Internet-Draft, September 1993. [15] Leiner, B., Rehkter, Y., The Multiprotocol Internet, RFC 1560, December 1993. [16] Callon, R., and Perlman, R., Integrated IS-IS, RFC 1195. [17] Callon, "how to extend IP", Internet-draft in preparation. [18] Piscitello, D., FTP Operation Over Big Address Records (FOOBAR), RFC 1545, October 1993. [19] Manning, Colella, DNS RRs for NSAPAs, RFC in preparation [20] Rose, M., SNMP over OSI. RFC 1418, 1993 March. [21] Rose, M., SNMP over OSI. RFC 1283 1991 December [22] Katz, "Suggested System ID Option for the ES-IS Protocol", Internet-Draft in preparation [23] Katz, "Dynamic Assignment of OSI NSAP Addresses in the Internet", Internet-Draft in preparation. [24] Piscitello, D.,"MTU discovery for CLNP-based hosts", Internet-Draft in preparation. [25] Whyman, "ICAO CLNP Header Compression algorithm",available by anonymous FTP, in compressed postscript form, from comm.cenaath.cena.dgac.fr as /atn/icao-clnp-compress-ps.zand [26] Satz, G., Request for Comments 1238, Connectionless- mode Network Service Management Information Base - for use with Connectionless Network Protocol (ISO 8473) and End system to Intermediate System Protocol (ISO 9452)", Internet Architecture Board, June 1991. [27] Katz, D., P. Ford, "TUBA: Replacing IP with CLNP", March 24 1993. [28] Wittbrodt, C., and S. Hares, Essential Tools for the OSI Internet, Request for Comments 1574, March 1994. [29] Wittbrodt, C., and S. Hares, CLNP Ping (Echo), Request for Comments 1575, March 1994. [30] Bound, J., IPng Host Implementation Analysis, IPng white paper, February 1994. [31] SDNS, "Security Protocol 3 (SP3)," Specification SDN.301/Revision 1.5, May 1989. [32] ISO/IEC, "Information technology -- Open Systems Interconnection -- Network Layer Security Protocol," International Standard 11577, November 1993. [33] Glenn, K. Robert, "Integrated Network Layer Security Protocol," Internet Draft (draft-glenn-layer-security- 00.txt), September 1993 (work in progress). [34] Hanks, S., Li, T., Farinacci, D., Traina, P., Generic Routing Encapsulation (GRE), draft-hanks-gre-00.txt, work in progress, September, 1993. [35] Estrin, D., Zappala, D., Li, T., Rekhter, Y., Source Demand Routing: Packet Format and Forwarding Specification (Version 1), draft-estrin-sdrp-03.txt, work in progress, September, 1993. [36] Cellular Digital Packet Data System Specification, Release 1.0, July 19, 1993. [37] Colella, R., Callon, R., Gardner, E., Rekhter, Y., Guidelines for OSI NSAP Allocation in the Internet, draft-ietf-osinsap-allocation-00.txt, work in progress, December 25, 1993. [38] Hares, S., Scudder, J., IDRP for IP, draft-hares-idrp-05.txt, work in progress, September, 1993. [39] Kleinrock, L., Farouk, K., Hierarchical Routing for Large Networks, Computer Networks 1, 1977. [40] Fuller, V., Li, T., Yu, J., Varadhan, K., Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy, Request for Comments 1519, September, 1993. From brian@dxcoms.cern.ch Wed Apr 27 17:18:07 1994 Return-Path: brian@dxcoms.cern.ch 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 LAA00409; Wed, 27 Apr 1994 11:18:41 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20666; Wed, 27 Apr 1994 17:18:08 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20024; Wed, 27 Apr 1994 17:18:07 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404271518.AA20024@dxcoms.cern.ch> Subject: Re: Review of the Proposals To: mankin@cmf.nrl.navy.mil (Allison J Mankin) Date: Wed, 27 Apr 1994 17:18:07 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <199404271314.JAA20771@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Apr 27, 94 09:14:21 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: 158 Status: O Hi, Could you clarify whether the reviews will be published as I-Ds? If so can you also provide the boilerplate? I plan to use I-D format anyway. Brian From mankin@cmf.nrl.navy.mil Wed Apr 27 22:54:10 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id WAA04904 for ; Wed, 27 Apr 1994 22:54:16 -0400 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id WAA22525; Wed, 27 Apr 1994 22:54:10 -0400 Date: Wed, 27 Apr 1994 22:54:10 -0400 From: Allison J Mankin Message-Id: <199404280254.WAA22525@radegond.cmf.nrl.navy.mil> To: dino@cisco.com Subject: re: Review of the Proposals Cc: ipng@cmf.nrl.navy.mil Status: O Interop. Yes, we do realize. We hope you will do as much as you can, if you recall, the actual desire was to have all the reviews under peoples' belts by the time of the retreat. Allison From bound@zk3.dec.com Wed Apr 27 23:57:34 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA05203; Thu, 28 Apr 1994 00:01:23 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA06286; Wed, 27 Apr 94 20:57:45 -0700 Received: by xirtlu.zk3.dec.com; id AA29352; Wed, 27 Apr 1994 23:57:41 -0400 Message-Id: <9404280357.AA29352@xirtlu.zk3.dec.com> To: mankin@cmf.nrl.navy.mil, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Cc: Dino Farinacci Subject: Re: Review of the Proposals In-Reply-To: Your message of "Wed, 27 Apr 94 18:30:02 PDT." <199404280130.SAA14014@feta.cisco.com> Date: Wed, 27 Apr 94 23:57:34 -0400 X-Mts: smtp Status: O Allison, May I suggest the following. I have already read all of these and think May 8th is intense too. Make deadline May 15th. This gives us two weeks and also gives us time to share ideas with others where we work. These should be publicly available but not IDs or RFCs etc. I think they should be messages to you and Scott based on what we have learned as Directorate memo's. I personally have more leverage in my response if its just mail that is archived and not IDs. If it had to be an ID then I would want to do the same logic check in my company that I did for my host paper and that will take all of May for many of us vendors. A mail message is much more acceptable so to speak. We should not have to respond in detail to all specs. I would be pretty amazed if anyone had expertise in all areas to respond in any technical depth. Here is a format I am going to use and I am not suggesting others use this format because I believe the format should be as the Directorate reviewer is most comfortable (and I might change these). [really off the top of my head] 1. Network Layer Header and Protocol Review. 2. IPng Reqs not met or not met strongly. 3. Transition Review. 4. IPng Carrots Available. 5. Address Hiearchy potential. 6. Routing Hiearchy potential. 7. Security Issues. 8. Emerging Technology Benefits. 9. Technical Feasibility. 10. Technical Hate Points. Just an idea ??? /jim From francis@cactus.slab.ntt.jp Thu Apr 28 08:40:18 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id TAA04134; Wed, 27 Apr 1994 19:40:55 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Thu, 28 Apr 1994 08:40:20 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA21008; Thu, 28 Apr 1994 08:40:19 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA02271; Thu, 28 Apr 94 08:40:18 JST Date: Thu, 28 Apr 94 08:40:18 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404272340.AA02271@cactus.slab.ntt.jp> To: ipng@cmf.nrl.navy.mil, mankin@cmf.nrl.navy.mil Subject: Re: Review of the Proposals Status: O Ok. As Brian asked, is there a complete list somewhere of the specs? I just want to make sure I'm not missing something..... PF From francis@cactus.slab.ntt.jp Thu Apr 28 08:41:09 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id TAA04138; Wed, 27 Apr 1994 19:41:13 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Thu, 28 Apr 1994 08:41:10 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id IAA21012; Thu, 28 Apr 1994 08:41:09 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA02283; Thu, 28 Apr 94 08:41:09 JST Date: Thu, 28 Apr 94 08:41:09 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9404272341.AA02283@cactus.slab.ntt.jp> To: ipng@cmf.nrl.navy.mil, mankin@cmf.nrl.navy.mil Subject: Re: Review of the Proposals Status: O never mind.....I just saw Coya's list..... Later, PF From Greg_Minshall@Novell.COM Thu Apr 28 08:44:00 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.4.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA08784 for ; Thu, 28 Apr 1994 11:45:53 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA04779; Thu, 28 Apr 94 09:50:31 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB14056; Thu, 28 Apr 94 08:44:00 PDT Date: Thu, 28 Apr 94 08:44:00 PDT Message-Id: <9404281544.AB14056@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Steve Coya , ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: Re: Reading List Status: O Steve C., Thanks for the list. Could Scott or Allison highlight which documents, in particular, they would like to have reviewed? And, procedural question, i wasn't sure from the teleconference (in late, out early) if *each of us* is to review *all the documents*. Greg From craig@aland.bbn.com Thu Apr 28 17:42:48 1994 Return-Path: craig@aland.bbn.com Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id UAA12635 for ; Thu, 28 Apr 1994 20:45:17 -0400 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA17955 for ipng@cmf.nrl.navy.mil; Thu, 28 Apr 94 20:45:06 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id RAA01803; Thu, 28 Apr 1994 17:42:50 -0700 Message-Id: <199404290042.RAA01803@aland.bbn.com> To: ipng@cmf.nrl.navy.mil Subject: IPng requirements & migration from other protocols Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 28 Apr 94 17:42:48 -0700 Sender: craig@aland.bbn.com Status: O Hi folks: I'm just coming up from 3 weeks of intense work on non-IPng activities and trying to get a sense of what issues are lingering as Frank and I do a final pass over the requirements document. From a quick scan of IPng mail I think the one issue remaining is seeing if there's a requirement that comes from folks who'd like to migrate from their current solution (IPX, CLNP, AppleTalk, etc) to IPng. I've heard suggestions of the form that we have a requirement that a IPng not inhibit migration from other protocols, but that particular wording seems much too broad to me. Taken to an extreme, it says IPng must be all things for all protocols and that's a kitchen-sink type approach to architecture we're trying to avoid. On another axis, I'm quite willing to see IPng do something (can't imagine what but assume something dire) that makes protocol X to IPng convergence extremely hard, if in return, IPng (for instance) offers much better address scaling (or performance) as a result. What this suggests to me is that if we're going to have a migration-related requirement (or set of requirements) we need much tighter wording that reflects what we believe is the critical functionality that makes migration from other protocols easy. But I'm not in a position to say what that functionality might be (flexible addressing?). Any thoughts on how we work through this problem? Thanks! Craig From brian@dxcoms.cern.ch Fri Apr 29 08:12:40 1994 Return-Path: brian@dxcoms.cern.ch 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 CAA13576 for ; Fri, 29 Apr 1994 02:13:15 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16217; Fri, 29 Apr 1994 08:12:42 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28845; Fri, 29 Apr 1994 08:12:40 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404290612.AA28845@dxcoms.cern.ch> Subject: Re: IPng requirements & migration from other protocols To: ipng@cmf.nrl.navy.mil Date: Fri, 29 Apr 1994 08:12:40 +0200 (MET DST) In-Reply-To: <199404290042.RAA01803@aland.bbn.com> from "Craig Partridge" at Apr 28, 94 05:42:48 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: 725 Status: O Craig, ... > From a quick scan of IPng mail I think the one issue remaining is seeing > if there's a requirement that comes from folks who'd like to migrate from > their current solution (IPX, CLNP, AppleTalk, etc) to IPng. I've been thinking about this a bit. It seems to me to be too big a mouthful. I propose splitting it into two: - a specific solution for support of NSAPAs as an alternative address format. This only affects SIPP and it is being worked on. - a generalised encapsulation mechanism (GEM) for foo-over-IPng. This is much more realistic than requiring a generalised migration mechanism; I can't begin to imagine how to do that. And GEM is not an IPng protocol requirement anyway. Brian From J.Crowcroft@cs.ucl.ac.uk Fri Apr 29 08:54:59 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id DAA13762 for ; Fri, 29 Apr 1994 03:55:29 -0400 Message-Id: <199404290755.DAA13762@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 29 Apr 1994 08:55:03 +0100 To: Craig Partridge cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng requirements & migration from other protocols In-reply-to: Your message of "Thu, 28 Apr 94 17:42:48 PDT." <199404290042.RAA01803@aland.bbn.com> Date: Fri, 29 Apr 94 08:54:59 +0100 From: Jon Crowcroft Status: O >Any thoughts on how we work through this problem? Craig well, the resistence from large coporate and government net sites that run (say) clnp implies that the problem is the logistics of s/w upgrade. however much or little change you have, their problem is largely one of change at all. in the light of that, i don't see an problem with how different IPng is from IPv4 or CLNP. it has to be dfifferent. any difference is either easy (for a site like mine, we can reconfig 100-200 thousand hosts a year), or near to impossible (for a site like the UK DSS who have 500,000 CLNP based ICL systems that are obsolete, but not affordably discarded, and certainly not likely to get an upgrade) so the answer for convergence is interworking tools rfc1006 and tuba provide 2 interworking tools. application layer gateways provide the rest...shared routing infrastructure is also handy...but none of this is news i.e. i am saying: at the network layer, unless clnp _is_ the ipng, convergence is not worth bothering with. jon From brian@dxcoms.cern.ch Fri Apr 29 10:13:24 1994 Return-Path: brian@dxcoms.cern.ch 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 EAA13806 for ; Fri, 29 Apr 1994 04:13:58 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11525; Fri, 29 Apr 1994 10:13:26 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA02316; Fri, 29 Apr 1994 10:13:25 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404290813.AA02316@dxcoms.cern.ch> Subject: Re: IPng requirements & migration from other protocols To: ipng@cmf.nrl.navy.mil Date: Fri, 29 Apr 1994 10:13:24 +0200 (MET DST) In-Reply-To: <199404290755.DAA13762@picard.cmf.nrl.navy.mil> from "Jon Crowcroft" at Apr 29, 94 08:54:59 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 273 Status: O Jon, ... > i.e. i am saying: at the network layer, unless clnp _is_ the ipng, > convergence is not worth bothering with. > I agree except for CYA (in its original meaning) which is a political constraint. That's how I reached the two points in my previous mail. Brian From smb@research.att.com Fri Apr 29 07:08:05 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA14127 for ; Fri, 29 Apr 1994 07:09:09 -0400 From: smb@research.att.com Message-Id: <199404291109.HAA14127@picard.cmf.nrl.navy.mil> Date: Fri, 29 Apr 94 07:08:05 EDT To: ipng@cmf.nrl.navy.mil Subject: should we tweak TCP? Status: O We're going to have to make some minor changes around the fringes of TCP -- to accomodate the different pseudo-header checksum, if nothing else. Should we go a bit deeper? Specifically, should we (a) increase the size of sequence numbers to 64 bits, and (b) increase the size of the option field? From J.Crowcroft@cs.ucl.ac.uk Fri Apr 29 12:31:43 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id HAA14187 for ; Fri, 29 Apr 1994 07:32:39 -0400 Message-Id: <199404291132.HAA14187@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 29 Apr 1994 12:31:47 +0100 To: smb@research.att.com cc: ipng@cmf.nrl.navy.mil Subject: Re: should we tweak TCP? In-reply-to: Your message of "Fri, 29 Apr 94 07:08:05 EDT." <199404291109.HAA14127@picard.cmf.nrl.navy.mil> Date: Fri, 29 Apr 94 12:31:43 +0100 From: Jon Crowcroft Status: O >We're going to have to make some minor changes around the fringes of >TCP -- to accomodate the different pseudo-header checksum, if nothing >else. Should we go a bit deeper? Specifically, should we (a) increase >the size of sequence numbers to 64 bits, and (b) increase the size >of the option field? no,no,no,no,no please keep the scpe of ipng to layer 3 and limit the effects on any other layer... the tcp tweakery in end2end has been more than enough, and is still looking at the correct solution to the above problems. The folks there can produce code that will be re-usable over an IPng easily... if you open the door to changes elsewhere, we'll get into agruing about the use of hybrid analog/digital systems and video on demand:-) jon From brian@dxcoms.cern.ch Fri Apr 29 14:12:09 1994 Return-Path: brian@dxcoms.cern.ch 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 IAA14360 for ; Fri, 29 Apr 1994 08:12:45 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06287; Fri, 29 Apr 1994 14:12:12 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09047; Fri, 29 Apr 1994 14:12:09 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9404291212.AA09047@dxcoms.cern.ch> Subject: Re: should we tweak TCP? To: ipng@cmf.nrl.navy.mil Date: Fri, 29 Apr 1994 14:12:09 +0200 (MET DST) In-Reply-To: <199404291132.HAA14187@picard.cmf.nrl.navy.mil> from "Jon Crowcroft" at Apr 29, 94 12:31:43 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: 1225 Status: O I think there is a whole class of tweaking that will be made necessary by the IPng choice. This is just an example. I think we should resolve to forget about all these things until after the recommendation is made and accepted. Then, the IESG will have to figure out which working groups need to tweak what. Remember, choosing IPng is the quick and easy part. Brian >--------- Text sent by Jon Crowcroft follows: > > > > >We're going to have to make some minor changes around the fringes of > >TCP -- to accomodate the different pseudo-header checksum, if nothing > >else. Should we go a bit deeper? Specifically, should we (a) increase > >the size of sequence numbers to 64 bits, and (b) increase the size > >of the option field? > > no,no,no,no,no > > please keep the scpe of ipng to layer 3 and limit the effects on any > other layer... > > the tcp tweakery in end2end has been more than enough, and is still > looking at the correct solution to the above problems. The folks there > can produce code that will be re-usable over an IPng easily... > > if you open the door to changes elsewhere, we'll get into agruing > about the use of hybrid analog/digital systems and video on demand:-) > > jon > From kasten@mailserv-D.ftp.com Fri Apr 29 08:36:18 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA14463 for ; Fri, 29 Apr 1994 08:37:30 -0400 Received: from ftp.com by ftp.com ; Fri, 29 Apr 1994 08:37:27 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 29 Apr 1994 08:37:27 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA01882; Fri, 29 Apr 94 08:36:18 EDT Date: Fri, 29 Apr 94 08:36:18 EDT Message-Id: <9404291236.AA01882@mailserv-D.ftp.com> To: smb@research.att.com Subject: Re: should we tweak TCP? From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 1585 Status: O > We're going to have to make some minor changes around the fringes of > TCP -- to accomodate the different pseudo-header checksum, if nothing > else. Should we go a bit deeper? Specifically, should we (a) increase > the size of sequence numbers to 64 bits, and (b) increase the size > of the option field? would be nice. i assume that by 'increase the size of the option field' you really are saying that the max header length will be bigger? i think that we have enough to do right now. i don't think that ipng will be globally fielded by the end of 1994. i do think that, perhaps, after we finish the ipng work, we can (if we want to, and by 'we' i mean the internet community, not just the ipng crowd) start developing updates for tcp. we probably can have these ready before ipng starts being fielded in large numbers. which would still allow the community to field them both. note that there are also issues relating to transition and interoperating with 'old' tcp's one other possible course of action would be for the directorati to write a small paper and submit it as an rfc that says that in the course of figuring out what the future internet will be, we have identified these particular 'lacks' in the current tcp and that the iab and iesg should start an effort to identify problems in tcp and go off and develop solutions and have those solutions ready in time for fielding along with ipng... the other possible course of action would be to forget about it. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From bound@zk3.dec.com Fri Apr 29 09:32:57 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA14782 for ; Fri, 29 Apr 1994 09:35:48 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA15170; Fri, 29 Apr 94 06:33:12 -0700 Received: by xirtlu.zk3.dec.com; id AA04465; Fri, 29 Apr 1994 09:33:03 -0400 Message-Id: <9404291333.AA04465@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IPng Reviews Date: Fri, 29 Apr 94 09:32:57 -0400 X-Mts: smtp Status: O Allison, May I suggest that we send our reviews to you and Scott and then you buffer them until you get them all and then send the reviews out 1 by 1. This way the first ones out do not produce a feeding frenzy of responses which could be counter productive to this process. ????? I assume May 8th is still the due date? /jim From sob@hsdndev.harvard.edu Fri Apr 29 09:46:47 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA14801 for ; Fri, 29 Apr 1994 09:47:10 -0400 Date: Fri, 29 Apr 94 09:46:47 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9404291346.AA26035@hsdndev.harvard.edu> To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: IPng Reviews Status: O > May I suggest that we send our reviews to you and Scott Jim, This is a good idea. It should cut down on the flame & brimstone untill we have the pile ready to ignite :-). lets follow Jim's suggestion. Scott From ericf@atc.boeing.com Fri Apr 29 09:29:21 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA16969 for ; Fri, 29 Apr 1994 12:28:31 -0400 Received: by atc.boeing.com (5.57) id AA13021; Fri, 29 Apr 94 09:29:21 -0700 Date: Fri, 29 Apr 94 09:29:21 -0700 From: Eric Fleischman Message-Id: <9404291629.AA13021@atc.boeing.com> To: J.Crowcroft@cs.ucl.ac.uk, craig@aland.bbn.com Subject: Re: IPng requirements & migration from other protocols Cc: ipng@cmf.nrl.navy.mil Status: O I concur with Jon's observations below: the problem is change (change costs money and resources) and the best solution is to make change easier. [Of course, there has to be a reason for change from the end-user's perspective or else we are wasting our breath.] Other aspects to the problem, of course, are political and religious. "Political" in that if international treaties are involved with the technology then the new technology had better be permitted in that region for that purpose as well. "Religious" in that bigots of all stripes exist and they tend to make technical things become emotional. We as a community do not like to deal with the latter two types of problems but they are undoubtedly part of the total problem set. Both of these latter problems will (optimistically) be largely resolved once TCP/IP is recognized to be a bona fide international standard. That is one reason why I value the liaison activities between the ISOC and the ISO and ITU. Another important factor will be to finally have a viable IPng selected so that the scaling problem can be addressed and the detracters can no longer claim that TCP/IP is going full speed ahead into a brick wall. This is a very serious problem which certainly must concern us with the imminent approach of toasternet. Sincerely yours, --Eric Fleischman >From: Jon Crowcroft > >Any thoughts on how we work through this problem? > > Craig > >well, the resistence from large coporate and government net sites that >run (say) clnp implies that the problem is the logistics of s/w >upgrade. however much or little change you have, their problem is >largely one of change at all. > >in the light of that, i don't see an problem with how different IPng >is from IPv4 or CLNP. it has to be dfifferent. any difference is >either easy (for a site like mine, we can reconfig 100-200 thousand >hosts a year), or near to impossible (for a site like the UK DSS who >have 500,000 CLNP based ICL systems that are obsolete, but not >affordably discarded, and certainly not likely to get an upgrade) > >so the answer for convergence is interworking tools > >rfc1006 and tuba provide 2 interworking tools. application layer >gateways provide the rest...shared routing infrastructure is also >handy...but none of this is news > >i.e. i am saying: at the network layer, unless clnp _is_ the ipng, >convergence is not worth bothering with. > > jon From ericf@atc.boeing.com Fri Apr 29 12:50:20 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA18356 for ; Fri, 29 Apr 1994 15:48:26 -0400 Received: by atc.boeing.com (5.57) id AA12236; Fri, 29 Apr 94 12:50:20 -0700 Date: Fri, 29 Apr 94 12:50:20 -0700 From: Eric Fleischman Message-Id: <9404291950.AA12236@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: Second IPng Requirments Document Status: O IPng Business Requirements Eric Fleischman April 29, 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 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 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 Greg_Minshall@Novell.COM Fri Apr 29 15:27:57 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA19030 for ; Fri, 29 Apr 1994 18:29:50 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA03235; Fri, 29 Apr 94 16:34:33 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA18026; Fri, 29 Apr 94 15:27:58 PDT Date: Fri, 29 Apr 94 15:27:57 PDT Message-Id: <9404292227.AA18026@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), ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: Re: IPng requirements & migration from other protocols Status: O Brian, >- a generalised encapsulation mechanism (GEM) for foo-over-IPng. > This is much more realistic than requiring a generalised migration > mechanism; I can't begin to imagine how to do that. And GEM > is not an IPng protocol requirement anyway. A bare-bones "encapsulation mechanism" doesn't offer anything that i can see for convergence of any X to IPng... Greg From ericf@atc.boeing.com Fri Apr 29 15:57:30 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id SAA19083 for ; Fri, 29 Apr 1994 18:55:53 -0400 Received: by atc.boeing.com (5.57) id AA10544; Fri, 29 Apr 94 15:57:30 -0700 Date: Fri, 29 Apr 94 15:57:30 -0700 From: Eric Fleischman Message-Id: <9404292257.AA10544@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: CATNIP Status: O Dear Group, The following claim for CATNIP is contained within the draft-ietf-catnip-base-03.txt document. I find this claim to be immensely appealing. Rather, the claim is so good that I worry that it couldn't possibly be true since this is my "dream scenario". Hence this message to you all: Does anybody know the extent to which CATNIP achieves this claim? [I believe that CATNIP hasn't yet been implemented. Please let me know if this is false and if aspects of this claim has been demonstrated. If it hasn't, does anybody know of any reason why -- or why not -- this claim may not be realizable based on the current CATNIP spec? Are there any known technical problems with CATNIP? Why haven't we been more forthcoming in our discussions of CATNIP such as we were with SIPP and TUBA? Thus, will one of you technical whiz-kids please address CATNIP for my benefit?] Sincerely yours, --Eric Fleischman >CATNIP is designed to be incrementally deployable in the strong sense: >you can plop a CATNIP system down in place of any existing network >component and continue to operate normally with no reconfiguration. The >vendors do all of the work. For example, the DNS records are to be >generated automatically by the DNS software from the existing >configuration, not by manual administration. > >There are also no external requirements, no "border routers", no >requirement that administrators apply specific restrictions to their >network designs, define special tables, or add things to the DNS. >Eventually with full understanding of the combined system the end users >and administrators will want to operate differently, but in no case, not >even in small ways, will they be forced. Networks and end user >organizations operate under sufficient constraints on deployment of >systems anyway; they do not need a new network architecture adding to >the difficulty. From bound@zk3.dec.com Sun May 1 11:02:07 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA24382 for ; Sun, 1 May 1994 11:05:15 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA29899; Sun, 1 May 94 08:02:21 -0700 Received: by xirtlu.zk3.dec.com; id AA10072; Sun, 1 May 1994 11:02:13 -0400 Message-Id: <9405011502.AA10072@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: NEW SIPP BSD API Spec Available fyi .............. Date: Sun, 01 May 94 11:02:07 -0400 X-Mts: smtp Status: O - --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Simple Internet Protocol Plus Working Group of the IETF. Title : SIPP Program Interfaces for BSD Systems Author(s) : R. Gilligan, R. Govindan, S. Thomson, J. Bound Filename : draft-ietf-sipp-bsd-api-02.txt Pages : 12 Date : 04/28/1994 In order to implement the Simple Internet Protocol (SIPP) in an operating system based on 4.x BSD, changes must be made to some of the application program interfaces (APIs). TCP/IP applications written for BSD-based operating systems have in the past enjoyed a high degree of portability because most of the systems derived from BSD provide the same API, known informally as "the socket interface". We would like the same portability to be possible with SIPP applications. This memo presents a set of changes to the BSD socket API to support SIPP. The changes include a new data structure to carry SIPP address sequences, new name to address translation library functions, new address conversion functions, and some new setsockopt() options. The changes are designed to be minimal and to provide source and binary compatibility for existing applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-sipp-bsd-api-02.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-sipp-bsd-api-02.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940428102702.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-sipp-bsd-api-02.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipp-bsd-api-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940428102702.I-D@CNRI.Reston.VA.US> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From lkeiper@IETF.CNRI.Reston.VA.US Mon May 2 08:55:39 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA27567 for ; Mon, 2 May 1994 08:56:02 -0400 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa03218; 2 May 94 8:55 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 May 1994 08:55:39 +0100 To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference Cc: lkeiper@cnri.reston.va.us Message-ID: <9405020855.aa03218@IETF.CNRI.Reston.VA.US> Status: O > ANNOUNCEMENT: > > >The names marked with an asterisk are those who have confirmed >participation for the IPng teleconference sheduled for Monday, May 2, 1994 >11:30 - 1:30pm EST. Please send your RSVP as soon as possible. Thank You!! > >Please contact me with any changes @lkeiper.cnri.reston.va.us. >My sincere apologies for the delayed announcement. > > J. Allard 206-936-9031 > Scott Bradner 617-495-3864 > Steve Bellovin 908-582-5886 > Jim Bound 603-465-3130 > Ross Callon 508-436-3936 > Brian Carpenter +41 227 674 967 > Dave Clark 617-253-6003 > *Steve Coya 703-620-8990* > Jon Crowcroft +44 713 807 296 > John Curran 617-873-4398 > Steve Deering 415-812-4839 > Dino Farinacci 408-226-6870 > Eric Fleischman 206-957-5334 > Paul Frances +81 339 280 408 > Frank Kastenholz 508-685-4000 > Mark Knopper 313-741-5445 > Allison Mankin 202-404-7030 > Greg Minshall 510-975-4507 > Craig Partridge 415-326-4541 > Rob Ullmann 617-693-1315 > Lixia Zhang 415-812-4415 > > > > > >If you need to be added to the call in progress, Please call 1-800-232-1234 >or for international particpants, 516-424-3151. The call can be referenced >by the confirmation number ER75869 in the orginators name, Steve Coya. > >Many thanks, > >Lois > > Lois J. Keiper IETF Secretariat From lkeiper@IETF.CNRI.Reston.VA.US Mon May 2 09:26:08 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA27797 for ; Mon, 2 May 1994 09:26:51 -0400 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa04139; 2 May 94 9:26 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 May 1994 09:26:08 +0100 To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: OOPs! Cc: lkeiper@IETF.CNRI.Reston.VA.US Message-ID: <9405020926.aa04139@IETF.CNRI.Reston.VA.US> Status: O Ipng participants, My sincere apologies for the announcement this morning. The next IPng telconference is Monday, May 9, 1994. Thank you. Lois From francis@cactus.slab.ntt.jp Mon May 2 11:51:03 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp (mail.ntt.jp [192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id WAA25907 for ; Sun, 1 May 1994 22:51:13 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Mon, 2 May 1994 11:51:04 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id LAA22747; Mon, 2 May 1994 11:51:04 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA04104; Mon, 2 May 94 11:51:03 JST Date: Mon, 2 May 94 11:51:03 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405020251.AA04104@cactus.slab.ntt.jp> To: ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil Subject: Re: CATNIP Status: O > > The following claim for CATNIP is contained within the > draft-ietf-catnip-base-03.txt document. I find this claim to be immensely > appealing. Rather, the claim is so good that I worry that it couldn't > possibly be true since this is my "dream scenario". Hence this message to > you all: I think CATNIP probably can acheive the claim that it sets forth. However, please understand the limitations that you operate under as a result. What CATNIP does is grandfather existing address spaces (IP and IPX) into the NSAP address space. It does so in such a way that there is straight- forward bi-directional translation between the existing address space and the CATNIP encoding of the same address space. For the sake of discussion, define C-xxx to be protocol xxx encoded in a CATNIP header. To translate from say C-IP to IP, the CATNIP box simply translates the IP address into its C-IP form and sends the packet. However, a CATNIP box *cannot* translate between IP and C-NSAP (where C-NSAP is an NSAP address in CATNIP form). This is because the NSAP address cannot (easily) be expressed in only 32 bits, and therefore the IP host cannot "address" the C-NSAP host. So, an IP host cannot talk to a C-IPX or C-NSAP host. An IPX host cannot talk to a C-NSAP host. It also cannot talk to a C-IP host unless you partition off part of the IPX address space to include the IP address space, which has not been done with CATNIP (based on my cursory reading). Indeed, after IP addresses expire, C-IP hosts won't even be able to talk to C-IP hosts except for intra-domain (i.e., it is no different from the case of IP host to IP host). *If* you want a CATNIP host to talk to an IPv4 host, then you must assign the CATNIP host an IPv4 address. In the CATNIP host, the IPv4 address gets encoded as a CATNIP address (its C-IP form), but it is for all practical purposes an IPv4 address, with the *same limitations* of scaling and address depletion as existing IPv4. CATNIP transition is essentially dual-stack (I guess by which I mean no translation). If you want a CATNIP host to talk to an existing (non-catnip) host, then it must have an address from the existing host's address space, routers must know how to route on that address, and so on. In my mind, you may as well just be running the native protocol (indeed, it is simpler....doesn't mix stacks). Note that, as far as protocol translatability is concerned, you can do the same thing that CATNIP does with CLNP by assigning the AFI's that CATNIP suggests, and building translating routers.... The primary difference between CATNIP and CLNP, then, is that CATNIP has the flow field (the Forward Cache Identifier), and the corresponding compressed packet form (without addresses). (It also has a "word" alligned encoding.) So, in my mind, the reason that one would choose CATNIP as IPng is because they believed that the FCI approach is a big win. There is no transition magic in CATNIP..... PF From kasten@mailserv-D.ftp.com Mon May 2 09:08:38 1994 Return-Path: kasten@mailserv-D.ftp.com Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA27638 for ; Mon, 2 May 1994 09:09:52 -0400 Received: from ftp.com by ftp.com ; Mon, 2 May 1994 09:09:50 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 2 May 1994 09:09:50 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA18378; Mon, 2 May 94 09:08:38 EDT Date: Mon, 2 May 94 09:08:38 EDT Message-Id: <9405021308.AA18378@mailserv-D.ftp.com> To: lkeiper@IETF.CNRI.Reston.VA.US Subject: Re: IPng Teleconference From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@cmf.nrl.navy.mil Content-Length: 440 Status: O um, er, ah, my notes say that the con is next week? i can join, but can we get reconfirmation from allison or scott? > >The names marked with an asterisk are those who have confirmed > >participation for the IPng teleconference sheduled for Monday, May 2, 1994 > >11:30 - 1:30pm EST. Please send your RSVP as soon as possible. Thank You!! -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From mankin@cmf.nrl.navy.mil Mon May 2 11:06:26 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id LAA28887 for ; Mon, 2 May 1994 11:06:28 -0400 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id LAA28809; Mon, 2 May 1994 11:06:26 -0400 Date: Mon, 2 May 1994 11:06:26 -0400 From: Allison J Mankin Message-Id: <199405021506.LAA28809@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil, lkeiper@cnri.reston.va.us Subject: IPng teleconference Status: O Lois and Directorate, Our next meeting is next week (May 9). Thanks, Allison From Greg_Minshall@Novell.COM Mon May 2 11:42:33 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id OAA01063 for ; Mon, 2 May 1994 14:44:27 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA19563; Mon, 2 May 94 12:49:18 MDT Received: from [130.57.64.145] (spurcell.wc.novell.com) by WC.Novell.COM (4.1/SMI-4.1) id AA24552; Mon, 2 May 94 11:42:35 PDT Date: Mon, 2 May 94 11:42:33 PDT Message-Id: <9405021842.AA24552@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: CATNIP as a "convergence point", not a "proposal" Status: O Group, The subject line says it all. I would propose that we "drop" CATNIP as a proposal (though, we may want to understand key points of CATNIP as well as consider it as possibly helping to define a convergence point/space). Greg From bound@zk3.dec.com Tue May 3 00:00:24 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA04422 for ; Tue, 3 May 1994 00:05:17 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA07447; Mon, 2 May 94 21:00:40 -0700 Received: by xirtlu.zk3.dec.com; id AA29982; Tue, 3 May 1994 00:00:30 -0400 Message-Id: <9405030400.AA29982@xirtlu.zk3.dec.com> To: Greg Minshall Cc: ipng@cmf.nrl.navy.mil Subject: Re: CATNIP as a "convergence point", not a "proposal" In-Reply-To: Your message of "Mon, 02 May 94 11:42:33 PDT." <9405021842.AA24552@WC.Novell.COM> Date: Tue, 03 May 94 00:00:24 -0400 X-Mts: smtp Status: O Greg, I agree with you. /jim From bound@zk3.dec.com Tue May 3 00:12:14 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA04458 for ; Tue, 3 May 1994 00:15:12 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA08233; Mon, 2 May 94 21:12:25 -0700 Received: by xirtlu.zk3.dec.com; id AA00150; Tue, 3 May 1994 00:12:20 -0400 Message-Id: <9405030412.AA00150@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: NSAPs Date: Tue, 03 May 94 00:12:14 -0400 X-Mts: smtp Status: O While preparing for my input I studied various NSAP thoughts and literature on the subject. Well as I stated on the last telechat I am on the side of the fence with Steve Deering on this subject, unless we can build an NSAP for IPng that is not defined exactly as today for ISO. I talked to Peter Ford last week (while working on another piece of work non-IPng) a little about NSAPs and felt Peter had a good handle on how it could be used as we want to define it for IPng. I think Peter, Ross Callon, and Rob Ullmann can figure this out, but I can't take the formats of ISO as gospel technically for routing or the way variable addresses would show up at the transport either in the 'Internet'. I do hear a lot folks like the way we did it with Phase V, not that this should be used for IPng, but that maybe there is some knowledge here to be gained. p.s. Yakov Rehkter seems to have a good handle on this too. /jim From bound@zk3.dec.com Tue May 3 01:01:04 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id BAA04656 for ; Tue, 3 May 1994 01:05:15 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA11644; Mon, 2 May 94 22:01:16 -0700 Received: by xirtlu.zk3.dec.com; id AA00675; Tue, 3 May 1994 01:01:11 -0400 Message-Id: <9405030501.AA00675@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Reqs Doc ... Date: Tue, 03 May 94 01:01:04 -0400 X-Mts: smtp Status: O Frank, Craig, and Jon, I am using the reqs doc to build my review input. Hey it works and is really helping me to structure my response in an objective and concise manner. Good job again, /jim From brian@dxcoms.cern.ch Tue May 3 09:02:25 1994 Return-Path: brian@dxcoms.cern.ch 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 DAA04936 for ; Tue, 3 May 1994 03:02:59 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03270; Tue, 3 May 1994 09:02:26 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA24150; Tue, 3 May 1994 09:02:25 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405030702.AA24150@dxcoms.cern.ch> Subject: Re: CATNIP as a "convergence point", not a "proposal" To: ipng@cmf.nrl.navy.mil Date: Tue, 3 May 1994 09:02:25 +0200 (MET DST) In-Reply-To: <9405021842.AA24552@WC.Novell.COM> from "Greg Minshall" at May 2, 94 11:42:33 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: 540 Status: O Greg, I think you are going too quickly by making this formal proposal before the Directorate members have submitted their reviews. There are some very attractive ideas in CATNIP. Some of them at least should be kept. Brian >--------- Text sent by Greg Minshall follows: > > Group, > > The subject line says it all. > > I would propose that we "drop" CATNIP as a proposal (though, we may want to > understand key points of CATNIP as well as consider it as possibly helping > to define a convergence point/space). > > Greg > > From brian@dxcoms.cern.ch Tue May 3 09:46:28 1994 Return-Path: brian@dxcoms.cern.ch 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 DAA05050 for ; Tue, 3 May 1994 03:47:02 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10588; Tue, 3 May 1994 09:46:30 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA25527; Tue, 3 May 1994 09:46:28 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405030746.AA25527@dxcoms.cern.ch> Subject: Re: IPng requirements & migration from other protocols To: ipng@cmf.nrl.navy.mil Date: Tue, 3 May 1994 09:46:28 +0200 (MET DST) In-Reply-To: <9405021737.AA24092@WC.Novell.COM> from "Greg Minshall" at May 2, 94 10:37:28 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: 1525 Status: O Greg, > > >No, it perpetuates multiprotocolism. I think this is realistic, > >and defining an IPng that allows foo-to-IPng convergence for > >any value of foo is unrealistic. That doesn't mean you cannot > >implement Fooware over IPng of course. > > I think multiprotocolism perpetuates itself, and doesn't need a "generic > encaps" mechanism to help it along. We can agree to differ on this. It doesn't affect the IPng choice significantly. > > >I have the feeling that out there in the real world, the API > >matters more than anything. > > I don't know. Maybe you are saying "if the applications don't come, we may > as well forget it", which is true. But, there is a vicious cycle (if hosts > don't come, if routers don't come, if applications don't come, ...). Make > it easy for applications (i think APIs are important - maybe just not the > BE all and END all). > > I think that if we don't massively screw up, AND if the traditional > IETF/research community move their banging over to banging on IPng to make > it more productive, better, etc., put apps on it, etc., new facilities, > etc., then it may well "succeed". (It is just that with the right > technical content, eg, autoconfig, discovery, etc., the "succeeding" may be > better...) > Well, my heretical view is that IP was going nowhere fast in the market until BSD sockets were defined (and later, Winsock in the PC market). All we really need for IPng is a modified sockets and Winsock definition. SIPP has started on this already. Brian From brian@dxcoms.cern.ch Tue May 3 10:29:13 1994 Return-Path: brian@dxcoms.cern.ch 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 EAA05147 for ; Tue, 3 May 1994 04:29:49 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18784; Tue, 3 May 1994 10:29:15 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA26517; Tue, 3 May 1994 10:29:14 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405030829.AA26517@dxcoms.cern.ch> Subject: Re: NSAPs To: ipng@cmf.nrl.navy.mil Date: Tue, 3 May 1994 10:29:13 +0200 (MET DST) In-Reply-To: <9405030412.AA00150@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at May 3, 94 00:12:14 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: 1698 Status: O Directorate, I have to say something I think I first said on the TUBA list 18 months ago: it is OK to define an optimised NSAPA format for IPng, but it is unacceptable for that format to be mandatory. It MUST be possible to use an arbitrary NSAPA, at the price of reduced routing and host performance. The reasons for this have been bashed around on the TUBA list in the past, so I won't waste space here. Let's just say that if you don't allow an arbitrary NSAPA format, you've thrown away the advantage of choosing NSAPAs in the first place. We are really getting back to basics here. Who thinks we'll be all done by July? 82 days to go until the opening plenary. Brian >--------- Text sent by bound@zk3.dec.com follows: > > While preparing for my input I studied various NSAP thoughts and > literature on the subject. Well as I stated on the last telechat I am > on the side of the fence with Steve Deering on this subject, unless we > can build an NSAP for IPng that is not defined exactly as today for ISO. > > I talked to Peter Ford last week (while working on another piece of work > non-IPng) a little about NSAPs and felt Peter had a good handle on how > it could be used as we want to define it for IPng. I think Peter, Ross > Callon, and Rob Ullmann can figure this out, but I can't take the > formats of ISO as gospel technically for routing or the way variable > addresses would show up at the transport either in the 'Internet'. I do > hear a lot folks like the way we did it with Phase V, not that this should > be used for IPng, but that maybe there is some knowledge here to be > gained. > > p.s. Yakov Rehkter seems to have a good handle on this too. > > /jim > From brian@dxcoms.cern.ch Tue May 3 15:19:38 1994 Return-Path: brian@dxcoms.cern.ch 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: O 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 mankin@cmf.nrl.navy.mil Tue May 3 10:01:59 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id KAA06463 for ; Tue, 3 May 1994 10:02:02 -0400 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id KAA00416 for ipng; Tue, 3 May 1994 10:01:59 -0400 Date: Tue, 3 May 1994 10:01:59 -0400 From: Allison J Mankin Message-Id: <199405031401.KAA00416@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: The Actual Deadline Status: O Hi, folks, Greg and Jim asked for an actual deadline. We revised the deadline provisionally once, so now you will only be condemned and censured if you do not finish written reviews before the retreat. We asked for the reviews by May 8 (forgetting Motherhood Day), to give ourselves some time to go through them ahead of time. Even Friday May 13 will still afford this time. Brian has started our countdown until Toronto. 82 days. Thanks, Brian. Scott and Allison From bound@zk3.dec.com Wed May 4 10:45:45 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id KAA07005; Wed, 4 May 1994 10:53:42 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA02936; Wed, 4 May 94 07:45:56 -0700 Received: by xirtlu.zk3.dec.com; id AA04718; Wed, 4 May 1994 10:45:51 -0400 Message-Id: <9405041445.AA04718@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: ipng@cmf.nrl.navy.mil Subject: Re: The Actual Deadline In-Reply-To: Your message of "Tue, 03 May 94 10:01:59 EDT." <199405031401.KAA00416@radegond.cmf.nrl.navy.mil> Date: Wed, 04 May 94 10:45:45 -0400 X-Mts: smtp Status: O Thank you Scott and Allison. I am on vacation but doing IPng work as a dedicated directorate. But now I will take time to do some fishing. I had to re-read IS-IS and ES-IS. After reading OSFP, MOSPF, PIM, Draft OSI NSAPs, and other IETF docs I must say: "I really think ISO needs to learn from the IETF how to write documents it takes me much more time to read ISO material than IETF material and ISO does not take the time the IETF docs do explaining rationale for the choice either. ISO docs remind me of my old IBM 360/370 assembler days of having to read SNA manuals. thanks /jim From bound@zk3.dec.com Wed May 4 11:20:09 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA07261 for ; Wed, 4 May 1994 11:28:23 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA05721; Wed, 4 May 94 08:21:09 -0700 Received: by xirtlu.zk3.dec.com; id AA05756; Wed, 4 May 1994 11:21:01 -0400 Message-Id: <9405041521.AA05756@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: SIPP Concepts and Principles for Transition fyi ... Date: Wed, 04 May 94 11:20:09 -0400 X-Mts: smtp Status: O ------- Forwarded Message Return-Path: sipp-request@sunroof2.eng.sun.com Received: from decvax.zk3.dec.com by wasted.zk3.dec.com; (5.65/1.1.8.2/01Apr94-1041AM) id AA20211; Tue, 3 May 1994 21:14:14 -0400 Received: from Sun.COM by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) id AA26128; Tue, 3 May 1994 21:14:09 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA22389; Tue, 3 May 94 18:07:18 PDT Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA05987; Tue, 3 May 94 18:06:20 PDT Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08062; Tue, 3 May 94 18:06:56 PDT Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08056; Tue, 3 May 94 18:06:53 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA01976; Tue, 3 May 1994 18:06:12 -0700 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA02033; Tue, 3 May 1994 18:02:06 +0800 Date: Tue, 3 May 1994 18:02:06 +0800 From: Bob.Gilligan@eng.sun.com (Bob Gilligan) Message-Id: <9405040102.AA02033@kandinsky.Eng.Sun.COM> To: sipp@sunroof.eng.sun.com Subject: SIPP Transition: Concepts and Principles Sender: sipp-request@sunroof.eng.sun.com One thing that was clear to me after the Seattle IETF meeting was that we really have not done a very good job of explaining how the SIPP transition mechanisms (IPAE), as they are currently designed, work. In order to help people to understand a little bit more about the background and requirements that went into their design, I thought I would write up a short overview paper on the SIPP transition mechanisms. This isn't intended to be a detailed treatment; Its just a high-level paper. I have included the first draft of this paper below. I'd like to get comments/questions/suggestions as well as feedback from people as to whether a high-level paper like this is useful. If people think that this paper is valuable, I will submit it as an internet draft. Bob. Internet Engineering Task Force Robert E. Gilligan INTERNET-DRAFT 3 May 1994 SIPP Transition: Concepts and Principles Status of this Memo Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. This Internet Draft expires on November 3, 1994. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Distribution of this memo is unlimited. 1. Introduction In order for the next generation Internet Protocol to be successful, it must provide ways for the Internet to transition to the new protocol. The Simple Internet Protocol Plus (SIPP) proposal includes a set of transition mechanisms that are designed make the transition easy and flexible for the end user. Before attempting to understand how the SIPP transition mechanisms work, and what benefits they provide, it is useful to understand the problems that they were designed to solve, as well as the features that they were designed to provide. This background can provide insight into how useful the SIPP transition mechanisms will be in practice. This paper presents a general overview of the SIPP transition mechanisms, and explains the goals that its designers were attempting to achieve. This paper is intended to serve as introduction to the SIPP transition mechanisms. This is a high-level paper; Some of the details are draft-ietf-sipp-trans-concepts-00.txt [Page 1]  INTERNET-DRAFT SIPP Transition: Concepts and Principles May 1994 omitted. One can find more detailed information in the SIPP transition specification [SIPP-TRANS] and in the SIPP specification [SIPP]. The remainder of the paper is organized as follows: - Chapter 2 explains the problems that the SIPP transition mechanisms were designed to solve. - Chapter 3 explains the general principles that guided the design of the SIPP transition mechanisms. - Chapter 4 gives an overview of the SIPP transition mechanisms. 2. Objectives The SIPP transition mechanisms were designed to solve two important problems: global interoperability between SIPP and IPv4 systems, and the scaling of global IPv4 routing. 2.1. Global IPv4-SIPP Interoperability In order for SIPP to be successful, it must be possible for all SIPP systems connected to the global Internet to interoperate with all IPv4 systems. This global interoperability must be possible at least up until the time when IPv4 addresses "run out." After this time, it is generally believed that it will be impossible for SIPP nodes to directly interoperate with every IPv4 system, or even for every IPv4 system to interoperate with every other IPv4 system, because there will not be enough IPv4 addresses to identify each one uniquely. Still, it should be possible for SIPP systems to interoperate with IPv4 hosts within a limited domain where IPv4 addresses remain locally unique. The scope of SIPP-IPv4 interoperability after the time when IPv4 addresses run out should be as large as possible. 2.2. Global IPv4 Routing One of the reasons why a new Internet Protocol is needed is because of huge number of IPv4 routes that must be carried in the backbone. The root cause of this problem is the inability to add more layers of hierarchy to the limited 32-bit IPv4 address. The larger address space of SIPP allows more layers of hierarchy, so the SIPP routing system should scale to a very large size. However, during the transition period, sites will continue to deploy new IPv4 systems and networks. Also, SIPP systems must be able to globally interoperate with IPv4 systems during this period. We must continue to have global reachability to all IPv4 destinations during the transition period. Thus the backbone must continue to be able to route traffic to all IPv4 draft-ietf-sipp-trans-concepts-00.txt [Page 2]  INTERNET-DRAFT SIPP Transition: Concepts and Principles May 1994 destinations up until the time when IPv4 addresses "run out." 3. Design Principles A number of basic principles were considered important in designing the SIPP transition mechanisms. 3.1. Easy for the End User The transition should be as easy as possible for the largest population of individuals who will be affected by it: the end users. This population is also the least technically sophisticated, and thus least prepared to deal with some of the complex problems that the transition may bring about. So, wherever possible, the designers of the transition mechanisms have attempted simplify the transition for the end user. To the extent possible, the transition mechanisms should also minimize the amount of effort required by the other populations that will be involved, including, in descending priority: the administrators who manage the end-user networks and hosts; the operators of the backbone networks; and those who design and implement these protocols. Spectrum of transition effort: Easiest: End Users ^ | System Administrators | | Network Operators | | Protocol Implementors v Hardest: Protocol Designers 3.2. Incremental Deployment Users and sites must be able to upgrade hosts and routers to SIPP in an incremental manner. They can not be forced to upgrade all of their machines, or even a subset of systems, at one time. They must be able to upgrade their systems one by one. Incremental deployment is essential because different vendors will make SIPP available in their products at different times. Most sites use systems from more than one vendor. Sites and users must have the option draft-ietf-sipp-trans-concepts-00.txt [Page 3]  INTERNET-DRAFT SIPP Transition: Concepts and Principles May 1994 of upgrading systems at the time when SIPP becomes available in the systems they use. If sites were required upgrade all of their hosts or all of their routers at one time, the upgrade would be delayed until the time when SIPP becomes available for all of their systems. 3.3. No Upgrade Inter-dependencies There must be no pre-requisites to upgrading to SIPP. Users and sites must be able to upgrade both hosts and routers to SIPP without any other system being upgraded first. Upgrading one system to SIPP must never be dependent on first upgrading some other system to SIPP. It must be possible to upgrade a host to SIPP before any routers on the subnet it is attached to are upgraded. Similarly, it must be possible to upgrade any router to SIPP before any hosts on the subnets it is attached to have been upgraded, and before any other routers in the domain have been upgraded. Given the size and complexity of the Internet, and the fact of multiple independent administrative domains, co-ordinating upgrades is not feasible. If co-ordination were required, upgrading would be delayed until the time when slowest organization could upgrade. The SIPP transition allows completely independent deployment of hosts and routers. Hosts may be upgraded to SIPP before any routers on their attached subnet are upgraded. Routers may be upgraded to SIPP before any hosts on their attached subnets are upgraded. 3.4. Two Hosts on a Wire It must be possible for a SIPP host and an IPv4 host attached to the same physical subnet to directly interoperate without the help of a third machine. Direct interoperability is a key feature of IPv4, and it must be maintained between during the transition. The SIPP transition meets this requirement by requiring SIPP systems to implement IPv4 and ARP. SIPP systems use IPv4 when interoperating with IPv4 hosts on the same subnet. 3.5. Extended Transition Time Users and network administrators should have as long a time as possible in which to upgrade their systems to SIPP. The longer the upgrade window, the more flexibility users will have to conveniently schedule their upgrade. draft-ietf-sipp-trans-concepts-00.txt [Page 4]  INTERNET-DRAFT SIPP Transition: Concepts and Principles May 1994 In the Internet, the hosts and routers are controlled by a variety of different organizations and individuals, with widely varying schedules and needs. Users must be able to upgrade their hosts and routers at a time that is convenient for them. The window of time during which they may transition to SIPP must be as long as possible. The only hard deadline in the SIPP transition is the time when IPv4 addresses "run out". After this time, hosts that have not upgraded will not be able to globally interoperate. IPv4 routers can continue to be used in an IPv4 cluster (see section 4.2) even after the time that IPv4 addresses run out. Many of the new features of SIPP only become available to the user after they upgrade their systems. Some new SIPP mechanisms require on-subnet SIPP routers. Users and sites that do not need these features should not be required to upgrade prematurely. Users and sites that desire these features may upgrade earlier. 3.6. Leverage the Installed Base Wherever possible, the transition mechanisms should make use of the installed base of IPv4 hosts and routers. This is important because organizations expect to pay for their investment in IPv4 equipment over time. If the transition requires them to immediately replace their IPv4 systems, that investment will have been wasted. If the transition allows them to continue to use their IPv4 systems for a long time, the transition is less expensive. The SIPP transition *allows* sites to upgrade systems to SIPP immediately, but does not require it. 4. Transition Mechanisms The SIPP transition uses three mechanisms: - An IPv4-compatible SIPP address format - A mechanism to tunnel SIPP traffic within IPv4 - A mechanism to translate IPv4 traffic into SIPP There are some dependencies between the mechanisms. Both the tunneling and translation mechanisms make use of the information encoded in the IPv4-compatible SIPP address. 4.1. Addressing draft-ietf-sipp-trans-concepts-00.txt [Page 5]  INTERNET-DRAFT SIPP Transition: Concepts and Principles May 1994 SIPP provides for a variety of addressing formats. One of those formats is the IPv4-compatible SIPP address format. This address format was designed to encode the information necessary to allow tunneling and translation to be performed, while also allowing more hierarchical addressing information than was possible with IPv4. The IPv4-compatible SIPP address was designed to be compatible with the existing IPv4 addressing structure, so that sites can use their existing IPv4 addresses when they upgrade to SIPP. IPv4 hosts and routers do not need to change their address when they upgrade to SIPP. They continue to use their existing IPv4 address when sending and receiving IPv4 traffic. For SIPP traffic, they use a SIPP address that is composed of their existing IPv4 address, with 32 additional address bits prepended at the front. All hosts within a site prepend the same prefix. The 64-bit IPv4-compatible SIPP address format is: |1| 31 bits | 32 bits | +-+-+-+-+-+-+-+-+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+-+-+-+-+-+-+-+-+ |C| higher-order SIPP prefix | IPv4 address | +-+-+-+-+-+-+-+-+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+-+-+-+-+-+-+-+-+ The low-order 32-bits of this address format encodes an IPv4 address. SIPP hosts can use this as their IPv4 address whenever they send or receive IPv4 packets. The high-order bit, known as the C-bit, has a special significance for the transition mechanisms. IPv4 compatible SIPP addresses can be assigned to both IPv4 and SIPP nodes. The C-bit indicates whether the node that the address identifies is an IPv4 node, or a SIPP node. Node type C-bit --------- ----- IPv4 1 SIPP 0 Many of the SIPP transition mechanisms make use of the fact that they can determine whether a node supports SIPP or IPv4 based on the C-bit of its address. The middle 31-bits are used to encode additional addressing information. IPv4 compatible SIPP addresses are assigned according to a global SIPP addressing plan. This plan will provide for a hierarchy of assignment, and may be based on CIDR. The Internet Assigned Number Authority (IANA) will delegate blocks of the SIPP address space to subordinate organizations. The delegation will proceed down to individual user sites which will be assigned a single block of contiguous address space draft-ietf-sipp-trans-concepts-00.txt [Page 6]  INTERNET-DRAFT SIPP Transition: Concepts and Principles May 1994 for use in assigning addresses to individual hosts and routers. The assignment of IPv4 compatible SIPP addresses to hosts and routers will be constrained for as long as possible so that the low-order 32-bits are globally unique. This will ensure that the low-order 32-bits can be used as a globally unique IPv4 address for as long as possible. All SIPP hosts must be assigned IPv4 compatible SIPP addresses in order to interoperate with IPv4 hosts. 4.2. Tunnelling The SIPP-in-IPv4 tunneling technique was developed in order to allow SIPP hosts and routers to be deployed in a topology that includes IPv4 routers. The concept behind tunneling is that SIPP hosts and routers can treat clusters of IPv4 topology (groups of subnets connected by IPv4 routers) as a single subnet from the point of view of SIPP routing. In the same way that IPv4 hosts can treat a non-broadcast multipoint network, such as the ARPAnet, as a single IPv4 subnet, SIPP nodes can treat almost any cluster of IPv4 topology as a non-broadcast SIPP subnet. (The restrictions on an IPv4 cluster are: [1] it must be fully IPv4-connected internally; and [2] it must fully contain an IPv4 address block such as a subnetted IPv4 network, or a CIDR prefix.) SIPP nodes can send SIPP traffic to other SIPP nodes that are attached to the same "IPv4 clusters" by encapsulating it within IPv4. Since SIPP nodes use IPv4 compatible SIPP addresses, which have an IPv4 address embedded within them, the sending node can always automatically determine the address to send the encapsulating IPv4 packet to based on the SIPP address that it desires to reach. The IPv4 address of the "tunnel endpoint" is always the low-order 32-bits of the SIPP address of the tunnel endpoint. In this sense, we can say that SIPP-in-IPv4 tunnels are "automatically configured". SIPP-in-IPv4 tunneling can be end-to-end (i.e. one tunnel between two SIPP hosts) or a tunnel can comprise only part of the end-to-end path (e.g. the path between a SIPP host and the first-hop SIPP router). In all cases, however, tunneling is only used between SIPP nodes; The "endpoints" of a tunnel are always SIPP nodes. When processing packets, SIPP hosts and routers use the C-bit, which is encoded into the IPv4-compatible SIPP address, to determine whether a particular destination can be reached via tunneling. SIPP hosts and routers use one additional piece of per-interface draft-ietf-sipp-trans-concepts-00.txt [Page 7]  INTERNET-DRAFT SIPP Transition: Concepts and Principles May 1994 configuration information to make decisions about which destinations can be tunneled to. The "SIPP/IPv4 cluster mask" is a 64-bit mask that is used in a manner analogous to the IPv4 "netmask" to determine whether a destination is located within a directly connected IPv4 cluster or not. If a destination is located within an attached IPv4 cluster (its address, and-ed with the cluster mask, matches the interface address, and-ed with cluster mask), and is a SIPP host (the C-bit of address is zero), then that destination can be tunneled to. The decisions that a SIPP host or router makes about whether to tunnel a packet or not are entirely determined by information contained within the packet being sent, and per-interface configuration information. 4.3. Header Translation The header translation mechanism was designed in order to allow portions of the Internet routing system to eventually be upgraded to support only SIPP traffic. This will allow the Internet backbone to eventually stop directly handling IPv4 traffic. This will solve the IPv4 route scaling problem, since SIPP traffic can be routed based on SIPP addresses which contain more levels of hierarchy. In header translation, the IPv4 headers of traffic sent by IPv4 hosts are "translated" into SIPP headers. The transport layer headers, and all other data beyond the Internet header, is not changed. Once translated into SIPP form, the resulting traffic can be carried by the SIPP routing system. If the traffic is destined to an IPv4 host, it must be translated back to IPv4 form before it is delivered to the destination host. The incorporation of the C-bit into the IPv4-compatible SIPP address is essential to translation. If a SIPP packet is addressed to a destination with the C-bit equal to one, then that packet must be translated to IPv4 before it is delivered to the destination host. Header translation can be viewed as having three functional components: - SIPP routers translate IPv4 traffic into SIPP - SIPP routers translate SIPP traffic into IPv4 - SIPP hosts "pre-translate" IPv4 traffic into SIPP. In the first component, SIPP routers translate IPv4 headers of traffic sent by IPv4 hosts into SIPP form. This "direction" of translation (IPv4-to-SIPP) is more complex, because the information in the IPv4 packet being translated is insufficient to form a SIPP packet. The source and destination addresses in an IPv4 packet do not provide enough information to compose the source and destination addresses in the SIPP draft-ietf-sipp-trans-concepts-00.txt [Page 8]  INTERNET-DRAFT SIPP Transition: Concepts and Principles May 1994 packet. To remedy this problem, the "IPv4-to-SIPP translators" must be equipped with an "address mapping table" which maps the destination IPv4 address in an IPv4 packet into a 32-bit prefix. The 32-bit prefix is pre-pended to the IPv4 address to compose a full 64-bit SIPP address. The mapping table is structured with a 32-bit mask and prefix, so that entire IPv4 address blocks may be represented with only one entry. However, the mapping table must be globally maintained and distributed to all translators. The second component involves the translation by SIPP routers of SIPP traffic addressed to IPv4 hosts into IPv4 form. This "direction" of translation is much simpler than the first, since all of the information needed to form the IPv4 header is contained in the SIPP header being translated. The low-order 32-bits of the source and destination addresses of the SIPP packet being translated can be used for the source and destination addresses of the IPv4 packet being composed. The third component of translation is implemented in SIPP hosts. When sending, SIPP hosts use the C-bit of the destination address to determine whether the destination is an IPv4 host or a SIPP host. If the destination is an IPv4 host (the C-bit equals one), the sending SIPP host calculates the transport layer pseudo-header checksum in a manner compatible with IPv4 (the SIPP pseudo-header checksum algorithm is slightly different from IPv4). The SIPP host may then send the traffic with SIPP headers or with IPv4 headers. If it sends in the SIPP form, a translating router will translate the SIPP headers into IPv4 before the traffic is delivered to the destination IPv4 host. Since IPv4-compatible SIPP addresses (with the C-bit set to one) can be assigned to IPv4 hosts and listed in the DNS, applications running on SIPP hosts need not be aware that they are interacting with IPv4 hosts. Applications simply lookup SIPP addresses in the DNS and pass them down to the SIPP layer, which determines which packet format and pseudo-header checksum algorithm to employ. The capability of SIPP hosts to send traffic for IPv4 hosts using SIPP headers can be thought of as "pre-translating" the traffic to SIPP. 5. Conclusion The SIPP transition mechanisms address the two problems of IPv4 route scaling and interoperability between IPv4 and SIPP systems, while making the transition as simple as possible for the end users. The mechanisms generally trade off complexity for the designers and implementors of the protocols in favor of simplicity for the end users and network administrators. While writing the software to implement the SIPP transition mechanisms draft-ietf-sipp-trans-concepts-00.txt [Page 9]  INTERNET-DRAFT SIPP Transition: Concepts and Principles May 1994 might involve more work than some of the more straightforward transition mechanisms, the benefits in terms of added flexibility for the users far outweighs these costs. 6. Acknowledgments The author would like to thank the people who provided feedback and suggestions based on earlier drafts of this paper, including . 7. Author's Address Robert E. Gilligan Phone: 415-336-1012 Sun Microsystems, Inc. Fax: 415-336-6015 2550 Garcia Avenue Mail: gilligan@eng.sun.com Mailstop UMTV05-44 Mountain View, California 94043-1100 8. References [DISC] W. Simpson, "SIPP Neighbor Discovery", Internet Draft, draft- ietf-sipp-discovery-04.txt, March 1994. [SIPP] S. Deering, "Simple Internet Protocol Plus (SIPP) Specification", Internet Draft, draft-ietf-sipp-spec-00.txt, February, 1994. [SIPP-ADDR] P. Francis, "Simple Internet Protocol Plus (SIPP): Unicast Hierarchical Address Assignment", Internet Draft, , January 1994. [SIPP-DHCP] S. Thompson. SIPP Extensions to BOOTP/DHCP. February 1994. Internet Draft. [SIPP-TRANS] R. Gilligan, et al, " IPAE: The SIPP Interoperability and Transition Mechanism", Internet Draft, draft-ietf-sipp-ipae- transition-01.txt, March 1994. draft-ietf-sipp-trans-concepts-00.txt [Page 10]  ------- End of Forwarded Message From bound@zk3.dec.com Wed May 4 11:38:37 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA07346 for ; Wed, 4 May 1994 11:43:06 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA07162; Wed, 4 May 94 08:39:29 -0700 Received: by xirtlu.zk3.dec.com; id AA06782; Wed, 4 May 1994 11:39:19 -0400 Message-Id: <9405041539.AA06782@xirtlu.zk3.dec.com> To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Cc: ipng@cmf.nrl.navy.mil Subject: Re: NSAPs In-Reply-To: Your message of "Tue, 03 May 94 10:29:13 +0200." <9405030829.AA26517@dxcoms.cern.ch> Date: Wed, 04 May 94 11:38:37 -0400 X-Mts: smtp Status: O Brian, >We are really getting back to basics here. Who thinks we'll >be all done by July? 82 days to go until the opening plenary. I think if we have to handle the convergence problem of the entire multiprotocol envirnment we will not make it. Because it introduces a new complexity into the equation. If we only are concerned with IPv4 backwards compatibility then we can make the deliverable. PERFORMANCE: I cannot support any proposal that causes a host performance cost greater in magnitude than the performance today in IPv4. IPv4 is the measuring stick. The question is what is 'magnitude' in my previous statement. Well today I can saturate with UDP and close with TCP an Ethernet or FDDI link on a host via packet throughput on our OSF/1 and OpenVMS hosts with IPv4. If I can't do that with IPng then that is bogus to my customers. /jim From Greg_Minshall@Novell.COM Wed May 4 12:31:00 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id PAA09307 for ; Wed, 4 May 1994 15:33:04 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA14689; Wed, 4 May 94 13:37:50 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB01468; Wed, 4 May 94 12:31:00 PDT Date: Wed, 4 May 94 12:31:00 PDT Message-Id: <9405041931.AB01468@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), ipng@cmf.nrl.navy.mil From: Greg Minshall Subject: Re: NSAPs Status: O Brian, >I have to say something I think I first said on the TUBA list >18 months ago: it is OK to define an optimised NSAPA format >for IPng, but it is unacceptable for that format to be >mandatory. It MUST be possible to use an arbitrary NSAPA, >at the price of reduced routing and host performance. *If* IPng supports NSAPs, then i would guess it would have to allow the embedding of an arbitrary NSAP in the "destination" field. However, it may be the case that the syntactic way that embedding occurs may do something like, for instance, make the NSAP length be 0 mod 64 bits (by extending with 0's). Then, your req't is that arbitrary NSAPs can be routed. I would assume that arbitrary "destinations" can be routed. A separate issue is whether someone (ISOC, IANA, InterNIC, whatever) decides to define an NSAP format which is *preferred* (in terms of being a) length 0 mod 64 to begin with, maybe, and b) optimal for routing, etc.). Greg (catching up on some e-mail) From brian@dxcoms.cern.ch Wed May 4 22:03:37 1994 Return-Path: brian@dxcoms.cern.ch 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 QAA09638 for ; Wed, 4 May 1994 16:04:13 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24771; Wed, 4 May 1994 22:03:40 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA01178; Wed, 4 May 1994 22:03:38 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405042003.AA01178@dxcoms.cern.ch> Subject: Re: NSAPs To: Greg_Minshall@novell.com (Greg Minshall) Date: Wed, 4 May 1994 22:03:37 +0200 (MET DST) Cc: ipng@cmf.nrl.navy.mil In-Reply-To: <9405041931.AB01468@WC.Novell.COM> from "Greg Minshall" at May 4, 94 12:31:00 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 58 Status: O Grege, I entirely agree with your last message. Brian From kasten@Research.Ftp.Com Wed May 4 16:49:05 1994 Return-Path: kasten@Research.Ftp.Com Received: from Research.Ftp.Com (research.ftp.com [128.127.145.125]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA09893 for ; Wed, 4 May 1994 16:53:24 -0400 Received: by Research.Ftp.Com (920330.SGI/) for ipng@cmf.nrl.navy.mil id AA02809; Wed, 4 May 94 16:49:06 -0400 Received: by Research.Ftp.Com id AA02809; Wed, 4 May 94 16:49:06 -0400 Date: Wed, 4 May 1994 16:49:05 -0400 (EDT) From: Frank Kastenholz Subject: implementation status To: ipng mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O hi i am starting to review the various ipng proposals. i am using the reading list that steve coya sent out a week or two ago. however, what would also be useful is an implementation status report, listing things like what functions of what documents have been implemented, tested, and so on. this could be as simple as "we implemented all of document x, none of document y, and sections 1, 2, and 3 of document z". this would help me, as a reviewer, getting a 'feel' for how 'firm' the various documents are (if all of document x has been implemented, then i'd assume that it pretty much represents the 'final thing' while of none of y is implemented, i'd assume that y is nothing but whiteboard engineering...) thanks frank From ericf@atc.boeing.com Wed May 4 16:13:33 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id TAA10579 for ; Wed, 4 May 1994 19:11:52 -0400 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 Status: O 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 Wed May 4 16:13:33 1994 Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id XAA11343 for ; Wed, 4 May 1994 23:30:40 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA07937; Thu, 5 May 1994 12:30:15 +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 Status: O 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 lkeiper@IETF.CNRI.Reston.VA.US Thu May 5 09:13:32 1994 Return-Path: lkeiper@IETF.CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA12947 for ; Thu, 5 May 1994 09:17:15 -0400 Received: from [132.151.1.55] by IETF.CNRI.Reston.VA.US id aa04918; 5 May 94 9:13 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 May 1994 09:13:32 +0100 To: ipng@cmf.nrl.navy.mil From: Lois Keiper Subject: IPng Teleconference Message-ID: <9405050913.aa04918@IETF.CNRI.Reston.VA.US> Status: O >ANNOUNCEMENT: >> >> >>The names marked with an asterisk are those who have confirmed >>participation for the IPng teleconference sheduled for Monday, May 2, 1994 >>11:30 - 1:30pm EST. Please send your RSVP as soon as possible. Thank >>You!! >> >>Please contact me with any changes @lkeiper.cnri.reston.va.us. >> J. Allard 206-936-9031 >> Scott Bradner 617-495-3864 >> Steve Bellovin 908-582-5886 >> Jim Bound 603-465-3130 >> Ross Callon 508-436-3936 >> Brian Carpenter +41 227 674 967 >> Dave Clark 617-253-6003 >> *Steve Coya 703-620-8990* >> Jon Crowcroft +44 713 807 296 >> John Curran 617-873-4398 >> Steve Deering 415-812-4839 >> Dino Farinacci 408-226-6870 >> Eric Fleischman 206-957-5334 >> Paul Frances +81 339 280 408 >> Frank Kastenholz 508-685-4000 >> Mark Knopper 313-741-5445 >> Allison Mankin 202-404-7030 >> Greg Minshall 510-975-4507 >> Craig Partridge 415-326-4541 >> Rob Ullmann 617-693-1315 >> Lixia Zhang 415-812-4415 >> >> >> >> >> >>If you need to be added to the call in progress, Please call 1-800-232-1234 >>or for international particpants, 516-424-3151. The call can be referenced >>by the confirmation number ER27251 in the orginators name, Steve Coya. >> >>Many thanks, >> >>Lois >> >> > From Robert_Ullmann.LOTUS@CRD.lotus.com Thu May 5 12:43:42 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA14343 for ; Thu, 5 May 1994 12:38:03 -0400 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com by lotus.com (4.1/SMI-4.1) id AA05804; Thu, 5 May 94 12:39:21 EDT Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA11270; Thu, 5 May 94 12:43:42 EDT Date: Thu, 5 May 94 12:43:42 EDT Message-Id: <9405051643.AA11270@Mail.Lotus.com> Received: by DniMail (v1.0); Thu May 5 12:43:40 1994 EDT To: UNIXML::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Re: should we tweak TCP? Status: O > We're going to have to make some minor changes around the fringes of > TCP -- to accomodate the different pseudo-header checksum, if nothing > else. Should we go a bit deeper? Specifically, should we (a) increase > the size of sequence numbers to 64 bits, and (b) increase the size > of the option field? Gee, this sounds familiar. (see RFC1475) The consistant feedback was (is, see Jon's note) that the transport should be independent of the IPng. It isn't necessarily true that we have to tweak anything in TCP. Catnip (re-)defines the TCP checksum to include the least significant 32 bits of the network layer address; for IPv4, this is the same as the existing checksum (of course). To answer the usual question: no, this isn't as "good" as it could be, but it is as good as TCPv4. (Keep in mind that the existing TCP checksum doesn't somehow give you perfect integrity, it simply reduces the experienced error rate by 4.7 decimal orders of magnitude.) The win is that the checksum is still end-to-end when datagrams get translated (and they *will* get translated :-). An intermediate system that needs to "fix up" the transport checksum would be a very bad thing indeed. --- This, BTW, highlights the one remaining technical difference between TUBA and Catnip; if TUBA uses the checksum as presently defined, then Catnip will need to assign a different code point to TUBA-TCP from the one assigned to IPv4-TCP, which would be too bad. Catnip<-->SIPP already works correctly with the SIPP definition of the checksum (special cased on the C bit) when interoperating with IPv4, but not when using SIPP-native. --- A new transport layer protocol with 64 bit seq/ack, 32 bit window, EIDs *idependent* of the NL-address, etc. would be a fine thing to design. And being end-to-end, it would be a lot easier to test and deploy. My input is mostly represented in RFC1475. Best Regards, Robert From francis@cactus.slab.ntt.jp Fri May 6 10:24:39 1994 Return-Path: francis@cactus.slab.ntt.jp Received: from mail.ntt.jp ([192.5.216.174]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id VAA17772 for ; Thu, 5 May 1994 21:24:59 -0400 Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Fri, 6 May 1994 10:24:40 +0900 Received: by slab.ntt.jp (8.6.8/core-slab.s5+) id KAA00268; Fri, 6 May 1994 10:24:40 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA28003; Fri, 6 May 94 10:24:39 JST Date: Fri, 6 May 94 10:24:39 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9405060124.AA28003@cactus.slab.ntt.jp> To: Greg_Minshall@novell.com, ipng@cmf.nrl.navy.mil Subject: Re: CATNIP as a "convergence point", not a "proposal" Status: O > > The subject line says it all. > > I would propose that we "drop" CATNIP as a proposal (though, we may want to > understand key points of CATNIP as well as consider it as possibly helping > to define a convergence point/space). > In my analysis-of-the-proposals paper (already turned in....almost a week ahead of deadline....ha!) I stated the opinion that CATNIP can't be chosen if for no other reason than lack of maturity and popular support, the latter of which is reflected in the lack of implementation. (I also gave some technical arguments against it.) Perhaps we can discuss "dropping" CATNIP as a proposal-under-consideration at the retreat, but even if we don't, I don't see any way that CATNIP could be accepted given its current state of development.... PF From mankin@radegond.cmf.nrl.navy.mil Fri May 6 15:10:55 1994 Return-Path: mankin@radegond.cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id PAA21987 for ; Fri, 6 May 1994 15:11:03 -0400 Received: from localhost.cmf.nrl.navy.mil (localhost.cmf.nrl.navy.mil [127.0.0.1]) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id PAA06297 for ; Fri, 6 May 1994 15:10:57 -0400 Message-Id: <199405061910.PAA06297@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost.cmf.nrl.navy.mil didn't use HELO protocol To: ipng@radegond.cmf.nrl.navy.mil Subject: More about IPNG Retreat Date: Fri, 06 May 1994 15:10:55 -0400 From: Allison J Mankin Status: O Hello folks, The IPNG Retreat will be May 19 and 20 in the Big Ten Conference Center and the Marriott O'Hare Hotel It will start at the Conf. Ctr. on Thursday at 9:30 AM (I'm told we'll have coffee and pastries starting earlier), so East coast folks can take early flights that morning. We'll stop at 5 PM on Friday. We'll work into Thursday evening, after a dinner break, using an additional meeting room at the hotel. Please get reservations at the Marriott O'Hare (not the Suites). The information is below. It will be easiest for all if everyone stays there, plus it's inexpensive. I'm working on the agenda, and Scott and I will settle on a draft over the weekend. I'd like to say the major themes are the routing and addressing architecture; and plug-and-play and autoconfiguration. I'd like to say that we consider security specifically in the context of plug-and-play, wide deployment, ready use. And that we review transition specifically in the context of technology to make protocol transitions and addressing corrections possible. Everyone must have done the peer reviews of the proposal documents by then. The guest list as of now is (Bob Hinden, by the way, will be in Sweden, to our regret): Bob Gilligan Erik Nordmark Ran Atkinson Sue Thomsen Peter Ford (invited by both TUBA and CATNIP) Dave Piscitello (may not be able to make it) Dave Katz Tony Li I will shortly send out a Co-AD Official Invitation to all those people. At the last telechat and other times, we have expressed consensus not to have IESG or IAB members involved in the Directorate's deliberations. This affected one request for a guest (Yakov), by Peter Ford. We remind Lixia and Brian that your Directorate membership preceded your IAB appointments, so Scott and I assume that you are giving the Directorate precedence, and not the IAB, when you participate. Onward and upward, Allison / mankin@cmf.nrl.navy.mil ================================================================== ================================================================== ================================================================== Date: Thu, 21 Apr 94 16:57:08 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) To: ipng@cmf.nrl.navy.mil Subject: retreat info The IPng retreat will be held at the Big-10 Conference Headquarters. The Big-10 Conference Headquarters and meeting facility is located at 1500 West Higgins Road, Park Ridge, Illinois (708) 696-1010. If you are flying into O'hare, we recommend taking the Marriott Shuttle to get there. Walk out of the lower level baggage claim area and wait in the hotel courtesy bus area on the median strip. There are two areas outside each terminal, located toward the ends of the terminals. Marriott advertises that the shuttle runs every 15 minutes. They stop at both the Suites and the Hotel. Marriott also has an arrangement with the Big-10. Ask the driver to let you off at the Big-10 facility, which is located between the Suites and the Hotel. The entrance to the facility is at the rear of the building. Usually the driver will stop at the entrance. However, if they are busy, the driver will stop in front of the building and you will have to make your way across the intersection, which is protected by a stop light, and around to the rear of the building. We will all stay at the the Marriott O'Hare (NOT the Suites). Marriott O'Hare is within walking distance of the Big-10 Conference Center and offers a special rate of $78 for folks who will be using the Big Ten Conference Center. The reservations number is 1-800-228-9290, though you must use 312-693-4444 to get the low rate. From mankin@cmf.nrl.navy.mil Fri May 6 18:10:46 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id SAA22770 for ; Fri, 6 May 1994 18:12:21 -0400 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id SAA06692; Fri, 6 May 1994 18:10:46 -0400 Date: Fri, 6 May 1994 18:10:46 -0400 From: Allison J Mankin Message-Id: <199405062210.SAA06692@radegond.cmf.nrl.navy.mil> To: atkinson@itd.nrl.navy.mil, corecom@TIGGER.JVNC.NET, dkatz@cisco.com, gilligan@eng.sun.com, nordmark@eng.sun.com, peter@lanl.gov, set@thumper.bellcore.com, tli@cisco.com Subject: INVITATION to IPng Retreat Cc: hinden@eng.sun.com, ipng@cmf.nrl.navy.mil Status: O Hi, The IPng Directorate invites you to attend a two day meeting in Chicago May 19 and 20. We hope to advance the reviewing of the three IPng proposals and to help the IPng ADs towards the recommendation we must make in the end of July. You are asked to join us as important contributors to the proposals. Next week we will send you a detailed agenda. Meantime, we would like you to see if you can make it (please do!) and, while you make your travel plans, help with the Directorate's review by considering writing peer reviews of the criteria draft and of the three proposals. If you are willing to do this (some of you have done some review already), please send them to the Directorate mailing list preferably, or to Scott and Allison. Here's the meeting information: ====================================================================== The IPNG Retreat will be May 19 and 20 in the Big Ten Conference Center and the Marriott O'Hare Hotel It will start at the Conf. Ctr. on Thursday at 9:30 AM (I'm told we'll have coffee and pastries starting earlier), so East coast folks can take early flights that morning. We'll stop at 5 PM on Friday. We'll work into Thursday evening, after a dinner break, using an additional meeting room at the hotel. Please get reservations at the Marriott O'Hare (not the Suites). The information is below. It will be easiest for all if everyone stays there, plus it's inexpensive. I'm working on the agenda, and Scott and I will settle on a draft over the weekend. I'd like to say the major themes are the routing and addressing architecture; and plug-and-play and autoconfiguration. I'd like to say that we consider security specifically in the context of plug-and-play, wide deployment, ready use. And that we review transition specifically in the context of technology to make protocol transitions and addressing corrections possible. ====================================================================== The Big-10 Conference Headquarters and meeting facility is located at 1500 West Higgins Road, Park Ridge, Illinois (708) 696-1010. If you are flying into O'hare, we recommend taking the Marriott Shuttle to get there. Walk out of the lower level baggage claim area and wait in the hotel courtesy bus area on the median strip. There are two areas outside each terminal, located toward the ends of the terminals. Marriott advertises that the shuttle runs every 15 minutes. They stop at both the Suites and the Hotel. Marriott also has an arrangement with the Big-10. Ask the driver to let you off at the Big-10 facility, which is located between the Suites and the Hotel. The entrance to the facility is at the rear of the building. Usually the driver will stop at the entrance. However, if they are busy, the driver will stop in front of the building and you will have to make your way across the intersection, which is protected by a stop light, and around to the rear of the building. We will all stay at the the Marriott O'Hare (NOT the Suites). Marriott O'Hare is within walking distance of the Big-10 Conference Center and offers a special rate of $78 for folks who will be using the Big Ten Conference Center. The reservations number is 1-800-228-9290, though you must use 312-693-4444 to get the low rate. =========================================================================== Scott sob@harvard.edu Allison mankin@cmf.nrl.navy.mil From Greg_Minshall@Novell.COM Sun May 8 05:54:21 1994 Return-Path: Greg_Minshall@Novell.COM Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA27377 for ; Sun, 8 May 1994 08:56:40 -0400 Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA26318; Sun, 8 May 94 07:01:28 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB10082; Sun, 8 May 94 05:54:21 PDT Date: Sun, 8 May 94 05:54:21 PDT Message-Id: <9405081254.AB10082@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: IPng requirements & migration from other protocols Cc: ipng@cmf.nrl.navy.mil Status: O Brian, >Well, my heretical view is that IP was going nowhere fast in >the market until BSD sockets were defined (and later, Winsock >in the PC market). All we really need for IPng is a modified >sockets and Winsock definition. SIPP has started on this already. Yes, you are a bit of a heretic. I would say that in the Unix space it was less socket, per se, that made TCP/IP, but the BSD implementation, freely available and used by lots of people and put on lots of workstations, that did the trick. Part of the implementation was the sockets API, but part also (and at least equally if not more important) were protocol stacks, applications (ftp, telnet, rsh), etc. Then, things like NFS and X helped quite a bit. And, today, things like Mosaic. I think that, to date, Winsock has a small impact on the PC market. (Which is not to say i don't think it is important; i do, in fact, think Winsock is very important for the PC environment. It is just that Winsock is only now gaining momentum.) Greg From brian@dxcoms.cern.ch Sun May 8 16:02:14 1994 Return-Path: brian@dxcoms.cern.ch 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 KAA27517 for ; Sun, 8 May 1994 10:02:48 -0400 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20621; Sun, 8 May 1994 16:02:15 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA13064; Sun, 8 May 1994 16:02:14 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9405081402.AA13064@dxcoms.cern.ch> Subject: Telechat during retreat To: ipng@cmf.nrl.navy.mil Date: Sun, 8 May 1994 16:02:14 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 521 Status: O Scott, Allison, et al, Unfortunately I cannot be at the retreat, but I can be near a telephone. I would like to request that either you arrange a telechat to allow the absent members of the Directorate to interact, or if I am the only person interested, that you call me directly. I can be available on the Thursday at the usual time, but not on the Friday. Thursday morning may be too soon to be useful; I could join in a call on Thursday afternoon, Chicago time, if AT&T calls me at home (+41 22 776 3168). Brian From sob@hsdndev.harvard.edu Sun May 8 11:27:16 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA27659 for ; Sun, 8 May 1994 11:27:25 -0400 Date: Sun, 8 May 94 11:27:16 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405081527.AA18910@hsdndev.harvard.edu> To: brian@dxcoms.cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: Telechat during retreat Status: O Brian, Sounds like a good idea. This does bring up a point, who else will not be at the retreat? Scott From sob@hsdndev.harvard.edu Sun May 8 16:39:45 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA28327 for ; Sun, 8 May 1994 16:39:56 -0400 Date: Sun, 8 May 94 16:39:45 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405082039.AA25253@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: Unified Routing Requirements for IPng Status: O forwarded document: --- Scott, Appended is the list of requirements for the IPng. The list is from the Unified Architecture for Inter-Domain Routing perspective. We would appreciate if you'll distribute it to other folks in the IPng directorate, as it might be useful in evaluating various IPng proposals. Deborah & Yakov. Unified Routing Requirements for IPng Deborah Estrin and Yakov Rekhter Draft 5/5/94 1. To provide scalable routing, IPng addressing must provide support for topologically significant address assignment. 2. Since it is hard to predict how routing information will be aggregated, the IPng addressing structure should impose as few preconditions as possible on the number of levels in the hierarchy. 3. The IPng packet header should accommodate a "routing label" or "route ID". This label will be used to identify a particular FIB to be used for packet forwarding by each router. Two types of routing labels should be supported: "strong" and "weak". When a packet carries a "strong" routing label and a router does not have a FIB with this label, the packet is discarded (and an error message is sent back to the source). When a packet carries a "weak" routing label and a router does not have a FIB with this label, the packet should be forwarded via a "default" FIB, i.e., according to the destination address. In addition, the packet should carry an indication that somewhere along the path the desired routing label was unavailable. 4. IPng should provide a source routing mechanism with the following capabilities (i.e. flexibility): Specification of either individual routers or collections of routers as the entities in the source route. The option to indicate that two consecutive entities in a source route must share a common subnet in order for the source route to be valid. Specification of the default behavior when the route to the next entry in the source route is unavailable: The packet is discarded, or The source route is ignored and the packet is forwarded based only on the destination address (and the packet header will indicate this action). The option to indicate that the source route information should be carried all the way to the destination even after the source route is completed (otherwise the source route information is stripped off upon source route completion). A mechanism to verify the feasibility of a source route. From 0003858921@mcimail.com Sun May 8 23:16:00 1994 Return-Path: 0003858921@mcimail.com Received: from gatekeeper.mcimail.com (gatekeeper.mcimail.com [192.147.45.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id AAA29592 for ; Mon, 9 May 1994 00:18:50 -0400 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> Status: O ---------------------------------------------------------------------- 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 Sun May 8 23:16:00 1994 Return-Path: owner-Big-Internet@munnari.OZ.AU Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id EAA00288 for ; Mon, 9 May 1994 04:26:11 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA12996; Mon, 9 May 1994 17:24:09 +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> Status: O ---------------------------------------------------------------------- 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 jallard@microsoft.com Mon May 9 08:25:12 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id LAA02241 for ; Mon, 9 May 1994 11:30:24 -0400 From: jallard@microsoft.com Received: by netmail2.microsoft.com (5.65/25-eef) id AA17296; Mon, 9 May 94 07:31:42 -0700 Message-Id: <9405091431.AA17296@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Mon, 09 May 94 07:31:41 PDT To: brian@dxcoms.cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng requirements & migration from other protocols Date: Mon, 09 May 94 08:25:12 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: O as usual, i agree and disagree. >Yes, you are a bit of a heretic. I would say that in the Unix space it was >less socket, per se, that made TCP/IP, but the BSD implementation, freely >available and used by lots of people and put on lots of workstations, that >did the trick. i agree. >I think that, to date, Winsock has a small impact on the PC market. (Which >is not to say i don't think it is important; i do, in fact, think Winsock >is very important for the PC environment. It is just that Winsock is only >now gaining momentum.) i disagree. windows sockets has had a very real impact in the pc marketplace. prior to windows sockets definition there were but 4 or 5 public domain applications which all included ip functionality since there was no common interface. now there are over 50. there's even a public domain winsock stack. look at the impact that it's had for application-only vendors - rather than only supporting 2 or 3 stacks with "shims", their potential marketplace has expanded to include virtually every microsoft windows desktop running ip. windows sockets plays an important role in the pc marketplace, a role which will grow in significance with v2.0 - an effort kicked off last week. i've recommended ipng as a requirement for this effort, and believe that it will be very important to see ipng embraced by this community. when it's time to roll out ipng, there will be more pc's to worry abt than anyone else (as far as existing systems). let's be sure we're on the same page as the ws2.0 people. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From iesg-request@ietf.cnri.reston.va.us Mon May 9 16:26:36 1994 Return-Path: iesg-request@ietf.cnri.reston.va.us Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA04836 for ; Mon, 9 May 1994 16:28:55 -0400 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25752; 9 May 94 16:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25748; 9 May 94 16:26 EDT Received: from radegond.cmf.nrl.navy.mil by CNRI.Reston.VA.US id aa27578; 9 May 94 16:26 EDT Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id QAA15214; Mon, 9 May 1994 16:26:36 -0400 Date: Mon, 9 May 1994 16:26:36 -0400 Sender: iesg-request@IETF.CNRI.Reston.VA.US From: Allison J Mankin Message-Id: <199405092026.QAA15214@radegond.cmf.nrl.navy.mil> To: iesg@CNRI.Reston.VA.US Subject: Please advise the IPng ADs/Directorate Cc: iab@isi.edu, ipng@radegond.cmf.nrl.navy.mil Status: O Hi, Up until now, we have tried to be careful to separate the IPng Directorate deliberations from the IESG and the IAB, as the former will be voting on the recommendations that result, and the latter will be in the appeals chain for the IESG decision on IPng. When the NomCom picked three of the Directorate for IESG and IAB, we consulted you, the IESG, for advice, and finally concluded that the two IAB folks could stay IFF they would put the Directorate first. We have been asked to invite an IAB member and liaison to the IESG to the 2 day Directorate meeting in Chicago May 19 and 20. Yakov Rekhter is a very important technical contributor to TUBA, but he is also on the IAB and very much involved in IESG activities as the liaison. We would like your opinions about his essentially becoming a guest member of the IPng Directorate. Thanks, Allison and Scott From mankin@cmf.nrl.navy.mil Mon May 9 16:26:36 1994 Return-Path: mankin@cmf.nrl.navy.mil Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with ESMTP id QAA04815 for ; Mon, 9 May 1994 16:27:02 -0400 Received: (from mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id QAA15214; Mon, 9 May 1994 16:26:36 -0400 Date: Mon, 9 May 1994 16:26:36 -0400 From: Allison J Mankin Message-Id: <199405092026.QAA15214@radegond.cmf.nrl.navy.mil> To: iesg@cnri.reston.va.us Subject: Please advise the IPng ADs/Directorate Cc: iab@isi.edu, ipng@cmf.nrl.navy.mil Status: O Hi, Up until now, we have tried to be careful to separate the IPng Directorate deliberations from the IESG and the IAB, as the former will be voting on the recommendations that result, and the latter will be in the appeals chain for the IESG decision on IPng. When the NomCom picked three of the Directorate for IESG and IAB, we consulted you, the IESG, for advice, and finally concluded that the two IAB folks could stay IFF they would put the Directorate first. We have been asked to invite an IAB member and liaison to the IESG to the 2 day Directorate meeting in Chicago May 19 and 20. Yakov Rekhter is a very important technical contributor to TUBA, but he is also on the IAB and very much involved in IESG activities as the liaison. We would like your opinions about his essentially becoming a guest member of the IPng Directorate. Thanks, Allison and Scott From sob@hsdndev.harvard.edu Mon May 9 16:48:11 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id QAA05038 for ; Mon, 9 May 1994 16:48:17 -0400 Date: Mon, 9 May 94 16:48:11 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405092048.AA09334@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: new version of the Unified Routing Req doc, please zap the old one Status: O Unified Routing Requirements for IPng Deborah Estrin and Yakov Rekhter Draft 5/9/94 The following list provides requirements on the IPng from the perspective of the Unified Routing Architecture, as describe in RFC1322. 1. To provide scalable routing, IPng addressing must provide support for topologically significant address assignment. 2. Since it is hard to predict how routing information will be aggregated, the IPng addressing structure should impose as few preconditions as possible on the number of levels in the hierarchy. Specifically, the number of levels must be allowed to be different at different parts in the hierarchy. Further, the levels must not be statically tied to particular parts (fields) in the addressing information. 3. Hop-by-hop forwarding algorithm requires IPng to carry enough information in the Network Layer header to unambiguously determine a particular next hop. Unless mechanisms to compute context-sensitive forwarding tables and provide consistent forwarding are defined, the requirement assumes the presence of full hierarchical addresses. Therefore, IPng packet format must provide efficient determination of the full hierarchical destination address. 4. Hierarchical address assignment should not imply strictly hierarchical routing. Therefore, IPng should carry enough information to provide forwarding along both hierarchical and non-hierarchical routes. 5. The IPng packet header should accommodate a "routing label" or "route ID". This label will be used to identify a particular FIB to be used for packet forwarding by each router. Two types of routing labels should be supported: "strong" and "weak". When a packet carries a "strong" routing label and a router does not have a FIB with this label, the packet is discarded (and an error message is sent back to the source). When a packet carries a "weak" routing label and a router does not have a FIB with this label, the packet should be forwarded via a "default" FIB, i.e., according to the destination address. In addition, the packet should carry an indication that somewhere along the path the desired routing label was unavailable. 6. IPng should provide a source routing mechanism with the following capabilities (i.e. flexibility): - Specification of either individual routers or collections of routers as the entities in the source route. - The option to indicate that two consecutive entities in a source route must share a common subnet in order for the source route to be valid. - Specification of the default behavior when the route to the next entry in the source route is unavailable: - The packet is discarded, or - The source route is ignored and the packet is forwarded based only on the destination address (and the packet header will indicate this action). - A mechanism to verify the feasibility of a source route. Acknowledgements We would like to express our thanks to Tony Li (cisco Systems) for his review and constructive comments. From sob@hsdndev.harvard.edu Mon May 9 23:55:58 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA07373 for ; Mon, 9 May 1994 23:56:02 -0400 Date: Mon, 9 May 94 23:55:58 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405100355.AA23752@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: DECnet Phase IV to Phase V presentation Status: O I have not been able to figure out how to make a postscript file of Bill Duane's very good presentation on the Digital experience during the DECnet Phase IV to Phase V transition. I have put a PowerPoint file of it on hsdndev.harvard.edu in pub/ipng/presentations. If you can read PowerPoint I'd suggest taking a look, it is a very good and useful presentation. Scott From sob@hsdndev.harvard.edu Mon May 9 23:56:38 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id XAA07377 for ; Mon, 9 May 1994 23:56:41 -0400 Date: Mon, 9 May 94 23:56:38 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9405100356.AA23760@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: ps Status: O the file is MIG.PPT (I don't know why, but that is what Bill called it) From J.Crowcroft@cs.ucl.ac.uk Tue May 10 09:09:57 1994 Return-Path: J.Crowcroft@cs.ucl.ac.uk Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id EAA08008 for ; Tue, 10 May 1994 04:10:12 -0400 Message-Id: <199405100810.EAA08008@picard.cmf.nrl.navy.mil> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 10 May 1994 09:09:57 +0100 To: ipng@cmf.nrl.navy.mil Subject: IPng need have no fear of ATM Date: Tue, 10 May 94 09:09:57 +0100 From: Jon Crowcroft Status: O this is a bit orthogonal, but i think its nice to put it to rest: i meant to say in yesterdays teleconf that i had a very interesting set of exchanges with the Xerox people working on Class Y service for ATM (basically, a propoper data service) - they have incontrovertable proof that to optimise revenue and user satisfaction, an ATM net _must_ offer a service without admission control tests - i.e. to all intents & purposes, a connectionless service (at least semantically, if not syntactically...) there's a paper by shenker that relates to this work in the upcoming sigcomm, but i'm not sure of the status of their submissions to the ATM forum: Lixia, could you say if they are available for ftp? jon From iesg-request@ietf.cnri.reston.va.us Tue May 10 08:25:30 1994 Return-Path: iesg-request@ietf.cnri.reston.va.us Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA08722 for ; Tue, 10 May 1994 08:39:37 -0400 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02283; 10 May 94 8:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02279; 10 May 94 8:35 EDT Received: from inet-gw-3.pa.dec.com by CNRI.Reston.VA.US id aa05033; 10 May 94 8:35 EDT Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA02216; Tue, 10 May 94 05:25:47 -0700 Received: by xirtlu.zk3.dec.com; id AA24292; Tue, 10 May 1994 08:25:36 -0400 Message-Id: <9405101225.AA24292@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: iesg@CNRI.Reston.VA.US, iab@isi.edu, ipng@cmf.nrl.navy.mil Subject: Re: Please advise the IPng ADs/Directorate In-Reply-To: Your message of "Mon, 09 May 94 16:26:36 EDT." <199405092026.QAA15214@radegond.cmf.nrl.navy.mil> Date: Tue, 10 May 94 08:25:30 -0400 Sender: iesg-request@IETF.CNRI.Reston.VA.US From: bound@zk3.dec.com X-Mts: smtp Status: O Allison, I would like Yakov to be there for many reasons and mostly as an industry technical leader with vast knowledge which would be very helpful to our process. take care, /jim From bound@zk3.dec.com Tue May 10 08:25:30 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id IAA08697; Tue, 10 May 1994 08:35:10 -0400 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94) id AA02216; Tue, 10 May 94 05:25:47 -0700 Received: by xirtlu.zk3.dec.com; id AA24292; Tue, 10 May 1994 08:25:36 -0400 Message-Id: <9405101225.AA24292@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: iesg@cnri.reston.va.us, iab@isi.edu, ipng@cmf.nrl.navy.mil Subject: Re: Please advise the IPng ADs/Directorate In-Reply-To: Your message of "Mon, 09 May 94 16:26:36 EDT." <199405092026.QAA15214@radegond.cmf.nrl.navy.mil> Date: Tue, 10 May 94 08:25:30 -0400 X-Mts: smtp Status: O Allison, I would like Yakov to be there for many reasons and mostly as an industry technical leader with vast knowledge which would be very helpful to our process. take care, /jim From lixia@parc.xerox.com Tue May 10 06:41:33 1994 Return-Path: lixia@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id JAA09306 for ; Tue, 10 May 1994 09:42:33 -0400 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14459(2)>; Tue, 10 May 1994 06:41:03 PDT Received: by redwing.parc.xerox.com id <57154>; Tue, 10 May 1994 06:41:42 -0700 Date: Tue, 10 May 1994 06:41:33 PDT Sender: Lixia Zhang From: Lixia Zhang To: Jon Crowcroft Cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng need have no fear of ATM In-Reply-To: Your message of Tue, 10 May 1994 01:09:57 -0700 Message-ID: Status: O I really like your subject line of this msg! Yes it is US (IP people) who are driving this Class-Y frontier. > there's a paper by shenker that relates to this work in the upcoming > sigcomm, but i'm not sure of the status of their submissions to the > ATM forum: Lixia, could you say if they are available for ftp? Shenker's paper to sigcomm'94 probably has a slightly diff emphasis (game theory). In anycase I'll ask Scott to make both ftp-able. stay tuned. From jallard@microsoft.com Tue May 10 09:24:31 1994 Return-Path: jallard@microsoft.com Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by picard.cmf.nrl.navy.mil (8.6.8.1/8.6.4) with SMTP id MAA10566 for ; Tue, 10 May 1994 12:29:35 -0400 From: jallard@microsoft.com Received: by netmail2.microsoft.com (5.65/25-eef) id AA01091; Tue, 10 May 94 08:31:01 -0700 Message-Id: <9405101531.AA01091@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 10 May 94 08:31:01 PDT To: ipng@cmf.nrl.navy.mil Subject: Re: Please advise the IPng ADs/Directorate Date: Tue, 10 May 94 09:24:31 Status: O >I would like Yakov to be there for many reasons and mostly as an >industry technical leader with vast knowledge which would be very >helpful to our process. i have a great deal of respect for yakov and do believe that he can add considerable value to our deliberations. however, i must admit that the "special guest" count is starting to alarm me. the difficulty in maintaining a useful, focused, and objective meeting is increasing with the invite lists. remember that this is not a wg, but a review and recommendations gathering. let's try to keep the appropriate balance between cooks and customers. thx _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT"