From Mon Oct 25 09:37:42 1993 Return-Path: Received: from hal.cs.wisc.edu by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA20966; Mon, 25 Oct 93 10:37:44 EDT Date: Mon, 25 Oct 93 09:37:42 -0500 From: mankin@cs.wisc.edu (Allison Mankin) Message-Id: <9310251437.AA08094@hal.cs.wisc.edu> Received: by hal.cs.wisc.edu; Mon, 25 Oct 93 09:37:42 -0500 To: ipng@cmf.nrl.navy.mil Subject: IPNG Directorate Cc: mankin@cs.wisc.edu This is a test of the mailing list ipng@cmf.nrl.navy.mil. Don't delete it though, because I'll take this opportunity to remind you that you should send in your one or two sentence bio. Just send it to mankin@cmf.nrl.navy.mil at this point. From Fri Oct 29 16:09:38 1993 Return-Path: Received: by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA00447; Fri, 29 Oct 93 16:09:38 EDT Date: Fri, 29 Oct 93 16:09:38 EDT From: mankin@cmf.nrl.navy.mil Message-Id: <9310292009.AA00447@picard.cmf.nrl.navy.mil> To: ipng Subject: Dinner on Monday night Cc: mankin Hello: We would like you to meet us at the IETF registration desk at 6:30 PM on Monday evening. Scott and I will make a dinner reservation somewhere (probably right in the hotel). Everyone has confirmed joining up (now for a sinister laugh). Here's the final list: Steve Bellovin, AT&T Jim Bound, DEC Ross Callon, Wellfleet Brian Carpenter, CERN Dave Clark, MIT John Curran, NEARnet Steve Deering, Xerox PARC Dino Farinacci, Cisco Eric Fleischmann, Boeing Paul Francis, Bellcore Daniel Karrenberg, RIPE Mark Knopper, MERIT Greg Minshall, Novell Paul Mockapetris, ARPA Rob Ullman, Lotus Lixia Zhang, Xerox PARC We'll be sending out an announcement of the directorate to IETF before Monday. See you at the IETF. Allison / mankin@cmf.nrl.navy.mil From Sun Oct 31 21:55:54 1993 Return-Path: Received: by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA13727; Sun, 31 Oct 93 21:55:54 EST Date: Sun, 31 Oct 93 21:55:54 EST From: mankin@cmf.nrl.navy.mil Message-Id: <9311010255.AA13727@picard.cmf.nrl.navy.mil> To: ipng Subject: Dinner redux We're still meeting at 6:30 by the IETF registration desk. But since Steve Coya can't join us, please make sure you introduce yourselves to him (those who haven't made his acquaintance), as he is going to take our minutes and otherwise facilitate the directorate. See you tomorrow. Allison and Scott From Mon Nov 1 00:23:37 1993 Return-Path: Received: from radegond.cmf.nrl.navy.mil by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA14222; Mon, 1 Nov 93 00:23:38 EST From: mankin@cmf.nrl.navy.mil Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA13709; Mon, 1 Nov 93 00:23:37 EST Date: Mon, 1 Nov 93 00:23:37 EST Message-Id: <9311010523.AA13709@radegond.cmf.nrl.navy.mil> To: ipng Subject: Reminder about tomorrow AM Hi, For those who didn't hear this before, we request that those directorate members who have arrived in time join us on the stage for the question/discussion part of tomorrow's plenary. As Scott says, that you join us up where the spears are flying. From Sat Nov 6 11:52:08 1993 Return-Path: Received: from inet-gw-1.pa.dec.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA18767; Sat, 6 Nov 93 11:52:23 EST Received: by inet-gw-1.pa.dec.com; id AA06958; Sat, 6 Nov 93 08:52:16 -0800 Received: by xirtlu.zk3.dec.com; id AA00190; Sat, 6 Nov 1993 11:52:14 -0500 Message-Id: <9311061652.AA00190@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Cc: bound@zk3.dec.com Subject: Two Slides for thought coming ... Date: Sat, 06 Nov 93 11:52:08 -0500 From: bound@zk3.dec.com X-Mts: smtp I will send out two slides later this week. One will depict what I call the reality Defacto Host IPv4 Architecture and where code will be effected in all proposals (SIPP, TUBA, CATNIP). The other will be a slide depicting the Server/Client application issue across a local link or a multiprovider link when IPng happens. These two slides are indirect pointers to Host transition, which are indirect pointers to network layer transition for Hosts and Routers. Fun eh !!! Nice meetin ya all who were thar at the IETF down in Houston.... take care, /jim From Tue Nov 9 08:44:27 1993 Return-Path: Received: from dxmint.cern.ch by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA28645; Tue, 9 Nov 93 02:44:31 EST Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18595; Tue, 9 Nov 1993 08:44:29 +0100 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA08890; Tue, 9 Nov 1993 08:44:28 +0100 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9311090744.AA08890@dxcern.cern.ch> Subject: When teleconferences? To: ipng@cmf.nrl.navy.mil Date: Tue, 9 Nov 1993 08:44:27 +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: 318 Hi, Can I request that the precise schedule for IPng teleconferences between now and the end of the year be set up very soon. My agenda is pretty crowded already. [BTW I will be out of the office Nov. 11 through 19] Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 From Tue Nov 9 11:35:23 1993 Return-Path: Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA02862; Tue, 9 Nov 93 14:29:24 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08006; 9 Nov 93 11:35 EST To: ipng@cmf.nrl.navy.mil Cc: lkeiper@CNRI.Reston.VA.US Subject: Checking phone numbers Date: Tue, 09 Nov 93 11:35:23 -0500 From: Steve Coya Message-Id: <9311091135.aa08006@IETF.CNRI.Reston.VA.US> Greetings, These are the phone numbers I have for the IPNG Area Directors and the Area Direcorate. Please check and confirm (or correct). Steve ======================================= Scott Bradner 617-495-3864 Allison Mankin 202-404-7030 Steve Bellovin, AT&T 908-582-5886 Jim Bound, DEC 508-486-5180 Ross Callon, Wellfleet 508-436-3936 Brian Carpenter, CERN +41 22 767 4967 Dave Clark, MIT 617-253-6002 John Curran, NEARnet 617-873-4398 Steve Deering, Xerox PARC 415-812-4839 Dino Farinacci, Cisco 415-688-4696 Eric Fleischman, Boeing 206-957-5334 Paul Francis, Bellcore 201-829-4484 Daniel Karrenberg, RIPE +31 20 592 5065 Mark Knopper, MERIT 313-763-6061 Greg Minshall, Novell 510-975-4507 Paul Mockapetris, ARPA 703-696-2262 Rob Ullmann, Lotus 617-693-1315 Lixia Zhang, Xerox PARC 604-322-0687 From Tue Nov 9 22:30:56 1993 Return-Path: Received: from hsdndev.harvard.edu by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA05225; Tue, 9 Nov 93 22:30:59 EST Date: Tue, 9 Nov 93 22:30:56 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9311100330.AA21232@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: teleconferences I'd like to propose that the IPng teleconferences be on monday at 11:30 eastern US time with the 1st one on Nov 23rd. We have been asked by Steve Coya to not have them during the same week as the IESG teleconferences and there is one of those next week. How many of you would not be able to make a 1.5 to 2 hr call starting at that time? If you can't my 2nd choise would be fridays at the same time, please indicate if you could make that time also. THanks Scott From Tue Nov 9 22:43:11 1993 Return-Path: Received: from hsdndev.harvard.edu by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA05245; Tue, 9 Nov 93 22:43:15 EST Date: Tue, 9 Nov 93 22:43:11 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9311100343.AA22519@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: ps - on teleconferences I'd expect that we would start out with teleconferences every two weeks. The frequency would reduce as we get things established. Scott From Tue Nov 9 23:57:38 1993 Return-Path: Received: from regal.cisco.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA05812; Wed, 10 Nov 93 02:58:13 EST Received: by regal.cisco.com id AA01881 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Tue, 9 Nov 1993 23:57:38 -0800 Date: Tue, 9 Nov 1993 23:57:38 -0800 From: Dino Farinacci Message-Id: <199311100757.AA01881@regal.cisco.com> To: sob@hsdndev.harvard.edu Cc: ipng@cmf.nrl.navy.mil In-Reply-To: Scott Bradner's message of Tue, 9 Nov 93 22:30:56 -0500 <9311100330.AA21232@hsdndev.harvard.edu> Subject: teleconferences >> I'd like to propose that the IPng teleconferences be on monday at 11:30 >> eastern US time with the 1st one on Nov 23rd. We have been asked >> by Steve Coya to not have them during the same week as the IESG >> teleconferences and there is one of those next week. How about a little later for us West coasters. Friday would be better for me - how about 1:30 EST. Dino From Wed Nov 10 09:32:17 1993 Return-Path: Received: from dxmint.cern.ch by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA05897; Wed, 10 Nov 93 03:32:28 EST Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14787; Wed, 10 Nov 1993 09:32:26 +0100 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA15123; Wed, 10 Nov 1993 09:32:20 +0100 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9311100832.AA15123@dxcern.cern.ch> Subject: Re: teleconferences To: ipng@cmf.nrl.navy.mil Date: Wed, 10 Nov 1993 09:32:17 +0100 (MET) In-Reply-To: <199311100757.AA01881@regal.cisco.com> from "Dino Farinacci" at Nov 9, 93 11:57:38 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: 121 Dino, 7.30 pm on Friday evening for the Europeans? You have to be kidding. Devotion to duty has its limits :-) Brian From Wed Nov 10 09:45:14 1993 Return-Path: Received: from ncc.ripe.net by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA05919; Wed, 10 Nov 93 03:45:23 EST Received: from reif.ripe.net by ncc.ripe.net with SMTP id AA03054 (5.65a/NCC-1.12); Wed, 10 Nov 1993 09:45:15 +0100 Message-Id: <9311100845.AA03054@ncc.ripe.net> To: Dino Farinacci Cc: ipng@cmf.nrl.navy.mil Subject: Re: teleconferences In-Reply-To: Your message of Tue, 09 Nov 1993 23:57:38 PST. <199311100757.AA01881@regal.cisco.com> From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Wed, 10 Nov 1993 09:45:14 +0100 Sender: Daniel.Karrenberg@ripe.net E-Mail rule #5: Scheduling meetings by e-mail list does not work. Lets keep the proposed date! It seems to cover the timezones involved very well. For me it will be 5:30 to 7:30 pm. Anything later will be stretching it. For the west coast anything earlier will. Daniel From Wed Nov 10 09:52:26 1993 Return-Path: Received: from nic.near.net by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA07425; Wed, 10 Nov 93 09:52:29 EST Message-Id: <9311101452.AA07425@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa22108; 10 Nov 93 9:52 EST To: Scott Bradner Cc: ipng@cmf.nrl.navy.mil Subject: Re: teleconferences In-Reply-To: Your message of Tue, 09 Nov 1993 22:30:56 -0500. <9311100330.AA21232@hsdndev.harvard.edu> Date: Wed, 10 Nov 1993 09:52:26 -0500 From: John Curran -------- ] From: Scott Bradner ] Subject: teleconferences ] Date: Tue, 9 Nov 93 22:30:56 -0500 ] ] I'd like to propose that the IPng teleconferences be on monday at 11:30 ] eastern US time with the 1st one on Nov 23rd. We have been asked ] by Steve Coya to not have them during the same week as the IESG ] teleconferences and there is one of those next week. ] ] How many of you would not be able to make a 1.5 to 2 hr call starting ] at that time? If you can't my 2nd choise would be fridays at the same time, ] please indicate if you could make that time also. I can make either. I highly recommend an email notice an hour or so before the call, if such can be arranged. /John From Wed Nov 10 09:57:38 1993 Return-Path: Received: from hsdndev.harvard.edu by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA07475; Wed, 10 Nov 93 09:57:45 EST Date: Wed, 10 Nov 93 09:57:38 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9311101457.AA26335@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: slipping digits yes, yes Monday is the 22nd and not the 23rd (oh well, so much for looking like I'm on the ball :-) ) Scott From Wed Nov 10 10:06:16 1993 Return-Path: Received: from hsdndev.harvard.edu by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA07541; Wed, 10 Nov 93 10:06:25 EST Date: Wed, 10 Nov 93 10:06:16 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9311101506.AA26914@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: more teleconference info For those lucky ones that have not had to deal with the IESG teleconferences (contents, not organization, I'm quick to add since Steve is listening) The procedure for these teleconferences is that Steve sends out a notice a few days before the scheduled date asking who will be taking part and requesting the phone number that they will be at. At about the appointed hour the telco will call that number and put you on hold until everyone has been called (well, everyone who claimed that they would be around). The teleconference then starts. In Steve's message there will be a 800 number that you can call and an ID number for the particular teleconference session in case you will be on the road or want to call in later for some reason. (Steve will politely correct any errors in this verbal flow diagram) Scott From Wed Nov 10 07:21:11 1993 Return-Path: Received: from alpha.xerox.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA07687; Wed, 10 Nov 93 10:21:47 EST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12381(2)>; Wed, 10 Nov 1993 07:21:36 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 10 Nov 1993 07:21:26 -0800 To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil Subject: Re: teleconferences In-Reply-To: Your message of "Tue, 09 Nov 93 19:30:56 PST." <9311100330.AA21232@hsdndev.harvard.edu> Date: Wed, 10 Nov 1993 07:21:11 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Nov10.072126pst.12171@skylark.parc.xerox.com> > I'd like to propose that the IPng teleconferences be on monday at 11:30 > eastern US time with the 1st one on Nov 23rd. Scott, The 23rd is a Tuesday; did you mean the 22nd? Mondays or Fridays at 11:30 Eastern Time are fine with me. Steve From Wed Nov 10 10:34:09 1993 Return-Path: Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA08238; Wed, 10 Nov 93 11:34:48 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06971; 10 Nov 93 10:34 EST To: Scott Bradner Cc: ipng@cmf.nrl.navy.mil Subject: Re: more teleconference info In-Reply-To: Your message of "Wed, 10 Nov 93 10:06:16 EST." <9311101506.AA26914@hsdndev.harvard.edu> Date: Wed, 10 Nov 93 10:34:09 -0500 From: Steve Coya Message-Id: <9311101034.aa06971@IETF.CNRI.Reston.VA.US> >> (Steve will politely correct any errors in this verbal flow diagram) No errors, but a clarification. The "real work" in setting up the teleconference with the service will be done by Lois Keiper. The default is that you'll be at your "normal" site (i.e. the numbers I sent in a previous message). With this crowd, though, the default doesn't always work as many of you travel :-) When you know you'll be out of town, send Lois and/or me the phone number that should be used to reach you for that particular teleconference. If unknown, plan to call it and let us know. If you are unable to participate, let us know. This information will keep the operators from calling you at the wrong number. With this message, let me state what I believe the consensus to be: first teleconference will be on Monday, November 22, beginning at 11:30 US Eastern Standard Time. If my math and direction is correct, this translates to 1630 GMT. If my math is incorrect, use the US EST time, not GMT... I'll get it right eventually :-) Steve From Wed Nov 10 10:08:01 1993 Return-Path: Received: from regal.cisco.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA08868; Wed, 10 Nov 93 13:08:07 EST Received: by regal.cisco.com id AA23989 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Wed, 10 Nov 1993 10:08:01 -0800 Date: Wed, 10 Nov 1993 10:08:01 -0800 From: Dino Farinacci Message-Id: <199311101808.AA23989@regal.cisco.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil In-Reply-To: Brian Carpenter CERN-CN's message of Wed, 10 Nov 1993 09:32:17 +0100 (MET) <9311100832.AA15123@dxcern.cern.ch> Subject: teleconferences >> 7.30 pm on Friday evening for the Europeans? You have to be >> kidding. Devotion to duty has its limits :-) 8:30 in the morning stretches those limits too :-) I can work with whatever Scott/Allison decides. Dino From Wed Nov 10 17:53:20 1993 Return-Path: Received: from lobster.wellfleet.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA12745; Wed, 10 Nov 93 17:50:23 EST Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04078; Wed, 10 Nov 93 17:39:16 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA00489; Wed, 10 Nov 93 17:53:20 EST Date: Wed, 10 Nov 93 17:53:20 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9311102253.AA00489@cabernet.wellfleet> To: scoya@CNRI.Reston.VA.US Subject: Re: more teleconference info Cc: ipng@cmf.nrl.navy.mil With this message, let me state what I believe the consensus to be: first teleconference will be on Monday, November 22, beginning at 11:30 US Eastern Standard Time. If my math and direction is correct, this translates to 1630 GMT. If my math is incorrect, use the US EST time, not GMT... I'll get it right eventually :-) Steve; 11:30 Monday morning is fine for me, and the 22nd is also okay. However, I will be out of town next week, and so may be far enough behind in my mail that I won't have read any mail transmitted after this Friday. Ross PS: Generally, Mondays are usually fine for me. Fridays are also okay at 11:30, but are not okay later in the day due to a frequent Friday mid-afternoon meeting. From Wed Nov 10 17:34:26 1993 Return-Path: Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA12824; Wed, 10 Nov 93 18:12:36 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17790; 10 Nov 93 17:34 EST To: ipng@cmf.nrl.navy.mil Subject: International call ins Date: Wed, 10 Nov 93 17:34:26 -0500 From: Steve Coya Message-Id: <9311101734.aa17790@IETF.CNRI.Reston.VA.US> Greetings, I forgot to include the number for calling in to a telechat from outside the US (where 800 numbers fear to tread). The number to call in from outside the US is 516-524-3151 I gotta be honest, I'm not 100% sure that if this number is dialed that the cost shows up on our teleconference invoice. Keep that in mind if you decide to call in from outside the US. Steve From Wed Nov 10 17:52:55 1993 Return-Path: Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA12860; Wed, 10 Nov 93 18:16:55 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18302; 10 Nov 93 17:53 EST To: Ross Callon Cc: ipng@cmf.nrl.navy.mil Subject: Re: more teleconference info In-Reply-To: Your message of "Wed, 10 Nov 93 17:53:20 EST." <9311102253.AA00489@cabernet.wellfleet> Date: Wed, 10 Nov 93 17:52:55 -0500 From: Steve Coya Message-Id: <9311101753.aa18302@IETF.CNRI.Reston.VA.US> Ross, Thanks for responding. I see I misread your last message and thought you'd be at the ATM forum meeting on the 22nd. Now I realize the meeting is next week, but the first IPNG telechat is not. Steve From Thu Nov 11 11:01:35 1993 Return-Path: Received: from atc.boeing.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA15668; Thu, 11 Nov 93 14:00:14 EST Received: by atc.boeing.com (5.57) id AA29286; Thu, 11 Nov 93 11:01:35 -0800 Date: Thu, 11 Nov 93 11:01:35 -0800 From: Eric Fleischman Message-Id: <9311111901.AA29286@atc.boeing.com> To: dino@cisco.com, sob@hsdndev.harvard.edu Subject: Re: teleconferences Cc: ipng@cmf.nrl.navy.mil Should Scott's proposal for a Tuesday (11/23) teleconference not pan out, I would like to observe that his Friday alternative would be 11/26 -- one of the Thanksgiving Holiday days within the USA. That option would definitely not be a good time for me because I will be out of town with my family. Of course, 11/19 or 12/3 would be an entirely different matter. On another subject, do our co-chairs want us to do any particular "homework" in anticipation of our first teleconference? --Eric From Thu Nov 11 15:59:37 1993 Return-Path: Received: from inet-gw-1.pa.dec.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA16067; Thu, 11 Nov 93 16:01:05 EST Received: by inet-gw-1.pa.dec.com; id AA20086; Thu, 11 Nov 93 13:00:51 -0800 Received: by xirtlu.zk3.dec.com; id AA08547; Thu, 11 Nov 1993 15:59:43 -0500 Message-Id: <9311112059.AA08547@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: POSTSCRIPT 2 Slides [Defacto TCP/IP Host & Server/Client Use] Date: Thu, 11 Nov 93 15:59:37 -0500 From: bound@zk3.dec.com X-Mts: smtp %!PS-Adobe-2.1 %%Creator: DECpresent V1.0 %%+Copyright (c) 1990 DIGITAL EQUIPMENT CORPORATION. %%+All Rights Reserved. %%DocumentFonts: (atend) %%EndComments %%BeginProcSet DEC_WRITE 1.07 /DEC_WRITE_dict 150 dict def DEC_WRITE_dict begin/$D save def/$I 0 def/$S 0 def/$C matrix def/$R matrix def/$L matrix def/$E matrix def/pat1{/px exch def/pa 8 array def 0 1 7{/py exch def/pw 4 string def 0 1 3{pw exch px py 1 getinterval putinterval}for pa py pw put}for}def/pat2{/pi exch def/cflag exch def save cflag 1 eq{eoclip}{clip}ifelse newpath{clippath pathbbox}stopped not{/ph exch def/pw exch def/py exch def/px exch def/px px 3072 div floor 3072 mul def/py py 3072 div floor 3072 mul def px py translate/pw pw px sub 3072 div floor 1 add cvi def/ph ph py sub 3072 div floor 1 add cvi def pw 3072 mul ph 3072 mul scale/pw pw 32 mul def/ph ph 32 mul def/px 0 def/py 0 def pw ph pi[pw 0 0 ph 0 0]{pa py get/px px 32 add def px pw ge{/px 0 def/py py 1 add 8 mod def}if}pi type/booleantype eq{imagemask}{image}ifelse}if restore}def/PS{/_op exch def/_np 8 string def 0 1 7{/_ii exch def/num _op _ii get def _np 7 _ii sub num -4 bitshift PX num 15 and 4 bitshift -4 bitshift PX 4 bitshift or put}for _np}def/PX{[15 7 11 3 13 5 9 1 14 6 10 2 12 4 8 0]exch get}def/FR{0.7200 0 $E defaultmatrix dtransform/yres exch def/xres exch def xres dup mul yres dup mul add sqrt}def/SU{/_sf exch def/_sa exch def/_cs exch def/_mm $C currentmatrix def/rm _sa $R rotate def/sm _cs dup $L scale def sm rm _mm _mm concatmatrix _mm concatmatrix pop 1 0 _mm dtransform/y1 exch def/x1 exch def/_vl x1 dup mul y1 dup mul add sqrt def/_fq FR _vl div def/_na y1 x1 atan def _mm 2 get _mm 1 get mul _mm 0 get _mm 3 get mul sub 0 gt{{neg}/_sf load concatprocs/_sf exch def}if _fq _na/_sf load setscreen}def/BO{/_yb exch def/_xb exch def/_bv _bs _yb _bw mul _xb 8 idiv add get def/_mk 1 7 _xb 8 mod sub bitshift def _bv _mk and 0 ne $I 1 eq xor}def/BF{DEC_WRITE_dict begin/_yy exch def/_xx exch def/_xi _xx 1 add 2 div _bp mul cvi def/_yi _yy 1 add 2 div _bp mul cvi def _xi _yi BO{/_nb _nb 1 add def 1}{/_fb _fb 1 add def 0}ifelse end}def/setpattern{/_cz exch def/_bw exch def/_bp exch def/_bs exch PS def/_nb 0 def/_fb 0 def _cz 0/BF load SU{}settransfer _fb _fb _nb add div setgray/$S 1 def}def/invertpattern{$S 0 eq{{1 exch sub}currenttransfer concatprocs settransfer}if}def/invertscreen{/$I 1 def/$S 0 def}def/revertscreen{/$I 0 def}def/setrect{/$h exch def/$w exch def/$y exch def/$x exch def newpath $x $y moveto $w $x add $y lineto $w $x add $h $y add lineto $x $h $y add lineto closepath}def/concatprocs{/_p2 exch cvlit def/_p1 exch cvlit def/_pn _p1 length _p2 length add array def _pn 0 _p1 putinterval _pn _p1 length _p2 putinterval _pn cvx}def/OF/findfont load def/findfont{dup DEC_WRITE_dict exch known{DEC_WRITE_dict exch get}if DEC_WRITE_dict/OF get exec}def mark/ISOLatin1Encoding 8#000 1 8#001{StandardEncoding exch get}for /emdash/endash 8#004 1 8#025{StandardEncoding exch get}for /quotedblleft/quotedblright 8#030 1 8#054{StandardEncoding exch get}for /minus 8#056 1 8#217 {StandardEncoding exch get}for/dotlessi 8#301 1 8#317{StandardEncoding exch get}for/space/exclamdown/cent/sterling/currency/yen/brokenbar/section /dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered /macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph /periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter /onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde /Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave /Iacute/Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde /Odieresis/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave /uacute/ucircumflex/udieresis/yacute/thorn/ydieresis 256 array astore def cleartomark /encodefont{findfont dup maxlength dict begin{1 index/FID ne{def}{pop pop}ifelse}forall/Encoding exch def dup/FontName exch def currentdict definefont end}def/loads{/$/ISOLatin1Encoding load def/&/encodefont load def/*/invertpattern load def/+/revertscreen load def/-/invertscreen load def/:/concatprocs load def/^/setpattern load def/~/pat1 load def/_/pat2 load def/@/setrect load def/A/arcn load def/B/ashow load def/C/curveto load def/D/def load def/E/eofill load def/F/findfont load def/G/setgray load def/H/closepath load def/I/clip load def/J/fill load def/K/kshow load def/L/lineto load def/M/moveto load def/N/newpath load def/O/rotate load def/P/pop load def/R/grestore load def/S/gsave load def/T/translate load def/U/sub load def/V/div load def/W/widthshow load def/X/exch load def/Y/awidthshow load def/a/save load def/c/setlinecap load def/d/setdash load def/e/restore load def/f/setfont load def/g/initclip load def/h/show load def/i/setmiterlimit load def/j/setlinejoin load def/k/stroke load def/l/rlineto load def/m/rmoveto load def/n/currentfont load def/o/scalefont load def/p/currentpoint load def/q/setrgbcolor load def/r/currenttransfer load def/s/scale load def/t/setmatrix load def/u/settransfer load def/w/setlinewidth load def/x/matrix load def/y/currentmatrix load def}def end %%EndProcSet %%EndProlog %%BeginSetup DEC_WRITE_dict begin loads version cvi 23.0 gt { currentdict {dup type /arraytype eq {bind def} {pop pop} ifelse} forall} if 0.0100 0.0100 s %%EndSetup %%Page: 1 1 /$P a D g N 0 79200 T N 30598 -16200 M 50400 0 L 10799 0 L H S 0.9375 G J R N N 3116 -77382 M 1800 -77382 L 2458 -76244 L H S 0.625 G J R N N 8012 -77382 M 6697 -77382 L 7354 -76244 L H S 0.625 G J R N N 10460 -77382 M 9145 -77382 L 9802 -76244 L H S 0.625 G J R N N 15354 -77382 M 14039 -77382 L 14696 -76244 L H S 0.625 G J R N N 20247 -77382 M 18933 -77382 L 19590 -76244 L H S 0.625 G J R N N 25142 -77382 M 23827 -77382 L 24484 -76244 L H S 0.625 G J R N N 30036 -77382 M 28721 -77382 L 29378 -76244 L H S 0.625 G J R N N 34930 -77382 M 33615 -77382 L 34272 -76244 L H S 0.625 G J R N N 39824 -77382 M 38509 -77382 L 39166 -76244 L H S 0.625 G J R N N 44717 -77382 M 43403 -77382 L 44060 -76244 L H S 0.625 G J R N N 47165 -77382 M 45850 -77382 L 46507 -76244 L H S 0.625 G J R N N 49612 -77382 M 48297 -77382 L 48954 -76244 L H S 0.625 G J R N N 52059 -77382 M 50744 -77382 L 51401 -76244 L H S 0.625 G J R N N 54505 -77382 M 53191 -77382 L 53848 -76244 L H S 0.625 G J R N N 56953 -77382 M 55638 -77382 L 56295 -76244 L H S 0.625 G J R N N 59400 -77382 M 58085 -77382 L 58742 -76244 L H S 0.625 G J R N N 2700 -2700 M 58500 -2700 L 58500 -74700 L 2700 -74700 L 2700 -2700 L S 50 w 0 c 0 j 2 i 0.00 G k R N N 5564 -77382 M 4248 -77382 L 4906 -76244 L H S 0.625 G J R N N 12907 -77382 M 11591 -77382 L 12249 -76244 L H S 0.625 G J R N N 17801 -77382 M 16486 -77382 L 17143 -76244 L H S 0.625 G J R N N 22695 -77382 M 21379 -77382 L 22037 -76244 L H S 0.625 G J R N N 27589 -77382 M 26274 -77382 L 26932 -76244 L H S 0.625 G J R N N 32483 -77382 M 31167 -77382 L 31825 -76244 L H S 0.625 G J R N N 37377 -77382 M 36061 -77382 L 36719 -76244 L H S 0.625 G J R N N 42271 -77382 M 40955 -77382 L 41613 -76244 L H S 0.625 G J R N N 28434 -73259 M 32765 -73258 L 30600 -76500 L H S 1.00 G J R S 10 w 0 c 0 j 2 i 0.00 G k R N 28799 -73479 T N 1522 -1050 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1000 o f 0.000000 0.000000 0.000000 q (1) h -28799 73479 T 3247 -75911 M /Helvetica-Bold-ISOLatin1 $ /Helvetica-Bold & P /Helvetica-Bold-ISOLatin1 F 1200 o f (IPng Directorate \255 Jim Bound \(Digital\)) h 4499 -3599 T N 26100 -3000 M 26100 -3000 M 5897 -6500 M 5897 -6500 M n 2.000 o f 0.000000 0.000000 0.000000 q (A Defacto Host TCP/IP Architecture) h -4499 3599 T N S 4789 -71550 50987 55685 @ I N 4789 -15865 T N 11124 -6589 27966 2545 @ S 150 w 0 c 0 j 0.00 G k R N 18387 -5466 M /Helvetica-Bold-ISOLatin1 F 1400 o f (Application Layer) h 11821 -11379 27966 2545 @ S 150 w 0 c 0 j 0.00 G k R N 14139 -10518 M (Socket System Calls and Libraries*) h N S 1854 -17442 7107 9206 @ I N 1854 -8236 T 0 -9206 7107 9206 @ S 0.00 1 X U G J R N S N /ctm_cached x y D 3553 -8046 T 2781 711 s 0 0 1 90 -270 A ctm_cached t H N /ctm_cached x y D 3553 -8046 T 2781 711 s 0 0 1 90 -270 A ctm_cached t S 150 w 0 c 0 j 0.00 G k R R S N /ctm_cached x y D 3476 -1272 T 2781 711 s 0 0 1 90 -270 A ctm_cached t H N /ctm_cached x y D 3476 -1272 T 2781 711 s 0 0 1 90 -270 A ctm_cached t S 150 w 0 c 0 j 0.00 G k R R N 850 -1347 M 927 -7634 L S 150 w 0 c 0 j 0.00 G k R N N 6103 -1272 M 6180 -7634 L S 150 w 0 c 0 j 0.00 G k R N 1981 -4153 M /Helvetica-Bold-ISOLatin1 F 1400 o f (BIND) h 1981 -5425 M (DNS) h S N /ctm_cached x y D 3632 -8083 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R R 11665 -20210 27966 2545 @ S 150 w 0 c 0 j 0.00 G k R N 20626 -19273 M (Socket Layer*) h N 9193 -13774 M 59330 -13924 L S 150 w 0 c 0 j [400 400] 0 d 0.00 G k R N 20009 -13061 M (User Space) h 19623 -15757 M (Kernel Space) h N 155 -13774 M 1777 -13774 L S 150 w 0 c 0 j [400 400] 0 d 0.00 G k R N 11665 -24476 27966 2545 @ S 150 w 0 c 0 j 0.00 G k R N 16190 -23614 M (Transport Layer \(TCP/UDP\)) h N S 42182 -27058 7107 9206 @ I N 42182 -17852 T 0 -9206 7107 9206 @ S 0.00 1 X U G J R N S N /ctm_cached x y D 3553 -8046 T 2781 711 s 0 0 1 90 -270 A ctm_cached t H N /ctm_cached x y D 3553 -8046 T 2781 711 s 0 0 1 90 -270 A ctm_cached t S 150 w 0 c 0 j 0.00 G k R R S N /ctm_cached x y D 3476 -1272 T 2781 711 s 0 0 1 90 -270 A ctm_cached t H N /ctm_cached x y D 3476 -1272 T 2781 711 s 0 0 1 90 -270 A ctm_cached t S 150 w 0 c 0 j 0.00 G k R R N 850 -1347 M 927 -7634 L S 150 w 0 c 0 j 0.00 G k R N N 6103 -1272 M 6180 -7634 L S 150 w 0 c 0 j 0.00 G k R N 900 -3479 M /Helvetica-Bold-ISOLatin1 F 1400 o f (Queues) h 899 -5875 M (Control) h 2677 -4677 M (&) h 1208 -6923 M (Blocks) h S N /ctm_cached x y D 3244 -8121 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R R 39061 -15157 M (AF_INET) h 44854 -16504 M (Domain) h 32186 -16505 M ( Communications ) h 11588 -42887 27966 15119 @ S 150 w 0 c 0 j 0.00 G k R N 11556 -27356 M (Network Layer) h 12516 -40117 11356 10927 @ S 200 w 0 c 0 j 0.00 G k R N 25031 -33232 5948 2993 @ S 200 w 0 c 0 j 0.00 G k R N 32409 -33233 5948 2993 @ S 200 w 0 c 0 j 0.00 G k R N 16254 -34467 M (IPv4) h 26527 -32221 M (ICMP) h 33480 -32146 M (IGMP) h 24916 -41092 5948 5014 @ S 200 w 0 c 0 j 0.00 G k R N 32563 -41091 5948 5088 @ S 200 w 0 c 0 j 0.00 G k R N 25907 -37535 M (RIP) h 26680 -38881 M (&) h 25598 -40228 M (OSPF) h 33367 -37461 M (EGP) h 34216 -38807 M (&) h 33366 -40079 M (BGP) h 24690 -29677 M (Discovery) h 32193 -29676 M (Multicast) h 28329 -35364 M (Routing) h 11743 -47827 27966 2545 @ S 150 w 0 c 0 j 0.00 G k R N 11634 -44869 M (Link Dependent Layer) h 12638 -46664 M (ARP, RARP, InARP, NCPs, Addr Tables) h 11898 -53515 27966 2545 @ S 150 w 0 c 0 j 0.00 G k R N 11951 -50483 M (Data Link Layer) h 15196 -52728 M (Ethernet, FDDI, ATM, HIPPI, PPP) h N S 41873 -41502 7107 9206 @ I N 41873 -32296 T 0 -9206 7107 9206 @ S 0.00 1 X U G J R N S N /ctm_cached x y D 3553 -8046 T 2781 711 s 0 0 1 90 -270 A ctm_cached t H N /ctm_cached x y D 3553 -8046 T 2781 711 s 0 0 1 90 -270 A ctm_cached t S 150 w 0 c 0 j 0.00 G k R R S N /ctm_cached x y D 3476 -1272 T 2781 711 s 0 0 1 90 -270 A ctm_cached t H N /ctm_cached x y D 3476 -1272 T 2781 711 s 0 0 1 90 -270 A ctm_cached t S 150 w 0 c 0 j 0.00 G k R R N 850 -1347 M 927 -7634 L S 150 w 0 c 0 j 0.00 G k R N N 6103 -1272 M 6180 -7634 L S 150 w 0 c 0 j 0.00 G k R N 977 -4377 M /Helvetica-Bold-ISOLatin1 F 1400 o f (Routing) h 1208 -5650 M (Tables) h S N /ctm_cached x y D 3707 -6400 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R R N S 1933 -50109 7107 9206 @ I N 1933 -40903 T 0 -9206 7107 9206 @ S 0.00 1 X U G J R N S N /ctm_cached x y D 3553 -8046 T 2781 711 s 0 0 1 90 -270 A ctm_cached t H S 150 w 0 c 0 j 0.00 G k R R S N /ctm_cached x y D 3476 -1272 T 2781 711 s 0 0 1 90 -270 A ctm_cached t H S 150 w 0 c 0 j 0.00 G k R R N 850 -1347 M 927 -7634 L S 150 w 0 c 0 j 0.00 G k R N N 6103 -1272 M 6180 -7634 L S 150 w 0 c 0 j 0.00 G k R N 1981 -4153 M /Helvetica-Bold-ISOLatin1 F 1400 o f (ARP) h 1517 -5575 M (Cache) h S N /ctm_cached x y D 3553 -8121 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R R 1203 -55496 M n 0.714 o f (Could be Streams Architecture too ) h 619 -55161 M n 1.200 o f (*) h S N /ctm_cached x y D 38550 -10630 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 38318 -19088 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 37469 -23429 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 22559 -38996 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 30207 -32560 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 30130 -40193 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 37237 -40118 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 38859 -47228 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 37314 -32409 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 45348 -14970 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 38087 -52392 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R S N /ctm_cached x y D 1314 -1125 T 236 358 s 0 0 1 90 -270 A ctm_cached t S 0.00 G J R H S 100 w 0 c 0 j 2 i 0.00 G k R R 2241 -1724 M n 1.167 o f (= Change because of IPng) h 50 -55635 50887 55585 @ S 100 w 0 c 0 j 2 i [400 400] 0 d 0.00 G k R R showpage $P e %%Page: 2 2 /$P a D g N 0 79200 T N 30598 -16200 M 50400 0 L 10799 0 L H S 0.9375 G J R N N 3116 -77382 M 1800 -77382 L 2458 -76244 L H S 0.625 G J R N N 8012 -77382 M 6697 -77382 L 7354 -76244 L H S 0.625 G J R N N 10460 -77382 M 9145 -77382 L 9802 -76244 L H S 0.625 G J R N N 15354 -77382 M 14039 -77382 L 14696 -76244 L H S 0.625 G J R N N 20247 -77382 M 18933 -77382 L 19590 -76244 L H S 0.625 G J R N N 25142 -77382 M 23827 -77382 L 24484 -76244 L H S 0.625 G J R N N 30036 -77382 M 28721 -77382 L 29378 -76244 L H S 0.625 G J R N N 34930 -77382 M 33615 -77382 L 34272 -76244 L H S 0.625 G J R N N 39824 -77382 M 38509 -77382 L 39166 -76244 L H S 0.625 G J R N N 44717 -77382 M 43403 -77382 L 44060 -76244 L H S 0.625 G J R N N 47165 -77382 M 45850 -77382 L 46507 -76244 L H S 0.625 G J R N N 49612 -77382 M 48297 -77382 L 48954 -76244 L H S 0.625 G J R N N 52059 -77382 M 50744 -77382 L 51401 -76244 L H S 0.625 G J R N N 54505 -77382 M 53191 -77382 L 53848 -76244 L H S 0.625 G J R N N 56953 -77382 M 55638 -77382 L 56295 -76244 L H S 0.625 G J R N N 59400 -77382 M 58085 -77382 L 58742 -76244 L H S 0.625 G J R N N 2700 -2700 M 58500 -2700 L 58500 -74700 L 2700 -74700 L 2700 -2700 L S 50 w 0 c 0 j 2 i 0.00 G k R N N 5564 -77382 M 4248 -77382 L 4906 -76244 L H S 0.625 G J R N N 12907 -77382 M 11591 -77382 L 12249 -76244 L H S 0.625 G J R N N 17801 -77382 M 16486 -77382 L 17143 -76244 L H S 0.625 G J R N N 22695 -77382 M 21379 -77382 L 22037 -76244 L H S 0.625 G J R N N 27589 -77382 M 26274 -77382 L 26932 -76244 L H S 0.625 G J R N N 32483 -77382 M 31167 -77382 L 31825 -76244 L H S 0.625 G J R N N 37377 -77382 M 36061 -77382 L 36719 -76244 L H S 0.625 G J R N N 42271 -77382 M 40955 -77382 L 41613 -76244 L H S 0.625 G J R N N 28434 -73259 M 32765 -73258 L 30600 -76500 L H S 1.00 G J R S 10 w 0 c 0 j 2 i 0.00 G k R N 28799 -73479 T N 1522 -1050 M /Helvetica-ISOLatin1 $ /Helvetica & P /Helvetica-ISOLatin1 F 1000 o f 0.000000 0.000000 0.000000 q (2) h -28799 73479 T 3247 -75911 M /Helvetica-Bold-ISOLatin1 $ /Helvetica-Bold & P /Helvetica-Bold-ISOLatin1 F 1200 o f (IPng Directorate \255 Jim Bound \(Digital\)) h 4499 -3599 T N 26100 -3000 M 26100 -3000 M 3227 -6500 M 3227 -6500 M n 2.000 o f 0.000000 0.000000 0.000000 q (Server/Client Network Layer Application) h 15162 -9100 M (VIew IPng and IPv4) h 300 -10370 M -4499 3599 T N S 6797 -71624 51452 56581 @ I N 6797 -15043 T N N 3246 -18560 M 48902 -18186 L S 400 w 0 c 0 j 0.00 G k R N N 13752 -18186 M 13675 -12198 L S 200 w 0 c 0 j 0.00 G k R N 8266 -12197 10738 8531 @ S 200 w 0 c 0 j 0.00 G k R N 8421 -3142 M /Helvetica-Bold-ISOLatin1 F 1400 o f (Server) h 9117 -5462 M n 0.857 o f ( Application) h N 8499 -8157 M 18774 -8007 L S 100 w 0 c 0 j 2 i 0.00 G k R N 9272 -6436 M (Network API) h 9272 -7558 M (Interface) h N 13289 -8306 M 13443 -11974 L S 100 w 0 c 0 j 2 i 0.00 G k R N 9116 -9504 M (IPv4) h 14371 -9429 M (IPng) h 3168 -18111 M (Local LAN) h 5641 -25446 4712 4117 @ S 0.00 G J R S 100 w 0 c 0 j 2 i 0.00 G k R N 4945 -26568 M (Client IPv4) h N 35422 -16051 M 35345 -18074 L S 0.00 G J R S 200 w 0 c 0 j 0.00 G k R N N 40906 -18372 M 41139 -21591 L S 0.00 G J R S 200 w 0 c 0 j 0.00 G k R N N 7610 -18972 M 7843 -22191 L S 0.00 G J R S 200 w 0 c 0 j 0.00 G k R N 33492 -16128 4712 4117 @ S 0.00 G J R S 100 w 0 c 0 j 2 i 0.00 G k R N 40134 -25858 4712 4117 @ S /patt33 D patt33 ~ 1 1 _ R S 100 w 0 c 0 j 2 i 0.00 G k R N 32702 -11637 M (Client IPv4) h 39963 -26980 M (Client IPng) h 14409 -11489 3321 1273 @ S patt33 ~ 1 1 _ R S 100 w 0 c 0 j 2 i 0.00 G k R N 9233 -11563 3321 1273 @ S 0.00 G J R S 100 w 0 c 0 j 2 i 0.00 G k R N 20164 -30759 7493 4940 @ S 200 w 0 c 0 j 0.00 G k R N 22172 -27916 M (IPng) h 21244 -29711 M (Traslator) h 19431 -25185 3321 1273 @ S 0.00 G J R S 100 w 0 c 0 j 2 i 0.00 G k R N 25225 -25259 3321 1273 @ S patt33 ~ 1 1 _ R S 100 w 0 c 0 j 2 i 0.00 G k R N 23332 -24997 M (or) h N 20241 -28140 M 15683 -28140 L S 400 w 0 c 0 j 0.00 G k R N N 15915 -28140 M 16070 -18560 L S 400 w 0 c 0 j 0.00 G k R N N 16456 -32481 M 14988 -32631 L 11821 -32930 L 10971 -33080 L 9735 -33529 L 9271 -33828 L 8808 -34128 L 8808 -34726 L 8885 -35550 L 8962 -36373 L 9040 -37196 L 9040 -38019 L 9117 -39441 L 9426 -40040 L 9812 -40414 L 10353 -40564 L 10971 -40864 L 11589 -41163 L 12207 -41238 L 13366 -41462 L 13984 -41462 L 15297 -41462 L 16765 -41462 L 17615 -41462 L 18851 -41387 L 19932 -41238 L 21400 -41163 L 21941 -41163 L 22250 -41687 L 22173 -42360 L 22018 -42884 L 21786 -43333 L 21709 -43857 L 21941 -44456 L 22327 -44905 L 22791 -45354 L 23254 -45803 L 23718 -46252 L 24259 -46552 L 24954 -46776 L 25804 -46776 L 26653 -46776 L 27503 -46776 L 28971 -46776 L 29821 -46701 L 30671 -46627 L 31520 -46552 L 32370 -46552 L 32834 -46252 L 33374 -45953 L 33683 -45504 L 33915 -44681 L 34301 -44231 L 34456 -43408 L 34688 -42809 L 35074 -42211 L 35383 -41762 L 35847 -41313 L 36387 -40938 L 37237 -40789 L 38087 -40714 L 39555 -40564 L 40404 -40414 L 41254 -40265 L 42722 -40115 L 43804 -39816 L 44267 -39516 L 45117 -39292 L 45812 -38618 L 45658 -37645 L 45349 -37196 L 45117 -36373 L 43649 -35475 L 42181 -35325 L 41332 -35250 L 29666 -36298 L 29280 -36672 L 28739 -36597 L 28662 -35999 L 28585 -35475 L 28585 -34876 L 28044 -34502 L 27194 -34427 L 26653 -34352 L 26190 -34128 L 26113 -33604 L 26035 -33080 L 25340 -33080 L 23254 -33080 L 21168 -33229 L 20628 -33229 L 20010 -32930 L 19546 -32706 L 18928 -32556 L 18310 -32481 L 17692 -32481 L 17151 -32481 L 16611 -32406 L H S 400 w 0 c 0 j 0.00 G k R N N 24799 -30834 M 24027 -32930 L S 400 w 0 c 0 j 0.00 G k R N 17616 -39366 M (IPng and IPv4 Internet Routing Domain) h N 16997 -41536 M 11049 -47450 L S 400 w 0 c 0 j 0.00 G k R N N 11125 -47450 M 11280 -49995 L S 400 w 0 c 0 j 0.00 G k R N N 2783 -50070 M 21324 -50220 L S 400 w 0 c 0 j 0.00 G k R N 3207 -53625 4712 2320 @ S 0.00 G J R S 100 w 0 c 0 j 2 i 0.00 G k R N 14255 -53849 4712 2320 @ S 0.00 G J R S 100 w 0 c 0 j 2 i 0.00 G k R N 33182 -53999 4712 2320 @ S patt33 ~ 1 1 _ R S 100 w 0 c 0 j 2 i 0.00 G k R N 42143 -53849 4712 2320 @ S patt33 ~ 1 1 _ R S 100 w 0 c 0 j 2 i 0.00 G k R N N 30516 -50369 M 50293 -50519 L S 400 w 0 c 0 j 0.00 G k R N N 36927 -40639 M 42413 -45354 L S 400 w 0 c 0 j 0.00 G k R N N 42336 -45504 M 36851 -50219 L S 400 w 0 c 0 j 0.00 G k R N N 4945 -50294 M 5023 -51417 L S 200 w 0 c 0 j 0.00 G k R N N 16379 -50294 M 16379 -51567 L S 200 w 0 c 0 j 0.00 G k R N N 34997 -50594 M 35229 -51492 L S 200 w 0 c 0 j 0.00 G k R N N 44267 -50594 M 44344 -51267 L S 200 w 0 c 0 j 0.00 G k R N 2727 -54598 M (Client IPv4) h 13156 -54747 M (Client IPv4) h 32480 -54822 M (Client IPng) h 41751 -54897 M (Client IPng) h 772 -49022 M (IPv4 Only LAN) h 41215 -49360 M (IPng Only LAN) h 21786 -5164 M n 1.167 o f (The application Server will need to know) h 21786 -6436 M (whether within AF_INET: client = IPv4 or) h 21786 -7708 M (client = IPng [this means AF_INET is using) h 21786 -8980 M (AF_IPNG protocol address and name ) h 21786 -10252 M (service].) h 100 -56481 51252 56381 @ S 200 w 0 c 0 j 0.00 G k R R showpage $P e %%Trailer $D restore end % DEC_WRITE_dict %%Pages: 2 %%DocumentFonts: Helvetica %%+ Helvetica-Bold From Thu Nov 11 17:23:21 1993 Return-Path: Received: from hsdndev.harvard.edu by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA16350; Thu, 11 Nov 93 17:23:27 EST Date: Thu, 11 Nov 93 17:23:21 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9311112223.AA24670@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: slides Jim, You trying to tell us that there is hardly any effect observed by changing the IP? :-) Your slides do raise a real question. Just what parts of this picture do we have to deal with? If we choose proposal X, are we saying 'go ye and modify BGP' or does this group also have to detail the changes required? (or demand that the proposal working groups do that before the selection?) It does seem to be a bit much to ask to have each proposal detail the changes required in all areas but if one proposal would require more extensive changes than another, should that be included in the selection process? Scott From Thu Nov 11 14:50:54 1993 Return-Path: Received: from atc.boeing.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA16430; Thu, 11 Nov 93 17:49:32 EST Received: by atc.boeing.com (5.57) id AA22142; Thu, 11 Nov 93 14:50:54 -0800 Date: Thu, 11 Nov 93 14:50:54 -0800 From: Eric Fleischman Message-Id: <9311112250.AA22142@atc.boeing.com> To: ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: slides Dear Jim and Scott, I am sorry to be a neanderthal, but our local postscript facilities leave much room for improvement. For this reason I was wondering if you might be able to re-send your charts in normal ASCII? Please note that I am making this request without knowing what type of data the charts contained so it may well be non-ASCII-able. Sincerely yours, --Eric Fleischman From Thu Nov 11 17:54:33 1993 Return-Path: Received: from hsdndev.harvard.edu by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA16448; Thu, 11 Nov 93 17:54:43 EST Date: Thu, 11 Nov 93 17:54:33 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9311112254.AA25670@hsdndev.harvard.edu> To: ericf@atc.boeing.com Subject: Re: slides Cc: ipng@cmf.nrl.navy.mil Eric, The slides (which I just printed out) are graphics only, not much text. - I could fax them to you sometime in the next few days if you send me your fax number. Scott From Thu Nov 11 17:59:13 1993 Return-Path: Received: from hsdndev.harvard.edu by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA16463; Thu, 11 Nov 93 17:59:21 EST Date: Thu, 11 Nov 93 17:59:13 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9311112259.AA25852@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: fyi J. Allard of Microsoft has joined the IPng directorate. He should be added to the mailing list soon. Scott From Thu Nov 11 22:31:49 1993 Return-Path: Received: from nic.near.net by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA17154; Thu, 11 Nov 93 22:31:52 EST Message-Id: <9311120331.AA17154@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa25769; 11 Nov 93 22:31 EST To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: POSTSCRIPT 2 Slides [Defacto TCP/IP Host & Server/Client Use] In-Reply-To: Your message of Thu, 11 Nov 1993 15:59:37 -0500. <9311112059.AA08547@xirtlu.zk3.dec.com> Date: Thu, 11 Nov 1993 22:31:49 -0500 From: John Curran -------- From: bound@zk3.dec.com Subject: POSTSCRIPT 2 Slides [Defacto TCP/IP Host & Server/Client Use] Date: Thu, 11 Nov 93 15:59:37 -0500 Jim, Interesting slides. You indicate that the Data Link Layer modules will be affected by IPng. Is there some change you see other than the protocol selector value being used? Also, you state on page 2 that the server will need to use AF_IPNG protocol address and name service. Do you mean an "IPNG name service"? I have been presuming that the current IPv4 DNS service would suffice in this role, although additional record types would be needed. Am I misinterpeting the slide? /John From Thu Nov 11 23:34:10 1993 Return-Path: Received: from inet-gw-1.pa.dec.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA17306; Thu, 11 Nov 93 23:34:19 EST Received: by inet-gw-1.pa.dec.com; id AA08623; Thu, 11 Nov 93 20:34:17 -0800 Received: by xirtlu.zk3.dec.com; id AA22845; Thu, 11 Nov 1993 23:34:16 -0500 Message-Id: <9311120434.AA22845@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: RE: slides Date: Thu, 11 Nov 93 23:34:10 -0500 From: bound@zk3.dec.com X-Mts: smtp Scott, *********************** Jim, You trying to tell us that there is hardly any effect observed by changing the IP? :-) ********************* On the contrary. The 'dark dots' at each point on the host require changes to the existing manner in which it is architected and coded because of IPng. An IPng proposal X will cause =< the changes noted in the Host slide. ****************************** Your slides do raise a real question. Just what parts of this picture do we have to deal with? If we choose proposal X, are we saying 'go ye and modify BGP' or does this group also have to detail the changes required? (or demand that the proposal working groups do that before the selection?) *************************** I think we need to deal at the framework level with each rectangle and each cylinder in the Host Slide. What we don't want is 'hand waving' that it will all work. From a framework perspective (without all the details) for each piece is as follows: 1) What cohesion is lost in each part and what cohesion is lost in the whole: a) For User Space b) For kernel Space 2) What rectangles or cylinders will completely be replaced and what is the effect on the whole. 3) What is the cost of changing to proposal X for the Defacto TCP/IP Host. The integration of those frameworks is the second test. I think the proposals should tell us exactly what has to change in BGP because of Proposal X's solution for any TCP/IP protocol suite member. This was a requirement in RFC 1380 and I thought a good one. It helps me as a developer determine my engineering ramp-up and costs to move to IPng. **************************** It does seem to be a bit much to ask to have each proposal detail the changes required in all areas but if one proposal would require more extensive changes than another, should that be included in the selection process? Scott *************************** I don't think its a bit much at all. I think any proposal should have gone into enough detail after the core architecture is defined so the IETF can see it in its pristine form. Yes its a lot of work. But changing The network layer of the TCP/IP protocol suite has a lot of ramifications, which is the key point of this slide. I think IPng is too critical for us not to enter into much detail or we could make a huge cost mistake. At the end of the day its the details are what will differ is my guess between all proposals as they migrate to fix the big issues for IPng, before the March IETF. What is good is that this slide was meant to create these kind of questions. /jim From Thu Nov 11 23:47:13 1993 Return-Path: Received: from inet-gw-1.pa.dec.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA17336; Thu, 11 Nov 93 23:47:26 EST Received: by inet-gw-1.pa.dec.com; id AA09926; Thu, 11 Nov 93 20:47:21 -0800 Received: by xirtlu.zk3.dec.com; id AA23389; Thu, 11 Nov 1993 23:47:19 -0500 Message-Id: <9311120447.AA23389@xirtlu.zk3.dec.com> To: John Curran Cc: ipng@cmf.nrl.navy.mil Subject: Re: POSTSCRIPT 2 Slides [Defacto TCP/IP Host & Server/Client Use] In-Reply-To: Your message of "Thu, 11 Nov 93 22:31:49 EST." <9311120331.AA17154@picard.cmf.nrl.navy.mil> Date: Thu, 11 Nov 93 23:47:13 -0500 From: bound@zk3.dec.com X-Mts: smtp John, ****************************** Jim, Interesting slides. You indicate that the Data Link Layer modules will be affected by IPng. Is there some change you see other than the protocol selector value being used? ********************************* I was thinking the MTU values may be set there if they are less than what the MTU minimum is for IPng. They may also play a bigger role in what I am hearing people talk about called temporary autoconfiguration. But hopefully this will all be limited. *********************************** Also, you state on page 2 that the server will need to use AF_IPNG protocol address and name service. Do you mean an "IPNG name service"? I have been presuming that the current IPv4 DNS service would suffice in this role, although additional record types would be needed. Am I misinterpeting the slide? ********************************* Record types is correct. I was just looking at IBMs latest MPTN document and I think that influenced me when I wrote that sentence. MPTN is flexible about the name service used. A key point to note is that most OSI stacks in most kernels are implemented not using AF_INET but actually use a different sa_family like AF_ISO or AF_OSI (which is OK with BSD). But, because of transition and the Server/Client issue portrayed its more efficient and more code can be reused if one sticks to AF_INET and then use protocol switches to a dual or hybrid stack below the Transport. /jim From Fri Nov 12 09:57:48 1993 Return-Path: Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA19004; Fri, 12 Nov 93 10:14:57 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04415; 12 Nov 93 9:57 EST To: ipng@cmf.nrl.navy.mil, jallard@microsoft.com Subject: Once again Date: Fri, 12 Nov 93 09:57:48 -0500 From: Steve Coya Message-Id: <9311120957.aa04415@IETF.CNRI.Reston.VA.US> Greetings, It appears that not everyone has received all the IPNG messages pertaining to phone numbers, so here we go again. The "x" at the end of the line notes those folks who have confirmed that I have the correct phone numbers. No x means no confirm (but not necessarily the wrong number :-). For your records, if you are to be calling in to a teleconference from somewhere in the US, the number to dial is: 800-232-1234 For those calling from outside the US, the number is: 516-424-3151 And finally, Lois Keiper (lkeiper@cnri.reston.va.us) is the person who will be setting up the teleconferences, and the person to contact with updated information on a particular week's teleconference. Contact me if there are any questions. Steve =========================================================================== Scott Bradner 617-495-3864 x Allison Mankin 202-404-7030 x Jim Allard 206-822-8080 x Steve Bellovin, AT&T 908-582-5886 x Jim Bound, DEC 508-486-5180 Ross Callon, Wellfleet 508-436-3936 x Brian Carpenter, CERN +41 22 767 4967 x Dave Clark, MIT 617-253-6002 6003 John Curran, NEARnet 617-873-4398 Steve Deering, Xerox PARC 415-812-4839 x Dino Farinacci, Cisco 415-688-4696 x Eric Fleischman, Boeing 206-957-5334 x Paul Francis, Bellcore 201-829-4484 Daniel Karrenberg, RIPE +31 20 592 5065 x or (+31 20 592 5089) Mark Knopper, MERIT 313-763-6061 x Greg Minshall, Novell 510-975-4507 Paul Mockapetris, ARPA 703-696-2262 Rob Ullmann, Lotus 617-693-1315 Lixia Zhang, Xerox PARC 415-812-4415 x From Fri Nov 12 10:49:28 1993 Return-Path: Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA19504; Fri, 12 Nov 93 11:30:33 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06157; 12 Nov 93 10:49 EST To: ipng@cmf.nrl.navy.mil, jallard@microsoft.com Cc: lkeiper@CNRI.Reston.VA.US Subject: First Teleconference Date: Fri, 12 Nov 93 10:49:28 -0500 From: Steve Coya Message-Id: <9311121049.aa06157@IETF.CNRI.Reston.VA.US> The first teleconference will be on Monday, November 22, beginning at 11:30 US Eastern Standard Time. The default is that you'll be at your "normal" site. When you know you'll be out of town (for this and future teleconferences), send Lois the phone number that should be used to reach you for that particular teleconference. If unknown, plan to call in and let us know. If you are unable to participate, let us know. This information will keep the operators from calling you at the wrong number, or calling you when you are not participating. For your records, if you are to be calling in to a teleconference from somewhere in the US, the number to dial is: 800-232-1234 For those calling from outside the US, the number is: 516-424-3151 If calling Lois or me, our phone number is: 703-620-8990 From Fri Nov 12 14:46:50 1993 Return-Path: Received: from radegond.cmf.nrl.navy.mil by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA20593; Fri, 12 Nov 93 14:46:50 EST From: mankin@cmf.nrl.navy.mil Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA11358; Fri, 12 Nov 93 14:46:50 EST Date: Fri, 12 Nov 93 14:46:50 EST Message-Id: <9311121946.AA11358@radegond.cmf.nrl.navy.mil> To: ipng Subject: The IPng Mailing List Hi, The directorate at last being fully assembled, here is the list that constitutes ipng@cmf.nrl.navy.mil: ariel@world.std.com bound@zk3.dec.com brian@dxcern.cern.ch callon@wellfleet.com daniel@ripe.net ddc@lcs.mit.edu deering@parc.xerox.com dino@cisco.com ericf@atc.boeing.com francis@thumper.bellcore.com jallard@microsoft.com jcurran@nic.near.net lixia@parc.xerox.com mankin@cmf.nrl.navy.mil mak@merit.edu minshall@wc.novell.com pvm@arpa.mil scoya@cnri.reston.va.us smb@research.att.com sob@harvard.edu From Fri Nov 12 15:29:30 1993 Received: from merit.edu by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA21029; Fri, 12 Nov 93 15:52:48 EST Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA28306; Fri, 12 Nov 93 15:29:31 -0500 Message-Id: <9311122029.AA28306@merit.edu> To: bound@zk3.dec.com Cc: John Curran , ipng@cmf.nrl.navy.mil Subject: Re: POSTSCRIPT 2 Slides [Defacto TCP/IP Host & Server/Client Use] In-Reply-To: Your message of "Thu, 11 Nov 1993 23:47:13 EST." <9311120447.AA23389@xirtlu.zk3.dec.com> Date: Fri, 12 Nov 1993 15:29:30 -0500 From: Mark Knopper I took a look at the slides and as far as the "defacto architecture" slide, I wonder what is the value of the dot indicating that a change is necessary for IPng. You show everything affected except the application layer. However it seems clear (e.g. FOOBAR, ftp over big addresses) that many applications will need changes as well. One can quibble about some of the components such as exterior routing protocols (egp and bgp) in the sense that IDRP is useful for any of the IPng approaches and will not really need any changes that aren't already being made. Regarding the "server/client network layer application" slide, you show the IPng translator with single stack IPng approach. This is not what is viewed for TUBA at least, where all IPng hosts for the indefinite future will need to be dual stack. Therefore in general no translator will be needed, except in cases where re-use of IPv4 address space is needed. The dual stack transition will require tunnelling such as EON to allow IPng to be carried across IPv4-only domains, and in the future when we have IPng-only domains the converse encapsulation (some have called it EIN) may be needed. Perhaps more to the point of these slides, I very much agree that a general purpose API with relatively transparent naming architecture is necessary for IPng hosts. Mark > From: bound@zk3.dec.com > To: John Curran > CC: ipng@cmf.nrl.navy.mil > John, > > ****************************** > Jim, > > Interesting slides. You indicate that the Data Link Layer modules > will be affected by IPng. Is there some change you see other than the > protocol selector value being used? > ********************************* > > I was thinking the MTU values may be set there if they are less than what > the MTU minimum is for IPng. They may also play a bigger role in > what I am hearing people talk about called temporary autoconfiguration. > But hopefully this will all be limited. > > *********************************** > Also, you state on page 2 that the server will need to use AF_IPNG > protocol address and name service. Do you mean an "IPNG name service"? > I have been presuming that the current IPv4 DNS service would suffice > in this role, although additional record types would be needed. Am I > misinterpeting the slide? > ********************************* > > Record types is correct. I was just looking at IBMs latest MPTN > document and I think that influenced me when I wrote that sentence. > MPTN is flexible about the name service used. > > A key point to note is that most OSI stacks in most kernels are > implemented not using AF_INET but actually use a different sa_family > like AF_ISO or AF_OSI (which is OK with BSD). But, because of > transition and the Server/Client issue portrayed its more efficient and > more code can be reused if one sticks to AF_INET and then use protocol > switches to a dual or hybrid stack below the Transport. > > /jim > From Fri Nov 12 15:34:18 1993 Received: from merit.edu by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA21060; Fri, 12 Nov 93 15:56:14 EST Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA29095; Fri, 12 Nov 93 15:34:19 -0500 Message-Id: <9311122034.AA29095@merit.edu> To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: slides In-Reply-To: Your message of "Thu, 11 Nov 1993 23:34:10 EST." <9311120434.AA22845@xirtlu.zk3.dec.com> Date: Fri, 12 Nov 1993 15:34:18 -0500 From: Mark Knopper I agree with Jim on most of these points. It is necessary to evaluate the changes in each module for all of the IPng approaches. However I've always felt that all of the approaches have some key features in common. One could look at each module for the generic IPng meaning different-network-layer-addressing, without assuming any other changes to the IP functionality, and say what changes are needed. The answers to this will be helpful to all of the IPng approaches, and will help the various working groups focus on what is unique to their approach. Mark > From: bound@zk3.dec.com > To: ipng@cmf.nrl.navy.mil > Scott, > > *********************** > Jim, > You trying to tell us that there is hardly any effect observed > by changing the IP? :-) > ********************* > > On the contrary. The 'dark dots' at each point on the host require > changes to the existing manner in which it is architected and coded > because of IPng. An IPng proposal X will cause =< the changes noted in > the Host slide. > > ****************************** > Your slides do raise a real question. Just what parts of this > picture do we have to deal with? If we choose proposal X, are we > saying 'go ye and modify BGP' or does this group also have to detail > the changes required? (or demand that the proposal working groups do that > before the selection?) > *************************** > > I think we need to deal at the framework level with each rectangle and > each cylinder in the Host Slide. What we don't want is 'hand waving' > that it will all work. From a framework perspective (without all the > details) for each piece is as follows: > > 1) What cohesion is lost in each part and what cohesion is lost in > the whole: > a) For User Space > b) For kernel Space > > 2) What rectangles or cylinders will completely be replaced and > what is the effect on the whole. > > 3) What is the cost of changing to proposal X for the Defacto TCP/IP > Host. > > The integration of those frameworks is the second test. > > I think the proposals should tell us exactly what has to change in BGP > because of Proposal X's solution for any TCP/IP protocol suite member. > This was a requirement in RFC 1380 and I thought a good one. It helps > me as a developer determine my engineering ramp-up and costs to move to > IPng. > > **************************** > It does seem to be a bit much to ask to have each proposal > detail the changes required in all areas but if one proposal would > require more extensive changes than another, should that be included > in the selection process? > > Scott > *************************** > > I don't think its a bit much at all. I think any proposal should have > gone into enough detail after the core architecture is defined so the > IETF can see it in its pristine form. Yes its a lot of work. But > changing The network layer of the TCP/IP protocol suite has a lot of > ramifications, which is the key point of this slide. I think IPng is > too critical for us not to enter into much detail or we could make a > huge cost mistake. > > At the end of the day its the details are what will differ is my guess > between all proposals as they migrate to fix the big issues for IPng, > before the March IETF. > > What is good is that this slide was meant to create these kind of > questions. > > /jim > > From Fri Nov 12 21:10:46 1993 Return-Path: Received: from ftp.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA22261; Fri, 12 Nov 93 21:11:11 EST Received: from solensky.fenway.ftp.com by ftp.com via PCMAIL with DMSP id AA21282; Fri, 12 Nov 93 21:10:46 -0500 Date: Fri, 12 Nov 93 21:10:46 -0500 Message-Id: <9311130210.AA21282@ftp.com> To: ipng@cmf.nrl.navy.mil Subject: 'ipv4-ale' list From: solensky@ftp.com (Frank T Solensky) Sender: solensky@ftp.com Repository: babyoil.ftp.com Originating-Client: fenway.ftp.com At Scott's recommendation, the IPng directorate members have been added to the "ipv4-ale" list. You can disregard the note sent to the IETF and big-internet lists earlier today.. -- Frank From Fri Nov 12 21:50:08 1993 Return-Path: Received: from inet-gw-1.pa.dec.com by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA22344; Fri, 12 Nov 93 21:55:39 EST Received: by inet-gw-1.pa.dec.com; id AA20350; Fri, 12 Nov 93 18:50:16 -0800 Received: by xirtlu.zk3.dec.com; id AA17246; Fri, 12 Nov 1993 21:50:15 -0500 Message-Id: <9311130250.AA17246@xirtlu.zk3.dec.com> To: Mark Knopper Cc: bound@zk3.dec.com, John Curran , ipng@cmf.nrl.navy.mil Subject: Re: POSTSCRIPT 2 Slides [Defacto TCP/IP Host & Server/Client Use] In-Reply-To: Your message of "Fri, 12 Nov 93 15:29:30 EST." <9311122029.AA28306@merit.edu> Date: Fri, 12 Nov 93 21:50:08 -0500 From: bound@zk3.dec.com X-Mts: smtp Mark, ********************** I took a look at the slides and as far as the "defacto architecture" slide, I wonder what is the value of the dot indicating that a change is necessary for IPng. You show everything affected except the application layer. However it seems clear (e.g. FOOBAR, ftp over big addresses) that many applications will need changes as well. One can quibble about some of the components such as exterior routing protocols (egp and bgp) in the sense that IDRP is useful for any of the IPng approaches and will not really need any changes that aren't already being made. ************************* Why I called it defacto is that is about as close as I could get it based on a BSD UNIX base. I checked this out with our PC and VMS folks too. But it isn't that clean really, but good for suggestion. A key point is that IPng often is stated to change the network layer. But the network layer as I am picturing it is not just IPv4 RFC 791. Good point on the application layer. I view FTP, TELNET, and Network /Systems Management as a different order of magnitude and requirement. I was thinking more like PATRAN for Finite Element Analysis, Sybase Transaction Database, or Powerpoint on NT...etc. Probably could break application out into its own slide if we wanted to. I figured if a proposal does a good job with the Sockets or other APIs then hopefully binary compatibility can be maintained or at least just a recompile (source portability). One thing Dave P., Tracy M., and I did before the last TUBA WG meeting for transition at Houston was use the IPAE applications that have address problems as a beginning. Yes I could have put interior routing protocols but then I would have made an assumption that hosts won't do exterior routing. Good point. ********************************* Regarding the "server/client network layer application" slide, you show the IPng translator with single stack IPng approach. This is not what is viewed for TUBA at least, where all IPng hosts for the indefinite future will need to be dual stack. Therefore in general no translator will be needed, except in cases where re-use of IPv4 address space is needed. The dual stack transition will require tunnelling such as EON to allow IPng to be carried across IPv4-only domains, and in the future when we have IPng-only domains the converse encapsulation (some have called it EIN) may be needed. ********************************** I should have put the little black and striped boxes in the Translator box. I mean't dual stack (and really multiprotocol stack). ******************* Perhaps more to the point of these slides, I very much agree that a general purpose API with relatively transparent naming architecture is necessary for IPng hosts. Mark ***************** To all I am not wedded to these slides. My key point is that there is a bunch of work to do on a Host for any IPng proposal. I have figured out the work at about 10,000 feet for both TUBA and SIPP and need more CATNIP awareness and will have that view too. But, I am sure new drafts will be coming out adding to the knowledge base of IPngs', over the next month. In addition the complications for the server is as Mark stated partially an API problem, but mostly a network kernel problem for Hosts or Hosts that will be built as Translators or Encapsulation mechanisms for IPng. thanks Mark for the input, /jim From Fri Nov 19 15:21:00 1993 Return-Path: Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA28868; Fri, 19 Nov 93 15:59:38 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11627; 19 Nov 93 15:21 EST To: ipng@cmf.nrl.navy.mil Subject: Agenda for the November 22 IPNG Directorate Teleconference Date: Fri, 19 Nov 93 15:21:00 -0500 From: Steve Coya Message-Id: <9311191521.aa11627@IETF.CNRI.Reston.VA.US> IPNG Directorate Agenda for the November 22, 1993 Teleconference 1. Administrivia o Roll Call o Agenda bashing 2. General Items o Telechat procedures (identify before speaking) o Dealing with the Press o Review directorate role 3. Definition (and membership) of external review panel clarify objectives/instructions for the review panel 4. White Papers o Outline to be used by authors on white papers o Identification/solicition of white paper authors o Process for white paper review 5. Working Groups (solicitation of chairs, draft charters, etc.) o Requirements WG o Transition, coexistence, and testing WG 6. Roundtable 7. Date of next teleconference From scoya@CNRI.Reston.VA.US Mon Nov 29 13:43:56 1993 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.4/8.6.4) with SMTP id NAA17232 for ; Mon, 29 Nov 1993 13:45:49 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02179; 29 Nov 93 13:43 EST To: ipng@cmf.nrl.navy.mil Subject: DRAFT minutes from November 22 Telechat Date: Mon, 29 Nov 93 13:43:56 -0500 From: Steve Coya Message-ID: <9311291343.aa02179@IETF.CNRI.Reston.VA.US> DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * IPNG Directorate Teleconference November 22, 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 Dave Clark / MIT John Curran / NEARnet Steve Deering /Xerox PARC Dino Farinacci / Cisco Eric Fleischman / Boeing Paul Francis / Bellcore Daniel Karrenberg / RIPE Mark Knopper / MERIT Greg Minshall / Novell Paul Mockapetris / ISI Rob Ullmann / Lotus Lixia Zhang / Xerox PARC Regrets ------- J Allard / Mircosoft 1. With respect to dealing with the press, it was requested that all queries about the IPNG directorate and the IPNG process should be directed to the Co-Area Directors, but that queries about individual IPng proposals should be dealt with by the authors of those proposals 2. Allison initiated a discussion on the roles of the IPNG Directorate. Essentially, the Directorate members represent a wide variety of groups and backgrounds. The Directorate will be performing the white paper reviews, review of the various proposal documents, work with the co-directors in the establishment of working groups under the area, participate in big-internet discussions, do outreach when offered the chance, review working group documents, etc. 3. There was a lot of discussion on the external review panel, including the proposal that Dave Clark function as the handler for the ExRP. There were a number of comments and some concerns raised during the discussion. It was decided to continue the discussion on the mailing list preparatory to discussion of membership of the ExRP at the next teleconference. 4. It was decided that the draft white paper outline should be discussed via e-mail, particularly to see if there were some areas that had not been explicitly mentioned. It was suggested that earlier works, such as the Selection Criteria I-D, might be reviewed with the purpose of identifying additional criteria to be used when reviewing white papers. The direcotorate also agreed to seperate the original white paper concept into two parts: 1) white papers that represent the views or concers that an author wishes to bring to the attention of the IETF and the IPng process 2) overview documents of the IPng proposals - it was agreed that the directorate was not ready to define the form of these overviews Initially, the document reviews will focus on clarity and self-completeness. Directorate comments will be returned to the authors. It was proposed that when a revision is ready, a notification is to be sent to Steve Coya who will then notify the Directorate. 5. The Directorate discussed the establishment of a Requirements WG and a Transition and Coexistence, including Testing (TACIT) Working Group. Allison and Scott asked for suggestions for people that might chair these new working groups. Frank Kastenholtz was mentioned as a chair of the Requirements WG though there was some discussion on getting a co-chair 6. Next teleconference will be December 6, 1993 From brian@dxcoms.cern.ch Tue Nov 30 08:16:45 1993 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.4/8.6.4) with SMTP id CAA20446 for ; Tue, 30 Nov 1993 02:17:19 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA05595; Tue, 30 Nov 1993 08:16:47 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA08751; Tue, 30 Nov 1993 08:16:46 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9311300716.AA08751@dxcoms.cern.ch> Subject: What's missing from WP outline To: ipng@cmf.nrl.navy.mil Date: Tue, 30 Nov 1993 08:16:45 +0100 (MET) Reply-To: Brian.Carpenter@cern.ch X-Comment: I have changed hosts to dxcoms.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: 796 Just to start the discussion, here are the headings from the Criteria draft which are absent in the draft White Paper outline This is the list I scribbled in real time during the teleconference, but I think it is complete. Topological flexibility Robustness Supports all hardware media Supports datagram service Unique naming of end-systems Open access to standards Supports multicast Accounting Sufficient performance Acceptable cost Opinion: these are all perfectly reasonable things for people to prioritise in requirements/concerns white papers, and for proposers to respond to. Maybe I'm naive, but I've never fully understood why the Criteria draft made people so nervous. Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From scoya@CNRI.Reston.VA.US Tue Nov 30 09:47:04 1993 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.4/8.6.4) with SMTP id JAA21687 for ; Tue, 30 Nov 1993 09:48:44 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04252; 30 Nov 93 9:47 EST To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: What's missing from WP outline In-reply-to: Your message of "Tue, 30 Nov 93 08:16:45 +0100." <9311300716.AA08751@dxcoms.cern.ch> Date: Tue, 30 Nov 93 09:47:04 -0500 From: Steve Coya Message-ID: <9311300947.aa04252@IETF.CNRI.Reston.VA.US> Brian, >> Opinion: these are all perfectly reasonable things for >> people to prioritise in requirements/concerns white papers, >> and for proposers to respond to. Maybe I'm naive, but I've never >> fully understood why the Criteria draft made people so nervous. Folks were originally nervous wrt what criteria would be identified, and what weight/priority would be assigned. This was especially true from the operations folks who had to implement whatever was decided. Based on comments made to me during IETF meetings (especially following the Selection Criteria BOF in DC-Nov '92), folks are now more frustrated than nervous. The criteria were reasonable, but also a little too basic in nature (gee, they forgot to list a requirement that this work over multiple networks). The pre-bof (July 92) desire was that the selection criteria would be used to pair down the candidates, but the actual criteria was such that all candidates met it (or would meet it soon), and the community was still stuck with no clear winner. Steve From ericf@atc.boeing.com Tue Nov 30 09:09:03 1993 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.4/8.6.4) with SMTP id MAA23416 for ; Tue, 30 Nov 1993 12:07:36 -0500 Received: by atc.boeing.com (5.57) id AA28657; Tue, 30 Nov 93 09:09:03 -0800 Date: Tue, 30 Nov 93 09:09:03 -0800 From: Eric Fleischman Message-Id: <9311301709.AA28657@atc.boeing.com> To: ipng@cmf.nrl.navy.mil Subject: Re: What's missing frow WP outline This note seeks to supplement the list of IPng requirements which Brian Carpenter has just enumerated. The Boeing Company believes that the following are also IPng requirements. Thus, I suggest that the following be added to the list of requirements: 1) The IPng approach must permit users to slowly transition to IPng in a piecemeal fashion. 2) The IPng approach must not hinder technological advances to be implemented (e.g., mobile hosts, multimedia applications, real-time applications). 3) The IPng approach must have "self-defining network" (i.e., plug-and-play) capabilities. That is, large installations require device portability in which one may readily move devices within one's coproprate network and have them autoconfigure, autoaddress, and autoregister without explicit human administration overhead at the new location -- assuming that the security criteria of the new location have been met. In addition to these requirements, The Boeing Company also has the following desire (hope) for IPng: We desire that IPng should assist in the formation of greater synergy between Internet Standards and International standards. (Note: this may be accomplished in a variety of ways, including having Internet Standards become International Standards.) Thank you for your attention on these matters. Sincerely yours, --Eric Fleischman From bound@zk3.dec.com Tue Nov 30 12:32:29 1993 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.4/8.6.4) with SMTP id MAA24672 for ; Tue, 30 Nov 1993 12:36:45 -0500 From: bound@zk3.dec.com Received: by inet-gw-1.pa.dec.com; id AA26670; Tue, 30 Nov 93 09:32:37 -0800 Received: by xirtlu.zk3.dec.com; id AA15712; Tue, 30 Nov 1993 12:32:35 -0500 Message-Id: <9311301732.AA15712@xirtlu.zk3.dec.com> To: Steve Coya Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: What's missing from WP outline In-Reply-To: Your message of "Tue, 30 Nov 93 09:47:04 EST." <9311300947.aa04252@IETF.CNRI.Reston.VA.US> Date: Tue, 30 Nov 93 12:32:29 -0500 X-Mts: smtp The BOF results I have did try to apply MUSTs etc.. But I think this is premature until more analysis is done for requirements. In addition to just specifying topics like Multicast and Performance we need to look at those requirements across the IPng spectrum. For example Performance and Mutlicast effect the following: a) algorithm for routing and its performance. b) datalink performance. c) network layer service transfer to the transport. d) access to the service at the transport by the application. e) how the proposals fields accomodate data structure efficiency. We have to continue to look at the whole picture and not just pieces. Functionality which performs outstanding at a point in the IPng spectrum may perform so poorly in another spectrum or create so much cost that its gain in one spectrum may be lost and actually decrease performance customers have today with TCP/IP. Note I consider cost as one attribute of performance. In addition each proposal will create a set of changes which will be apparent eventually during this process. The extent of the changes will be in my mind the rate of reality for the end users to adopt and use the new IPng. That is why its very important we check each piece against the IPng spectrum. Here is the spectrum I see as food for thought: 1. Router Code Base (router person can expand). 2. Host Code Base (using my IPng slides sent out previously). 3. Autoconfiguration and Autoregistration (system discovery/DNS). 4. Network Management Software. 5. TCP/IP Application Utility Software (ftp, telnet, etc). 6. Application Software (Sybase, PATRAN, Wordperfect, etc.). 7. Transition effect and points of encapsulation and translation. 8. Effect on well known TCP/IP network tools. 9. Portability of User interfaces - This needs some explanation. One of the good things about the TCP/IP protocol suite is that if I sit down at a Digital, Sun, HP, IBM, or PC machine that supports TCP/IP rlogin, finger, ftp, telnet, rcp, dump, etc. are all the same commands regardless of the vendor who implemented the suite. IPng should not break this defacto experience for the end user. Costs include: 1. Performance at each point in the spectrum. 2. Porting to the new IPng in the spectrum. 3. Training the provider and end user community. A point to remember about Transition is this: If the applications a customer uses are not available epediently on a new stack they will not move to that new stack at the desk top, which extends the transition period. Many variables effect how to make applications run on a new stack. It is not just a case of absorbing new or altered fields at the transport and then all becomes transparent. That is why when a new stack shows up in the market it takes much time to move the applications to that new stack. If it were just a matter of changing the communicatins domain at the applications interface to the transport it would be simple. But it involves name space strategy, routing strategy, and how the new stack is implemented in the systems. Hopefully the IPng solution will not have all these problems as IPng is supposed to replace parts of the network layer and then modify the existing infrastructure which is not exactly like replacing the entire TCP/IP stack. Anyway here are some other requirements to consider: Protocol changes in IPv4 Hosts and Routers. Protocols removed in IPv4 Hosts and Routers and replaced. Protocols that must coexist with existing IPv4 protocols and how. Security and Authentication changes. DNS changes. Network Management changes. Changes required to operations (ping, netstat, tracroute, tcpview, etc.) Changes required to operational and administrative procedures. The impact and changes to the existing set of TCP/IP protocols should be described (TCP, UDP, ICMP, RIP, OSPF, SNMP, etc..). Implementation experience on Hosts and Routers. Performance impact to IPv4 systems. Effect on User Community. Deployment Plan Description. Future Evolution. Effect to existing application base moving to new IPng protocol. Effect to transport interfaces because of new IPng protocol. What are your points of translation. What are your points of encapsulation. /jim From ariel@world.std.com Tue Nov 30 21:30:06 1993 Return-Path: ariel@world.std.com Received: from world.std.com (ariel@world.std.com [192.74.137.5]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id VAA27249 for ; Tue, 30 Nov 1993 21:31:23 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA09145; Tue, 30 Nov 1993 21:30:06 -0500 Date: Tue, 30 Nov 1993 21:30:06 -0500 From: ariel@world.std.com (Robert L Ullmann) Message-Id: <199312010230.AA09145@world.std.com> To: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: What's missing from WP outline Hi, Brian: I'll suggest a few reasons why "the Criteria draft made people so nervous"; or, more precisely, why that sort of thing does: 1) have you ever seen a US DoD RFP (U.S.A. Dept of Defence Request for Proposal :-) written by someone who already knows which vendor and which product they want? It is real easy to write an RFP that only one vendor can possibly meet. 2) In part, proposals (such as SIPP/CATNIP/TUBA) differ because they have differing view of what the problem really is, and where the solution set lies; straight comparison is difficult. The comment I like (and I'm sorry I don't remember the source, it was said about some other thing entirely) is that it is like comparing apples and oranges based on shinyness and redness. (Suppose one of the criteria were: must provide compatibilty with IPX?) 3) most serious: there is a tendency to attempt to require things that in fact _no_one_ knows how to do. I.e. "must provide security". Right. Just a little bit underspecified. Or "must do multicasting", when multicasting is in the throes of early experimentation, and it isn't clear that applying the same term to broadcast-LAN-type-MAC multicast, and wide-area-spanning tree-type is valid at all. (SIPP certainly thinks they ought to be done the same way, and are really important; I think they are utterly disjoint, and not terribly important anyway.) My point is that it it easy to write a "criteria" that is horribly ill-defined, or even impossible, and still sound plausible. Best Regards, Robert From bound@zk3.dec.com Wed Dec 1 00:00:53 1993 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.4/8.6.4) with SMTP id AAA27716 for ; Wed, 1 Dec 1993 00:08:36 -0500 From: bound@zk3.dec.com Received: by inet-gw-1.pa.dec.com; id AA25136; Tue, 30 Nov 93 21:01:04 -0800 Received: by xirtlu.zk3.dec.com; id AA00553; Wed, 1 Dec 1993 00:00:59 -0500 Message-Id: <9312010500.AA00553@xirtlu.zk3.dec.com> To: ariel@world.std.com (Robert L Ullmann) Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: What's missing from WP outline In-Reply-To: Your message of "Tue, 30 Nov 93 21:30:06 EST." <199312010230.AA09145@world.std.com> Date: Wed, 01 Dec 93 00:00:53 -0500 X-Mts: smtp Rob, I see your point about the shinniest apple. But with your comments what do you suggest? Both the BOF and 1380 criteria I believe was not biased but did miss key points already brought up within the Directorate. The objective of IPng at this point is to extend the address space, provide efficiency within the routing infrastructure, address new technology emerging, and keep the TCP/IP protocol suite going (so to speak). I think 1380 was concerned with keeping the TCP/IP suite going, and the next BOF by Craig absorbed that need and added pieces such as presented by Brian. Both completely missed Eric's input and some of mine just sent. Hence, I deduce its up to us to establish a process and talk it out. Regarding Multicast I have customers asking for 1119 right now or we don't get the bid so its real. Plus several of our Technical Directors and others in the Internet community watched the U.S. Congress on Multicast so it seems pretty real to me. I know the problems as I sit next to our IP multicast engineer, but it is a requirement. I also think TUBA and SIPP are heading in the same direction with different magnitudes effecting direction on the vectors regarding requirements they will address. Its important to scope out effect to the TCP/IP suite and maybe we can look at this like a hunting license. You only get to hunt certain creatures at different points of times and some creatures you can never hunt anytime of the year. The IPng requirements maybe cannot be determined until specific evolutionary stages are accomplished. But, we need to at least get a list of what is important. /jim From mankin@radegond.cmf.nrl.navy.mil Wed Dec 1 01:00:50 1993 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.4/8.6.4) with SMTP id BAA27896 for ; Wed, 1 Dec 1993 01:00:52 -0500 Received: from localhost by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA17251; Wed, 1 Dec 93 01:00:51 EST Message-Id: <9312010600.AA17251@radegond.cmf.nrl.navy.mil> To: ipng@radegond.cmf.nrl.navy.mil Subject: Re: 2nd try - White Paper solicitation and descriptions Date: Wed, 01 Dec 1993 01:00:50 -0500 From: Allison J Mankin From: Allison & Scott Hi, IPng Directorate, Enclosed is another draft of the IPng document soliciting white papers. This document will be reformatted to follow RFC standard format and then submitted to the RFC editor as an Informational RFC after we are done with it. ---------------------------------------------------------------------------------------- ---- IPng White Paper Solicitation 1. Introduction The IP: next generation (IPng) area in the IETF is soliciting white papers on topics related to the IPng requirements and selection criteria. All interested parties are invited to submit white papers detailing any specific requirements that they feel an IPng must fulfill or any factors that they feel might sway the IPng selection. An example of the former might be a submission by a representative of a utility company detailing the scaling and addressing features which would be required to service future inclusion of utility meters on the network. An example of the other case might be a paper outlining the potential effect on an IPng of some sections of the future network connectivity being provided via wireless networks. All white papers will reviewed in a process described below. As a result of these reviews, each white paper will receive the focused attention of the IPng directorate and the community. The white papers will be used as resource materials by the IPng Area working groups, the directorate, the external review board and the area directors, during the selection process. 2. Document Review Process All submitted documents will first be reviewed for clarity by members of the IPng directorate and the external review board. This review may produce suggestions to the author on areas of the document where there may be some confusion as to the meaning. Authors are urged to consider any such suggestions as constructive and to reexamine their text in light of the suggestions. A separate technical review will then be done of the white paper. This review will be conducted within the context of the document. That is, the review will still not make value judgments on the white papers, but will assess technical feasibility. This review may also produce suggestions to the author. The document will be submitted as an Internet-Draft after these reviews have been completed and after whatever (if any) revisions that the author decides to make. After a suitable period of time these documents will be submitted as informational RFCs. These documents will comprise a part of the historical record of the IPng process. ****** question to directorate - if the author refuses to make changes to fix what is seen as a technical problem, should we issue a companion document detailing whatever technical issues the review process has found? ********* 3. Document Format Requirements All white papers must follow the format requirements listed in RFC1111 and must not exceed 10 pages in length. (The relevant portion of RFC1111 is included as Appendix A.) They should not include the 'status of memo' or 'distribution' sections; these will be added when the documents are posted as Internet Drafts. The reference version of the document must be in ASCII as is current practice with all RFCs. A PostScript version of the document may be submitted in addition to the ASCII version. 4.Outline for IPng Requirements and Concerns White Papers This section details the white paper outline to be followed by someone who would like to express an opinion about the various factors involved in the IPng definition and selection process. Any or all of the following topics can be addressed. Since these documents will be used as resource material by the various IPng working groups, the directorate, the external review board and the area directors, they should be well-focused and give specific pointers to data supporting their points. At this time, we are not accepting white papers that evaluate specific IPng proposals. This type of document will be accepted after the various proposal documents are deemed to be clear, complete, and technically feasible. Each white paper should begin with an executive summary of the important points of the document. This executive summary should not exceed 1/2 page in length. The white paper should then address the issue or issues that the author feels should be understood during the IPng process. The total document should not exceed 10 pages in length. An author may submit more than one white paper if he or she feels that the level of detailed discussion on each topic warrants it. 4.1 Topics In past discussions the following issues have been raised as relevant to the IPng selection process. This list is in no particular order. Any or all of these issues may be addressed as well as any other topic that the author feels is germane. scaling - What is a reasonable estimate for the scale of the future data networking environment? The current common wisdom is that IPng should be able to deal with a billion nodes. timescale - What are reasonable time estimates for the IPng selection, development and deployment process or what should the timeframe requirements be? This topic is being evaluated by the ALE working group and a copy of all white papers that express opinions about these topics will be forwarded to that group. transition and deployment - Transition from the current version to IPng will be a complex and difficult process. What are the issues that should be considered The TACIT working group will be discussing these issues and a copy of all white papers that express opinions about these topics will be forwarded to that group. security - What level and type of security will be required in the future network environment? What features should be in an IPng to facilitate security? configuration, administration and operation - As networks get larger and more complex, the day to day operational aspects become ever more important. What should an IPng include or avoid in order to minimize the effect on the network operators? mobile hosts - How important is the proliferation of mobile hosts to the IPng selection process? To what extent should features be included in an IPng to assist in dealing with mobile hosts? flows and resource reservation - As the data networks begin to get used for an increasing number of time-critical processes, what are the requirements or concerns that affect how IPng should facilitate the use of resource reservations or flows? policy based routing - How important is policy based routing? If it is important, what types of policies will be used? What requirements do routing policies and potential future global architectures of the Internet bring to IPng? How do policy requirements interact with scaling? topological flexibility - datagram service - Existing IP service is "best effort" and based on hop-by-hop routed datagrams. What requirements for this paradigm influence the IPng selection? support of all communication media robustness and fault tolerance - To the extent that the Internet built from IPv4 has been highly fault tolerant, what are ways that IPng may avoid inadvertant decrease in the robustness (since some things may work despite flaws that we do not understand well). Comment on any other ways in which this requirement may affect the IPng. technology pull - Are there technologies that will pull the Internet in a way that should influence IPng? Can specific strategies be developed to encompass these? action items - suggested charges to the directorate, working groups or others to support the concerns or gather more information needed for a decision. Appendix Formatting Rules (from RFC1111) 2a. ASCII Format Rules: The character codes are ASCII. Each page must be limited to 58 lines followed by a form feed on a line by itself. Each line must be limited to 72 characters followed by carriage return and line feed. No overstriking (or underlining) is allowed. These "height" and "width" constraints include any headers, footers, page numbers, or left side indenting. Do not fill the text with extra spaces to provide a straight right margin. Do not do hyphenation of words at the right margin. Do not use footnotes. If such notes are necessary, put them at the end of a section, or at the end of the document. Use single spaced text within a paragraph, and one blank line between paragraphs. From bound@zk3.dec.com Wed Dec 1 01:28:23 1993 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.4/8.6.4) with SMTP id BAA27988 for ; Wed, 1 Dec 1993 01:31:06 -0500 From: bound@zk3.dec.com Received: by inet-gw-1.pa.dec.com; id AA01573; Tue, 30 Nov 93 22:28:33 -0800 Received: by xirtlu.zk3.dec.com; id AA01996; Wed, 1 Dec 1993 01:28:30 -0500 Message-Id: <9312010628.AA01996@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: ipng@radegond.cmf.nrl.navy.mil Subject: Re: 2nd try - White Paper solicitation and descriptions In-Reply-To: Your message of "Wed, 01 Dec 93 01:00:50 EST." <9312010600.AA17251@radegond.cmf.nrl.navy.mil> Date: Wed, 01 Dec 93 01:28:23 -0500 X-Mts: smtp Regarding companion documents for those papers with outstanding Directorate Technical problems I think is quite fair. Where we have to be careful is to keep our focus on each paper for clarity and technical feasibility in the words. For example if someone states: ...and use the low order bit of the address mask to denote a piggy back address is enclosed. If they did not explain what the low order bit is or how the next address is piggy backed clarity is not there. If they did not state why piggy backing is important as a technical requirement then the technical feasibility of the words are not valid with a premise. But we should not question the value of piggy backing at this point. [We might later though ???]. I completely made this up but trying to come up with example. ??? /jim From bound@zk3.dec.com Wed Dec 1 01:28:23 1993 Return-Path: bound@zk3.dec.com Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id BAA27987 for ; Wed, 1 Dec 1993 01:31:06 -0500 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA17317; Wed, 1 Dec 93 01:31:04 EST Received: by inet-gw-1.pa.dec.com; id AA01573; Tue, 30 Nov 93 22:28:33 -0800 Received: by xirtlu.zk3.dec.com; id AA01996; Wed, 1 Dec 1993 01:28:30 -0500 Message-Id: <9312010628.AA01996@xirtlu.zk3.dec.com> To: Allison J Mankin Cc: ipng@radegond.cmf.nrl.navy.mil Subject: Re: 2nd try - White Paper solicitation and descriptions In-Reply-To: Your message of "Wed, 01 Dec 93 01:00:50 EST." <9312010600.AA17251@radegond.cmf.nrl.navy.mil> Date: Wed, 01 Dec 93 01:28:23 -0500 X-Mts: smtp Regarding companion documents for those papers with outstanding Directorate Technical problems I think is quite fair. Where we have to be careful is to keep our focus on each paper for clarity and technical feasibility in the words. For example if someone states: ...and use the low order bit of the address mask to denote a piggy back address is enclosed. If they did not explain what the low order bit is or how the next address is piggy backed clarity is not there. If they did not state why piggy backing is important as a technical requirement then the technical feasibility of the words are not valid with a premise. But we should not question the value of piggy backing at this point. [We might later though ???]. I completely made this up but trying to come up with example. ??? /jim From brian@dxcoms.cern.ch Wed Dec 1 08:22:42 1993 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.4/8.6.4) with SMTP id CAA28080 for ; Wed, 1 Dec 1993 02:23:15 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14002; Wed, 1 Dec 1993 08:22:43 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09592; Wed, 1 Dec 1993 08:22:42 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312010722.AA09592@dxcoms.cern.ch> Subject: Criteria Draft (Dec. 92 version) To: ipng@cmf.nrl.navy.mil Date: Wed, 1 Dec 1993 08:22:42 +0100 (MET) Reply-To: Brian.Carpenter@cern.ch X-Comment: I have changed hosts to dxcoms.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: 45824 Allison asked me to send this to the ipng list FYI, since I had saved a copy. Brian >--------- Text sent by Frank Kastenholz follows: >From kasten@ftp.com Mon Dec 14 21:02:37 1992 X-Delivered: at request of brian on dxcern.cern.ch Date: Mon, 14 Dec 92 14:02:15 -0500 Message-Id: <9212141902.AA23547@ftp.com> To: criteria@ftp.com Subject: new version of the draft From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Hi, I just sent the attached off to the internet-drafts repositories. It reflects the changes that have been discussed at the IETF, along with some other concerns that have been raised (there is a change log near the beginning of the document...) -- Frank Kastenholz o / ------------------------------x----------------------------------------- O \ INTERNET DRAFT Criteria for Choosing IP Version 7 (IPv7) 14 December 1992 Craig Partridge BBN Systems and Technologies craig@aland.bbn.com Frank Kastenholz FTP Software, Inc 2 High Street North Andover, Mass 01845-2620 USA kasten@ftp.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or 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 Internet Draft IPv7 Criteria December 1992 Draft. This is a working document only, it should neither be cited nor quoted in any formal document. This document will expire before 19 June 1993. Distribution of this document is unlimited. Please send comments to criteria@ftp.com or the authors. Partridge & KastenholzExp. 19 June 1993 [Page 1] Internet Draft IPv7 Criteria December 1992 1. Introduction This note attempts to codify and organize the criteria to be used in evaluating the protocols being proposed for adoption as IP Version 7. The criteria presented are culled from several sources, including "IP Version 7" [1], "IESG Deliberations on Routing and Addressing" [2], "Towards the Future Internet Architecture" [3], and the ongoing discussions held on the Big-Internet mailing list and the mailing lists devoted to the individual IPv7 efforts. This document presumes that a new IP-layer protocol is actually desired. There is some discussion in the community as to whether we can extend the life of IPv4 for a significant amount of time by better engineering of, e.g., routing protocols, or we should develop IPv7 now. This question is not addressed in this document. 1.1. Change Log At the Washington D.C. IETF meeting, a BOF was held during which this document was discussed. The following changes have been made to reflect that discussion. (1) The list has been changed from an ordered list of criteria, where each criterion was considered "more important" than those that followed to a split into two groups: (A) those criteria which the new IP "must" have, where "must" is defined by agreeing that a new IPv7 will not be accepted or deployed unless it fullfills all the "must" requirements; and (B) those criteria which it would be desirable to have in the new IP but are not a pre-requisite for deployment. This change has engendered most of the editorial work on the document. Most notably, references to "ordered lists" had to be reworded, and the document needed to be re-organized to have must and should subsections. (2) A section called "General Principles" has been added to the beginning of the document. This section contains Partridge & KastenholzExp. 19 June 1993 [Page 2] Internet Draft IPv7 Criteria December 1992 those items discussed that are hard to quantify as criteria for the protocol, yet which we believe are essential to the future success of IPv7 and the Internet as a whole. (3) Discussion at the BOF made it clear that it would be desirable to refine the criteria into questions that could be used to help distinguish proposals. The goal of these questions is not to grade proposals, and determine which one becomes IPv7, but rather to help elucidate the various ways that the different proposals try to meet the criteria. A beginning of this process, in the form of a section of detailed questions has been added to the end of the document. (4) A MUST criterion for "documents being on-line and owned by the IETF" has been added per the BOF. (5) Per the BOF, the section on accounting has been deleted. (6) Several criteria were mentioned at the BOF but we could find no reasonable definition of them. Place-holders for these criteria are given, but no discussion of them is given. We hope that these place-holders will stimulate discussion on the mailing list. If not, they will be deleted. (7) The IP Checksum was made a non-goal. There has been sufficient discussion on the big-i mailing list to suggest that it does not provide significant data protection. (8) Some typos were fixed. Some additional explanatory text has been added. (9) Additional parts added to the "Configuration, Administration, and Operation" section per the discussion at the BOF. (10) The "Scale" criterion has been expanded per the BOF to address 10**12 nodes and requesting a description of the performance as the limit is reached. Partridge & KastenholzExp. 19 June 1993 [Page 3] Internet Draft IPv7 Criteria December 1992 (11) Robust Service includes a mention of Hostile attacks and Byzantine failures. Partridge & KastenholzExp. 19 June 1993 [Page 4] Internet Draft IPv7 Criteria December 1992 2. Goals We believe that by developing a list of criteria for evaluating proposals for IP version 7 (IPv7), the IETF will make it easier for developers of proposals to prioritize their work and efforts and make reasoned choices as to where they should spend relatively more and less time. This set of criteria originally began as an ordered list, with the goal of ranking the importance of various criteria. However, after discussion it became clear that the criteria list actually could be more simply characterized as falling into two groups: those criteria which had to be met by any proposed IPv7 before anyone felt that IPv7 should be deployed; and those criteria which it would be useful, but not essential, for an IPv7 to meet. The current criteria are presented in this form. We have attempted to state the criteria in the form of goals or requirements and not demand specific engineering solutions. For example, there has been talk in the community of making route aggregation a requirement. We believe that Route Aggregation is not, in and of itself, a requirement but rather one part of a solution to the real problem of scaling to some very large, complex topology. Therefore, Route Aggregation is NOT listed as a requirement. In determining the relative order of the various criteria, we have had two guiding principles. First, IPv7 must offer an internetwork service akin to that of IPv4, but improved to handle the well-known and widely-understood problems of scaling the Internet architecture to more end-points and an ever increasing range of bandwidths. Second, it must be desirable for users and network managers to upgrade their equipment to support IPv7. At minimum, this second point implies that there must be a straightforward way to transition systems from IPv4 to IPv7. But it also strongly suggests that IPv7 should offer features that IPv4 does not; new features provide a motivation to deploy IPv7 more quickly. Partridge & KastenholzExp. 19 June 1993 [Page 5] Internet Draft IPv7 Criteria December 1992 3. Note on Terminology The existing proposals tend distinguish between end-point identification of, e.g., individual hosts, and topological addresses of network attachment points. In this memo we do not make that distinction. We use the term "Address" as it is currently used in IPv4; i.e., for both the identification of a particular endpoint or host AND as the topological address of a point on the network. We presume that if the endpoint/ address split remains, the proposals will make the proper distinctions with respect to the criteria enumerated below. Partridge & KastenholzExp. 19 June 1993 [Page 6] Internet Draft IPv7 Criteria December 1992 4. General Principles 4.1. Architectural Simplicity In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. Antoine de Saint-Exupery 4.2. One Protocol to Bind Them All One of the most important aspects of The Internet is that it provides global IP-layer connectivity. The IP-layer provides the point of commonality among all of the nodes on the Internet. In effect, the main goal of the Internet is to provide an IP Connectivity Service to all who wish it. This does NOT say that the Internet is a One-Protocol Internet. The Internet is today, and shall remain in the future, a Multi-Protocol Internet. Multi-Protocol operations are required to allow for continued testing, experimentation, and development and because service providers' customers clearly want to be able to run protocols such as CLNP, DECNET, and Novell over their Internet connections. 4.3. Live Long It is very difficult to change a protocol as central to the workings of the Internet as IP. Even more problematic is changing such a protocol frequently. This simply can not be done. We believe that it is impossible to expect the community to make significant, non-backward compatible changes to the IP layer more often than once every 10-15 years. In order to be conservative, we strongly urge protocol developers to consider what the Internet will look like in 20 years and design their protocols to fit that vision. As a data point, the SNMP community recently rebelled at changing from SNMPv1 to SNMPv1+Security with SNMPv2+Security on the horizon. The community chose to delay deployment of SNMPv1+Security until SNMPv2 is done. Partridge & KastenholzExp. 19 June 1993 [Page 7] Internet Draft IPv7 Criteria December 1992 Author's Note We believe that this section covers the "Long Life" criterion discussed in the Washington D.C. IETF BOF. 4.4. Live Long AND Prosper We believe that simply allowing for bigger addresses and more efficient routing is not enough of a benefit to encourage vendors, service providers, and users to switch to IPv7, with its attendant distruptions of service, etc. These problems can be solved much more simply with more router-thrust, balkanization of the Internet, and so on. We believe that there must be positive, functional or operational, benefits to switching to IPv7. In other words, IPv7 must be able to live for a long time AND it must allow the Internet to prosper and to grow. Partridge & KastenholzExp. 19 June 1993 [Page 8] Internet Draft IPv7 Criteria December 1992 5. Criteria This section enumerates the criteria against which the IP Version 7 proposals will be evaluated. Each criterion is presented in its own section. The first paragraph of each section is a short, one or two sentence statement of the criterion. Additional paragraphs then explain the criterion in more detail, clarify what it does and does not say and provide some indication of its relative importance. 5.1. MUSTs The following criteria were deemed by an IETF BOF session to be absolutely essential. Any new IP protocol must meet all of these criteria before it is deployed. The standard for making a criteria a must requirement was that we would refuse to deploy a candidate IPv7 that failed to meet just one must requirement, EVEN IF THE CURRENT IPV4 INTERNET IS COLLAPSING DUE TO ROUTING CONGESTION. 5.1.1. Scale CRITERION The IPv7 Protocol must scale to allow the identification and addressing of 10**12 end systems. The IPv7 Protocol, and its associated routing protocols and architecture must allow for up to 10**9 individual networks. The routing schemes must scale with the number of constituent networks at a rate that is much less than linear. DISCUSSION The whole purpose of the IPv7 effort is to allow the Internet to grow beyond the size constraints imposed by the current IPv4 addressing and routing technologies. Both aspects of scaling are important. If we can't route then connecting all these hosts is worthless, but without connected hosts, there's no point in routing, so we must scale in both directions. Partridge & KastenholzExp. 19 June 1993 [Page 9] Internet Draft IPv7 Criteria December 1992 In any proposal, Particular attention should be paid to describing the routing hierarchy, how the routing and addressing will be organized, how different layers of the routing interact, and relationship between addressing and routing. Particular attention must be paid to describing what happens when the size of the network approaches these limits. How are network, forwarding, and routing performance affected? Does performance fall off or does the network simply stop as the limit is neared. Placement This criterion is the essential problem motivating the transition to IPv7. If the proposed protocol does not satisfy this criteria, there is no point in considering it. 5.1.2. Topological Flexibility CRITERION The routing architecture and protocols of IPv7 must allow for many different network topologies. DISCUSSION As the Internet becomes ever more global and ubiquitous, it will develop new and different topologies. We already see cases where the network hierarchy is very "broad" with many subnetworks, each with only a few hosts and where it is very "narrow", with few subnetworks each with many hosts. We can expect these and other topological forms. Furthermore, since we expect that IPv7 will allow for many more levels of hierarchy than are allowed under IPv4, we can expect very "tall" and very "short" topologies as well. 5.1.3. Robust Service CRITERION The network service and its associated routing and control protocols must be robust. Partridge & KastenholzExp. 19 June 1993 [Page 10] Internet Draft IPv7 Criteria December 1992 DISCUSSION Murphy's Law applies to networking. Any proposed IPv7 protocol must be well-behaved in the face of malformed packets, mis-information, and occasional failures of links, routers and hosts. IPv7 should perform gracefully in response to willful management and configuration mistakes (i.e. service outages should be minimized). Putting this requirement another way, IPv7 must make it possible to continue the Internet tradition of being conservative in what is sent, but liberal in what one is willing to receive. We note that IPv4 is reasonably robust and any proposed IPv7 must be at least as robust as IPv4. Hostile attacks on the network layer and Byzantine failure modes must be dealt with in a safe and graceful manner. We note that Robust Service is, in some form, a part of security and vice-versa. Placement Due to its size, complexity, decentralized administration, brain-dead users and administrators, and so on, The Internet is a very hostile environment. If a protocol can not be used in such a hostile environment then it is not suitable for use in the Internet. 5.1.4. Transition CRITERION The protocol must have a straightforward transition plan from the current IPv4. DISCUSSION A smooth, orderly, transition from IPv4 to IPv7 is needed. If we can't transition to the new protocol, then no matter how wonderful it is, we'll never get to it. We believe that it is not possible to have a "flag-day" form of transition in which all hosts and routers must Partridge & KastenholzExp. 19 June 1993 [Page 11] Internet Draft IPv7 Criteria December 1992 change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible. Rather IPv7 will need to co-exist with IPv4 for some period of time. There are a number of ways to achieve this co-existence such as requiring hosts to support two stacks, converting between protocols, or using backward compatible extensions to IPv4. Each scheme has its strengths and weaknesses, which have to be weighed. However, the absence of a rational and well-defined transition plan is not acceptable. Indeed, the difficulty of running a network that is transitioning from IPv4 to IPv7 must be minimized. (A good target is that running a mixed IPv4-IPv7 network should be no more and preferably less difficult than running IPv4 in parallel with existing non-IP protocols). Furthermore, a network in transition must still be robust. IPv7 schemes which maximize stability and connectivity in mixed IPv4-IPv7 networks are preferred. Finally, it may be necessary that multiple IPv7 protocols coexist on the network during the testing and evaluation periods. Transition plans must address this issue. The transition plan must address the following general areas of the Internet's infrastructure: o Host Protocols and Software o Router Protocols and Software o Security and Authentication o Domain Name System o Network Management o Operations Tools (e.g., Ping and Traceroute) o Operations and Administration procedures The impact on protocols which use IP addresses as data (e.g. DNS, SNMP and FTP) must be specifically addressed. The transition plan should address the issue of cost distribution. That is, it should identify what tasks are required of the service providers, of the end users, of the backbones and so on. Partridge & KastenholzExp. 19 June 1993 [Page 12] Internet Draft IPv7 Criteria December 1992 Placement If the transition scheme is painful, no one will transition. But we should only transition if the protocol we transition to solves the scaling problems and is useful to use. 5.1.5. Media CRITERION The protocol must work across an internetwork of many differnet LAN, MAN, and WAN media, with individual link speeds ranging from a ones-of-bits per second to hundreds of gigabits per second. Multiple-access and point-to- point media must be supported, as must both media supporting switched and permanent circuits. DISCUSSION The joy of IP is that it works over just about anything. That ease of adding new technologies, and continuing to operate with old technologies must be maintained. We believe this range of speed is right for the next twenty years, though it may be we should require terabit performance at the high-end. By switched circuits we mean both "permanent" connections such as X.25 and Frame Relay services AND "temporary" types of dialup connections similar to today's SLIP and dialup PPP services. The latter form of connection implies that dynamic network access (i.e., the ability to unplug a machine, move it to a different point on the network topology, and plug it back in, possibly with a changed IPv7 address) is required. We note that this is an aspect of mobility. By work, we mean we have hopes that a stream of IPv7 datagrams (whether from one source, or many) can come close to filling the link at high speeds, but also scales gracefully to low speeds. Placement The protocol must be general. It must operate over all of the media that IPv4 operates over today. A general goal of the Internet is ubiquity. Besides all of the common Partridge & KastenholzExp. 19 June 1993 [Page 13] Internet Draft IPv7 Criteria December 1992 media available today, there are all sorts of "legacy" systems which we would like to connect to IPv7 and these systems might have odd media. Furthermore, there are all sorts of difficult corners of the world which ought to be connected to the Ubiquitous Internet but the medium to get into such corners is "odd" (one example mentioned at the Washington D.C. IETF was to use ELF to connect to submerged submarines -- ELF has a "speed" on the order of <10 characters per second) 5.1.6. Unreliable Datagram Service CRITERION The protocol must support an unreliable datagram delivery service. DISCUSSION We like IP's datagram service and it seems to work very well. So we must keep it. 5.1.7. Configuration, Administration, and Operation CRITERION The protocol must permit easy and largely distributed configuration and operation. Automatic configuration of hosts and routers is required. DISCUSSION People complain that IP is hard to manage. We cannot plug and play. We must fix that problem. We do note that fully automated configuration, especially for large, complex networks, is still a topic of research. Our concern is mostly for small and medium sized, less complex, networks; places where the essential knowledge and skills would not be as readily available. In dealing with this criterion, address assignment and delegation procedures and restrictions should be addressed by the proposal. Furthermore, "ownership" of addresses (e.g. user or service provider) has recently become a concern and the issue should be addressed. Partridge & KastenholzExp. 19 June 1993 [Page 14] Internet Draft IPv7 Criteria December 1992 Additional elements of this criterion are: - Ease of address allocation. - Ease of changing the topology of the network within a particular routing domain. - Ease of changing network provider. - Ease of (re)configuring host/endpoint parameters such as addressing and identification. - Ease of (re)configuring router parameters such as addressing and identification. Placement The placement of this criterion as a "must" is in response to the pressures of the user community, who are crying out for easier to use IP. 5.1.8. Allow Secure Operation CRITERION The protocol should not preclude secure operation. DISCUSSION We need to be sure that we have not created a network that is a cracker's playground. In order to meet the Robustness criterion, some elements of what is commonly shrugged off as "security" are needed; e.g. to prevent a villan from injecting bogus routing packets, and destroying the routing system within the network. This criterion covers those aspects of security that are not needed to provide the Robustness criterion. 5.1.9. Unique Naming CRITERION IPv7 must assign all IP-Layer objects in the global, Partridge & KastenholzExp. 19 June 1993 [Page 15] Internet Draft IPv7 Criteria December 1992 ubiquitous, Internet unique names. DISCUSSION We use the term "Name" in this criterion synonymously with the term "End Point Identifier" as used in the NIMROD proposal, or as IP Addresses uniquely identify interfaces/hosts in IPv4. The authors are not convinced that this ought to be a criterion of the protocol. We feel that it may in fact be a part of a solution to other criteria and as such, is not a criterion of its own. The BOF expressed a very strong desire to include this criterion and we are placing it here in the hope that it will stimulate discussion on the subject. 5.1.10. Access CRITERION The protocols that define IPv7, its associated protocols (similar to ARP and ICMP in IPv4) and the routing protocols (e.g. OSPF, BGP, and RIP in IPv4) must be freely available in the same fashion that RFCs are: namely in ASCII format, obtainable by anonymous FTP, and freely reproducible without copyright restrictions. DISCUSSION An essential aspect of the development of the Internet and its protocols has been the fact that the protocol specifications are freely available to anyone who wishes a copy. Beyond simply minimizing the cost of learning about the technology, the free access to specifications has made it easy for researchers and developers to easily incorporate portions of old protocol specifications in the revised specifications. This type of easy access to the standards documents is required for IPv7. 5.2. SHOULDs The following criteria were deemed by an IETF BOF session to be of lesser importance than the preceeding ones. Every attempt should be made by protocol designers to satisfy these Partridge & KastenholzExp. 19 June 1993 [Page 16] Internet Draft IPv7 Criteria December 1992 criteria, however, deployment would not be held up, waiting for one of these criteria to be met. Some of the criteria represent technologies which are only now starting to move from the research world to the engineering and development world. Other criteria were demoted to this level for reasons that are unclear to the authors. In particular, the authors firmly believe that multicasting and extensibility are actually requirements that no IPv7 should be without. To reflect the decisions at the DC meeting, these criteria have been demoted to this section, but the authors may, after further reflection, move them back into the must category in the future. 5.2.1. Addressing CRITERION The protocol must allow for both unicast and multicast addressing. Part of the multicast capability is a requirement to be able to send to "all IP hosts on THIS network". DISCUSSION IPv4 has made heavy use of the ability to multicast requests to all IPv4 hosts on a subnet, especially for autoconfiguration. This ability must be retained in IPv7. Unfortunately, IPv4 currently uses the local media broadcast address to multicast to all IP hosts. This behavior is anti-social in mixed-protocol networks and should be fixed in IPv7. There's no good reason for IPv7 to send to all hosts on a subnet when it only wishes to send to all IPv7 hosts. The protocol must make allowances for media that do not support true multicasting. In the past few years, we have begun to deploy support for wide-area multicast addressing in the Internet, and it has proved valuable. This capability should not be lost in the transition to IPv7. Partridge & KastenholzExp. 19 June 1993 [Page 17] Internet Draft IPv7 Criteria December 1992 The ability to restrict the range of a broadcast or multicast to specific networks is also important. It should be noted that addressing -- specifically the syntax and semantics of addresses -- has a great impact on the scalability of the architecture. Placement We believe that Multicast Addressing is vital to support future applications such as remote conferencing. It is also used quite heavily in the current Internet for things like service location and routing. Author's Note The Washington D.C. BOF did not come down firmly that multicast should be a MUST, however the authors believe it to be essential. 5.2.2. Extensibility CRITERION The protocol must be extensible; it must be able to evolve to meet the future service needs of the Internet. This evolution must be achievable without requiring network-wide software upgrades. DISCUSSION We do not today know all of the things that we will want the Internet to be able to do 10 years from now. At the same time, it is not reasonable to ask users to transition to a new protocol with each passing decade. Thus, we believe that it must be possible to extend IPv7 to support new services and facilities. Furthermore, it is essential that any extensions can be incrementally deployed to only those systems which desire to use them. Systems upgraded in this fashion must still be able to communicate with systems which have not been so upgraded. Placement We believe that this criterion should be a "MUST" simply because we can not predict very well what the future will bring so the protocol must be able to deal with the future -- whatever it is. Partridge & KastenholzExp. 19 June 1993 [Page 18] Internet Draft IPv7 Criteria December 1992 Author's Note The Washington D.C. BOF did not come down firmly that extensibility should be a MUST, however the authors believe it to be essential. 5.2.3. Support for Guaranteed Flows CRITERION The protocol should support guaranteed flows. DISCUSSION Multimedia is now on our desktop and will be an essential part of future networking. So we have to find ways to support it; and a failure to support it may mean users choose to use protocols other than IPv7. The IETF multicasts have shown that we can currently support multimedia over internetworks with some hitches. If we can achieve the needed support for guaranteed flows in IPv7, we will dramatically increase its success. 5.2.4. Support for Mobility CRITERION The protocol should support mobile hosts. DISCUSSION Again, mobility is becoming increasingly important. Look at the portables that everyone is carrying. Note the strength of the Apple commercial showing someone automatically connecting up her Powerbook to her computer back in the office. There have been a number of pilot projects showing ways to support mobility in IPv4. All have some drawbacks. But like guaranteed flows, if we can support mobility, IPv7 will have features that will encourage transition. We use a vague definition of "mobility" here. To some people, this means hosts that physically move and remain connected (via some wireless datalink), to others it means disconnecting a host from one spot in the network, connecting it back in another arbitrary spot and Partridge & KastenholzExp. 19 June 1993 [Page 19] Internet Draft IPv7 Criteria December 1992 continuing to work. At this point we expect that the proposals will discuss their own abilities in this general area. 5.2.5. Cost Distribution This is a place-holder from the BOF. 5.2.6. Risk and Maturity This is a place-holder from the BOF. 5.2.7. Performance This is a place-holder from the BOF. 5.3. Explicit Non-Goals This section contains some explicit non-goals of IPv7. A non-goal does not mean that a protocol MUST NOT do something. It means that the authors do not believe that it matters whether the non-goal is in the protocol or not. If a protocol includes one of the non-goals; well, that's cool. If it doesn't; that's cool too. A non-goal might be necessary in order to meet some other criterion, however this is irrelevant to including the non-goal merely for its own sake. Fragmentation The technology exists for path MTU discovery. Presumably, IPv7 will continue to provide this technology. Therefore, we believe that IPv7 Fragmentation and Reassembly, as provided in IPv4, is not necessary. IPv4/IPv7 Communication It is not necessary that IPv4-only and IPv7-only hosts be able to communicate directly with each other. IP Checksum There has been discussion indicating that the IP Checksum does not provide enough error protection to warrant its Partridge & KastenholzExp. 19 June 1993 [Page 20] Internet Draft IPv7 Criteria December 1992 performance impact. The argument states that there is almost always a stronger datalink level CRC, and that end-to-end protection is provided by the TCP checksum. Therefore we believe that an IPv7 checksum is not required per-se. Partridge & KastenholzExp. 19 June 1993 [Page 21] Internet Draft IPv7 Criteria December 1992 6. Detailed Questions This section is an initial draft of a list of detailed questions designed to start to help refine our understanding of how each proposal meets the criteria. The questions are written such that there are no right or wrong answers, but rather, that by reading answers to the questions one can develop a better understanding of the tradeoffs chosen by the protocol designers. The questions are grouped according to the criteria they are intended to help readers better understand. Partridge & KastenholzExp. 19 June 1993 [Page 22] Internet Draft IPv7 Criteria December 1992 7. References [1] Internet Architecture Board, IP Version 7, Draft 8, Internet Draft, July, 1992. [2] Gross, P. and P. Almquist, IESG Deliberations on Routing and Addressing, Internet Draft, September 1992. [3] Clark, D., et al, Towards the Future Internet Architecture Network Working Group Request For Comments 1287, December 1991. [4] Dave Clark's paper at SIGCOMM '88 where he pointed out that the design of TCP/IP was guided, in large part, by an ordered list of requirements. Partridge & KastenholzExp. 19 June 1993 [Page 23] Internet Draft IPv7 Criteria December 1992 Table of Contents Status of this Memo .................................... 1 1 Introduction .......................................... 2 1.1 Change Log .......................................... 2 2 Goals ................................................. 5 3 Note on Terminology ................................... 6 4 General Principles .................................... 7 4.1 Architectural Simplicity ............................ 7 4.2 One Protocol to Bind Them All ....................... 7 4.3 Live Long ........................................... 7 4.4 Live Long AND Prosper ............................... 8 5 Criteria .............................................. 9 5.1 MUSTs ............................................... 9 5.1.1 Scale ............................................. 9 5.1.2 Topological Flexibility ........................... 10 5.1.3 Robust Service .................................... 10 5.1.4 Transition ........................................ 11 5.1.5 Media ............................................. 13 5.1.6 Unreliable Datagram Service ....................... 14 5.1.7 Configuration, Administration, and Operation ...... 14 5.1.8 Allow Secure Operation ............................ 15 5.1.9 Unique Naming ..................................... 15 5.1.10 Access ........................................... 16 5.2 SHOULDs ............................................. 16 5.2.1 Addressing ........................................ 17 5.2.2 Extensibility ..................................... 18 5.2.3 Support for Guaranteed Flows ...................... 19 5.2.4 Support for Mobility .............................. 19 5.2.5 Cost Distribution ................................. 20 5.2.6 Risk and Maturity ................................. 20 5.2.7 Performance ....................................... 20 5.3 Explicit Non-Goals .................................. 20 6 Detailed Questions .................................... 22 7 References ............................................ 23 Partridge & KastenholzExp. 19 June 1993 [Page ii] From brian@dxcoms.cern.ch Wed Dec 1 08:36:46 1993 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.4/8.6.4) with SMTP id CAA28116 for ; Wed, 1 Dec 1993 02:37:20 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA15832; Wed, 1 Dec 1993 08:36:47 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09892; Wed, 1 Dec 1993 08:36:46 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312010736.AA09892@dxcoms.cern.ch> Subject: What criteria are good for To: ipng@cmf.nrl.navy.mil Date: Wed, 1 Dec 1993 08:36:46 +0100 (MET) Reply-To: Brian.Carpenter@cern.ch X-Comment: I have changed hosts to dxcoms.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: 552 OK.. people were nervous because criteria can be exploited to prejudice the decision process. But we need something against which to make the engineering judgement required of us. So we need engineering criteria. Let's NOT classify them into MUST and SHOULD, or even prioritise them. Let's not even call them 'criteria'. I propose that we call them 'engineering considerations' and that we list them in strict alphabetical order. If we could agree on something like this we could ask Craig and Frank to reorganise their document accordingly. Brian From iesg-request@ietf.cnri.reston.va.us Wed Dec 1 10:02:49 1993 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.4/8.6.4) with SMTP id KAA29421 for ; Wed, 1 Dec 1993 10:05:34 -0500 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05569; 1 Dec 93 10:02 EST Received: from hsdndev.harvard.edu by IETF.CNRI.Reston.VA.US id aa05565; 1 Dec 93 10:02 EST Date: Wed, 1 Dec 93 10:02:49 -0500 Sender: iesg-request@IETF.CNRI.Reston.VA.US From: Scott Bradner Message-Id: <9312011502.AA23661@hsdndev.harvard.edu> To: iesg@IETF.CNRI.Reston.VA.US Subject: ALE charter Here is a revised version of the ALE proposed charter, this has not yet been reviewed by the IPng directorate but since this was noted on tomorrow's agenda here it is for discussion. Scott & Allison ------- Address Lifetime Expectations (ALE) WG Chair: Frank Solensky, FTP Software Tony Li, Cisco Systems IPng Area The primary purpose of the Address Lifetime Expectations Working Group is to develop an estimate for the remaining lifetime of the IPv4 address space based on currently known and available technologies. The members of the working group will consider whether more stringent address allocation and utilization policies might provide additional time and, if so, recommend such policies. The working group will also investigate whether it is worthwhile to mount a serious effort to reclaim addresses and/or to renumber significant portions of the Internet. It will also weigh the benefit of other potential options against their expected cost and notify the responsible working groups or area directors of those proposals the ALE group considers worthy of their further attention. The working group will have several ongoing activities which will result in non-periodic reports to the IETF community and the IPng Area Directors. One ongoing activity is to produce predictions of the address space exhaustion timeframe, assessing the accuracy of these predictions and the data on which they are based. The group will also project the impact of various policy compliance data and possible policy recommendations. Another ongoing activity is to monitor the perceived utilization of address space and identify sources of poor utilization, set address utilization goals and to itemize possible policies to improve utilization. The group will also monitor the number of routes present in the Internet backbones, and determine, in conjunction with the CIDR deployment WG, locate sources of poor aggregation within the network, and make necessary recommendations to insure continued operations. Milestones: November 1993 Coordinate with existing efforts in this area, for example, those of the IEPG and the CIDR Deployment BOF. Result is an allocations of tasks agreed among the efforts. April 1994 In cooperation with the BGP Deployment Working Group, produce a report on the status of address aggregation, including additional guidelines/strategies, if necessary. July 1994 Produce a report on the status of addess space utilization, including goals and guidelines for improving address space utilization. From sob@hsdndev.harvard.edu Wed Dec 1 10:14:25 1993 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.4/8.6.4) with SMTP id KAA29491 for ; Wed, 1 Dec 1993 10:14:34 -0500 Date: Wed, 1 Dec 93 10:14:25 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9312011514.AA24545@hsdndev.harvard.edu> To: ericf@atc.boeing.com Subject: Re: What's missing frow WP outline Cc: mankin@cmf.nrl.navy.mil Eric, It would be nice if you could also give your own opinions. The articulatioon of the Boeing Co is very useful but we need you to be able to express your own thoughts as an extension or as a counter. Scott From scoya@CNRI.Reston.VA.US Wed Dec 1 10:27:53 1993 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.4/8.6.4) with SMTP id KAA29563 for ; Wed, 1 Dec 1993 10:29:37 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08318; 1 Dec 93 10:27 EST To: Allison J Mankin cc: ipng@radegond.cmf.nrl.navy.mil Subject: Re: 2nd try - White Paper solicitation and descriptions In-reply-to: Your message of "Wed, 01 Dec 93 01:00:50 EST." <9312010600.AA17251@radegond.cmf.nrl.navy.mil> Date: Wed, 01 Dec 93 10:27:53 -0500 From: Steve Coya Message-ID: <9312011027.aa08318@IETF.CNRI.Reston.VA.US> Allison, >> All white papers must follow the format requirements listed in >> RFC1111 and must not exceed 10 pages in length. (The relevant >> portion of RFC1111 is included as Appendix A.) RFC1111 was updated by RFC1543. I don't believe the rules for ASCII have changed, but the note should reference 1543. From scoya@CNRI.Reston.VA.US Wed Dec 1 10:35:13 1993 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.4/8.6.4) with SMTP id KAA29621 for ; Wed, 1 Dec 1993 10:37:57 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08473; 1 Dec 93 10:35 EST To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: What criteria are good for In-reply-to: Your message of "Wed, 01 Dec 93 08:36:46 +0100." <9312010736.AA09892@dxcoms.cern.ch> Date: Wed, 01 Dec 93 10:35:13 -0500 From: Steve Coya Message-ID: <9312011035.aa08473@IETF.CNRI.Reston.VA.US> We (the IETF community) are going to have to realize that two or more different approaches may in fact address all the concerns, criteria, and engineering considerations. I.e. more than one proposal will work, more than one proposal will meet all tests, etc. Suppose the requirement is to have eggs for breakfast. They can be scrambled, poached, over-easy or sunny side up. Ya gotta chose one, but all meet the criteria (sorry for that analogy... I didn't have breakfast this morning :-) Steve From iesg-request@ietf.cnri.reston.va.us Wed Dec 1 10:49:20 1993 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.4/8.6.4) with SMTP id KAA29686 for ; Wed, 1 Dec 1993 10:51:10 -0500 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08879; 1 Dec 93 10:49 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08873; 1 Dec 93 10:49 EST Received: from hsdndev.harvard.edu by CNRI.Reston.VA.US id aa09882; 1 Dec 93 10:49 EST Date: Wed, 1 Dec 93 10:49:20 -0500 Sender: iesg-request@IETF.CNRI.Reston.VA.US From: Scott Bradner Message-Id: <9312011549.AA26713@hsdndev.harvard.edu> To: Lyman@bbn.com, ietf@CNRI.Reston.VA.US Subject: Re: Proposed new mode of operation for X3S3.3 Cc: iab@venera.isi.edu, iesg@CNRI.Reston.VA.US Lyman, Has there been any thought to what happens to the product of the IETF working group (an Internet-Draft and then an RFC) from the point of view of X3S3? Do they then take it and somehow ratify it? If someone in their process has a problem with the document are we expected to address the problem even if the working group thinks they are done. Please don't take this a negative, I think that the saving of travel money and the understanding a clear and large overlap in people and problems is very good but there is a lot of procedural history to the way that X3S3 and groups of that type have been run and I'd like to know if there has been any thought given to dealing with the different base procedural assumptions. Scott From bound@zk3.dec.com Wed Dec 1 10:53:01 1993 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.4/8.6.4) with SMTP id KAA29712 for ; Wed, 1 Dec 1993 10:56:04 -0500 From: bound@zk3.dec.com Received: by inet-gw-1.pa.dec.com; id AA15173; Wed, 1 Dec 93 07:53:11 -0800 Received: by xirtlu.zk3.dec.com; id AA15132; Wed, 1 Dec 1993 10:53:07 -0500 Message-Id: <9312011553.AA15132@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: What criteria are good for In-Reply-To: Your message of "Wed, 01 Dec 93 08:36:46 +0100." <9312010736.AA09892@dxcoms.cern.ch> Date: Wed, 01 Dec 93 10:53:01 -0500 X-Mts: smtp I support Brian's idea of engineering considerations. /jim From ietf-request@ietf.cnri.reston.va.us Wed Dec 1 10:49:20 1993 Return-Path: ietf-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.4/8.6.4) with SMTP id LAA29791 for ; Wed, 1 Dec 1993 11:06:48 -0500 Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08937; 1 Dec 93 10:51 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08873; 1 Dec 93 10:49 EST Received: from hsdndev.harvard.edu by CNRI.Reston.VA.US id aa09882; 1 Dec 93 10:49 EST Date: Wed, 1 Dec 93 10:49:20 -0500 Sender: ietf-request@IETF.CNRI.Reston.VA.US From: Scott Bradner Message-Id: <9312011549.AA26713@hsdndev.harvard.edu> To: Lyman@bbn.com, ietf@CNRI.Reston.VA.US Subject: Re: Proposed new mode of operation for X3S3.3 Cc: iab@venera.isi.edu, iesg@CNRI.Reston.VA.US Lyman, Has there been any thought to what happens to the product of the IETF working group (an Internet-Draft and then an RFC) from the point of view of X3S3? Do they then take it and somehow ratify it? If someone in their process has a problem with the document are we expected to address the problem even if the working group thinks they are done. Please don't take this a negative, I think that the saving of travel money and the understanding a clear and large overlap in people and problems is very good but there is a lot of procedural history to the way that X3S3 and groups of that type have been run and I'd like to know if there has been any thought given to dealing with the different base procedural assumptions. Scott From bound@zk3.dec.com Wed Dec 1 11:03:33 1993 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.4/8.6.4) with SMTP id LAA29795 for ; Wed, 1 Dec 1993 11:07:06 -0500 From: bound@zk3.dec.com Received: by inet-gw-1.pa.dec.com; id AA16190; Wed, 1 Dec 93 08:03:42 -0800 Received: by xirtlu.zk3.dec.com; id AA15474; Wed, 1 Dec 1993 11:03:39 -0500 Message-Id: <9312011603.AA15474@xirtlu.zk3.dec.com> To: Steve Coya Cc: Brian.Carpenter@cern.ch, ipng@cmf.nrl.navy.mil Subject: Re: What criteria are good for In-Reply-To: Your message of "Wed, 01 Dec 93 10:35:13 EST." <9312011035.aa08473@IETF.CNRI.Reston.VA.US> Date: Wed, 01 Dec 93 11:03:33 -0500 X-Mts: smtp >We (the IETF community) are going to have to realize that two or more >different approaches may in fact address all the concerns, criteria, >and engineering considerations. I.e. more than one proposal will work, >more than one proposal will meet all tests, etc. > >Suppose the requirement is to have eggs for breakfast. They can be >scrambled, poached, over-easy or sunny side up. Ya gotta chose one, but >all meet the criteria (sorry for that analogy... I didn't have >breakfast this morning :-) This could happen if all the proposals really do a good job with the specs and will make our job and consensus process much more complex. But I hope it happens. There will most likely be tradeoffs between each proposal regarding the engineering considerations. For example you get more of the Vitamin E in an egg yolk if their poached rather then scrambled, but even more if hard-boiled. p.s. Nutri-Grain Fruit bars taste good, are quick, and are healthy and cheap. /jim From scoya@CNRI.Reston.VA.US Wed Dec 1 11:10:13 1993 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.4/8.6.4) with SMTP id LAA29907 for ; Wed, 1 Dec 1993 11:23:13 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09332; 1 Dec 93 11:10 EST To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: What criteria are good for In-reply-to: Your message of "Wed, 01 Dec 93 11:03:33 EST." <9312011603.AA15474@xirtlu.zk3.dec.com> Date: Wed, 01 Dec 93 11:10:13 -0500 From: Steve Coya Message-ID: <9312011110.aa09332@IETF.CNRI.Reston.VA.US> >> p.s. Nutri-Grain Fruit bars taste good, are quick, and are healthy and >> cheap. Yeah, but they don't meet the requirement: to have eggs for breakfast :-) From ericf@atc.boeing.com Wed Dec 1 11:22:02 1993 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.4/8.6.4) with SMTP id OAA00901 for ; Wed, 1 Dec 1993 14:20:35 -0500 Received: by atc.boeing.com (5.57) id AA14854; Wed, 1 Dec 93 11:22:02 -0800 Date: Wed, 1 Dec 93 11:22:02 -0800 From: Eric Fleischman Message-Id: <9312011922.AA14854@atc.boeing.com> To: ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: ALE charter Cc: ericf Dear Scott and Allison, Thank you for the opportunity to review the ALE charter. I generally approve of the charter with one specific exception: I do not approve of the mention within the charter of address reclamation and forced renumbering. While I think both ideas are abhorrent, unenforcable, and possibly illegal, my official objection stems from the inclusion of *ANY* possible address lifetime extension mechanisms being included within the charter itself. That is, the charter should simply mention that address lifetime mechanisms will be investigated by the ALE WG and the "likely payback" of these approaches will be evaluated and their subsequent address lifetime value estimated. Let's not mention the mechanisms themselves in the charter because 1) such controvery is not really necessary at this point. 2) mentioning only a subset of mechanisms may guide the WG in unfortunate directions (i.e., put the WG "in a groove" from which it may not escape). However, if the mechanisms must be mentioned, please be sure that the charter includes the mechanism which I personally think is the most viable of all: local addresses (coupled with application-layer gateways [rather than NATs] at the enterprise boundary). [Note: I am under great pressure from within Boeing to write an internet draft proposing the immediate postulation of a range of Class B addresses to serve as local addresses. Simularly, other user companies (e.g., Chrysler) have expressed such a need due to (1) security considerations and (2) our current difficulty in obtaining addresses in the current environment. Increasingly end users are purposefully using addresses which have already been assigned to other companies for our own internal networks as an "ad hoc" fix. This is a very big deal with large end-user corporations.] Thus, if specific mechanisms must be mentioned, and dispicable alternatives such as forced renumbering and address reclamation are enumerated, please do not fail to mention sane approaches such as local addresses. I think that any impartial reader must be wondering at this point whether the emotionalism of this note has been added for "humor" or for "effect". Actually, the emotionalism is due to real "emotion" and is not an artificial affectation. Sincerely yours, --Eric Fleischman From sob@hsdndev.harvard.edu Wed Dec 1 14:29:33 1993 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.4/8.6.4) with SMTP id OAA00959 for ; Wed, 1 Dec 1993 14:29:41 -0500 Date: Wed, 1 Dec 93 14:29:33 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9312011929.AA11004@hsdndev.harvard.edu> To: ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil Subject: Re: ALE charter Eric, The exporation of those topics is in the ALE charter because it was in the charge to the IPng area. But you are right that the specific procedures do not need to be mentioned. I do think that it very important for the IPng area in some way to come out and say that forced renumbering and address reclamation are not 1/ required or 2/ a good idea. (assuming that this is as true as I think it is) The lingering fear is not a good idea, we have to make a statement and I think that the ALE group is a good place for that statement to be verified. But assuming that we should be more neutrial in the charter, do you have a suggested alternate wording of the section? Scott From ericf@atc.boeing.com Wed Dec 1 12:40:17 1993 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.4/8.6.4) with SMTP id PAA01661 for ; Wed, 1 Dec 1993 15:38:53 -0500 Received: by atc.boeing.com (5.57) id AA20123; Wed, 1 Dec 93 12:40:17 -0800 Date: Wed, 1 Dec 93 12:40:17 -0800 From: Eric Fleischman Message-Id: <9312012040.AA20123@atc.boeing.com> To: ericf@atc.boeing.com, ipng@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu Subject: Re: ALE charter Cc: ericf Dear Scott, The section of the ALE charter which I found offensive is the following: > The working group will also investigate > whether it is worthwhile to mount a serious effort to reclaim addresses > and/or to renumber significant portions of the Internet. It will also > weigh the benefit of other potential options against their expected cost > and notify the responsible working groups or area directors of those > proposals the ALE group considers worthy of their further attention. I propose that these sentences be re-written as follows: "The working group will enumerate address lifetime extension mechanisms. It will then evaluate these mechanisms concerning their possible benefit against their expected cost. Any mechanism which the ALE working group considers worthy of further attention will be forwarded to the responsible working groups or area directors for further evaluation." Sincerely yours, --Eric Fleischman From sob@hsdndev.harvard.edu Wed Dec 1 18:35:00 1993 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.4/8.6.4) with SMTP id SAA02529 for ; Wed, 1 Dec 1993 18:35:06 -0500 Date: Wed, 1 Dec 93 18:35:00 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9312012335.AA00912@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: FYI I talked to a reporter about IPng today (so what else is new?) He asked that I not give the publication name until close to publication so his article is not leaked. I'll let you know more as soon as he will let me. The reason I'm sending this out to the list is to say that I gave him Mark's, Steve's and Rob's names for info about the protocol proposals themselves. A bit of a warning - don't answer you phone :-). actually he seems quite interested but needs help in understanding some of the basics. Scott ps - I finally faxed copies of the articles (the Open Systems & Network World ones) to each of you that I had a working fax # for. The number I have for Mark is always busy and the one I have for Brian gets me a 'no such number' message and I don't have a fax # for Paul M. From brian@dxcoms.cern.ch Thu Dec 2 08:36:48 1993 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.4/8.6.4) with SMTP id CAA03730 for ; Thu, 2 Dec 1993 02:37:29 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14192; Thu, 2 Dec 1993 08:36:49 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09310; Thu, 2 Dec 1993 08:36:48 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312020736.AA09310@dxcoms.cern.ch> Subject: Re: ALE charter To: ipng@cmf.nrl.navy.mil Date: Thu, 2 Dec 1993 08:36:48 +0100 (MET) In-Reply-To: <9312011504.AA23779@hsdndev.harvard.edu> from "Scott Bradner" at Dec 1, 93 10:04:31 am Reply-To: Brian.Carpenter@cern.ch X-Comment: I have changed hosts to dxcoms.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: 2965 I have one comment: there are two distinct lifetime issues, adress depletion as such, and router table overflow. Is predicting router table overflow something we want ALE to do? If yes, we need a few small changes in the charter. I also suggest that the routine predictions that Frank seems to do monthly anyway should be tagged as "monthly", unless Frank objects to writing this down. > > The primary purpose of the Address Lifetime Expectations Working Group is > to develop an estimate for the remaining lifetime of the IPv4 address > space based on currently known and available technologies. *** This concerns both depletion of the address space and overflow *** of routing tables. > The members > of the working group will consider whether more stringent address > allocation and utilization policies might provide additional time and, > if so, recommend such policies. The working group will also investigate > whether it is worthwhile to mount a serious effort to reclaim addresses > and/or to renumber significant portions of the Internet. It will also > weigh the benefit of other potential options against their expected cost > and notify the responsible working groups or area directors of those > proposals the ALE group considers worthy of their further attention. > > The working group will have several ongoing activities which will result in > non-periodic reports to the IETF community and the IPng Area Directors. > *** One ongoing activity is to produce monthly predictions of the address space > exhaustion timeframe, *** and the routing table overflow timeframe, > assessing the accuracy of these predictions and > the data on which they are based. The group will also project the > impact of various policy compliance data and possible policy > recommendations. > > Another ongoing activity is to monitor the perceived utilization of address > space and identify sources of poor utilization, set address utilization > goals and to itemize possible policies to improve utilization. > > The group will also monitor the number of routes present in the Internet > backbones, and determine, in conjunction with the CIDR deployment WG, > locate sources of poor aggregation within the network, and make necessary > recommendations to insure continued operations. > > Milestones: > > November 1993 Coordinate with existing efforts in this area, for > example, those of the IEPG and the CIDR Deployment BOF. Result > is an allocations of tasks agreed among the efforts. > > April 1994 In cooperation with the BGP Deployment Working Group, > produce a report on the status of address aggregation, including > additional guidelines/strategies, if necessary. *** Includes status of routing tables in the Internet. > > July 1994 Produce a report on the status of addess space utilization, > including goals and guidelines for improving address space utilization. > From brian@dxcoms.cern.ch Thu Dec 2 09:00:22 1993 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.4/8.6.4) with SMTP id DAA03770 for ; Thu, 2 Dec 1993 03:00:57 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18339; Thu, 2 Dec 1993 09:00:23 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA10229; Thu, 2 Dec 1993 09:00:22 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312020800.AA10229@dxcoms.cern.ch> Subject: Re: 2nd try - White Paper solicitation and descriptions To: ipng@cmf.nrl.navy.mil Date: Thu, 2 Dec 1993 09:00:22 +0100 (MET) In-Reply-To: <9312010600.AA17251@radegond.cmf.nrl.navy.mil> from "Allison J Mankin" at Dec 1, 93 01:00:50 am Reply-To: Brian.Carpenter@cern.ch X-Comment: I have changed hosts to dxcoms.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: 4812 A few comments: ... > The document will be submitted as an Internet-Draft after these > reviews have been completed and after whatever (if any) revisions > that the author decides to make. After a suitable period of time > these documents will be submitted as informational RFCs **unless withdrawn by their author(s). > These > documents will comprise a part of the historical record of the IPng > process. > > ****** > question to directorate - if the author refuses to make changes to > fix what is seen as a technical problem, should we issue a > companion document detailing whatever technical issues the > review process has found? **Why not add an annex to the document to reduce the number **of documents in the world? > ********* ... ** Instead of 'topics' and 'issues' I propose 'engineering ** considerations' > 4.1 Topics > > In past discussions the following issues have been raised as > relevant to the IPng selection process. This list is in no particular > order. Any or all of these issues may be addressed as well as any > other topic that the author feels is germane. > > scaling - What is a reasonable estimate for the scale of the > future data networking environment? The current common > wisdom is that IPng should be able to deal with a billion nodes. > > timescale - What are reasonable time estimates for the IPng > selection, development and deployment process or what should > the timeframe requirements be? This topic is being evaluated by > the ALE working group and a copy of all white papers that > express opinions about these topics will be forwarded to that > group. > > transition and deployment - Transition from the current > version to IPng will be a complex and difficult process. What are > the issues that should be considered The TACIT working group > will be discussing these issues and a copy of all white papers that > express opinions about these topics will be forwarded to that > group. > > security - What level and type of security will be required in > the future network environment? What features should be in an > IPng to facilitate security? > > configuration, administration and operation - As networks > get larger and more complex, the day to day operational aspects > become ever more important. What should an IPng include or > avoid in order to minimize the effect on the network operators? > > mobile hosts - How important is the proliferation of mobile > hosts to the IPng selection process? To what extent should features be > included in an IPng to assist in dealing with mobile hosts? > > flows and resource reservation - As the data networks begin > to get used for an increasing number of time-critical processes, > what are the requirements or concerns that affect how IPng should > facilitate the use of resource reservations or flows? > > policy based routing - How important is policy based > routing? If it is important, what types of policies will be used? > What requirements do routing policies and potential future global > architectures of the Internet bring to IPng? How do policy > requirements interact with scaling? > > topological flexibility - ** I think Ross originally raised this and could expand on it ** Is it linked to ROLC? > > datagram service - Existing IP service is "best effort" > and based on hop-by-hop routed datagrams. What requirements for > this paradigm influence the IPng selection? > > support of all communication media > > robustness and fault tolerance - To the extent that the > Internet built from IPv4 has been highly fault tolerant, what are > ways that IPng may avoid inadvertant decrease in the robustness > (since some things may work despite flaws that we do not understand > well). Comment on any other ways in which this requirement may > affect the IPng. > > technology pull - Are there technologies that will pull > the Internet in a way that should influence IPng? Can specific > strategies be developed to encompass these? > ** I recommend adding implementation cost and performance ** (they are linked by a trade-off I suppose). Somebody will have ** something to say about them ** I also want to see accounting/charging/billing in the list. ** Even if the Internet prejudice is to say "we don't want then" ** this should be on the table. > action items - suggested charges to the directorate, working > groups or others to support the concerns or gather more information > needed for a decision. > > Appendix Formatting Rules (from RFC1111) > ** Does somebody have a *roff template to make this easy? ** If yes, why not append it to the document? Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From lkeiper@CNRI.Reston.VA.US Fri Dec 3 12:42:49 1993 Return-Path: lkeiper@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.4/8.6.4) with SMTP id OAA12401 for ; Fri, 3 Dec 1993 14:49:18 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07798; 3 Dec 93 12:42 EST To: ipng@cmf.nrl.navy.mil cc: lkeiper@CNRI.Reston.VA.US Subject: IPng Teleconference, Monday, December 6, 1993. Date: Fri, 03 Dec 93 12:42:49 -0500 From: "Lois J. Keiper" Message-ID: <9312031242.aa07798@IETF.CNRI.Reston.VA.US> UPDATE*** The names marked with an asterisk are those who have confirmed participation for the IPng telconference scheduled for Monday, December 6, 1993 @11:30 - 13:30 EST. Please verify the number listed below and send your RSVP/Regrets or changes/corrections to lkeiper@cnri.reston.va.us. Thanks for your prompt responses! Thanks for your cooperation <:-)>>> *J. Allard 206-882-8080* Steve Bellovin 908-582-5886 *Jim Bound 603-465-3130* *Scott Bradner 617-495-3864* Ross Callon 508-436-3936 *Brian Carpenter +41 22 767 4967* Dave Clark 617-253-6003 *Steve Coya 703-620-8990* *John Curran 617-873-4398* *Steve Deering 415-812-4839* *Dino Farinacci 408-226-6870* *Eric Fleischman 206-957-5334* Paul Francis 201-829-4484 Daniel Karrenberg +31 20 592 5065 Mark Knopper 313-763-6061 Allison Mankin 202-404-7030 *Greg Minshall will call in (late, if available)* Paul Mockapetris 703-696-2262 Rob Ullmann 617-693-1315 *Lixia Zhang # pending * 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 -ER28257 in the orginators name, Steve Coya. Thanks Lois From scoya@CNRI.Reston.VA.US Fri Dec 3 14:52:10 1993 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.4/8.6.4) with SMTP id QAA13312 for ; Fri, 3 Dec 1993 16:29:12 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10457; 3 Dec 93 14:52 EST To: ipng@cmf.nrl.navy.mil Subject: Agenda for December 6 IPNG Directorate Teleconference Date: Fri, 03 Dec 93 14:52:10 -0500 From: Steve Coya Message-ID: <9312031452.aa10457@IETF.CNRI.Reston.VA.US> 1. Administrivia o Roll Call o Agenda bashing o Approval of minutes for November 22, 1993 2. White Papers o Outline to be used by authors on white papers o Identification/solicition of white paper authors o Next Steps 3. Working Groups Actions o Finalize Ale Charter o Requirements WG o Transition, coexistance, including testing 4. Roundtable 5. Date of next teleconference From lkeiper@CNRI.Reston.VA.US Mon Dec 6 10:38:41 1993 Return-Path: lkeiper@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.4/8.6.4) with SMTP id LAA22854 for ; Mon, 6 Dec 1993 11:29:14 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06131; 6 Dec 93 10:38 EST To: ipng@cmf.nrl.navy.mil cc: lkeiper@CNRI.Reston.VA.US Subject: IPng Teleconference, Monday, December 6, 1993 Date: Mon, 06 Dec 93 10:38:41 -0500 From: "Lois J. Keiper" Message-ID: <9312061038.aa06131@IETF.CNRI.Reston.VA.US> FINAL*** The names marked with an asterisk are those who have confirmed participation for the IPng telconference scheduled for Monday, December 6, 1993 @11:30 - 13:30 EST. Thanks for your cooperation. :-) *J. Allard 206-882-8080* *Steve Bellovin 908-582-5886* *Jim Bound 603-465-3130* *Scott Bradner 617-495-3864* *Ross Callon 508-436-3936 (1st 1/2 hr.) *Brian Carpenter +41 22 767 4967* Dave Clark 617-253-6003 *Steve Coya 703-620-8990* *John Curran 617-873-4398* *Steve Deering 415-812-4839* *Dino Farinacci 408-226-6870* *Eric Fleischman 206-957-5334* -Paul Francis Regrets -Daniel Karrenberg Regrets *Mark Knopper 313-763-6061* *Allison Mankin 202-404-7030* *Greg Minshall will call in (late, if available)* Paul Mockapetris 703-696-2262 *Rob Ullmann 617-693-1315* *Lixia Zhang # pending * 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 -ER28257 in the orginators name, Steve Coya. Thanks Lois From rcallon@wellfleet.com Mon Dec 6 12:20:35 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA23107 for ; Mon, 6 Dec 1993 12:17:26 -0500 Received: from pobox.wellfleet ([192.32.75.5]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28191; Mon, 6 Dec 93 12:04:46 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA25377; Mon, 6 Dec 93 12:13:02 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA02772; Mon, 6 Dec 93 12:20:35 EST Date: Mon, 6 Dec 93 12:20:35 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312061720.AA02772@cabernet.wellfleet> To: ipng@cmf.nrl.navy.mil, scoya@CNRI.Reston.VA.US Subject: Proposed wording for topology flexibility and applicability sections Cc: rcallon@wellfleet.com Topological Flexibility -- What topology is anticipated for the Internet? Will the current general topology model continue? Is it acceptable (or even necessary) to place significant topological restrictions on interconnectivity of networks? Applicability -- What environment / marketplace do you see for the application of IPng? From brian@dxcoms.cern.ch Tue Dec 7 08:32:54 1993 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.4/8.6.4) with SMTP id CAA28002 for ; Tue, 7 Dec 1993 02:36:01 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14281; Tue, 7 Dec 1993 08:32:55 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA24887; Tue, 7 Dec 1993 08:32:54 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312070732.AA24887@dxcoms.cern.ch> Subject: Re: Proposed wording for topology flexibility and applicability sections To: rcallon@wellfleet.com (Ross Callon) Date: Tue, 7 Dec 1993 08:32:54 +0100 (MET) Cc: ipng@cmf.nrl.navy.mil, scoya@CNRI.Reston.VA.US, rcallon@wellfleet.com In-Reply-To: <9312061720.AA02772@cabernet.wellfleet> from "Ross Callon" at Dec 6, 93 12:20:35 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: 469 >--------- Text sent by Ross Callon follows: > > > Topological Flexibility -- What topology is anticipated for the > Internet? Will the current general topology model continue? Is > it acceptable (or even necessary) to place significant topological > restrictions on interconnectivity of networks? > > > Applicability -- What environment / marketplace do you see > for the application of IPng? How much wider is it than the existing IP market? - Brian From brian@dxcoms.cern.ch Tue Dec 7 10:24:14 1993 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.4/8.6.4) with SMTP id EAA28500 for ; Tue, 7 Dec 1993 04:24:50 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA19123; Tue, 7 Dec 1993 10:24:16 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA27935; Tue, 7 Dec 1993 10:24:15 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9312070924.AA27935@dxcoms.cern.ch> Subject: IPng proposal overviews To: ipng@cmf.nrl.navy.mil Date: Tue, 7 Dec 1993 10:24:14 +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: 2061 Hi IPng people, There wasn't time in the conference call last night for me to say what I thought about the proposal overviews. I place a very high value on receiving an overview of each proposal - of course it could perfectly well be the introduction to a full description - but I would like each overview to have roughly the same contents. These overviews need to be written by the proponents, not by a third party, so that no proponent feels short-changed. Given that there will also be full descriptions, the overviews could be less than 10 pages, and they should be technical descriptions, not philosophies of life or sales documents. Here is a strawman: the main headings I would like to see in each overview. I've deliberately written this without looking again at what the proponents have already written. Comments/flames welcome. Brian IPng Proposal Overview ====================== 1. Name of proposal; origin(s) of proposal. 2. Addressing scheme; address allocation plan. (Including: any support of provider-based or geographical addressing? Any support of end-system IDs?) 3. Summary of packet format. (Yes, up front, let's be practical). 4. Summary of deployment plan and transition mechanism from Ipv4. 5. Does proposal support all basic IPv4 and ICMP functions? If not, what are the exceptions? 6. How does proposal interwork with IPv4 hosts and routers? (Including: are IPv4 addresses encodable within addressing scheme? 7. Which existing routing protocols can be used? (If modifications are needed, specify them.) 8. How does proposal support multicast? 9. How does proposal support flows? 10. How does proposal support portables and mobiles? 11. How does proposal support automatic configuration? ARP? 12. Is any new routing protocol proposed? 13. How does proposal support policy based routing? 14. Is there any support for security features? 15. Is there any support for accounting features? 16. Implementation issues in hosts and routers. 98. Miscellaneous remarks. 99. List of current documents. --- From sob@hsdndev.harvard.edu Tue Dec 7 07:09:28 1993 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.4/8.6.4) with SMTP id HAA29244 for ; Tue, 7 Dec 1993 07:09:40 -0500 Date: Tue, 7 Dec 93 07:09:28 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9312071209.AA14421@hsdndev.harvard.edu> To: Brian.Carpenter@cern.ch Subject: Re: Proposed wording for topology flexibility and applicability sections Cc: ipng@cmf.nrl.navy.mil > How much wider is it than the existing IP market? good point! Scott From rcallon@wellfleet.com Tue Dec 7 10:45:08 1993 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA01416 for ; Tue, 7 Dec 1993 10:42:09 -0500 Received: from pobox.wellfleet ([192.32.75.5]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA04201; Tue, 7 Dec 93 10:29:15 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA09385; Tue, 7 Dec 93 10:37:32 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA02953; Tue, 7 Dec 93 10:45:08 EST Date: Tue, 7 Dec 93 10:45:08 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9312071545.AA02953@cabernet.wellfleet> To: Brian.Carpenter@cern.ch Subject: Re: Proposed wording for topology flexibility and applicability sections Cc: ipng@cmf.nrl.navy.mil, rcallon@wellfleet.com > > Applicability -- What environment / marketplace do you see > for the application of IPng? How much wider is it than the existing IP market? Brian; I thought that the point was to ask the reviewers this precise question (I don't want to answer the question, I want to ask a wide range of folks this question). But, for my answer: when cable, telephone, and data merge, they are going to use something. Either this will be IPng, or else the biggest market will end up being something other than IPng. I would not be shocked if the big cable operators were a bit nervous about jumping on the IPng bandwagon at this time. Ross From mankin Tue Dec 7 19:12:49 1993 Return-Path: mankin Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id TAA08953 for ; Tue, 7 Dec 1993 19:12:58 -0500 From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA04141; Tue, 7 Dec 93 19:12:49 EST Date: Tue, 7 Dec 93 19:12:49 EST Message-Id: <9312080012.AA04141@radegond.cmf.nrl.navy.mil> To: ipng Subject: The Real Proposal Documents Hi, This is to remind you Proponents from Scott and me to send the complete list of current documents to the ipng list. Besides illuminating the directorate, your lists will be used to winnow out the contents of the IPng Web Server, which is now in partly constructed form at http://www.uu.net. Thanks, Allison / mankin@cmf.nrl.navy.mil From scoya@CNRI.Reston.VA.US Tue Dec 7 17:39:44 1993 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.4/8.6.4) with SMTP id UAA09191 for ; Tue, 7 Dec 1993 20:09:09 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14486; 7 Dec 93 17:39 EST To: ipng@cmf.nrl.navy.mil Subject: DRAFT minutes from December 6 teleconference Date: Tue, 07 Dec 93 17:39:44 -0500 From: Steve Coya Message-ID: <9312071739.aa14486@IETF.CNRI.Reston.VA.US> DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * DRAFT * INPG Directorate Teleconference December 6 , 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 J Allard / Mircosoft Steve Bellovin / AT&T Jim Bound / DEC Ross Callon / Wellfleet Brian Carpenter / CERN John Curran / NEARnet Steve Deering /Xerox PARC Dino Farinacci / Cisco Eric Fleischman / Boeing Mark Knopper / MERIT Paul Mockapetris / ISI Rob Ullmann / Lotus Regrets ------- Dave Clark / MIT Paul Francis / Bellcore Daniel Karrenberg / RIPE Greg Minshall / Novell Lixia Zhang / Xerox PARC 1. The minutes from the November 22 teleconference were approved. Coya to make minutes available on the IETF shadow directories. 2. Comments were solicitied on the white paper outlines. A number of topics were discussed (implementation costs, performance, accounting, policy-based routing, etc.). Revised text submissions are to be sent via e-mail. A revised white paper outline will be distributed to the directorate members for review prior to public distribution. The Directorate was requested to submit names of potential authors for white papers. 3. It was decided that the deadline for white paper submissions should be set to February 1, 1994. This should give sufficient time for review, returning comments to the authors for revisions, and getting revisions out before the IETF meeting in Seattle (last week of March). 4. The ALE Working Group charter was reviewed. A question was raised as to whether the wg should also consider the routing table exhaustion problem as part of its charter, in addition to focusing on address space usage. Another topic was whether the ALE WG should be asked to evaluate IP address proposals. Ross Callon is going to search for a paper he started on the use of hidden addresses and sent it to the IPNG list. A revised WG Charter is to be sent to both the IPNG Directorate and the ALE WG. 5. It was proposed that the white papers to be written by the candidate proponents should be considered as good overviews with highlights and summaries more than white papers. There were comments on what should and should not be included in these overview documents. It was noted that all candidtates had been invited to write articles for ConneXions, and these articles might meet the requirements for the overview documents requested by the IPNG Direcotorate. All proponents were ask to prepare a list of documents (and where they can be found) and make the list available. This would provide a bibliography for anyone interested in more detailed reading and/or analysis, especially after reading the proponent documents.