Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16727; 3 May 93 10:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16722; 3 May 93 10:50 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa04787; 3 May 93 10:49 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA14190; Mon, 3 May 93 08:46:14 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA09538; Mon, 3 May 93 08:42:53 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA09534; Mon, 3 May 93 08:42:52 MDT Received: from dnlts0.research.ptt.nl by p.lanl.gov (5.65/1.14) id AA14022; Mon, 3 May 93 08:42:49 -0600 Received: from research.ptt.nl by research.ptt.nl (PMDF #2928 ) id <01GXQUB3BMLCBJVAR7@research.ptt.nl>; Mon, 3 May 1993 16:44:02 +0200 Date: 03 May 1993 16:44:01 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ALEX REIJNIERSE Subject: TUBA demo at JENC93 To: tuba@lanl.gov Message-Id: <01GXQUB3BMLEBJVAR7@research.ptt.nl> Organization: PTT Research, The Netherlands X-Envelope-To: tuba@lanl.gov X-Vms-To: IN%"tuba@lanl.gov" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Comments: This mail was sent by PMDF V4.1 Hello TUBA fanatics, Next week we are going to perform a TUBA demo at the Joint European Networking Conference (JENC93). However, there is still a need for some NSAPs of systems that can do TUBA. If you want to participate (set up a TUBA system we can telnet to for example) please respond by filling in the short form below. JENC93 is from may 9th to may 13th. ------------------------------------------------ Name: Organisation: Geographic location: Type of System(s): Application(s): NSAP(s): Password(s): optional, preferrably 'JENC93' ------------------------------------------------ Thanks in advance Alex Reijnierse PTT Research The Netherlands   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17543; 3 May 93 11:28 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06866; 3 May 93 11:28 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17534; 3 May 93 11:28 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17496; 3 May 93 11:28 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: tuba@lanl.gov Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-tuba-sysids-00.txt Date: Mon, 03 May 93 11:27:55 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9305031128.aa17496@IETF.CNRI.Reston.VA.US> --NextPart A New Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP/UDP over CLNP-addressed Networks Working Group of the IETF. Title : Assignment of System Identifiers for TUBA/CLNP Hosts Author(s) : D. Piscitello Filename : draft-ietf-tuba-sysids-00.txt Pages : 7 This document describes conventions whereby the system identifier portion of an RFC1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. The mechanism is extensible and can provide a basis for assigning system identifiers in a globally unique fashion. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-tuba-sysids-00.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-tuba-sysids-00.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-tuba-sysids-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tuba-sysids-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11192; 4 May 93 15:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11188; 4 May 93 15:33 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa20559; 4 May 93 15:33 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA29888; Tue, 4 May 93 13:27:29 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18991; Tue, 4 May 93 13:26:01 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18987; Tue, 4 May 93 13:26:00 MDT Received: from mail.bellcore.com by p.lanl.gov (5.65/1.14) id AA29653; Tue, 4 May 93 13:25:55 -0600 Received: from [128.96.90.196] (mac16.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA26064; Tue, 4 May 1993 15:22:53 -0400 Message-Id: <199305041922.AA26064@mail.bellcore.com> Date: Tue, 4 May 1993 15:31:41 -0500 To: tuba@lanl.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dave@mail.bellcore.com Subject: errors in System Id's for TUBA internet-draft Apologies to all, but I botched the bit assignments in the system identifiers for TUBA/CLNP. Please make the following changes; I'll post a new draft when I get a sense of how important/irrelevant this is to folks on the list (in other words, READ AND COMMENT!) page 4, section 3.1, line 4: replace "QQ equals 10 or 11" with "QQ equals "00 or 01" page 5, Figure 4: octet 1 should have a value "VVVV VV00" page 5, section 4, line 1: replace "QQ = 00" with "QQ = 10" page 5, Figures 5 & 6: octet 1 should have a value "0000 0010" many thanks to Rich Colella for catching this early! --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) =======> I am now "dave@mail.bellcore.com"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12557; 4 May 93 16:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12542; 4 May 93 16:38 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa23778; 4 May 93 16:38 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA04416; Tue, 4 May 93 14:29:19 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19395; Tue, 4 May 93 14:27:52 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19391; Tue, 4 May 93 14:27:52 MDT Received: from vangogh.CS.Berkeley.EDU by p.lanl.gov (5.65/1.14) id AA04305; Tue, 4 May 93 14:27:51 -0600 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (ALPHA-6.55/6.25) id NAA08586; Tue, 4 May 1993 13:27:34 -0700 Date: Tue, 4 May 1993 13:27:34 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199305042027.NAA08586@vangogh.CS.Berkeley.EDU> To: tuba@lanl.gov Subject: a non-tirade tirade about tuba-sysids I think this is a good document. It is very clearly and cogently written, and it explicitly does not say certain things: 1.) This document DOES NOT SAY that tuba-sysids will be used apart from the NSAPs for identifying TCP connections 2.) This document DOES NOT SAY that tuba-sysids will necessarily be limited to 6 bytes {I think that time will tell how practical it is to administer a flat space of 6 bytes (or even 8 bytes for that matter)} The document addresses my concerns so well that you won't see any alternative proposal from me. Thanks for an excellent job, Dave!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14141; 4 May 93 17:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14132; 4 May 93 17:31 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa25859; 4 May 93 17:31 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA13311; Tue, 4 May 93 15:29:34 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA20045; Tue, 4 May 93 15:28:51 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA20041; Tue, 4 May 93 15:28:50 MDT Received: from regal.cisco.com by p.lanl.gov (5.65/1.14) id AA13240; Tue, 4 May 93 15:28:48 -0600 Received: by regal.cisco.com; Tue, 4 May 1993 14:28:44 -0700 Date: Tue, 4 May 1993 14:28:44 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Katz Message-Id: <199305042128.AA23071@regal.cisco.com> To: tuba@lanl.gov In-Reply-To: Keith Sklower's message of Tue, 4 May 1993 13:27:34 -0700 <199305042027.NAA08586@vangogh.CS.Berkeley.EDU> Subject: sysids A few minor comments on the sysid draft-- 10589 does not allow 0-length system IDs (I believe it to be impossible to do this, except in the case where the routing domain consists solely of a single router). Fix the sentence at the end of the first paragraph on page 4. The first paragraph of section 5, page 4, says that the IP address is encoded in "hexadecimal". I think this should probably just say "binary"; otherwise it might be confusing. (I'm sensitive to this after sitting through multiple attempts at changing 8348 to allow AFI values with hex digits in them...) I think the discussion of autoconfiguration should mention 9542 DAM1, the address assignment mechanism (Lyman can let you know what the official standing of this document is--the DAM ballot may already have closed). I would personally like to deprecate the "clever ES" approach to autoconfiguration; nasty things tend to happen when the area has multiple area addresses, for instance. Of course, when the router does the address assignment, it is harder for it to pick a system ID as anything other than the MAC address. Otherwise, it looks good.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01031; 5 May 93 7:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01027; 5 May 93 7:04 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa04917; 5 May 93 7:04 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA02674; Wed, 5 May 93 05:02:13 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA21583; Wed, 5 May 93 05:01:13 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA21579; Wed, 5 May 93 05:01:12 MDT Received: from ns.dknet.dk by p.lanl.gov (5.65/1.14) id AA02648; Wed, 5 May 93 05:01:09 -0600 Received: by ns.dknet.dk with UUCP id AA17217 (5.65c8/IDA-1.4.4j for tuba@lanl.gov); Wed, 5 May 1993 13:01:28 +0200 Received: by leo.tbit.dk (5.65/j1.1.7) id AA23905; Wed, 5 May 93 10:59:26 GMT Date: Wed, 5 May 93 10:59:26 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Peder Chr. Norgaard" Message-Id: <9305051059.AA23905@leo.tbit.dk> To: tuba@lanl.gov Subject: BSDi and TUBA - what, where? X-Charset: ASCII X-Char-Esc: 29 Hello, at the TUBA meeting at the IETF in Columbus it was mentioned that the BSDi system is a good choice for TUBA implementations. Will someone please point me to source for BSDi and the current CLNS and TUBA enhancements? Best regards Peder Chr. Norgaard, Telebit Communications Aps, Denmark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01952; 6 May 93 8:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01948; 6 May 93 8:26 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa07004; 6 May 93 8:26 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA22828; Thu, 6 May 93 06:17:59 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA27042; Thu, 6 May 93 06:16:53 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA27038; Thu, 6 May 93 06:16:50 MDT Received: from dnlts0.research.ptt.nl by p.lanl.gov (5.65/1.14) id AA22798; Thu, 6 May 93 06:16:39 -0600 Received: from research.ptt.nl by research.ptt.nl (PMDF #2928 ) id <01GXUUYF9STCBJVGJI@research.ptt.nl>; Thu, 6 May 1993 14:14:10 +0200 Date: 06 May 1993 14:14:10 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ALEX REIJNIERSE Subject: TUBA demonstration To: dino@cisco.com Cc: reb@noc.ans.net, cjw@barrnet.net, colella@nist.gov, trouble@noc.ans.net, ie@merit.edu, dave@mail.bellcore.com, stev@ftp.com, victor.reijs@surfnet.nl, tuba@lanl.gov, wg4-clns@funet.fi, sn3plus-clns@surfnet.nl, cmj@nsd.3com.com, mak@merit.edu, skh@merit.edu Message-Id: <01GXUUYF9STEBJVGJI@research.ptt.nl> Organization: PTT Research, The Netherlands X-Envelope-To: tuba@lanl.gov X-Vms-To: IN%"dino@cisco.com" X-Vms-Cc: IN%"reb@noc.ans.net", IN%"cjw@barrnet.net", IN%"colella@nist.gov", IN%"trouble@noc.ans.net", IN%"ie@merit.edu", IN%"dave@mail.bellcore.com", IN%"stev@ftp.com", IN%"victor.reijs@surfnet.nl", IN%"tuba@lanl.gov", IN%"wg4-clns@funet.fi", IN%"sn3plus-clns@surfnet.nl", IN%"cmj@nsd.3com.com", IN%"mak@merit.edu", IN%"skh@merit.edu", IN%"peter@goshawk@lanl.gov" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Comments: This mail was sent by PMDF V4.1 Well, how's that for a multicast mail. Hello everybody, This way i want to thank you all for participating in the TUBA demonstration at the Joint European Networking Conference (JENC93). I have had a lot of support from you all what resulted in a lot of TUBA connectivity over the world. Below follows a list of systems that will participate in this demo. Some of them are still not reachable at this moment, but i hope they will be next week. I will indicate at the end of the list what systems they are, so that the appropriate people can react. Keep it up from may 9th until may 13th!!!! (at least) Current participants: PTT Research - The Netherlands Universidad Politecnica de Madrid - Spain Universitetet Trondheim - Norway NIST - US 3Com corporation - US Cisco Systems - US MERIT - US LANL - US France has some TUBA systems availble, but lacks CLNS connectivity at this moment. Maybe they will join in later. If anyone wants to join in, please let me know. - Alex Reijnierse, PTT Research, The Netherlands ------------------ TUBA System list ------------------ ####### ####### Alex Reijnierse (A.A.Reijnierse@research.ptt.nl) ####### The Netherlands - PTT Research name=tuba10.research.ptt.nl; # NCSA PC hostnsap=39528F11000009100000000040bbbbaaaa001000; name=tuba20.research.ptt.nl; # NCSA PC hostnsap=39528F11000009100000000040bbbbaaaa002000; name=lsdm10.research.ptt.nl; # Cisco router hostnsap=39528F1100000910000000004000000c03df7d00; ####### ####### David Fernandez (david@dit.upm.es) ####### Spain - Universidad Politecnica de Madrid (UPM) name=cisco_iso.upm.dit.es; # Cisco router hostnsap=39724F1001000000020001000113800400200900; name=tuba-pc.upm.dit.es; # NCSA PC hostnsap=39724F1001000000020001000100000000001000; ####### ####### Richard Colella (colella@nist.gov) ####### US - National Institute of Standards and Technology (NIST) name=cursive.ncsl.nist.gov; # NCSA PC hostnsap=47000580005a0000000001e137eeeeee00008500; name=cisco1.ncsl.nist.gov; # Cisco router hostnsap=47000580005a0000000001e13788888800018100; name=3com1.ncsl.nist.gov; # 3Com router hostnsap=47000580005a0000000001e13711111100011100; ####### ####### Cyndi Jung (cmj@nsd.3com.com) ####### US - 3Com corporation name=tuba1.3com.com; # 3Com router hostnsap=4700040035110011111111111100; name=tuba2.3com.com; # ? hostnsap=4700040035110022222222222200; ####### ####### Dino Farinacci (dino@cisco.com) ####### US - Cisco Systems name=red.cisco.com; # Cisco router hostnsap=47000580ffef0000000001594016008906402200 ####### ####### Mark Knopper/Susan Hares (mak@merit.edu/skh@merit.edu) ####### US - merit.edu name=glasshouse.merit.edu # RS/6000 hostnsap=47000580ffff000000040000000000232a015500 name=michnetx.merit.edu # ? hostnsap=47000580ffff0000000400000000002301010b00 name=tschapperl.merit.edu # NCSA PC hostnsap=47000580ffff000000040000000000232a015e00 ####### ####### Peter Ford ####### US - lanl.gov name=maze.lanl.gov; # BSDi/4.4 hostnsap=4700058000570000000140000102608cae456c00 ----------------- Not Reachable yet --------------- - tuba2.3com.com - glasshouse.merit.edu - tschapperl.merit.edu - maze.lanl.gov I can reach other systems at 3com.com and merit.edu so i suppose that these systems are not up yet. Can someone answer me what the status is? The last system i can reach at lanl is: 4700058000570000000140000100000c016c3900 Is maze not up? Then still some questions. What kind of system is tuba2.3com.com? what kind of system is glasshouse.merit.edu? what kind of system is michnetx.merit.edu? what kind of system is maze.lanl.gov? - Alex   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07817; 6 May 93 14:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07813; 6 May 93 14:14 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa18108; 6 May 93 14:14 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA11428; Thu, 6 May 93 12:09:47 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29339; Thu, 6 May 93 12:09:08 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29335; Thu, 6 May 93 12:09:06 MDT Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA11367; Thu, 6 May 93 12:08:35 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA12067; Thu, 6 May 93 12:08:34 MDT Message-Id: <9305061808.AA12067@goshawk.lanl.gov> To: ALEX REIJNIERSE Cc: dino@cisco.com, reb@noc.ans.net, cjw@barrnet.net, colella@nist.gov, trouble@noc.ans.net, ie@merit.edu, dave@mail.bellcore.com, stev@ftp.com, victor.reijs@surfnet.nl, tuba@lanl.gov, wg4-clns@funet.fi, sn3plus-clns@surfnet.nl, cmj@nsd.3com.com, mak@merit.edu, skh@merit.edu Subject: Re: TUBA demonstration In-Reply-To: Your message of 06 May 93 14:14:10 +0200. <01GXUUYF9STEBJVGJI@research.ptt.nl> Date: Thu, 06 May 93 12:08:34 MST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: peter@goshawk.lanl.gov Current LANL CLNS systems up and running. cisco-ldcc-open.lanl.gov 47.00.05.80.00.57.00.00.00.01.40.00.01.00.00.0C.01.6C.39.00 cisco-fire1.lanl.gov 47.00.05.80.00.57.00.00.00.01.40.00.01.00.00.0C.01.06.EC.00 tuba.lanl.gov 47.00.05.80.00.57.00.00.00.01.40.00.01.00.60.8c.b1.1e.b8.00 maze.lanl.gov 47.00.05.80.00.57.00.00.00.01.40.00.01.fe.ed.ed.fe.ed.ed.00 tuba.lanl.gov is a 486 PC running BSDI w/tuba implementation currently will support tuba telnet daemon. maze.lanl.gov is a 386 PC running DOS and Colella TUBA telnet If you want to telnet to tuba.lanl.gov using TUBA telnet please let me know (mail peter@goshawk.lanl.gov) I have a mechanism for this which is not pretty, but it will suffice for demo purposes. cheers, peter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11863; 6 May 93 16:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11859; 6 May 93 16:19 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa22321; 6 May 93 16:19 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA18152; Thu, 6 May 93 14:12:36 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00303; Thu, 6 May 93 14:11:52 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00299; Thu, 6 May 93 14:11:50 MDT Received: from regal.cisco.com by p.lanl.gov (5.65/1.14) id AA18086; Thu, 6 May 93 14:11:49 -0600 Received: by regal.cisco.com; Thu, 6 May 1993 13:11:14 -0700 Date: Thu, 6 May 1993 13:11:14 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dino Farinacci Message-Id: <199305062011.AA20448@regal.cisco.com> To: peter@goshawk.lanl.gov Cc: A.A.Reijnierse@research.ptt.nl, reb@noc.ans.net, cjw@barrnet.net, colella@nist.gov, trouble@noc.ans.net, ie@merit.edu, dave@mail.bellcore.com, stev@ftp.com, victor.reijs@surfnet.nl, tuba@lanl.gov, wg4-clns@funet.fi, sn3plus-clns@surfnet.nl, cmj@nsd.3com.com, mak@merit.edu, skh@merit.edu In-Reply-To: peter@goshawk.lanl.gov's message of Thu, 06 May 93 12:08:34 MST <9305061808.AA12067@goshawk.lanl.gov> Subject: TUBA demonstration Current cisco CLNS systems up and running for JENC '93 demo. red.cisco.com - 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4022.00 There are two CLNS external accesses to red, one through Barrnet and one through an IP tunnel to NIST. Dino   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12325; 6 May 93 16:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12317; 6 May 93 16:36 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa23070; 6 May 93 16:36 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA18757; Thu, 6 May 93 14:28:41 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00572; Thu, 6 May 93 14:27:56 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00567; Thu, 6 May 93 14:27:54 MDT Received: from EMU.NCSL.NIST.GOV by p.lanl.gov (5.65/1.14) id AA18722; Thu, 6 May 93 14:27:53 -0600 Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA02255; Thu, 6 May 93 16:30:26 EDT Date: Thu, 6 May 93 16:30:26 EDT Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9305062030.AA02255@emu.ncsl.nist.gov> To: tuba@lanl.gov Subject: The beast has changed its spots.... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: colella@nist.gov Reply-To: colella@nist.gov I was looking around in gopherspace and came upon the entry "TCP/UDP over CLNP-addressed Networks (tuba)" Calling it up I discovered it contained the following: FDDI MIB (fddimib) ------------------ Charter Chair(s): Jeffrey Case Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:fddi-mib@CS.UTK.EDU To Subscribe: fddi-mib-request@CS.UTK.EDU Archive: Description of Working Group: The FDDI MIB Working Group is chartered to define a MIB for FDDI devices that is consistent with relevant FDDI specifications produced by ANSI. All definitions produced by this Working Group will be consistent with the SNMP network management framework and other internet-standard MIBs for SNMP. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 Mar 93 FDDI Management Information Base Go figure. --Richard   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01330; 7 May 93 6:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01326; 7 May 93 6:55 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa04588; 7 May 93 6:54 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA13578; Fri, 7 May 93 04:48:58 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03474; Fri, 7 May 93 04:47:59 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03470; Fri, 7 May 93 04:47:54 MDT Received: from aun.uninett.no by p.lanl.gov (5.65/1.14) id AA13566; Fri, 7 May 93 04:47:51 -0600 X400-Received: by mta aun.uninett.no in /PRMD=uninett/ADMD= /C=no/; Relayed; Fri, 7 May 1993 12:45:23 +0200 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Fri, 7 May 1993 12:45:15 +0200 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Fri, 7 May 1993 12:45:12 +0200 Date: Fri, 7 May 1993 12:45:12 +0200 X400-Originator: Olav.Kvittem@delab.sintef.no X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;930507124512] X400-Content-Type: P2-1984 (2) Content-Identifier: 4885 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Olav.Kvittem@delab.sintef.no Message-Id: <4885*/G=Olav/S=Kvittem/OU=delab/O=sintef/PRMD=uninett/C=no/@MHS> To: ALEX REIJNIERSE Cc: dino , reb , cjw , colella , trouble , ie , dave , stev , "victor.reijs" , tuba , wg4-clns , sn3plus-clns , cmj , mak , skh In-Reply-To: <01GXUUYF9STEBJVGJI@research.ptt.nl> Subject: Trondheim Tuba Reachability May 7 12:35 Hei, I have edited the file from Alex to fit osi_ping and here are the results. Olav CLNP Reachability check Fri May 7 12:35:04 MET DST 1993 ------------------------------------------------------------------ run from ES: odda program: tuba_ping possible IS: sintef-gw -- packets --- round-trip (ms) Hostname sent rcvd succ min avg max ----------------------------------------------------------------- tuba10.research.ptt.nl 10 10 100% 569 939 2054 tuba20.research.ptt.nl 10 0 0% 0 0 0 lsdm10.research.ptt.nl 10 10 100% 550 1052 2693 cisco_iso.upm.dit.es 10 10 100% 458 1806 4613 tuba-pc.upm.dit.es 10 10 100% 512 833 2434 cursive.ncsl.nist.gov Header syntax error cisco1.ncsl.nist.gov Header syntax error 3com1.ncsl.nist.gov Header syntax error tuba1.3com.com 10 0 0% 0 0 0 tuba2.3com.com Destination address unreachable red.cisco.com 10 10 100% 543 1309 3546 glasshouse.merit.edu 10 0 0% 0 0 0 michnetx.merit.edu 10 10 100% 1073 5602 1013 tschapperl.merit.edu 10 0 0% 0 0 0 maze.lanl.gov 10 0 0% 0 0 0 Olav   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02301; 7 May 93 8:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02297; 7 May 93 8:44 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa07559; 7 May 93 8:44 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA14884; Fri, 7 May 93 06:38:12 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03572; Fri, 7 May 93 06:37:09 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03568; Fri, 7 May 93 06:37:08 MDT Received: from EMU.NCSL.NIST.GOV by p.lanl.gov (5.65/1.14) id AA14867; Fri, 7 May 93 06:37:04 -0600 Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA03166; Fri, 7 May 93 08:36:37 EDT Date: Fri, 7 May 93 08:36:37 EDT Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9305071236.AA03166@emu.ncsl.nist.gov> To: A.A.Reijnierse@research.ptt.nl, Olav.Kvittem@delab.sintef.no Subject: Re: Trondheim Tuba Reachability May 7 12:35 Cc: dino@cisco.com, reb@noc.ans.net, cjw@barrnet.net, colella@nist.gov, trouble@noc.ans.net, ie@merit.edu, dave@mail.bellcore.com, stev@ftp.com, victor.reijs@surfnet.nl, tuba@lanl.gov, wg4-clns@funet.fi, sn3plus-clns@surfnet.nl, cmj@nsd.3com.com, mak@merit.edu, skh@merit.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: colella@nist.gov Reply-To: colella@nist.gov Olav, > cursive.ncsl.nist.gov Header syntax error > cisco1.ncsl.nist.gov Header syntax error > 3com1.ncsl.nist.gov Header syntax error The reason for this ping result is that all three systems are sitting behind a Sun3, which doesn't support the new ping. (It's due to be upgraded in a few weeks to a Sparc). Using telnet I verified that I can reach tuba10.research.ptt.nl, lsdm10.research.ptt.nl, cisco_iso.upm.dit.es, tuba-pc.upm.dit.es, tuba1.3com.com, michnetx.merit.edu, and tuba1.3com.com. So connectivity is okay. maze.lanl.gov is also reachable (PC running NCSA Telnet), but you're probably using the wrong NSAP (I originally sent the wrong one to Alex). Try the NSAP below. There's also tuba.lanl.gov, which is a PC running BSDi/4.4 BSD. It's refusing connections at the moment, but is reachable. maze.lanl.gov default NULL /NS+47000580005700000001400001feededfeeded00 tuba.lanl.gov default NULL /NS+4700058000570000000140000100608cb11eb800 --Richard   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02629; 8 May 93 11:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02625; 8 May 93 11:19 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa09238; 8 May 93 11:19 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA16578; Sat, 8 May 93 09:14:47 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA10269; Sat, 8 May 93 09:08:19 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA10265; Sat, 8 May 93 09:08:15 MDT Received: from aun.uninett.no by p.lanl.gov (5.65/1.14) id AA16549; Sat, 8 May 93 09:08:14 -0600 X400-Received: by mta aun.uninett.no in /PRMD=uninett/ADMD= /C=no/; Relayed; Sat, 8 May 1993 17:07:25 +0200 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Sat, 8 May 1993 17:07:20 +0200 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Sat, 8 May 1993 17:07:17 +0200 Date: Sat, 8 May 1993 17:07:17 +0200 X400-Originator: Olav.Kvittem@delab.sintef.no X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;930508170717] X400-Content-Type: P2-1984 (2) Content-Identifier: 4898 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Olav.Kvittem" Message-Id: <4898*/G=Olav/S=Kvittem/OU=delab/O=sintef/PRMD=uninett/C=no/@MHS> To: ALEX REIJNIERSE Cc: dino , reb , cjw , colella , trouble , ie , dave , stev , "victor.reijs" , tuba , wg4-clns , sn3plus-clns , cmj , mak , skh In-Reply-To: <01GXUUYF9STEBJVGJI@research.ptt.nl> Subject: Trondheim Tuba ping May 8 16:37:2 Hei, Reachability can still be better ;-), but lets hope for monday afternoon when US-people come to work after weekend ! Olav CLNP Reachability check Sat May 8 16:37:24 MET DST 1993 ------------------------------------------------------------------ run from ES: odda selection: es.tuba program: net_ping possible IS: sintef-gw -- packets --- round-trip (ms) Hostname sent rcvd succ min avg max ----------------------------------------------------------------- tuba10.research.ptt.nl 10 10 100% 557 826 1902 tuba20.research.ptt.nl 10 10 100% 555 815 1667 lsdm10.research.ptt.nl 10 10 100% 547 1156 3020 cisco_iso.upm.dit.es 10 10 100% 431 1138 3666 tuba-pc.upm.dit.es 10 10 100% 474 613 1608 cursive.ncsl.nist.gov Lifetime expired while in transit cisco1.ncsl.nist.gov Lifetime expired while in transit 3com1.ncsl.nist.gov Lifetime expired while in transit tuba1.3com.com Lifetime expired while in transit tuba2.3com.com Lifetime expired while in transit red.cisco.com 10 10 100% 378 613 1515 glasshouse.merit.edu 10 0 0% 0 0 0 michnetx.merit.edu 10 10 100% 327 500 1648 tschapperl.merit.edu 10 0 0% 0 0 0 maze.lanl.gov 10 9 90% 438 612 1632 rice1 10 0 0% 0 0 0 verge 10 0 0% 0 0 0 dallas 10 0 0% 0 0 0 psp-11-10 Destination address unreachable Increasing lifetime did not help : osi_ping -t 1000 cursive.ncsl.nist.gov rror PDU from 47000580ffff000000000100000000818c090f00: Reason for discard: Lifetime expired while in transit , Error offset 0, Olav   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12464; 9 May 93 17:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12460; 9 May 93 17:39 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa18519; 9 May 93 17:39 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA05601; Sun, 9 May 93 15:37:53 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA11581; Sun, 9 May 93 15:36:44 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA11577; Sun, 9 May 93 15:36:42 MDT Received: from yggdrasil.jenc93.uninett.no by p.lanl.gov (5.65/1.14) id AA05581; Sun, 9 May 93 15:36:36 -0600 Received: from valhall.jenc93.uninett.no by yggdrasil.jenc93.uninett.no with SMTP id AA03189 (5.65c/IDA-1.4.4 for ); Sun, 9 May 1993 23:34:56 +0200 Received: from localhost by valhall.jenc93.uninett.no (4.1/Uninett-C-1.4) id AA00668; Sun, 9 May 93 23:34:55 +0200 Message-Id: <9305092134.AA00668@valhall.jenc93.uninett.no> To: tuba@lanl.gov Cc: cmj@nsd.3com.com, skh@merit.edu, colella@nist.gov, dino@cisco.com Subject: TUBA connectivity from Trondheim Date: Sun, 09 May 1993 23:34:54 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alex Reijnierse Hello All, Today we have configured TUBA here on one PC and we are going to configure the cisco in a minute. Configuring and connectivity was not without problems, but then again, what is? Tomorrow, when we have another ethernet card, the other PC will be up too. So far so good. However, there are still some systems not reachable from here. Probably three out of four of these systems are not up (yet). This leaves only tuba1.3com.com that we cannot reach. When tracing, loops occur between some nsf backbone router and fix-sura. Could someone check (Cyndi?) what is going on? THe systems you should be able to reach here are: Tuba-1.jenc93.uninett.no 47.0023.0000.0005.0000.0002.0102.1292.4116.0022.00 Tuba-2.jenc93.uninett.no 47.0023.0000.0005.0000.0002.0102.1292.4116.0023.00 Cisco.jenc93.uninett.no 47.0023.0000.0005.0000.0002.0102.1292.4116.0024.00 - Alex P.S. Please mail me to this address in stead of the other one. .   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14789; 9 May 93 23:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14785; 9 May 93 23:41 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa24784; 9 May 93 23:41 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA08558; Sun, 9 May 93 21:39:54 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA11765; Sun, 9 May 93 21:39:32 MDT Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA11761; Sun, 9 May 93 21:39:31 MDT Received: from merit.edu by p.lanl.gov (5.65/1.14) id AA08546; Sun, 9 May 93 21:39:33 -0600 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA23648; Sun, 9 May 93 23:39:32 -0400 Message-Id: <9305100339.AA23648@merit.edu> To: tuba@lanl.gov Subject: International Tuba Day was May 7 Date: Sun, 09 May 1993 23:39:32 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Knopper FYI, perhaps we can have a retroactive celebration of this? Mark > From: "Steven J. Richardson" > To: mak@merit.edu > ...is "International Tuba Day"--announced on WQRS, a classical music > station hiding out at 105.1 FM... > > Thought you'd like to know, > > SJR   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03496; 10 May 93 16:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03492; 10 May 93 16:50 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa23899; 10 May 93 16:50 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA23143; Mon, 10 May 93 14:45:39 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA15004; Mon, 10 May 93 14:44:24 MDT Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14996; Mon, 10 May 93 14:44:21 MDT Received: from merit.edu by p.lanl.gov (5.65/1.14) id AA23047; Mon, 10 May 93 14:44:05 -0600 Return-Path: Received: from fox.merit.edu by merit.edu (5.65/1123-1.0) id AA28030; Mon, 10 May 93 16:44:02 -0400 Received: by fox.merit.edu (5.65/client-0.9) id AA06761; Mon, 10 May 93 16:44:01 -0400 Date: Mon, 10 May 93 16:44:01 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: mak@merit.edu Message-Id: <9305102044.AA06761@fox.merit.edu> To: tuba@lanl.gov Subject: Re: Today! ------- Forwarded Message Date: Mon, 10 May 1993 10:22:39 EDT To: Mark Knopper From: "Steven J. Richardson" Subject: Re: Today! Return-Path: sjr In-Reply-To: Your message of Sun, 09 May 1993 23:40:20 EDT. <9305100340.AA23873@merit.edu> International Tuba Day was also celebrated on the Tonight Show, as Brandon got together a group of Tubas...(several interoperable implementations ;-)... sjr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06310; 11 May 93 11:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06302; 11 May 93 11:41 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa12642; 11 May 93 11:41 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA28639; Tue, 11 May 93 09:27:28 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA17867; Tue, 11 May 93 09:24:24 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA17863; Tue, 11 May 93 09:24:23 MDT Received: from yggdrasil.jenc93.uninett.no by p.lanl.gov (5.65/1.14) id AA28513; Tue, 11 May 93 09:24:21 -0600 Received: from valhall.jenc93.uninett.no by yggdrasil.jenc93.uninett.no with SMTP id AA06491 (5.65c/IDA-1.4.4 for ); Tue, 11 May 1993 17:24:08 +0200 Received: from localhost by valhall.jenc93.uninett.no (4.1/Uninett-C-1.4) id AA02163; Tue, 11 May 93 17:24:07 +0200 Message-Id: <9305111524.AA02163@valhall.jenc93.uninett.no> To: tuba@lanl.gov Subject: TUBA connectivity? report Date: Tue, 11 May 1993 17:24:06 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alex Reijnierse Hello TUBA demonstration participants. Here are several traces of the TUBA connectivity from Trondheim. It seems that there are several looping problems between regionals and the NSFnet backbone. I hope that you can solve these problems quickly, so that we are able to demonstrate the whole thing. - Alex Begin tracing CLNP path (25 hop max) to tuba.lanl.gov : NS+4700058000570000000140000100608cb11eb800 TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] 1 - lsdm10.research.ptt.nl E- 208ms E- 11ms E- 12ms 2 - delft2.router.surfnet.nl E- 848ms E-1121ms E- 416ms 3 - amsterdam4.router.surfnet.nl E- 580ms E- 471ms E- 472ms 4 - amsterdam1.empb.net E- 802ms E- 676ms E- 676ms 5 - swieug.switch.ch E- 945ms E- 749ms E- 774ms 6 - swibe1.switch.ch E-1420ms E-2020ms E-1241ms 7 - swiez1.switch.ch E- 928ms E- 768ms E- 764ms 8 - swiez4.switch.ch E- 957ms E- 776ms E- 994ms 9 - 2nd.ctest1.cern.ch E-1026ms E- 815ms E-1411ms 10 - cern-gate.cern.ch E- E- E- 11 - psp-9-10.nsf.net E- E- E- 12 - umd-rt1.es.net E-1226ms E- 930ms E-1122ms 13 - psp-9-10.nsf.net E- E- E- 14 - umd-rt1.es.net E-1066ms E- 942ms E-1082ms 15 - psp-9-10.nsf.net E- E- E- 16 - umd-rt1.es.net E-1163ms E-1066ms E-1744ms 17 - psp-9-10.nsf.net E- E- E-^Cexplorer# explorer# Begin tracing CLNP path (25 hop max) to tuba1.3com.com : NS+4700040035110011111111111100 TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] 1 - lsdm10.research.ptt.nl E- 114ms E- 11ms E- 12ms 2 - delft2.router.surfnet.nl E- 678ms E-1190ms E- 591ms 3 - amsterdam4.router.surfnet.nl E- 566ms E- 459ms E- 460ms 4 - amsterdam1.empb.net E- 771ms E- 664ms E- 768ms 5 - swieug.switch.ch E- 994ms E- 879ms 6 - swieug.switch.ch E-2017ms 6 - swibe1.switch.ch E-1062ms E-1450ms 7 - swibe1.switch.ch E- 924ms 7 - swiez1.switch.ch E- 913ms E- 747ms 8 - swiez4.switch.ch E- 937ms E- 740ms E- 834ms 9 - 2nd.ctest1.cern.ch E-1090ms E- 800ms E- 783ms 10 - cern-gate.cern.ch E- E- E- 11 - psp-9-15.nsf.net E- E- E- 12 - fix-east.sura.net E-1264ms E-2302ms E-1477ms 13 - psp-9-15.nsf.net E- E- E- 14 - fix-east.sura.net E-1104ms E-1025ms ^Cexplorer# explorer# TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] 1 - lsdm10.research.ptt.nl E- 127ms E- 11ms E- 17ms 2 - delft2.router.surfnet.nl E- 521ms E-1069ms 3 - delft2.router.surfnet.nl E-1567ms 3 - amsterdam4.router.surfnet.nl E- 575ms E- 472ms 4 - amsterdam1.empb.net E- 786ms E- 680ms E- 700ms 5 - swieug.switch.ch E- 936ms E- 755ms E- 750ms 6 - swibe1.switch.ch E-1012ms E-2012ms E-1240ms 7 - swiez1.switch.ch E-1576ms E- 824ms E- 808ms 8 - swiez4.switch.ch E- 943ms E- 771ms E- 826ms 9 - 2nd.ctest1.cern.ch E-1013ms E- 884ms E- 831ms 10 - cern-gate.cern.ch E- E- E- 11 - psp-17-10.nsf.net E- E- E- 12 - michnet2.merit.edu E-1745ms E-1085ms E-1810ms 13 - 14 - 15 - 16 - 17 - - Alex P.S. Please include my e-mail address at jenc in your replies. From here i cannot read mail sent to my normal e-mail address.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06971; 11 May 93 12:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06967; 11 May 93 12:19 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa13906; 11 May 93 12:19 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA01260; Tue, 11 May 93 10:06:05 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18074; Tue, 11 May 93 10:03:41 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18070; Tue, 11 May 93 10:03:40 MDT Received: from BBN.COM by p.lanl.gov (5.65/1.14) id AA01115; Tue, 11 May 93 10:03:39 -0600 Message-Id: <9305111603.AA01115@p.lanl.gov> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Lyman Chapin Subject: CLNP second edition To: x3s33@merit.edu Cc: tuba@lanl.gov Date: Mon, 10 May 93 03:06:21 EDT Mail-System-Version: Thread Responsible person ------------------------------------------------------------------------ CLNP second edition Lyman Chapin (X3S3.3/93-143) - review of the second edition text in anticipation of a USA response to the SC6 call for comments prior to the SG 7 meeting at the end of June. This message is intended to open discussion of the second edition text of part 1 of ISO/IEC 8473 (CLNP). A postscript file of the second edition is available for anonymous ftp from the "iso" directory on merit.edu; I hope to be able to post an ASCII version soon. Keep in mind that the second edition text consists of material that has already made it through the ISO/IEC approval process - the subnetwork-independent part of the first edition of the standard, text changes adopted in response to defect reports (see X3S3.3/92-378, "ISO/IEC 8473 Technical Corrigendum 1 (resolving defect reports 8473/001 through 011)"), the new PICS proforma and conformance clause from Amendment 4 (X3S3.3/92-377), and the Echo function from Amendment 6 (X3S3.3/92-376). It does not include the multicast extensions contained in proposed amendment 7 (X3S3.3/93-104), nor does it include the changes that are anticipated by the new project on extensibility, quality of service, and record route timestamps (X3S3.3/93-94). Please send comments to the "x3s33@merit.edu" list. All comments received before the X3S3.3 meeting begins on June 2 will be considered in the preparation of the recommended US response to the call for comments. - Lyman   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07048; 11 May 93 12:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07044; 11 May 93 12:22 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa14038; 11 May 93 12:22 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA01264; Tue, 11 May 93 10:06:09 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18079; Tue, 11 May 93 10:03:46 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18075; Tue, 11 May 93 10:03:45 MDT Received: from BBN.COM by p.lanl.gov (5.65/1.14) id AA01124; Tue, 11 May 93 10:03:44 -0600 Message-Id: <9305111603.AA01124@p.lanl.gov> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Lyman Chapin Subject: IETF/ISO collaboration on CLNP To: x3s33@merit.edu Cc: tuba@lanl.gov Date: Mon, 10 May 93 03:27:27 EDT Mail-System-Version: As we agreed at the X3S3.3 meeting in Orlando at the end of April: Thread Responsible person ------------------------------------------------------------------------ IETF/ISO collaboration on CLNP Lyman Chapin - discussion of plausible scenarios for cooperative work on CLNP and its relatives (routing protocols, MIBs - specific list of standards). This message is intended to open discussion of how the work on CLNP and related standards might be carried out as a collaborative effort of the IETF and ISO. The two extremes of the "collaboration" spectrum, as they have been described during X3S3.3 discussions, are: - no collaboration: X3S3.3 and ISO/IEC JTC1/SC6 continue to work on CLNP as they have in the past, without explicit reference to the use of CLNP in the Internet. - devolution: responsibility for further technical development of CLNP and its relatives is transferred to one or more IETF working groups (in much the same way in which responsibility for LAN standards is vested in the IEEE). There are many alternatives between these two extremes (and variations on the details of the extreme points themselves). Please send comments to the "x3s33@merit.edu" list. Comments posted before the next X3S3.3 meeting begins on June 2 will be considered during the preparation of a US response to the SC6 call for comments on "liaison with the IETF". - Lyman   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07177; 11 May 93 12:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07173; 11 May 93 12:39 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa14585; 11 May 93 12:39 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA02431; Tue, 11 May 93 10:22:16 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18214; Tue, 11 May 93 10:19:56 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18210; Tue, 11 May 93 10:19:54 MDT Received: from concorde.inria.fr by p.lanl.gov (5.65/1.14) id AA02279; Tue, 11 May 93 10:19:52 -0600 Received: from givry.inria.fr by concorde.inria.fr; Tue, 11 May 1993 18:19:02 +0200 Received: by givry.inria.fr; Tue, 11 May 1993 18:19:01 +0200 Message-Id: <199305111619.AA27030@givry.inria.fr> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Francis Dupont To: peter@goshawk.lanl.gov Cc: ALEX REIJNIERSE , dino@cisco.com, reb@noc.ans.net, cjw@barrnet.net, colella@nist.gov, trouble@noc.ans.net, ie@merit.edu, dave@mail.bellcore.com, stev@ftp.com, victor.reijs@surfnet.nl, tuba@lanl.gov, wg4-clns@funet.fi, sn3plus-clns@surfnet.nl, cmj@nsd.3com.com, mak@merit.edu, skh@merit.edu Subject: Re: TUBA demonstration In-Reply-To: Your message of Thu, 06 May 1993 12:08:34 MST. <9305061808.AA12067@goshawk.lanl.gov> Date: Tue, 11 May 1993 18:17:52 +0200 X-Orig-Sender: Francis.Dupont@inria.fr X-Charset: ASCII X-Char-Esc: 29 I've found how to setup EON on SunNet OSI 7.0+, first an entry for IPPROTO_EON (== 80) is needed in inetsw table (/sys/netinet/in_proto.c) with eon_input as the input routine. The /etc/sunlink/osi/routes file must have entries like : prefix eon0 '470004' 'IP=192.221.254.247' for the rc.isoroutes.table (on merit.edu in /pub/noop) entry : 47:00:04 192.221.254.247 For EON operators, our entry is : 39:25:0f:00:00:02 192.93.2.6 For others ceasi2.cern.ch has a good route (via EON) to us. My TUBA host is mercurey.inria.fr, running a SunOS 4.1.2 + BSDI + Keith's TUBA patchs, NSAP 39250f0000020000000000000412809300801706. Regards Francis.Dupont@inria.fr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07338; 11 May 93 13:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07334; 11 May 93 13:08 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa15237; 11 May 93 13:08 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA05012; Tue, 11 May 93 10:59:37 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18611; Tue, 11 May 93 10:57:14 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18607; Tue, 11 May 93 10:57:13 MDT Received: from exmoor.lanl.gov by p.lanl.gov (5.65/1.14) id AA04904; Tue, 11 May 93 10:57:12 -0600 Received: by exmoor.lanl.gov. (5.65/DEC-Ultrix/4.3) id AA21382; Tue, 11 May 1993 10:57:03 -0600 Message-Id: <9305111657.AA21382@exmoor.lanl.gov.> To: Alex Reijnierse Cc: tuba@lanl.gov, trouble@es.net Subject: Re: TUBA connectivity? report In-Reply-To: Your message of "Tue, 11 May 93 17:24:06 +0200." <9305111524.AA02163@valhall.jenc93.uninett.no> Date: Tue, 11 May 93 10:57:03 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Rebecca L. Bostwick (505) 665-8282" X-Mts: smtp Alex: There was an unscheduled down time on the ESnet router at UMD. This would affect the access to LANL. The line just came back up, so connectivity should be restored. We apologize for this inconvenience and the bad timing for this to happen. What NSAP are you coming from? -- Becca Rebecca L. Bostwick ESnet Network Special Projects National Energy Research Supercomputer Center Lawrence Livermore National Laboratory phone: (505) 665-8282 fax: (505) 665-7793 bostwick@es.net >Hello TUBA demonstration participants. > >Here are several traces of the TUBA connectivity from Trondheim. >It seems that there are several looping problems between regionals >and the NSFnet backbone. I hope that you can solve these problems >quickly, so that we are able to demonstrate the whole thing. > >- Alex > >Begin tracing CLNP path (25 hop max) to tuba.lanl.gov : NS+4700058000570000000 > 140000100608cb11eb800 > > >TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] > 1 - lsdm10.research.ptt.nl E- 208ms E- 11ms E- 12ms > 2 - delft2.router.surfnet.nl E- 848ms E-1121ms E- 416ms > 3 - amsterdam4.router.surfnet.nl E- 580ms E- 471ms E- 472ms > 4 - amsterdam1.empb.net E- 802ms E- 676ms E- 676ms > 5 - swieug.switch.ch E- 945ms E- 749ms E- 774ms > 6 - swibe1.switch.ch E-1420ms E-2020ms E-1241ms > 7 - swiez1.switch.ch E- 928ms E- 768ms E- 764ms > 8 - swiez4.switch.ch E- 957ms E- 776ms E- 994ms > 9 - 2nd.ctest1.cern.ch E-1026ms E- 815ms E-1411ms >10 - cern-gate.cern.ch E- E- E- >11 - psp-9-10.nsf.net E- E- E- >12 - umd-rt1.es.net E-1226ms E- 930ms E-1122ms >13 - psp-9-10.nsf.net E- E- E- >14 - umd-rt1.es.net E-1066ms E- 942ms E-1082ms >15 - psp-9-10.nsf.net E- E- E- >16 - umd-rt1.es.net E-1163ms E-1066ms E-1744ms >17 - psp-9-10.nsf.net E- E- E-^Cexplorer# >explorer# > > >Begin tracing CLNP path (25 hop max) to tuba1.3com.com : NS+470004003511001111 > 1111111100 > > >TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] > 1 - lsdm10.research.ptt.nl E- 114ms E- 11ms E- 12ms > 2 - delft2.router.surfnet.nl E- 678ms E-1190ms E- 591ms > 3 - amsterdam4.router.surfnet.nl E- 566ms E- 459ms E- 460ms > 4 - amsterdam1.empb.net E- 771ms E- 664ms E- 768ms > 5 - swieug.switch.ch E- 994ms E- 879ms > 6 - swieug.switch.ch E-2017ms > 6 - swibe1.switch.ch E-1062ms E-1450ms > 7 - swibe1.switch.ch E- 924ms > 7 - swiez1.switch.ch E- 913ms E- 747ms > 8 - swiez4.switch.ch E- 937ms E- 740ms E- 834ms > 9 - 2nd.ctest1.cern.ch E-1090ms E- 800ms E- 783ms >10 - cern-gate.cern.ch E- E- E- >11 - psp-9-15.nsf.net E- E- E- >12 - fix-east.sura.net E-1264ms E-2302ms E-1477ms >13 - psp-9-15.nsf.net E- E- E- >14 - fix-east.sura.net E-1104ms E-1025ms ^Cexplorer# > >explorer# > > >TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] > 1 - lsdm10.research.ptt.nl E- 127ms E- 11ms E- 17ms > 2 - delft2.router.surfnet.nl E- 521ms E-1069ms > 3 - delft2.router.surfnet.nl E-1567ms > 3 - amsterdam4.router.surfnet.nl E- 575ms E- 472ms > 4 - amsterdam1.empb.net E- 786ms E- 680ms E- 700ms > 5 - swieug.switch.ch E- 936ms E- 755ms E- 750ms > 6 - swibe1.switch.ch E-1012ms E-2012ms E-1240ms > 7 - swiez1.switch.ch E-1576ms E- 824ms E- 808ms > 8 - swiez4.switch.ch E- 943ms E- 771ms E- 826ms > 9 - 2nd.ctest1.cern.ch E-1013ms E- 884ms E- 831ms >10 - cern-gate.cern.ch E- E- E- >11 - psp-17-10.nsf.net E- E- E- >12 - michnet2.merit.edu E-1745ms E-1085ms E-1810ms >13 - >14 - >15 - >16 - >17 - > > >- Alex > >P.S. Please include my e-mail address at jenc in your replies. From here >i cannot read mail sent to my normal e-mail address. >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07892; 11 May 93 13:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07888; 11 May 93 13:41 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa16316; 11 May 93 13:41 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA06826; Tue, 11 May 93 11:29:01 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18844; Tue, 11 May 93 11:26:41 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18840; Tue, 11 May 93 11:26:40 MDT Received: from exmoor.lanl.gov by p.lanl.gov (5.65/1.14) id AA06701; Tue, 11 May 93 11:26:40 -0600 Received: by exmoor.lanl.gov. (5.65/DEC-Ultrix/4.3) id AA21516; Tue, 11 May 1993 11:26:31 -0600 Message-Id: <9305111726.AA21516@exmoor.lanl.gov.> To: Alex Reijnierse Cc: tuba@lanl.gov, trouble@es.net Subject: Re: TUBA connectivity? report In-Reply-To: Your message of "Tue, 11 May 93 10:57:03 MDT." <9305111657.AA21382@exmoor.lanl.gov.> Date: Tue, 11 May 93 11:26:30 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Rebecca L. Bostwick (505) 665-8282" X-Mts: smtp Alex: Due to the router being down at UMD there are fallout problems in the ESnet backbone that are still affecting the CLNS connectivity to LANL. I am looking into the problem as fast as I can. -- Becca >Alex: > > There was an unscheduled down time on the ESnet router at >UMD. This would affect the access to LANL. The line just came back >up, so connectivity should be restored. We apologize for this >inconvenience and the bad timing for this to happen. > > What NSAP are you coming from? > > -- Becca > >Rebecca L. Bostwick >ESnet >Network Special Projects >National Energy Research Supercomputer Center >Lawrence Livermore National Laboratory >phone: (505) 665-8282 fax: (505) 665-7793 >bostwick@es.net > > >>Hello TUBA demonstration participants. >> >>Here are several traces of the TUBA connectivity from Trondheim. >>It seems that there are several looping problems between regionals >>and the NSFnet backbone. I hope that you can solve these problems >>quickly, so that we are able to demonstrate the whole thing. >> >>- Alex >> >>Begin tracing CLNP path (25 hop max) to tuba.lanl.gov : NS+470005800057000000 > 0 >> 140000100608cb11eb800 >> >> >>TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] >> 1 - lsdm10.research.ptt.nl E- 208ms E- 11ms E- 12ms >> 2 - delft2.router.surfnet.nl E- 848ms E-1121ms E- 416ms >> 3 - amsterdam4.router.surfnet.nl E- 580ms E- 471ms E- 472ms >> 4 - amsterdam1.empb.net E- 802ms E- 676ms E- 676ms >> 5 - swieug.switch.ch E- 945ms E- 749ms E- 774ms >> 6 - swibe1.switch.ch E-1420ms E-2020ms E-1241ms >> 7 - swiez1.switch.ch E- 928ms E- 768ms E- 764ms >> 8 - swiez4.switch.ch E- 957ms E- 776ms E- 994ms >> 9 - 2nd.ctest1.cern.ch E-1026ms E- 815ms E-1411ms >>10 - cern-gate.cern.ch E- E- E- >>11 - psp-9-10.nsf.net E- E- E- >>12 - umd-rt1.es.net E-1226ms E- 930ms E-1122ms >>13 - psp-9-10.nsf.net E- E- E- >>14 - umd-rt1.es.net E-1066ms E- 942ms E-1082ms >>15 - psp-9-10.nsf.net E- E- E- >>16 - umd-rt1.es.net E-1163ms E-1066ms E-1744ms >>17 - psp-9-10.nsf.net E- E- E-^Cexplorer# >>explorer# >> >> >>Begin tracing CLNP path (25 hop max) to tuba1.3com.com : NS+47000400351100111 > 1 >> 1111111100 >> >> >>TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] >> 1 - lsdm10.research.ptt.nl E- 114ms E- 11ms E- 12ms >> 2 - delft2.router.surfnet.nl E- 678ms E-1190ms E- 591ms >> 3 - amsterdam4.router.surfnet.nl E- 566ms E- 459ms E- 460ms >> 4 - amsterdam1.empb.net E- 771ms E- 664ms E- 768ms >> 5 - swieug.switch.ch E- 994ms E- 879ms >> 6 - swieug.switch.ch E-2017ms >> 6 - swibe1.switch.ch E-1062ms E-1450ms >> 7 - swibe1.switch.ch E- 924ms >> 7 - swiez1.switch.ch E- 913ms E- 747ms >> 8 - swiez4.switch.ch E- 937ms E- 740ms E- 834ms >> 9 - 2nd.ctest1.cern.ch E-1090ms E- 800ms E- 783ms >>10 - cern-gate.cern.ch E- E- E- >>11 - psp-9-15.nsf.net E- E- E- >>12 - fix-east.sura.net E-1264ms E-2302ms E-1477ms >>13 - psp-9-15.nsf.net E- E- E- >>14 - fix-east.sura.net E-1104ms E-1025ms ^Cexplorer > # >> >>explorer# >> >> >>TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] >> 1 - lsdm10.research.ptt.nl E- 127ms E- 11ms E- 17ms >> 2 - delft2.router.surfnet.nl E- 521ms E-1069ms >> 3 - delft2.router.surfnet.nl E-1567ms >> 3 - amsterdam4.router.surfnet.nl E- 575ms E- 472ms >> 4 - amsterdam1.empb.net E- 786ms E- 680ms E- 700ms >> 5 - swieug.switch.ch E- 936ms E- 755ms E- 750ms >> 6 - swibe1.switch.ch E-1012ms E-2012ms E-1240ms >> 7 - swiez1.switch.ch E-1576ms E- 824ms E- 808ms >> 8 - swiez4.switch.ch E- 943ms E- 771ms E- 826ms >> 9 - 2nd.ctest1.cern.ch E-1013ms E- 884ms E- 831ms >>10 - cern-gate.cern.ch E- E- E- >>11 - psp-17-10.nsf.net E- E- E- >>12 - michnet2.merit.edu E-1745ms E-1085ms E-1810ms >>13 - >>14 - >>15 - >>16 - >>17 - >> >> >>- Alex >> >>P.S. Please include my e-mail address at jenc in your replies. From here >>i cannot read mail sent to my normal e-mail address. >>   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08602; 11 May 93 14:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08598; 11 May 93 14:06 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa17159; 11 May 93 14:06 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA09838; Tue, 11 May 93 11:58:14 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19170; Tue, 11 May 93 11:55:46 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19165; Tue, 11 May 93 11:55:43 MDT Received: from is.rice.edu by p.lanl.gov (5.65/1.14) id AA09744; Tue, 11 May 93 11:55:40 -0600 Received: from sabine.is.rice.edu by is.rice.edu (AA07913); Tue, 11 May 93 12:55:05 CDT Received: by sabine.is.rice.edu (AA05524); Tue, 11 May 93 12:54:56 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Manning Message-Id: <9305111754.AA05524@sabine.is.rice.edu> Subject: Re: TUBA demonstration To: Francis Dupont Date: Tue, 11 May 93 12:54:54 CDT Cc: peter@goshawk.lanl.gov, A.A.Reijnierse@research.ptt.nl, dino@cisco.com, reb@noc.ans.net, cjw@barrnet.net, colella@nist.gov, trouble@noc.ans.net, ie@merit.edu, dave@mail.bellcore.com, stev@ftp.com, victor.reijs@surfnet.nl, tuba@lanl.gov, wg4-clns@funet.fi, sn3plus-clns@surfnet.nl, cmj@nsd.3com.com, mak@merit.edu, skh@merit.edu In-Reply-To: <199305111619.AA27030@givry.inria.fr>; from "Francis Dupont" at May 11, 93 6:17 pm X-Mailer: ELM [version 2.3 PL11] From here.... Tracing the route to 39.250F.0000.0200.0000.0000.0004.1280.9300.8017.06 1 PSP-11-10(47.0005.80FF.FF00.0000.0001.0000.0000.818C.0B0A.00) 4 msec ! 4 msec ! 4 msec ! 2 47.0005.80FF.FF00.0000.0001.0000.0000.C041.B9CA.00 152 msec ! 144 msec ! 144 msec ! 3 * * * 4 * * * ... :-( -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10228; 11 May 93 15:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10224; 11 May 93 15:19 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa19852; 11 May 93 15:19 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA15082; Tue, 11 May 93 13:16:02 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19824; Tue, 11 May 93 13:14:49 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19819; Tue, 11 May 93 13:14:48 MDT Received: from exmoor.lanl.gov by p.lanl.gov (5.65/1.14) id AA14973; Tue, 11 May 93 13:14:47 -0600 Received: by exmoor.lanl.gov. (5.65/DEC-Ultrix/4.3) id AA21890; Tue, 11 May 1993 13:14:26 -0600 Message-Id: <9305111914.AA21890@exmoor.lanl.gov.> To: Alex Reijnierse Cc: tuba@lanl.gov, trouble@es.net Subject: Re: TUBA connectivity? report In-Reply-To: Your message of "Tue, 11 May 93 17:24:06 +0200." <9305111524.AA02163@valhall.jenc93.uninett.no> Date: Tue, 11 May 93 13:14:26 -0600 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Rebecca L. Bostwick (505) 665-8282" X-Mts: smtp Alex: Things have been stable for a while now. We can get to sintef-gw.sintef.no (47.0023.0000.0005.0000.0002.0102.1292.4100.1001.00) from tuba.lanl.gov (47.0005.8000.5700.0000.0140.0001.0060.8cb1.1eb8.00) Let me know what NSAP you are coming from. -- Becca Rebecca L. Bostwick ESnet Network Special Projects National Energy Research Supercomputer Center Lawrence Livermore National Laboratory phone: (505) 665-8282 fax: (505) 665-7793 bostwick@es.net >Hello TUBA demonstration participants. > >Here are several traces of the TUBA connectivity from Trondheim. >It seems that there are several looping problems between regionals >and the NSFnet backbone. I hope that you can solve these problems >quickly, so that we are able to demonstrate the whole thing. > >- Alex > >Begin tracing CLNP path (25 hop max) to tuba.lanl.gov : NS+4700058000570000000 > 140000100608cb11eb800 > > >TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] > 1 - lsdm10.research.ptt.nl E- 208ms E- 11ms E- 12ms > 2 - delft2.router.surfnet.nl E- 848ms E-1121ms E- 416ms > 3 - amsterdam4.router.surfnet.nl E- 580ms E- 471ms E- 472ms > 4 - amsterdam1.empb.net E- 802ms E- 676ms E- 676ms > 5 - swieug.switch.ch E- 945ms E- 749ms E- 774ms > 6 - swibe1.switch.ch E-1420ms E-2020ms E-1241ms > 7 - swiez1.switch.ch E- 928ms E- 768ms E- 764ms > 8 - swiez4.switch.ch E- 957ms E- 776ms E- 994ms > 9 - 2nd.ctest1.cern.ch E-1026ms E- 815ms E-1411ms >10 - cern-gate.cern.ch E- E- E- >11 - psp-9-10.nsf.net E- E- E- >12 - umd-rt1.es.net E-1226ms E- 930ms E-1122ms >13 - psp-9-10.nsf.net E- E- E- >14 - umd-rt1.es.net E-1066ms E- 942ms E-1082ms >15 - psp-9-10.nsf.net E- E- E- >16 - umd-rt1.es.net E-1163ms E-1066ms E-1744ms >17 - psp-9-10.nsf.net E- E- E-^Cexplorer# >explorer# > > >Begin tracing CLNP path (25 hop max) to tuba1.3com.com : NS+470004003511001111 > 1111111100 > > >TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] > 1 - lsdm10.research.ptt.nl E- 114ms E- 11ms E- 12ms > 2 - delft2.router.surfnet.nl E- 678ms E-1190ms E- 591ms > 3 - amsterdam4.router.surfnet.nl E- 566ms E- 459ms E- 460ms > 4 - amsterdam1.empb.net E- 771ms E- 664ms E- 768ms > 5 - swieug.switch.ch E- 994ms E- 879ms > 6 - swieug.switch.ch E-2017ms > 6 - swibe1.switch.ch E-1062ms E-1450ms > 7 - swibe1.switch.ch E- 924ms > 7 - swiez1.switch.ch E- 913ms E- 747ms > 8 - swiez4.switch.ch E- 937ms E- 740ms E- 834ms > 9 - 2nd.ctest1.cern.ch E-1090ms E- 800ms E- 783ms >10 - cern-gate.cern.ch E- E- E- >11 - psp-9-15.nsf.net E- E- E- >12 - fix-east.sura.net E-1264ms E-2302ms E-1477ms >13 - psp-9-15.nsf.net E- E- E- >14 - fix-east.sura.net E-1104ms E-1025ms ^Cexplorer# > >explorer# > > >TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] > 1 - lsdm10.research.ptt.nl E- 127ms E- 11ms E- 17ms > 2 - delft2.router.surfnet.nl E- 521ms E-1069ms > 3 - delft2.router.surfnet.nl E-1567ms > 3 - amsterdam4.router.surfnet.nl E- 575ms E- 472ms > 4 - amsterdam1.empb.net E- 786ms E- 680ms E- 700ms > 5 - swieug.switch.ch E- 936ms E- 755ms E- 750ms > 6 - swibe1.switch.ch E-1012ms E-2012ms E-1240ms > 7 - swiez1.switch.ch E-1576ms E- 824ms E- 808ms > 8 - swiez4.switch.ch E- 943ms E- 771ms E- 826ms > 9 - 2nd.ctest1.cern.ch E-1013ms E- 884ms E- 831ms >10 - cern-gate.cern.ch E- E- E- >11 - psp-17-10.nsf.net E- E- E- >12 - michnet2.merit.edu E-1745ms E-1085ms E-1810ms >13 - >14 - >15 - >16 - >17 - > > >- Alex > >P.S. Please include my e-mail address at jenc in your replies. From here >i cannot read mail sent to my normal e-mail address. >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10585; 11 May 93 15:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10581; 11 May 93 15:44 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa20645; 11 May 93 15:44 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA17555; Tue, 11 May 93 13:37:12 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19973; Tue, 11 May 93 13:36:41 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19969; Tue, 11 May 93 13:36:40 MDT Received: from bridge2.NSD.3Com.COM by p.lanl.gov (5.65/1.14) id AA17450; Tue, 11 May 93 13:36:36 -0600 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA10588 (5.65c/IDA-1.4.4nsd for ); Tue, 11 May 1993 12:36:34 -0700 Received: by jaspar.NSD.3Com.COM id AA24086 (5.65c/IDA-1.4.4-910730); Tue, 11 May 1993 12:36:32 -0700 Date: Tue, 11 May 1993 12:36:32 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Cyndi M. Jung" Message-Id: <199305111936.AA24086@jaspar.NSD.3Com.COM> To: tuba@lanl.gov Subject: TUBA connectivity getting better Cc: alex@demo.jenc93.uninett.no The TUBA connectivity through SURA is working to Europe and ESNET. I'll try some more locations. We have two routers here, tuba1 and tuba2, waiting for a TUBA/Telnet session. Thanks to everyone who helped get this working again. Cyndi [4]TUBA# otr /39528f1100000910000000004000000c03df7d00 TTL Next_Hop_Address 1 /47/0004/00351100080002033AD200 2 /47/0004/00351000080002033ABB00 3 /47/0004/00351000080002013C3700 4 /47/0004/00351000080002013C3700 5 /47/0005/80FFF100000001010000080002A0724B00 6 /47/0005/80FFF10000000001000100000001000100 7 /47/0005/80FFF10000000001000100000000000800 8 /47/0005/80FFFF000000000100000000818C090F00 9 /47/0005/80FFFF000000000100000000C041B9CA00 10 /39/756/1111111101000001458012814120001100 11 /39/756/1111111101000001456013005900120400 12 /39/756/1111111101000001456013005900120100 13 /39/756/1111111101000001448013005905600100 14 /39/756/1111111101000001600113005911500100 15 /39/528/110300000001000100000000000100 16 /39/528/1100100020000000000000000C0429B400 17 /39/528/11000000900000000040AA000400157400 18 /39/528/1100000910000000004000000C03DF7D00 [5]TUBA#   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15094; 11 May 93 16:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15090; 11 May 93 16:48 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa23456; 11 May 93 16:48 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA23511; Tue, 11 May 93 14:35:59 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA20478; Tue, 11 May 93 14:35:30 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA20474; Tue, 11 May 93 14:35:29 MDT Received: from EMU.NCSL.NIST.GOV by p.lanl.gov (5.65/1.14) id AA23482; Tue, 11 May 93 14:35:24 -0600 Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA13245; Tue, 11 May 93 16:38:20 EDT Date: Tue, 11 May 93 16:38:20 EDT Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9305112038.AA13245@emu.ncsl.nist.gov> To: tuba@lanl.gov, noop@merit.edu Subject: Sparc binary for nslookup for NSAPs available Cc: alex@demo.jenc93.uninett.no, colella@nist.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: colella@nist.gov Reply-To: colella@nist.gov For those who are interested, a Sparc binary of nslookup that understands NSAP RRs is available: osi.ncsl.nist.gov:./pub/ncsa_tuba/nslookup.sparc Try 'ls -t nsap ' on the domains: tuba.ncsl.nist.gov (primary server emu.ncsl.nist.gov) nsap.lanl.gov (primary server labyrinth.lanl.gov) cisco.com (primary server dirt.cisco.com) This nslookup is derived from the bind 4.9 beta release. We'll be making the rest of the NSAP-capable release available RSN. This is just a teaser. --Richard   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16921; 11 May 93 17:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16917; 11 May 93 17:08 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa24490; 11 May 93 17:08 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA25378; Tue, 11 May 93 15:07:14 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA20644; Tue, 11 May 93 15:06:46 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA20640; Tue, 11 May 93 15:06:45 MDT Received: from uu5.psi.com by p.lanl.gov (5.65/1.14) id AA25194; Tue, 11 May 93 15:06:31 -0600 Received: from port8.reston.pub-ip.psi.net by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA21016 for tuba@lanl.gov; Tue, 11 May 93 16:45:57 -0400 Message-Id: <9305112045.AA21016@uu5.psi.com> Received: from isc2.isci.com by isc1.isci.com id <11964-0@isc1.isci.com>; Tue, 11 May 1993 16:34:20 +0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eric D Williams Subject: Subscription... To: TUBA Discussion List Date: Tue, 11 May 93 16:40:31 PDT Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 11 TEXT , 4 TEXT Hello, Eric Williams of ISC, Inc. here. Please subscribe eric@isci.com to the TUBA Discussion list. Thank you, Eric Peace... Integrated Systems and Communications, Inc. (ISC) 1899 L Street N.W. Suite 500; Washington, DC 20036 eric@isci.com - Eric D. Williams - guru@isci.com Ph: (202) 331-3990 Fax: (202)331-4049   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01396; 12 May 93 4:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01392; 12 May 93 4:44 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa02800; 12 May 93 4:44 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA21905; Wed, 12 May 93 02:40:54 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA22718; Wed, 12 May 93 02:39:37 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA22714; Wed, 12 May 93 02:39:36 MDT Received: from yggdrasil.jenc93.uninett.no by p.lanl.gov (5.65/1.14) id AA21881; Wed, 12 May 93 02:39:37 -0600 Received: from valhall.jenc93.uninett.no by yggdrasil.jenc93.uninett.no with SMTP id AA06968 (5.65c/IDA-1.4.4 for ); Wed, 12 May 1993 10:38:51 +0200 Received: from localhost by valhall.jenc93.uninett.no (4.1/Uninett-C-1.4) id AA02480; Wed, 12 May 93 10:38:50 +0200 Message-Id: <9305120838.AA02480@valhall.jenc93.uninett.no> To: tuba@lanl.gov, cmj@nsd.3com.com, bostwick@es.net, noc@sura.net, labovit@merit.edu, skh@merit.edu Subject: Somewhat further down the road Date: Wed, 12 May 1993 10:38:50 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alex Reijnierse Hello again, Well, this morning things look a lot better then yesterday (except for the weather here, it's cold!!). Systems i can reach from the PCs abd cisco here are at the moment: lsdm10.research.ptt.nl cisco_iso.upm.dit.es tuba-pc.upm.dit.es cursive.ncsl.nist.gov cisco1.ncsl.nist.gov 3com1.ncsl.nist.gov red.cisco.com glasshouse.merit.edu michnetx.merit.edu maze.lanl.gov tuba.lanl.gov I can login to Peter's BSD system using TUBA (have to login first using IP though and running the TUBA telnet deamon. Telnetting to the RS/6000 (glasshouse) is not possible, neither from the PC nor Cisco. Sue, could you tell me what i can do with this system? This still leaves some systems that i cannot reach now. These are: tuba10.research.ptt.nl tuba20.research.ptt.nl tuba1.3com.com tuba2.3com.com The first two are my own, i am working on this at the moment. The others are from 3Com. Here's a trace. explorer# !! clnp-trace tuba1.3com.com Begin tracing CLNP path (25 hop max) to tuba1.3com.com : NS+4700040035110011111111111100 TTL SYSTEM: RESPONSE-[ROUND TRIP TIME] 1 - lsdm10.research.ptt.nl E- 124ms E- 11ms E- 14ms 2 - delft2.router.surfnet.nl E- 511ms E-1151ms E- 444ms 3 - amsterdam4.router.surfnet.nl E- 566ms E- 461ms E- 461ms 4 - amsterdam1.empb.net E- 782ms E- 676ms E- 667ms 5 - swieug.switch.ch E- 962ms E- 882ms E- 749ms 6 - swibe1.switch.ch E- 963ms E-1824ms 7 - swiez1.switch.ch E- 950ms E- 764ms E- 737ms 8 - swiez4.switch.ch E- 969ms E- 745ms E- 818ms 9 - 2nd.ctest1.cern.ch E-1009ms E- 912ms E- 838ms 10 - cern-gate.cern.ch E- E- E- 11 - psp-9-15.nsf.net E- E- E- 12 - fix-east.sura.net E-2584ms E-1660ms E-1130ms 13 - 14 - cos2sura.sura.net E-3708ms E-2776ms E-1948ms 15 - cos2sura.cos.com E-3734ms E-2797ms E-1976ms 16 - 17 - 18 - 19 - 20 - ^Cexplorer# explorer# - Alex Reijnierse P.S. the NSAPs of the TUBA systems here are: name=tuba-1; hostnsap=4700230000000500000002010219224116002200; # is_ether=00608cc0dce0; name=tuba-2; hostnsap=4700230000000500000002010212924116002300; is_ether=0000c0153865; name=cisco; hostnsap=4700230000000500000002010212924116002400; is_ether=00000c00adb9; Domain name = jenc93.uninett.no   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02502; 12 May 93 7:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02497; 12 May 93 7:45 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa06335; 12 May 93 7:45 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA26491; Wed, 12 May 93 05:43:21 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA22954; Wed, 12 May 93 05:41:26 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA22950; Wed, 12 May 93 05:41:25 MDT Received: from zippysun.math.uakron.edu by p.lanl.gov (5.65/1.14) id AA26456; Wed, 12 May 93 05:41:24 -0600 Received: Wed, 12 May 93 07:41:22 EDT by zippysun.math.uakron.edu (4.1/Uakron/RLG(1.0-main)) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Greg Akers Message-Id: <9305121141.AA00595@zippysun.math.uakron.edu> Subject: Subscribe To: tuba@lanl.gov Date: Wed, 12 May 1993 07:41:22 -0400 (EDT) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 96 Greetings, Could you please add me to this list.... Greg Akers grega@zippysun.math.uakron.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05883; 12 May 93 9:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05879; 12 May 93 9:21 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa09740; 12 May 93 9:21 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA28445; Wed, 12 May 93 07:19:56 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23212; Wed, 12 May 93 07:19:27 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23208; Wed, 12 May 93 07:19:26 MDT Received: from yggdrasil.jenc93.uninett.no by p.lanl.gov (5.65/1.14) id AA28425; Wed, 12 May 93 07:19:24 -0600 Received: from valhall.jenc93.uninett.no by yggdrasil.jenc93.uninett.no with SMTP id AA07345 (5.65c/IDA-1.4.4 for ); Wed, 12 May 1993 15:19:08 +0200 Received: from localhost by valhall.jenc93.uninett.no (4.1/Uninett-C-1.4) id AA02797; Wed, 12 May 93 15:19:07 +0200 Message-Id: <9305121319.AA02797@valhall.jenc93.uninett.no> To: colella@nist.gov Cc: tuba@lanl.gov, noop@merit.edu, alex@demo.jenc93.uninett.no, alex@demo.jenc93.uninett.no Subject: Re: Sparc binary for nslookup for NSAPs available In-Reply-To: Your message of "Tue, 11 May 1993 16:38:20 EDT." <9305112038.AA13245@emu.ncsl.nist.gov> Date: Wed, 12 May 1993 15:19:06 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alex Reijnierse Hello Richard, I still have a few questions. --------- Try 'ls -t nsap ' on the domains: tuba.ncsl.nist.gov (primary server emu.ncsl.nist.gov) nsap.lanl.gov (primary server labyrinth.lanl.gov) cisco.com (primary server dirt.cisco.com) -------- From what i can make up of this is that you, Peter and cisco have set up one NSAP capable name server each. Is that correct? What NSAPs are listed in these servers? Are these lists the same for each server? Is there an information exchange possibility? If i telnet to a name from the NCSA software or from a cisco and the name is not available in the config.tel file or the clns host table in the cisco, does it automatically contact one of the name servers? How do i set up another DNS? I want to do that in Europe and i think more people are interested in this. - Alex BTW, i tried logging in to Peter's system using TUBA directly and it works!!! P.S. If your NCSA software uses this DNS server, could i have a copy of the new NCSA software? P.S. 2 I will send an updated NSAP list of the current TUBA systems in a minute. (over the TUBA list)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08027; 12 May 93 9:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08023; 12 May 93 9:34 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa10211; 12 May 93 9:34 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA28816; Wed, 12 May 93 07:31:33 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23258; Wed, 12 May 93 07:31:04 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23254; Wed, 12 May 93 07:31:03 MDT Received: from yggdrasil.jenc93.uninett.no by p.lanl.gov (5.65/1.14) id AA28773; Wed, 12 May 93 07:31:01 -0600 Received: from valhall.jenc93.uninett.no by yggdrasil.jenc93.uninett.no with SMTP id AA07377 (5.65c/IDA-1.4.4 for ); Wed, 12 May 1993 15:30:59 +0200 Received: from localhost by valhall.jenc93.uninett.no (4.1/Uninett-C-1.4) id AA02825; Wed, 12 May 93 15:30:58 +0200 Message-Id: <9305121330.AA02825@valhall.jenc93.uninett.no> To: tuba@lanl.gov Subject: Updated TUBA list Date: Wed, 12 May 1993 15:30:58 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alex Reijnierse Hello All, Here's an updated list of TUBA NSAPs. Please note the entry of the SunOS UNIX version of Francis Dupont. ####### ####### Alex Reijnierse (A.A.Reijnierse@research.ptt.nl) ####### The Netherlands - PTT Research name=tuba10; # NCSA PC hostnsap=39528F11000009100000000040bbbbaaaa001000; name=tuba20; # NCSA PC hostnsap=39528F11000009100000000040bbbbaaaa002000; name=lsdm10; # Cisco router (jenc93) hostnsap=39528F1100000910000000004000000c03df7d00; ####### ####### David Fernandez (david@dit.upm.es) ####### Spain - Universidad Politecnica de Madrid (UPM) name=cisco_iso; # Cisco router (ripeop) hostnsap=39724F1001000000020001000113800400200900; name=tuba-pc; # NCSA PC hostnsap=39724F1001000000020001000100000000001000; ####### ####### Richard Colella (colella@nist.gov) ####### US - National Institute of Standards and Technology (NIST) name=cursive; # NCSA PC hostnsap=47000580005a0000000001e137eeeeee00008500; name=cisco1; # Cisco router (cisco@nist) hostnsap=47000580005a0000000001e13788888800018100; name=3com1; # 3Com router (user root, no password) hostnsap=47000580005a0000000001e13711111100011100; ####### ####### Cyndi Jung (cmj@nsd.3com.com) ####### US - 3Com corporation name=tuba1; # 3Com router (no password / menu -is) hostnsap=4700040035110011111111111100; name=tuba2; hostnsap=4700040035110022222222222200; ####### ####### Dino Farinacci (dino@cisco.com) ####### US - Cisco Systems name=red; # Cisco router hostnsap=47000580ffef0000000001594016008906402200 ####### ####### Mark Knopper/Susan Hares (mak@merit.edu/skh@merit.edu) ####### US - merit.edu name=glasshouse; # RS/6000 hostnsap=47000580ffff000000040000000000232a015500 name=michnetx; # Cisco router hostnsap=47000580ffff0000000400000000002301010b00 name=tschapperl; # NCSA PC hostnsap=47000580ffff000000040000000000232a015e00 ####### ####### Peter Ford (peter@goshawk.lanl.gov) ####### US - lanl.gov name=maze; # NCSA PC hostnsap=47000580005700000001400001feededfeeded00 name=tuba; # BSDi/4.4 BSD PC hostnsap=4700058000570000000140000100608cb11eb800 name=cisco-ldcc-open; # Cisco router hostnsap=47000580005700000000F00001AA0004007FA700 ####### ####### JENC 93 ####### name=tuba-1; hostnsap=4700230000000500000002010219224116002200; # is_ether=00608cc0dce0; name=tuba-2; hostnsap=4700230000000500000002010212924116002300; is_ether=0000c0153865; name=cisco; hostnsap=4700230000000500000002010212924116002400; is_ether=00000c00adb9; ###### ###### Francis Dupont (Francis.Dupont@inria.fr) ###### France - INRIA name=mercurey.inria.fr; hostnsap=39250f0000020000000000000412809300801700;   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08190; 12 May 93 9:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08184; 12 May 93 9:40 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa10419; 12 May 93 9:40 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA29154; Wed, 12 May 93 07:39:01 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23279; Wed, 12 May 93 07:38:08 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23275; Wed, 12 May 93 07:38:07 MDT Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA29072; Wed, 12 May 93 07:37:53 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA25187; Wed, 12 May 93 07:37:53 MDT Message-Id: <9305121337.AA25187@goshawk.lanl.gov> To: Alex Reijnierse Cc: tuba@lanl.gov, cmj@nsd.3com.com, bostwick@es.net, noc@sura.net, labovit@merit.edu, skh@merit.edu Subject: Re: Somewhat further down the road In-Reply-To: Your message of Wed, 12 May 93 10:38:50 +0200. <9305120838.AA02480@valhall.jenc93.uninett.no> Date: Wed, 12 May 93 07:37:52 MST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: peter@goshawk.lanl.gov Alex, I just deployed a "tubainetd" on tuba.lanl.gov so you can now telnet to this machine directly (without starting up a special TUBA telnet daemon by hand.) The nice thing is that tubainetd uses the "out of the box" version of telnetd (without any changes!). There is a temporary guest account on tuba.lanl.gov, which I will give out upon individual request for tuba testing. We have also deployed a DNS zone "nsap.lanl.gov" which now contains NSAPs: Script started on Wed May 12 07:28:08 1993 labyrinth 8%~/bin/nslookup Default Server: p.lanl.gov Address: 128.165.4.4 > server labyrinth.lanl.gov Default Server: labyrinth.lanl.gov Address: 128.165.114.6 > ls -t NSAP nsap.lanl.gov [labyrinth.lanl.gov] maze 47.0005.8000.5700.0000.0140.0001.FEED.EDFE.EDED.00 tuba 47.0005.8000.5700.0000.0140.0001.0060.8CB1.1EB8.00 peter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10077; 12 May 93 9:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10073; 12 May 93 9:57 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa11073; 12 May 93 9:57 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA29860; Wed, 12 May 93 07:55:10 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23328; Wed, 12 May 93 07:54:45 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23324; Wed, 12 May 93 07:54:43 MDT Received: from EMU.NCSL.NIST.GOV by p.lanl.gov (5.65/1.14) id AA29825; Wed, 12 May 93 07:54:42 -0600 Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA14458; Wed, 12 May 93 09:57:34 EDT Date: Wed, 12 May 93 09:57:34 EDT Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9305121357.AA14458@emu.ncsl.nist.gov> To: alex@demo.jenc93.uninett.no Subject: Re: Sparc binary for nslookup for NSAPs available Cc: tuba@lanl.gov, noop@merit.edu Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: colella@nist.gov Reply-To: colella@nist.gov Alex, > I still have a few questions. > > --------- > Try 'ls -t nsap ' on the domains: > > tuba.ncsl.nist.gov (primary server emu.ncsl.nist.gov) > nsap.lanl.gov (primary server labyrinth.lanl.gov) > cisco.com (primary server dirt.cisco.com) > > -------- > >From what i can make up of this is that you, Peter and cisco have set up > one NSAP capable name server each. Is that correct? Actually, I've shown just the primary name servers for the domains (and I'm not absolutely sure that dirt is cisco's primary). In fact, cisco has four or so name servers, with the others being secondaries. I have one secondary for the tuba.ncsl.nist.gov domain. Peter has the one server, with emu.ncsl.nist.gov acting as secondary for the nsap.lanl.gov domain. However, this is all DNS management gorp, and is usually invisible to the users. > What NSAPs are listed in these servers? Are these lists the same for each > server? Is there an information exchange possibility? The reason I listed servers is that to get a 'ls' from nslookup, you need to connect directly to a server that is serving the domain (e.g., 'server emu.ncsl.nist.gov' will allow you to use 'ls' to get a list of the systems that have nsaps in the tuba.ncsl.nist.gov domain). If you know the name of a system a priori, then you don't need to know the server names. Just use nslookup to ask for its nsap, just like you would use nslookup to ask for any other piece of information. In other words, it's just the DNS that we all know and love. Try this using the binary I put out: % nslookup (some server and address stuff printed) > set type=nsap > cursive.tuba.ncsl.nist.gov. (cursive nsap printed) > red.cisco.com. (red nsap printed) > tuba.nsap.lanl.gov. (etc.) > If i telnet to a name from the NCSA software or from a cisco and the name > is not available in the config.tel file or the clns host table in the cisco, > does it automatically contact one of the name servers? It automatically contacts whatever nameserver it is configured to contact. The nameserver it contacts is whatever local nameserver you normally use. The nameserver it contacts need not understand the nsap resource records; it will pass the request on to a nameserver that is serving the target domain (which *does* understand nsaps). Note1: the NCSA Telnet/TUBA software you have has not been modified to query the DNS for NSAPs. I have a version here that does, but want to add the ftp changes before releasing it. Note2: cisco had an earlier version of DNS NSAP queries in some of their images. What is currently deployed is different from this earlier one. You should talk to your cisco contact about this. > How do i set up another DNS? I want to do that in Europe and i think more > people are interested in this. I'm hoping that the software can be made available very shortly (days to weeks, I think). It's basically the bind 4.9 software, with NSAP diffs from Paul Traina (cisco), which is in beta testing now. We'll let everyone know as soon as it's available. > - Alex > > BTW, i tried logging in to Peter's system using TUBA directly and it works!!! > > P.S. If your NCSA software uses this DNS server, could i have a copy of the new > NCSA software? > > P.S. 2 I will send an updated NSAP list of the current TUBA systems in a minute. > (over the TUBA list) > --Richard   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10487; 12 May 93 10:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10483; 12 May 93 10:20 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa11899; 12 May 93 10:20 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA01172; Wed, 12 May 93 08:18:41 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23462; Wed, 12 May 93 08:18:19 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23458; Wed, 12 May 93 08:18:18 MDT Received: from mail.bellcore.com by p.lanl.gov (5.65/1.14) id AA01145; Wed, 12 May 93 08:18:14 -0600 Received: from [128.96.90.196] (mac16.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA04848; Wed, 12 May 1993 10:15:05 -0400 Message-Id: <199305121415.AA04848@mail.bellcore.com> Date: Wed, 12 May 1993 10:24:25 -0500 To: tuba@lanl.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dave@mail.bellcore.com Subject: while you're doing all this testing & showcasing... has anyone implemented FOOBAR? --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) =======> I am now "dave@mail.bellcore.com"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10800; 12 May 93 10:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10796; 12 May 93 10:31 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa12366; 12 May 93 10:31 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA01637; Wed, 12 May 93 08:27:57 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23527; Wed, 12 May 93 08:27:16 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23523; Wed, 12 May 93 08:27:15 MDT Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA01599; Wed, 12 May 93 08:27:15 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA26098; Wed, 12 May 93 08:27:14 MDT Message-Id: <9305121427.AA26098@goshawk.lanl.gov> To: dave@mail.bellcore.com Cc: tuba@lanl.gov Subject: Re: while you're doing all this testing & showcasing... In-Reply-To: Your message of Wed, 12 May 93 10:24:25 -0500. <199305121415.AA04848@mail.bellcore.com> Date: Wed, 12 May 93 08:27:14 MST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: peter@goshawk.lanl.gov >>> has anyone implemented FOOBAR? In the works ... cheers, peter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13622; 12 May 93 10:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13618; 12 May 93 10:56 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa13564; 12 May 93 10:56 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA03149; Wed, 12 May 93 08:54:03 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23656; Wed, 12 May 93 08:53:16 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23652; Wed, 12 May 93 08:53:11 MDT Received: from EMU.NCSL.NIST.GOV by p.lanl.gov (5.65/1.14) id AA03057; Wed, 12 May 93 08:53:02 -0600 Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA14588; Wed, 12 May 93 10:54:35 EDT Date: Wed, 12 May 93 10:54:35 EDT Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9305121454.AA14588@emu.ncsl.nist.gov> To: dave@mail.bellcore.com Subject: Re: while you're doing all this testing & showcasing... Cc: tuba@lanl.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: colella@nist.gov Reply-To: colella@nist.gov > > has anyone implemented FOOBAR? Not yet, but it's in the queue. --Richard   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25340; 12 May 93 15:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25336; 12 May 93 15:38 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa24186; 12 May 93 15:38 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA19155; Wed, 12 May 93 13:35:33 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA25753; Wed, 12 May 93 13:34:11 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA25749; Wed, 12 May 93 13:34:10 MDT Received: from mail.bellcore.com by p.lanl.gov (5.65/1.14) id AA19046; Wed, 12 May 93 13:34:08 -0600 Received: from [128.96.90.196] (mac16.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA06714; Wed, 12 May 1993 15:31:02 -0400 Message-Id: <199305121931.AA06714@mail.bellcore.com> Date: Wed, 12 May 1993 15:40:23 -0500 To: tuba@lanl.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dave@mail.bellcore.com Subject: suppression of error reports Hi, at the last IETF meeting, I was asked to scour RFC1122 to find additional "host requirements" that might impact TUBA/CLNP implementations. One area of interest is the issue of "silent discards": Currently, RFC1122 says packets MUST be discarded for the following reasons: bad version bad checksum bad ICMP type packet received not destined for the host packet received containing invalid source IP address RFC1122 also recommends that hosts do not generate a packet with lifetime=0. RFC1122 mentions that "Silent discard of erroneous datagrams is generally intended to prevent "broadcast storms", It seems appropriate to suppress these in TUBA/CLNP; what effect will this have on your implementations? CLNP implementations in general? --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) =======> I am now "dave@mail.bellcore.com"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26420; 12 May 93 16:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26415; 12 May 93 16:34 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa26010; 12 May 93 16:34 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA23822; Wed, 12 May 93 14:32:25 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA26120; Wed, 12 May 93 14:31:43 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA26116; Wed, 12 May 93 14:31:42 MDT Received: from bridge2.NSD.3Com.COM by p.lanl.gov (5.65/1.14) id AA23786; Wed, 12 May 93 14:31:43 -0600 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA25278 (5.65c/IDA-1.4.4nsd for ); Wed, 12 May 1993 13:31:39 -0700 Received: by jaspar.NSD.3Com.COM id AA25700 (5.65c/IDA-1.4.4-910730); Wed, 12 May 1993 13:31:38 -0700 Date: Wed, 12 May 1993 13:31:38 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Cyndi M. Jung" Message-Id: <199305122031.AA25700@jaspar.NSD.3Com.COM> To: dave@mail.bellcore.com Subject: Re: suppression of error reports Cc: tuba@lanl.gov Suppression of error report is allowed by 8473 for basically any reason, at least you can always claim local congestion and nobody could prove otherwise, but there is an abstract test suite for CLNP conformance that bases the verdict PASS/FAIL on the ER PDU returned for the packets with bad version or bad checksum - so discarding these could make the product fail conformance, fail to get on the GOSIP register, be ineligible for government contracts (there are already implementations on the register, so those would be bid according to the rules). Personally, I think returning an ER PDU for a packet received with a bad checksum is folly, and the test case should be invalidated. Also, if the version is one the machine has no knowledge of, how can it possibly have confidence extracting the source NSAP from it so it can return the ER PDU? Another bit of folly. But there are reason codes for the ER PDU in both cases. Bad ICMP type - well, I'm not sure what the equivalent would be, other than bad type, since ICMP functional equivalence is divided amoung CLNP and 9542. There is no ER PDU reason code for this, but that same abstract test suite expects to see an ER PDU or the implementation has FAIL'd the test. packet received not destined for the host - looks like a candidate for ER PDU with reason code Unreachable or Unknown, but the ATS doesn't appear to test that, though I've been looking at the router test and not the end system test. packet received containing invalid source IP address - which in the case of IP is mostly an IP broadcast of some sort (all 1's, all 0's, subnet). In CLNP, at least the 1992 version, there is no mention of possible errors in the Source Address - though I believe that the recent ANSI work on Multicast CLNP has made a multicast NSAP invalid as a source address in the CLNP multicast packet (or should if it isn't already). In which case the ER PDU should definitely be suppressed, as it would not be possible to build one with a unicast destination address. So as it stands now, if these slient discards are to become a part of TUBA/CLNP requirements, then the TUBA implementations would become non-conformant according to GOSIP testing. I know there is a movement towards taking control of the ISO standards related to TUBA (CLNP, ES-IS, IS-IS, IDRP), but will that also include taking control of these abstract test suites?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03227; 13 May 93 7:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03223; 13 May 93 7:14 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa06801; 13 May 93 7:14 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA24474; Thu, 13 May 93 05:02:32 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA27951; Thu, 13 May 93 05:01:31 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA27947; Thu, 13 May 93 05:01:30 MDT Received: from survis.surfnet.nl by p.lanl.gov (5.65/1.14) id AA24458; Thu, 13 May 93 05:01:27 -0600 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <06400-0@survis.surfnet.nl>; Thu, 13 May 1993 13:01:08 +0200 To: wg4-clns@funet.fi, tuba@lanl.gov Subject: thanks for the help Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Thu, 13 May 93 13:01:06 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Victor Reijs Message-Id: <"survis.sur.403:13.04.93.11.01.09"@surfnet.nl> Hello all of you, The demonstration of CLNS and TUBA has ended at Trondheim. I can say that the results of the demo are very good. We had a clear picture by means of the SUNnet Mgr of the European CLNS service and by means of the tcpdump/ttcp tools the CLNS and TUBA traffic could be watched and tested over the network. The TUBA demonstration was the biggest part of the whole demo we had, and thanks to everybody, who worked on that, so that we had impressive number of routers (cisco, 3COM) and end system running (SUN OS, BSDI, PC-DOS) over the CLNS service in the world. The services were just a start (telnet being the best demonstratable) and the demo demonstrated again that DNS and stable dynamic routeing is essential running a production service (the numbers on the keyboards are almost unvisible;-), so the CLNS providers have to hard very hard on implementing proper working IS-IS and more important IDRP. I am very glad to have seen DNS being born this week!!! I am convinced that at the TUBA demonstration at JENC (we are already starting the organisation of it), we can show the TUBA more extensive on a world scale (DNS, ftp, SMTP). Thanks again all of you. I would like to mentioned Alex as being the person who did the most TUBA work during this CLNS demonstration at the location of Trondheim. I am not going to mention names of all the people that work hard at their 'homes', but I would say look at the names on the mailing lists!!! Thanks again and All the best, Victor   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00786; 13 May 93 15:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00770; 13 May 93 15:33 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa27085; 13 May 93 15:33 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA18764; Thu, 13 May 93 13:28:49 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00282; Thu, 13 May 93 13:27:48 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00278; Thu, 13 May 93 13:27:47 MDT Received: from dnlts0.research.ptt.nl by p.lanl.gov (5.65/1.14) id AA18682; Thu, 13 May 93 13:27:46 -0600 Received: from research.ptt.nl by research.ptt.nl (PMDF #2928 ) id <01GY52A709LCBJWCC1@research.ptt.nl>; Thu, 13 May 1993 21:28:56 +0200 Date: 13 May 1993 21:28:56 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ALEX REIJNIERSE Subject: Signing off To: wg4-clns@funet.fi Cc: tuba@lanl.gov, sn3plus-clns@surfnet.nl Message-Id: <01GY52A709LEBJWCC1@research.ptt.nl> Organization: PTT Research, The Netherlands X-Envelope-To: tuba@lanl.gov X-Vms-To: IN%"wg4-clns@funet.fi" X-Vms-Cc: IN%"tuba@lanl.gov", IN%"sn3plus-clns@surfnet.nl" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Comments: This mail was sent by PMDF V4.1 Hello All, The TUBA demonstration at Trondheim has ended. With this in mind i would like to thank all the people involved, especially the people that hosted the conference in Trondheim. As Victor, i am not going to mention others, because i might miss someone. Anyway, the persons that feel addressed by this thanks should be. We have seen at Trondheim that there really was an interest in TUBA. I had made some 40 copies of the TUBA demonstration document to get through the first day, but it turned out that i had to make more and more and more. At the end of the conference i even was afraid to go to the copying machine, because i could see people thinking.. HIM AGAIN! From the side of the TUBA implementors, there was really work going on. At the conference itself, another TUBA implementation was introduced, TUBA on SunOS UNIX. Naturally, we tested on showed the implementation on the spot. There even was a guest account installed where we could play a game of GO FISH! This makes a total of 6 implementations: NCSA, BSDi/4.4, RS/6000, SunOS UNIX, Cisco and 3Com (in random order). And of course not to forget the routers that support CLNS. I expecially would like to thank these implementors that even worked the weekend and evenings to make this demonstration a success. From the side of the network operators i would say that the ones that already had CLNS as a network service, there was joy. Others that didn't support CLNS (yet) looked a bit worried. Things we have learned from this: We really need to work on DNS for NSAPs as soon as possible. A typing mistake in the configuration files is easily made. That's why i was really glad to see that at the conference, an early DNS for NSAPs was released. Three of the TUBA implementations already work with this DNS. So work is being done. Another thing was that all TUBA implentations should be released into the public domain. People were constantly asking me where to get these implementations. If we what TUBA to grow even faster, than this is the thing to do. Finally, i would like to stress that work must be done on IP<->CLNS gateways for the transition period. In this period, old IP hosts still need to talk to new (TUBA) hosts, so IP<->CLNS gatewaying is needed. Finally, i would like to invite all of you to participate in the TUBA demonstration at the IETF meeting in Amsterdam. I hope to show some real mature TUBA implementations of FTP and SMTP there. If you might have any good ideas for this joint demonstration, let me know. Many thanks, - Alex Reijnierse P.S. I am going to send over the list the TUBA demonstration document in postscript, but if you think you will get it before the weekend, you're wrong. I am going to take a rest!!!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05455; 13 May 93 16:25 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05451; 13 May 93 16:25 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa29222; 13 May 93 16:25 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA22914; Thu, 13 May 93 14:20:53 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00823; Thu, 13 May 93 14:19:53 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00819; Thu, 13 May 93 14:19:51 MDT Received: from cider.cisco.com by p.lanl.gov (5.65/1.14) id AA22826; Thu, 13 May 93 14:19:52 -0600 Received: from localhost by cider.cisco.com with TCP; Thu, 13 May 1993 13:19:43 -0700 Message-Id: <199305132019.AA27206@cider.cisco.com> To: wg4-clns@funet.fi Cc: tuba@lanl.gov, sn3plus-clns@surfnet.nl Subject: tuba Date: Thu, 13 May 1993 13:19:42 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paul Traina I'll trade a DNS for TUBA for a SunOS implementation. :-)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06378; 14 May 93 12:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06374; 14 May 93 12:09 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa13518; 14 May 93 12:09 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA07512; Fri, 14 May 93 10:05:10 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03584; Fri, 14 May 93 10:03:59 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03580; Fri, 14 May 93 10:03:59 MDT Received: from worldlink.com by p.lanl.gov (5.65/1.14) id AA07451; Fri, 14 May 93 10:03:53 -0600 Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA14546; Fri, 14 May 93 12:05:21 -0400 Date: Fri, 14 May 93 12:05:21 -0400 Message-Id: <9305141605.AA14546@worldlink.worldlink.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David M. Piscitello" To: Dino Farinacci Cc: tuba@lanl.gov Subject: Re: final word on pseudo-header In a private mail to Dino, I said... >> in the mail you posted *way* back in February (2/5/93 to be exact) >> describing the pseudoheader implementation, you >> indicated that "the last byte in each NSAP address has the value >> 0x06 for TCP and 0x11 for UDP. This is inconsistent with the addressing >> text, which recommends that the selector field of the source address be >> zeroed. >> Did you err, or were you suggesting that the source address selector should >> carry the protocol value? Dino sez in reply... >I was suggesting that the N-selector used for the pseudo-header > checksum be the same as the one in the CLNP packet, for both source > and destination NSAP addresses. Therefore, it is non-zero. OK, then you are suggesting something different than what I believe we agreed to quite a while ago, (at Ross's insistence?), which was to leave the selector field of the source NSAPA field zero. I am quite comfortable having the selector set to PROTO value in both addresses. Is everyone else implementing this way? Are we happy with making this change to the clnp internet-draft?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06421; 14 May 93 12:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06417; 14 May 93 12:12 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa13575; 14 May 93 12:12 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA07568; Fri, 14 May 93 10:06:10 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03600; Fri, 14 May 93 10:05:47 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03596; Fri, 14 May 93 10:05:46 MDT Received: from worldlink.com by p.lanl.gov (5.65/1.14) id AA07532; Fri, 14 May 93 10:05:29 -0600 Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA14644; Fri, 14 May 93 12:06:55 -0400 Date: Fri, 14 May 93 12:06:55 -0400 Message-Id: <9305141606.AA14644@worldlink.worldlink.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David M. Piscitello" To: tuba@lanl.gov Subject: replies to Cyndi on suppression of error reports Cyndi, thank you for the very helpful insights. We certainly don't want to create a situation where you can satisfy tuba/clnp interoperability but not GOSIP conformance. As you point out, there are, some situations ISO/IEC 8473 seems to handle incorrectly (hindsight...) >Personally, I think returning an ER PDU for a packet received with a >bad checksum is folly, and the test case should be invalidated. Also, >if the version is one the machine has no knowledge of, how can it possibly >have confidence extracting the source NSAP from it so it can return the >ER PDU? Another bit of folly. both of these are truly broken ideas. beyond the issue of having no confidence in the NSAPA you might use to route the error report, you may misdirect the pdu to a host that does not share the same security as the originator of the errored pdu. this is IMHO very bad. >Bad ICMP type - well, I'm not sure what the equivalent would be, other than >bad type, since ICMP functional equivalence is divided amoung CLNP and >9542. There is no ER PDU reason code for this, but that same abstract test >suite expects to see an ER PDU or the implementation has FAIL'd the test. I think in this case you'd return a bad header error reason code and point to the type octet. >packet received not destined for the host - looks like a candidate for >ER PDU with reason code Unreachable or Unknown, but the ATS doesn't appear >to test that, though I've been looking at the router test and not the >end system test. >In CLNP, at least the 1992 version, there is no mention of possible >errors in the Source Address - though I believe that the recent ANSI again, you'd return bad header error reason code and point to the first octet of the source address (aren't you supposed to do this with the second octet of the reason for discard field whenever you can localize the error to a particular header field?) >work on Multicast CLNP has made a multicast NSAP invalid as a source >address in the CLNP multicast packet (or should if it isn't already). In >which case the ER PDU should definitely be suppressed, as it would not >be possible to build one with a unicast destination address. >So as it stands now, if these slient discards are to become a part of >TUBA/CLNP requirements, then the TUBA implementations would become >non-conformant according to GOSIP testing. I know there is a movement >towards taking control of the ISO standards related to TUBA (CLNP, ES-IS, >IS-IS, IDRP), but will that also include taking control of these abstract >test suites? I think for now, we keep these out of tuba/clnp, but forward them to the X3S33 mailing list for consideraton in edition 2. problem is, as you point out, that changes of this nature to the ISO standard cause testing and interoperability problems. So perhaps the best idea is to get the test suites changes first, then correct and elaborate on these in the ISO Standard. BTW, I found another curious error code situation. Depending on the circumstance, if you receive an incomplete PDU, you may or may not have sufficient information to return an error report. The standard only mentions that you should return one.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06621; 14 May 93 12:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06617; 14 May 93 12:38 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa14229; 14 May 93 12:38 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA09544; Fri, 14 May 93 10:37:33 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03892; Fri, 14 May 93 10:37:03 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03888; Fri, 14 May 93 10:37:02 MDT Received: from regal.cisco.com by p.lanl.gov (5.65/1.14) id AA09510; Fri, 14 May 93 10:37:02 -0600 Received: by regal.cisco.com; Fri, 14 May 1993 09:35:39 -0700 Date: Fri, 14 May 1993 09:35:39 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dino Farinacci Message-Id: <199305141635.AA23849@regal.cisco.com> To: dave@mail.bellcore.com Cc: tuba@lanl.gov In-Reply-To: David M. Piscitello's message of Fri, 14 May 93 12:05:21 -0400 <9305141605.AA14546@worldlink.worldlink.com> Subject: final word on pseudo-header >> OK, then you are suggesting something different than >> what I believe we agreed to quite a while ago, (at Ross's insistence?), >> which was to leave the selector field of the source NSAPA field >> zero. I am quite comfortable having the selector set to PROTO value >> in both addresses. Is everyone else implementing this way? Are we >> happy with making this change to the clnp internet-draft? If no one else has implemented it this way, how do you explain the interoperability. Dino   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10626; 14 May 93 16:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10622; 14 May 93 16:48 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22409; 14 May 93 16:48 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 14 May 93 16:48:00 EDT Received: from atc.boeing.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Fri, 14 May 93 16:47:57 EDT Received: by atc.boeing.com (5.57) id AA14355; Fri, 14 May 93 13:52:03 -0700 Date: Fri, 14 May 93 13:52:03 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eric Fleischman Message-Id: <9305142052.AA14355@atc.boeing.com> To: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Subject: PROs/CONs of SIP/PIP/TUBA Cc: ericf@thumper.bellcore.com Request for Assistance I am frequently asked by other Boeing employees to explain to them the PROs (advantages) and CONs (disadvantages, unknowns, vulnerabilities) of the major IPng approaches. I have constructed the following list of the unique elements which form the PROs and CONs of SIP, PIP, and TUBA in order to partially satisfy these requests. However, I have noticed that my own understanding of these approaches is imperfect. This implies that I may have inadvertently misrepresented some of the proposals in various ways. Unfortunately, I am not usually aware of when I have been inaccurate. For this reason I am sending this note out to the SIP, PIP, and TUBA working groups in order to elicit their assistance to more accurately characterize these approaches. I offer my apologies to those people who, like me, belong to multiple lists since this will mean that we will be bothered by multiple copies of this note. I would like to request that interested parties read the following lists of PROs and CONs in order to enhance the list. I recognize the possibility that differing people may label the same feature differently since there are a variety of legitimate and differing perspectives by which the IPng issues may be viewed. For this reason, I would appreciate it if the responders would explicitly note the viewpoint of their comments (e.g., network providers, university, router vendor, end system vendor, government, non-computer-related industry, etc.) together with their sage advice as to how this list may be improved/enhanced. An enhanced version of this list may be requested in a week or two once the anticipated suggestions have been assimilated. One more thing: I have no desire to spark another "whose protocol is best" flaming fest by this request (hence I am not sending it to the big-internet list). Thus, I suggest that any respondent seriously consider not copying the entire list unless the response is deemed to be of value to the community as a whole (i.e., accomplishes more than just instructing a certain naive yours truly). In any case, thank you for your attention to this matter. Sincerely yours, --Eric Fleischman +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ SIP Pro 1) As much like the current TCP/IP network layer protocols as possible (except for SIP System Discovery which enhances upon the current protocols). This leverages off of our current IPv4 knowledge-base for IPng deployments (e.g., reduce training costs, etc.). It also greatly reduces the "risk factor" of introducing new technologies. 2) SIP has fewer options than IPv4 which means that it is even simpler than IPv4 to process (e.g., to route). 3) Theoretically positioned to better support "flows" and other future technologies than is the case for IPv4. 4) Has IPAE and other well-thought-out migration approaches. [Question to the reader: I suspect that a slightly modified IPAE would also work for TUBA and EIPIP has been proposed for PIP. Thus, is this really an advantage of SIP? Isn't it rather merely a function of the expertise of the original SIP designers rather than an inherent advantage of the SIP approach?] SIP Con 1) Since hierarchical addresses tend to be deployed in a "sparse" manner, it unclear whether a 64 bit address space will adequately scale to meet every conceivable future addressing scenario. 2) No SIP protocol is totally unchanged from its "IPv4" equivalent. This introduces a certain degree of risk in its deployment (i.e., the unknown). 3) No network provider currently supports SIP. 4) RFC 1454 stated: "although there are a few 'reserved' bits in the header, the extension of SIP to support new features is not obvious". [Question to the reader: Is this really the case? Isn't it rather the case that new features will be supported by optional header data field additions whose existence is signaled by the payload type field? But then, how would this be generally extensible for complex permutations of payload types? If so, then probably the original claim of RFC 1454 has merit. Does it?] -------------------------------------------------------------------------- PIP Pro 1. General routing and addressing without performance hit (i.e., in most cases PIP routes faster than IPv4. Exception is IP cache hit...) Tangible near-term benefit of this generality is provider selection and policy routing in general together with potentially simplified address administration. Longer term benefit of this generality is ability to evolve to new routing and addressing paradigms. 2. PIP has more features. These include provider selection, auto host configuration (address, ID, domain name, and DNS server address, plus auto-config of DNS), PDN address discovery, and domain-wide address prefix autoconfiguration. 3. Evolvability. PIP is architected to be well positioned to support "flows" and other future network-layer technologies (e.g., separation of routing/identification/handling), plus has explicit evolution mechanisms (contents numbers, host version number, fast options handling). This will hopefully enhance the possibility of support for real-time services. PIP Con 1. Complexity. 2. PIP is not directly based on existing protocols. Thus, it represents new technologies and it has a new addressing paradigm. This "newness" implies an unknown deployment "risk" factor (i.e., the "unknown"). 3. Since the PIP approach is novel, it represents a significant "learning curve" for deployments with attendant expenses. 4. No network provider currently supports PIP. -------------------------------------------------------------------------- TUBA Pro 1. Every TUBA protocol already exists and has experienced some degree of actual deployment experience. TUBA adopts these OSI network layer protocols in an unchanged fashion. 2. Internet currently becoming "bilingual" with IPv4 and CLNP. Thus, no change for many network providers to support TUBA. 3. Will partially join the TCP/IP and OSI/CCITT communities -- hopefully for greater synergy between these communities for those end users which currently support both protocol families. This may translate into reduced end user network complexity. 4. Has proven auto-configuration (auto-addressing) capabilities. 5. Is based upon International Standards and government-supported protocols which are currently mandated in certain environments. 6. Integrated IS-IS already exists for mixed IPv4/TUBA deployments. Integrated-OSPF (for IPv4/IPng) is yet to be defined. 7. The 160 bit TUBA address space is well positioned to meet any future address scaling requirement. TUBA Con 1. Unless a company is already familiar with OSI's connectionless network layer protocols, TUBA represents a significant "learning curve" for deployments with attendant expenses. 2. TUBA is no more positioned to support "flows" and other possible future technologies than is IPv4. 3. TUBA supports a 160 bit network address which represents a potentially significant overhead penalty for some environments. 4. TUBA protocols are not "tuned" for maximum routing efficiency (e.g. checksum, attention to 32-bit CPU alignment issues).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09125; 16 May 93 0:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09121; 16 May 93 0:56 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa24783; 16 May 93 0:56 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA20222; Sat, 15 May 93 22:54:06 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA07780; Sat, 15 May 93 22:52:23 MDT Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA07776; Sat, 15 May 93 22:52:22 MDT Received: from merit.edu by p.lanl.gov (5.65/1.14) id AA20210; Sat, 15 May 93 22:52:25 -0600 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA12857; Sun, 16 May 93 00:52:24 -0400 Message-Id: <9305160452.AA12857@merit.edu> To: tuba@lanl.gov Subject: IP-TNG Presentations in Amsterdam Date: Sun, 16 May 1993 00:52:24 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Knopper Hi. I thought it would be best to first share this message with the TUBA group for discussion before Peter and I answer it. Mark > From: Steve Coya > To: francis@thumper.bellcore.com, deering@parc.xerox.com, hinden@eng.sun .com, ullmann@process.com, mak@merit.edu, peter@lanl.gov > Greetings, > > Yes, it's me again, with a variation on a theme. > > I am working on setting up the technical presentations for the IETF > meeting in Amsterdam, and would like to have another in the series of > IPng. This time I have a very specific theme or focus in mind: what > needs to be done to implement. > > Essentially, I am envisioning responses to the global question: if the > [candidate name here] proposal was to be implemented, what needs to be > done? I am hoping for specific answers to cover such things as: > > a. changes that need to be made in hosts and/or routers > > "changes" means both table entries, modifications to software > (and what software), configuration changes, etc. > > > b. deployment strategy and pre-requisites > > By this I mean identifying what must be done before something > else is done (changes in router before changes to hosts, or > start at remote networks and work in to the regionals, say a > silent prayer and hit the button, etc.). > > > c. Coordination and cooperation > > what administrative efforts are needed (primarily between and > among network operators, though there might be others), etc. > > > > So, that's the idea. What I'd like to get in the way of responses are: > > 1. Are you interested in participating? > 2. Any suggestions or changes to the above theme? > > > Thanks in advance. > > > > Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19613; 17 May 93 3:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19609; 17 May 93 3:07 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa24280; 17 May 93 3:07 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA05407; Mon, 17 May 93 00:59:17 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA09903; Mon, 17 May 93 00:58:28 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA09899; Mon, 17 May 93 00:58:27 MDT Received: from dxmint.cern.ch by p.lanl.gov (5.65/1.14) id AA05379; Mon, 17 May 93 00:58:28 -0600 Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03621; Mon, 17 May 1993 08:58:19 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA13138; Mon, 17 May 1993 08:58:18 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9305170658.AA13138@dxcern.cern.ch> Subject: Re: IP-TNG Presentations in Amsterdam To: tuba@lanl.gov Date: Mon, 17 May 1993 08:58:17 +0200 (MET DST) In-Reply-To: <9305160452.AA12857@merit.edu> from "Mark Knopper" at May 16, 93 00:52:24 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1488 Tuba-ites, > > > > Essentially, I am envisioning responses to the global question: if the > > [candidate name here] proposal was to be implemented, what needs to be > > done? I am hoping for specific answers to cover such things as: > > > > a. changes that need to be made in hosts and/or routers > > > > "changes" means both table entries, modifications to software > > (and what software), configuration changes, etc. > > > > > > b. deployment strategy and pre-requisites > > > > By this I mean identifying what must be done before something > > else is done (changes in router before changes to hosts, or > > start at remote networks and work in to the regionals, say a > > silent prayer and hit the button, etc.). > > > > > > c. Coordination and cooperation > > > > what administrative efforts are needed (primarily between and > > among network operators, though there might be others), etc. Yes, yes, yes we must answer all these questions, otherwise forget the whole thing. I had understood that a couple of people were tasked to do essentially this after Columbus, and I would volunteer to start drafting except that I am about to take off for 2 weeks. I hereby volunteer to join in the drafting when I get back. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of | | PIP, SIP, IPv7, Nimrod, TUBA or anything. |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26545; 17 May 93 10:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26540; 17 May 93 10:31 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa03188; 17 May 93 10:31 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA15905; Mon, 17 May 93 08:28:45 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA11352; Mon, 17 May 93 08:28:17 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA11348; Mon, 17 May 93 08:28:14 MDT Received: from munin.fnal.gov by p.lanl.gov (5.65/1.14) id AA15886; Mon, 17 May 93 08:28:13 -0600 Received: from localhost.fnal.gov by munin.fnal.gov with SMTP id AA27198 (5.65c+/IDA-1.4.4 for tuba@lanl.gov); Mon, 17 May 1993 09:26:39 -0500 Message-Id: <199305171426.AA27198@munin.fnal.gov> To: John Day Cc: tuba@lanl.gov Subject: Re: final word on pseudo-header In-Reply-To: Your message of Sun, 16 May 93 21:33:12 EDT. <9305171300.AA12621@p.lanl.gov> Date: Mon, 17 May 93 09:26:39 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Matt Crawford > Managing what protocols are assigned to what addresses should be as much > a local matter as we can make it. It greatly decentralizes the operation > of the network. It also adds quite a bit of hair to the problem of setting up a network analyzer to, for example, "show me all the FTP traffic crossing this segment." _________________________________________________________ Matt Crawford crawdad@munin.fnal.gov Fermilab   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27532; 17 May 93 11:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27527; 17 May 93 11:03 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa04447; 17 May 93 11:03 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA17497; Mon, 17 May 93 09:00:44 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA11558; Mon, 17 May 93 09:00:22 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA11554; Mon, 17 May 93 09:00:21 MDT Received: from BBN.COM by p.lanl.gov (5.65/1.14) id AA17451; Mon, 17 May 93 09:00:19 -0600 Message-Id: <9305171500.AA17451@p.lanl.gov> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Day Subject: Re: final word on pseudo-header To: crawdad@munin.fnal.gov Cc: Day@p.lanl.gov, tuba@lanl.gov In-Reply-To: <199305171426.AA27198@munin.fnal.gov> Date: Mon, 17 May 93 11:03:42 EST Mail-System-Version: Matt >> Managing what protocols are assigned to what addresses should be as much >> a local matter as we can make it. It greatly decentralizes the operation >> of the network. > >It also adds quite a bit of hair to the problem of setting up a >network analyzer to, for example, "show me all the FTP traffic >crossing this segment." Then we do spend a lot more time debugging these networks than we do using them. John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27625; 17 May 93 11:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27621; 17 May 93 11:06 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aj04544; 17 May 93 11:05 EDT Received: from p.lanl.gov by IETF.CNRI.Reston.VA.US id aa24399; 17 May 93 9:12 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA12722; Mon, 17 May 93 07:02:32 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA10876; Mon, 17 May 93 07:01:06 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA10872; Mon, 17 May 93 07:00:49 MDT Received: from BBN.COM by p.lanl.gov (5.65/1.14) id AA12621; Mon, 17 May 93 07:00:41 -0600 Message-Id: <9305171300.AA12621@p.lanl.gov> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Day Subject: Re: final word on pseudo-header To: dino@cisco.com Cc: tuba@lanl.gov In-Reply-To: <199305141635.AA23849@regal.cisco.com> Date: Sun, 16 May 93 21:33:12 EDT Mail-System-Version: Guys, I can't answer Dino's question as to why it works, but I really do not like the idea of the NSEL identifying the protocol in the next higher layer. This is equivalent to well-known sockets and we did well-known sockets as a quick and dirty fix so we could use the net back in the 1971 or 72. We knew then that the address mappings should be handled by a directory, but we didn't have time to design and build one. (I have always likened well-known sockets to hard wiring low core in a processor architecture. We found that wasn't a good idea and this isn't either.) Managing what protocols are assigned to what addresses should be as much a local matter as we can make it. It greatly decentralizes the operation of the network. With TUBA, we can start to move away from a 30 year old kludge and get on with modern networking. Leave the NSEL out of it. (I still haven't figured out why there is one in the first place, certainly for the same reasons we created them in the upper layers.) Take care John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27671; 17 May 93 11:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27666; 17 May 93 11:06 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id at04544; 17 May 93 11:06 EDT Received: from p.lanl.gov by IETF.CNRI.Reston.VA.US id aa24467; 17 May 93 9:16 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA12822; Mon, 17 May 93 07:04:52 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA10913; Mon, 17 May 93 07:04:15 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA10909; Mon, 17 May 93 07:04:13 MDT Received: from BBN.COM by p.lanl.gov (5.65/1.14) id AA12758; Mon, 17 May 93 07:04:08 -0600 Message-Id: <9305171304.AA12758@p.lanl.gov> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Day Subject: Re: PROs/CONs of SIP/PIP/TUBA To: ericf@atc.boeing.com, X3S33@merit.edu Cc: ericf@p.lanl.gov, pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov In-Reply-To: <9305142052.AA14355@atc.boeing.com> Date: Sun, 16 May 93 21:55:04 EDT Mail-System-Version: >Received: from p.lanl.gov by BBN.COM id aa22582; 14 May 93 16:59 EDT >Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) > id AA26009; Fri, 14 May 93 14:53:37 -0600 >Received: by noc-gw.lanl.gov (4.1/SMI-4.1) > id AA05087; Fri, 14 May 93 14:51:28 MDT >Return-Path: >Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) > id AA05070; Fri, 14 May 93 14:50:39 MDT >Received: from atc.boeing.com by p.lanl.gov (5.65/1.14) > id AA25744; Fri, 14 May 93 14:48:53 -0600 >Received: by atc.boeing.com (5.57) > id AA14355; Fri, 14 May 93 13:52:03 -0700 >Date: Fri, 14 May 93 13:52:03 -0700 >From: Eric Fleischman >Message-Id: <9305142052.AA14355@atc.boeing.com> >To: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov >Subject: PROs/CONs of SIP/PIP/TUBA >Cc: ericf@p.lanl.gov > > Request for Assistance > >I am frequently asked by other Boeing employees to explain to them the PROs >(advantages) and CONs (disadvantages, unknowns, vulnerabilities) of the >major IPng approaches. I have constructed the following list of the unique >elements which form the PROs and CONs of SIP, PIP, and TUBA in order to >partially satisfy these requests. However, I have noticed that my own >understanding of these approaches is imperfect. This implies that I may have >inadvertently misrepresented some of the proposals in various ways. >Unfortunately, I am not usually aware of when I have been inaccurate. For >this reason I am sending this note out to the SIP, PIP, and TUBA working >groups in order to elicit their assistance to more accurately characterize >these approaches. I offer my apologies to those people who, like me, belong >to multiple lists since this will mean that we will be bothered by multiple >copies of this note. > >I would like to request that interested parties read the following lists of >PROs and CONs in order to enhance the list. I recognize the possibility >that differing people may label the same feature differently since there are >a variety of legitimate and differing perspectives by which the IPng issues >may be viewed. For this reason, I would appreciate it if the responders >would explicitly note the viewpoint of their comments (e.g., network >providers, university, router vendor, end system vendor, government, >non-computer-related industry, etc.) together with their sage advice >as to how this list may be improved/enhanced. An enhanced version of >this list may be requested in a week or two once the anticipated >suggestions have been assimilated. > >One more thing: I have no desire to spark another "whose protocol is best" >flaming fest by this request (hence I am not sending it to the >big-internet list). Thus, I suggest that any respondent seriously >consider not copying the entire list unless the response is deemed to be of >value to the community as a whole (i.e., accomplishes more than just >instructing a certain naive yours truly). > >In any case, thank you for your attention to this matter. > >Sincerely yours, > >--Eric Fleischman > >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > SIP Pro > >1) As much like the current TCP/IP network layer protocols as possible >(except for SIP System Discovery which enhances upon the current protocols). >This leverages off of our current IPv4 knowledge-base for IPng deployments >(e.g., reduce training costs, etc.). It also greatly reduces the "risk >factor" of introducing new technologies. > >2) SIP has fewer options than IPv4 which means that it is even simpler >than IPv4 to process (e.g., to route). > >3) Theoretically positioned to better support "flows" and other future >technologies than is the case for IPv4. Actually as long as the addresses are assigned to each "flow" all of the current protocols, IP, CLNP, SIP, PIP are equally well positioned to support flows. The problem is that we tend to treat everything going to the same place as the same address, which they only sort of are. Different addresses at the same place are really means for distinguishing different types of flows. If you take this view you won't believe the options you can get rid of. For example, priority is simply a flow with different traffic characteristics and should be on a separate address. > >4) Has IPAE and other well-thought-out migration approaches. [Question >to the reader: I suspect that a slightly modified IPAE would also work >for TUBA and EIPIP has been proposed for PIP. Thus, is this really an >advantage of SIP? Isn't it rather merely a function of the expertise of >the original SIP designers rather than an inherent advantage of the SIP >approach?] > I would list this as a CON. The IPAE properties that create the kind of chaos found in some European phone systems where the number you are calling depends on where you are calling from (and I don't mean just more numbers added on the front; different numbers added on the front depending on where you are calling from) is not something we want to foist on the world. Even the PTTs that did it don't seem to consider it a good idea. They are getting rid of it. > SIP Con > >1) Since hierarchical addresses tend to be deployed in a "sparse" manner, >it unclear whether a 64 bit address space will adequately scale to meet >every conceivable future addressing scenario. It is pretty clear that any fixed length will never be enough. > >2) No SIP protocol is totally unchanged from its "IPv4" equivalent. This >introduces a certain degree of risk in its deployment (i.e., the unknown). > >3) No network provider currently supports SIP. > >4) RFC 1454 stated: "although there are a few 'reserved' bits in the >header, the extension of SIP to support new features is not obvious". >[Question to the reader: Is this really the case? Isn't it rather the >case that new features will be supported by optional header data field >additions whose existence is signaled by the payload type field? But then, >how would this be generally extensible for complex permutations of payload >types? If so, then probably the original claim of RFC 1454 has merit. >Does it?] > >-------------------------------------------------------------------------- > > PIP Pro > >1. General routing and addressing without performance hit (i.e., in most >cases PIP routes faster than IPv4. Exception is IP cache hit...) Tangible >near-term benefit of this generality is provider selection and policy routing >in general together with potentially simplified address administration. >Longer term benefit of this generality is ability to evolve to new routing >and addressing paradigms. Addressing is independent of all of these protocols to the extent that an address from an addressing plan can be made to fit in the header. To the same extent, all of these protocols are independent of the routing. In fact this is a major advantage of all of these protocols. As long as the PDU that carries the user-data is independent of the addressing and routing (especially the latter), it will be possible to evolve routing techniques without disturbing the end-systems. Since we still have a lot to learn about routing this sounds like a big win, especially since it is so difficult to predict how new routing algorithms will work in the large. If PIP is really tied to a particular addressing and routing strategy then this is not a PRO. > >2. PIP has more features. These include provider selection, auto host >configuration (address, ID, domain name, and DNS server address, plus >auto-config of DNS), PDN address discovery, and domain-wide address prefix >autoconfiguration. Again, I hope these are properties of the protocols supporting PIP and not PIP itself. Otherwise, choosing PIP and then finding that one or more of its features are less desirable than first appears, then changing it is going to be very painful. > >3. Evolvability. PIP is architected to be well positioned to support >"flows" and other future network-layer technologies (e.g., separation of >routing/identification/handling), plus has explicit evolution mechanisms >(contents numbers, host version number, fast options handling). This will >hopefully enhance the possibility of support for real-time services. > > PIP Con > >1. Complexity. Might expand on this a bit. > >2. PIP is not directly based on existing protocols. Thus, it represents new >technologies and it has a new addressing paradigm. This "newness" implies >an unknown deployment "risk" factor (i.e., the "unknown"). > >3. Since the PIP approach is novel, it represents a significant "learning >curve" for deployments with attendant expenses. > >4. No network provider currently supports PIP. > >-------------------------------------------------------------------------- > > TUBA Pro > >1. Every TUBA protocol already exists and has experienced some degree of >actual deployment experience. TUBA adopts these OSI network layer protocols >in an unchanged fashion. > >2. Internet currently becoming "bilingual" with IPv4 and CLNP. Thus, no >change for many network providers to support TUBA. > >3. Will partially join the TCP/IP and OSI/CCITT communities -- hopefully >for greater synergy between these communities for those end users which >currently support both protocol families. This may translate into reduced >end user network complexity. > >4. Has proven auto-configuration (auto-addressing) capabilities. > >5. Is based upon International Standards and government-supported protocols >which are currently mandated in certain environments. > >6. Integrated IS-IS already exists for mixed IPv4/TUBA deployments. >Integrated-OSPF (for IPv4/IPng) is yet to be defined. > >7. The 160 bit TUBA address space is well positioned to meet any future >address scaling requirement. > > TUBA Con > >1. Unless a company is already familiar with OSI's connectionless network >layer protocols, TUBA represents a significant "learning curve" for >deployments with attendant expenses. > >2. TUBA is no more positioned to support "flows" and other possible future >technologies than is IPv4. > >3. TUBA supports a 160 bit network address which represents a potentially >significant overhead penalty for some environments. > >4. TUBA protocols are not "tuned" for maximum routing efficiency (e.g. >checksum, attention to 32-bit CPU alignment issues). >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28090; 17 May 93 11:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28086; 17 May 93 11:14 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05020; 17 May 93 11:14 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 17 May 93 11:13:23 EDT Received: from alpha.xerox.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 17 May 93 11:13:22 EDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11616>; Mon, 17 May 1993 08:12:53 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 17 May 1993 08:12:44 -0700 To: John Day Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Subject: Re: PROs/CONs of SIP/PIP/TUBA In-Reply-To: Your message of "Sun, 16 May 93 18:55:04 PDT." <9305171304.AA12758@p.lanl.gov> Date: Mon, 17 May 1993 08:12:32 PDT X-Orig-Sender: Steve Deering Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Deering Message-Id: <93May17.081244pdt.12171@skylark.parc.xerox.com> John Day wrote: > The IPAE properties that create the kind of > chaos found in some European phone systems where the number you are > calling depends on where you are calling from (and I don't mean just > more numbers added on the front; different numbers added on the front > depending on where you are calling from) is not something we want to > foist on the world. That is not a property of IPAE. If it is possible for someone to come to so false a conclusion after reading the IPAE specification, we clearly need to work more on that specification. > >1) Since hierarchical addresses tend to be deployed in a "sparse" manner, > >it unclear whether a 64 bit address space will adequately scale to meet > >every conceivable future addressing scenario. > > It is pretty clear that any fixed length will never be enough. Yes, in the sense that it is possible to conceive of an addressing scenario that uses an unbounded number of bits. Once we have infinitely fast routers with infinite memory, joined by links of infinite bandwidth, we could consider implementing an internet protocol with unbounded address length. Until then, we'll have to make an engineering choice of maximum address length. SIP's 64-bit address space is 10^7 times larger than the international telephone numbering space, and if managed sensibly (i.e., not just allowing everyone to cobble up their own favorite octet string and expect the world to be able to route on it) it will scale to handle many thousands of computers in every room and vehicle in this solar system. > Different addresses at the same place are really means for > distinguishing different types of flows. If you take this view you won't > believe the options you can get rid of. For example, priority is simply > a flow with different traffic characteristics and should be on a > separate address. That would work fine for connection-oriented priority, where the mappings from address to priority can be pre-established in the routers along a path. If your protocol supports connectionless priority (e.g., "loss preference" for layered video encodings) you don't want to have each of your routers doing some sort of directory lookup on each packet's destination address in order to determine the priority of the packet -- you want well-known priority values as a separate field (or in a fixed, known location within the address, which is effectively the same as a separate field). Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28163; 17 May 93 11:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28150; 17 May 93 11:16 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05178; 17 May 93 11:16 EDT Received: from thumper.bellcore.com by IETF.CNRI.Reston.VA.US id aa24293; 17 May 93 9:06 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 17 May 93 09:04:38 EDT Received: from BBN.COM by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 17 May 93 09:04:30 EDT Message-Id: <9305171304.AA05735@thumper.bellcore.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Day Subject: Re: PROs/CONs of SIP/PIP/TUBA To: ericf@atc.boeing.com, X3S33@merit.edu Cc: ericf@p.lanl.gov, pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov In-Reply-To: <9305142052.AA14355@atc.boeing.com> Date: Sun, 16 May 93 21:55:04 EDT Mail-System-Version: >Received: from p.lanl.gov by BBN.COM id aa22582; 14 May 93 16:59 EDT >Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) > id AA26009; Fri, 14 May 93 14:53:37 -0600 >Received: by noc-gw.lanl.gov (4.1/SMI-4.1) > id AA05087; Fri, 14 May 93 14:51:28 MDT >Return-Path: >Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) > id AA05070; Fri, 14 May 93 14:50:39 MDT >Received: from atc.boeing.com by p.lanl.gov (5.65/1.14) > id AA25744; Fri, 14 May 93 14:48:53 -0600 >Received: by atc.boeing.com (5.57) > id AA14355; Fri, 14 May 93 13:52:03 -0700 >Date: Fri, 14 May 93 13:52:03 -0700 >From: Eric Fleischman >Message-Id: <9305142052.AA14355@atc.boeing.com> >To: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov >Subject: PROs/CONs of SIP/PIP/TUBA >Cc: ericf@p.lanl.gov > > Request for Assistance > >I am frequently asked by other Boeing employees to explain to them the PROs >(advantages) and CONs (disadvantages, unknowns, vulnerabilities) of the >major IPng approaches. I have constructed the following list of the unique >elements which form the PROs and CONs of SIP, PIP, and TUBA in order to >partially satisfy these requests. However, I have noticed that my own >understanding of these approaches is imperfect. This implies that I may have >inadvertently misrepresented some of the proposals in various ways. >Unfortunately, I am not usually aware of when I have been inaccurate. For >this reason I am sending this note out to the SIP, PIP, and TUBA working >groups in order to elicit their assistance to more accurately characterize >these approaches. I offer my apologies to those people who, like me, belong >to multiple lists since this will mean that we will be bothered by multiple >copies of this note. > >I would like to request that interested parties read the following lists of >PROs and CONs in order to enhance the list. I recognize the possibility >that differing people may label the same feature differently since there are >a variety of legitimate and differing perspectives by which the IPng issues >may be viewed. For this reason, I would appreciate it if the responders >would explicitly note the viewpoint of their comments (e.g., network >providers, university, router vendor, end system vendor, government, >non-computer-related industry, etc.) together with their sage advice >as to how this list may be improved/enhanced. An enhanced version of >this list may be requested in a week or two once the anticipated >suggestions have been assimilated. > >One more thing: I have no desire to spark another "whose protocol is best" >flaming fest by this request (hence I am not sending it to the >big-internet list). Thus, I suggest that any respondent seriously >consider not copying the entire list unless the response is deemed to be of >value to the community as a whole (i.e., accomplishes more than just >instructing a certain naive yours truly). > >In any case, thank you for your attention to this matter. > >Sincerely yours, > >--Eric Fleischman > >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > SIP Pro > >1) As much like the current TCP/IP network layer protocols as possible >(except for SIP System Discovery which enhances upon the current protocols). >This leverages off of our current IPv4 knowledge-base for IPng deployments >(e.g., reduce training costs, etc.). It also greatly reduces the "risk >factor" of introducing new technologies. > >2) SIP has fewer options than IPv4 which means that it is even simpler >than IPv4 to process (e.g., to route). > >3) Theoretically positioned to better support "flows" and other future >technologies than is the case for IPv4. Actually as long as the addresses are assigned to each "flow" all of the current protocols, IP, CLNP, SIP, PIP are equally well positioned to support flows. The problem is that we tend to treat everything going to the same place as the same address, which they only sort of are. Different addresses at the same place are really means for distinguishing different types of flows. If you take this view you won't believe the options you can get rid of. For example, priority is simply a flow with different traffic characteristics and should be on a separate address. > >4) Has IPAE and other well-thought-out migration approaches. [Question >to the reader: I suspect that a slightly modified IPAE would also work >for TUBA and EIPIP has been proposed for PIP. Thus, is this really an >advantage of SIP? Isn't it rather merely a function of the expertise of >the original SIP designers rather than an inherent advantage of the SIP >approach?] > I would list this as a CON. The IPAE properties that create the kind of chaos found in some European phone systems where the number you are calling depends on where you are calling from (and I don't mean just more numbers added on the front; different numbers added on the front depending on where you are calling from) is not something we want to foist on the world. Even the PTTs that did it don't seem to consider it a good idea. They are getting rid of it. > SIP Con > >1) Since hierarchical addresses tend to be deployed in a "sparse" manner, >it unclear whether a 64 bit address space will adequately scale to meet >every conceivable future addressing scenario. It is pretty clear that any fixed length will never be enough. > >2) No SIP protocol is totally unchanged from its "IPv4" equivalent. This >introduces a certain degree of risk in its deployment (i.e., the unknown). > >3) No network provider currently supports SIP. > >4) RFC 1454 stated: "although there are a few 'reserved' bits in the >header, the extension of SIP to support new features is not obvious". >[Question to the reader: Is this really the case? Isn't it rather the >case that new features will be supported by optional header data field >additions whose existence is signaled by the payload type field? But then, >how would this be generally extensible for complex permutations of payload >types? If so, then probably the original claim of RFC 1454 has merit. >Does it?] > >-------------------------------------------------------------------------- > > PIP Pro > >1. General routing and addressing without performance hit (i.e., in most >cases PIP routes faster than IPv4. Exception is IP cache hit...) Tangible >near-term benefit of this generality is provider selection and policy routing >in general together with potentially simplified address administration. >Longer term benefit of this generality is ability to evolve to new routing >and addressing paradigms. Addressing is independent of all of these protocols to the extent that an address from an addressing plan can be made to fit in the header. To the same extent, all of these protocols are independent of the routing. In fact this is a major advantage of all of these protocols. As long as the PDU that carries the user-data is independent of the addressing and routing (especially the latter), it will be possible to evolve routing techniques without disturbing the end-systems. Since we still have a lot to learn about routing this sounds like a big win, especially since it is so difficult to predict how new routing algorithms will work in the large. If PIP is really tied to a particular addressing and routing strategy then this is not a PRO. > >2. PIP has more features. These include provider selection, auto host >configuration (address, ID, domain name, and DNS server address, plus >auto-config of DNS), PDN address discovery, and domain-wide address prefix >autoconfiguration. Again, I hope these are properties of the protocols supporting PIP and not PIP itself. Otherwise, choosing PIP and then finding that one or more of its features are less desirable than first appears, then changing it is going to be very painful. > >3. Evolvability. PIP is architected to be well positioned to support >"flows" and other future network-layer technologies (e.g., separation of >routing/identification/handling), plus has explicit evolution mechanisms >(contents numbers, host version number, fast options handling). This will >hopefully enhance the possibility of support for real-time services. > > PIP Con > >1. Complexity. Might expand on this a bit. > >2. PIP is not directly based on existing protocols. Thus, it represents new >technologies and it has a new addressing paradigm. This "newness" implies >an unknown deployment "risk" factor (i.e., the "unknown"). > >3. Since the PIP approach is novel, it represents a significant "learning >curve" for deployments with attendant expenses. > >4. No network provider currently supports PIP. > >-------------------------------------------------------------------------- > > TUBA Pro > >1. Every TUBA protocol already exists and has experienced some degree of >actual deployment experience. TUBA adopts these OSI network layer protocols >in an unchanged fashion. > >2. Internet currently becoming "bilingual" with IPv4 and CLNP. Thus, no >change for many network providers to support TUBA. > >3. Will partially join the TCP/IP and OSI/CCITT communities -- hopefully >for greater synergy between these communities for those end users which >currently support both protocol families. This may translate into reduced >end user network complexity. > >4. Has proven auto-configuration (auto-addressing) capabilities. > >5. Is based upon International Standards and government-supported protocols >which are currently mandated in certain environments. > >6. Integrated IS-IS already exists for mixed IPv4/TUBA deployments. >Integrated-OSPF (for IPv4/IPng) is yet to be defined. > >7. The 160 bit TUBA address space is well positioned to meet any future >address scaling requirement. > > TUBA Con > >1. Unless a company is already familiar with OSI's connectionless network >layer protocols, TUBA represents a significant "learning curve" for >deployments with attendant expenses. > >2. TUBA is no more positioned to support "flows" and other possible future >technologies than is IPv4. > >3. TUBA supports a 160 bit network address which represents a potentially >significant overhead penalty for some environments. > >4. TUBA protocols are not "tuned" for maximum routing efficiency (e.g. >checksum, attention to 32-bit CPU alignment issues). >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00355; 17 May 93 12:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00351; 17 May 93 12:09 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa07074; 17 May 93 12:09 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 17 May 93 12:08:48 EDT Received: from BBN.COM by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 17 May 93 12:08:46 EDT Message-Id: <9305171608.AA21198@thumper.bellcore.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Day Subject: Re: PROs/CONs of SIP/PIP/TUBA To: deering@parc.xerox.com Cc: Day@thumper.bellcore.com, pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov In-Reply-To: <93May17.081244pdt.12171@skylark.parc.xerox.com> Date: Mon, 17 May 93 12:10:03 EST Mail-System-Version: And he writes again: >John Day wrote: > >> The IPAE properties that create the kind of >> chaos found in some European phone systems where the number you are >> calling depends on where you are calling from (and I don't mean just >> more numbers added on the front; different numbers added on the front >> depending on where you are calling from) is not something we want to >> foist on the world. > >That is not a property of IPAE. If it is possible for someone to come to >so false a conclusion after reading the IPAE specification, we clearly need >to work more on that specification. > While I could be wrong from my last reading of IPAE, if I move my end system from one place to another all of the addresses I used to connect to will have changed. Why else are they exploring these methods to download addresses? > >> Different addresses at the same place are really means for >> distinguishing different types of flows. If you take this view you won't >> believe the options you can get rid of. For example, priority is simply >> a flow with different traffic characteristics and should be on a >> separate address. > >That would work fine for connection-oriented priority, where the mappings >from address to priority can be pre-established in the routers along a path. >If your protocol supports connectionless priority (e.g., "loss preference" >for layered video encodings) you don't want to have each of your routers >doing some sort of directory lookup on each packet's destination address in >order to determine the priority of the packet -- you want well-known priority >values as a separate field (or in a fixed, known location within the address, >which is effectively the same as a separate field). > Sorry Steve, but connection-oriented or not, pdus with different priorities are simply different flows. I realize that this is a shift in frame of reference in how we normally think about things and that such shifts are hard to think about. Doing the routing does not require doing a directory lookup for each packet's destination address (or only if you look at the problem wrong). The router merely has to know how it treats which flows which are identified by their addresses. What you want to know is what QoS policies are associated with which flows. You are making this problem too difficult. Take care John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00451; 17 May 93 12:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00447; 17 May 93 12:14 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa07279; 17 May 93 12:14 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA21306; Mon, 17 May 93 10:09:16 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA12106; Mon, 17 May 93 10:08:44 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA12102; Mon, 17 May 93 10:08:43 MDT Received: from BBN.COM by p.lanl.gov (5.65/1.14) id AA21227; Mon, 17 May 93 10:08:42 -0600 Message-Id: <9305171608.AA21227@p.lanl.gov> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Day Subject: Re: PROs/CONs of SIP/PIP/TUBA To: deering@parc.xerox.com Cc: Day@p.lanl.gov, pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov In-Reply-To: <93May17.081244pdt.12171@skylark.parc.xerox.com> Date: Mon, 17 May 93 12:10:03 EST Mail-System-Version: And he writes again: >John Day wrote: > >> The IPAE properties that create the kind of >> chaos found in some European phone systems where the number you are >> calling depends on where you are calling from (and I don't mean just >> more numbers added on the front; different numbers added on the front >> depending on where you are calling from) is not something we want to >> foist on the world. > >That is not a property of IPAE. If it is possible for someone to come to >so false a conclusion after reading the IPAE specification, we clearly need >to work more on that specification. > While I could be wrong from my last reading of IPAE, if I move my end system from one place to another all of the addresses I used to connect to will have changed. Why else are they exploring these methods to download addresses? > >> Different addresses at the same place are really means for >> distinguishing different types of flows. If you take this view you won't >> believe the options you can get rid of. For example, priority is simply >> a flow with different traffic characteristics and should be on a >> separate address. > >That would work fine for connection-oriented priority, where the mappings >from address to priority can be pre-established in the routers along a path. >If your protocol supports connectionless priority (e.g., "loss preference" >for layered video encodings) you don't want to have each of your routers >doing some sort of directory lookup on each packet's destination address in >order to determine the priority of the packet -- you want well-known priority >values as a separate field (or in a fixed, known location within the address, >which is effectively the same as a separate field). > Sorry Steve, but connection-oriented or not, pdus with different priorities are simply different flows. I realize that this is a shift in frame of reference in how we normally think about things and that such shifts are hard to think about. Doing the routing does not require doing a directory lookup for each packet's destination address (or only if you look at the problem wrong). The router merely has to know how it treats which flows which are identified by their addresses. What you want to know is what QoS policies are associated with which flows. You are making this problem too difficult. Take care John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00664; 17 May 93 12:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00660; 17 May 93 12:22 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa07638; 17 May 93 12:22 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA22583; Mon, 17 May 93 10:19:15 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA12239; Mon, 17 May 93 10:18:49 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA12235; Mon, 17 May 93 10:18:48 MDT Received: from regal.cisco.com by p.lanl.gov (5.65/1.14) id AA22470; Mon, 17 May 93 10:18:47 -0600 Received: by regal.cisco.com; Mon, 17 May 1993 09:18:37 -0700 Date: Mon, 17 May 1993 09:18:37 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dino Farinacci Message-Id: <199305171618.AA17478@regal.cisco.com> To: Day@bbn.com Cc: tuba@lanl.gov In-Reply-To: "John Day"'s message of Sun, 16 May 93 21:33:12 EDT <199305171300.AA27124@dirt.cisco.com> Subject: final word on pseudo-header >> I can't answer Dino's question as to why it works, but I really do not >> like the idea of the NSEL identifying the protocol in the next higher >> layer. This is equivalent to well-known sockets and we did well-known >> sockets as a quick and dirty fix so we could use the net back in the >> 1971 or 72. We knew then that the address mappings should be handled by >> a directory, but we didn't have time to design and build one. (I have >> always likened well-known sockets to hard wiring low core in a processor >> architecture. We found that wasn't a good idea and this isn't either.) There are two issues here: 1) Should the network layer use N-selectors to determine what client/protocol gets the packet. 2) When 1) is used should TCP/UDP use the N-selector in the pseudo-header calculation. Dave's original note was a clarification of 2). You bring up 1). 1) has been decided for quite a long time. It works, it is simple and there are implementations that follow this. >> Managing what protocols are assigned to what addresses should be as much >> a local matter as we can make it. It greatly decentralizes the operation >> of the network. With TUBA, we can start to move away from a 30 year old >> kludge and get on with modern networking. Leave the NSEL out of it. One problem about moving away from 30-year old kludges is that today people constantly ask "how can I filter FTAM packets". It can't be done easily, is the answer. I favor well-known code-points. Dino   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00893; 17 May 93 12:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00886; 17 May 93 12:51 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa08532; 17 May 93 12:51 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 17 May 93 12:51:11 EDT Received: from alpha.xerox.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 17 May 93 12:51:09 EDT Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11651>; Mon, 17 May 1993 09:50:30 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 17 May 1993 09:50:20 -0700 To: John Day Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Subject: Re: PROs/CONs of SIP/PIP/TUBA In-Reply-To: Your message of "Mon, 17 May 93 10:10:03 PDT." <9305171608.AA21198@thumper.bellcore.com> Date: Mon, 17 May 1993 09:50:06 PDT X-Orig-Sender: Steve Deering Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Deering Message-Id: <93May17.095020pdt.12171@skylark.parc.xerox.com> > While I could be wrong from my last reading of IPAE, if I move my end > system from one place to another all of the addresses I used to connect > to will have changed. That's incorrect. Maybe you are confusing IPAE with NAT? > Why else are they exploring these methods to download addresses? What "downloading" are you referring to? > Sorry Steve, but connection-oriented or not, pdus with different > priorities are simply different flows. Yes, I understand that model. What I was talking about is how those flows should be identified, by address+priority or by address alone. > I realize that this is a shift in frame of reference in how we normally > think about things and that such shifts are hard to think about. One of the goals of the SIP design is to avoid unnecessary shifts of frames of reference, so that SIP isn't hard to think about. > Doing the routing does not require doing a directory lookup for each > packet's destination address (or only if you look at the problem wrong). > The router merely has to know how it treats which flows which are > identified by their addresses. Are you proposing that the priority be indicated by well-known values in a well-known subfield of the addresses, or does the mapping of address to priority require external information, such as a directory entry or information distributed in a routing protocol? If the latter, it will be significantly and unnecessarily more expensive to support. > You are making this problem too difficult. Maybe you are making its solution too expensive? Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02740; 17 May 93 14:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02736; 17 May 93 14:03 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa11189; 17 May 93 14:03 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA26614; Mon, 17 May 93 12:00:29 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA13010; Mon, 17 May 93 12:00:03 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA13006; Mon, 17 May 93 12:00:02 MDT Received: from cider.cisco.com by p.lanl.gov (5.65/1.14) id AA26579; Mon, 17 May 93 12:00:02 -0600 Received: from localhost by cider.cisco.com with TCP; Mon, 17 May 1993 10:59:51 -0700 Message-Id: <199305171759.AA29245@cider.cisco.com> To: tuba@lanl.gov Cc: colella@nist.gov Subject: BIND 4.9 with NSAP support Date: Mon, 17 May 1993 10:59:51 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paul Traina Diffs for BIND 4.9(beta) to support NSAP addresses are available from ftp.cisco.com:/ftp/bind/4.9-nsap-diffs Also available are diffs for 4.8.3, but these are nasty, unsupported, not completely functional, and if you've never done a 4.8.3 for your platform, just don't screw with them. BIND 4.9 is a -major- win and installs w/o hacking on a number of platforms. ftp.cisco.com:/ftp/bind/4.8.3-nsap-diffs Please remember, we run a special ftp daemon that does not allow you to put pathnames in your requests. ftp ftp.cisco.com anonymous fnord cd bind get 4.9-nsap-diffs These patches will give you a working DiG, nslookup, resolver libraries, and a server. They are compatible with the NCSA TUBA-Telnet and cisco client implementations. The patches are a joint effort between Richard and myself. Bug reports to me, please. Paul ------- Forwarded Message Message-Id: <9305171020.AA16192@cognition.pa.dec.com> To: bind@uunet.UU.NET, bind-4.9@inet-gw-2.pa.dec.com Subject: BIND 4.9 has been released Date: Mon, 17 May 93 03:20:55 -0700 From: Paul A Vixie X-Mts: smtp After several years of development and at least one year of testing, BIND 4.9 has finally exited Beta testing and is ready to rock and roll. You can get it from gatekeeper.dec.com via anonymous FTP as /pub/BSD/bind/4.9/4.9.930517.tar.Z (the Bind Operations Guide, substantially improved, is in the same directory, called BOG.psf). This BIND has been the name server running on DECWRL.DEC.COM, UUNET.UU.NET, EUNET.EU.NET, MUNNARI.OZ.AU, and hundreds of other large and small servers, for at least six months. We consider it "stable". Improvements over 4.8.3 are too numerous to list. If you have had any kind of trouble with 4.8.3 (and if you use it, you've had trouble with it, though you may not know this), you should upgrade to 4.9. Operating system vendors are encouraged to include this version of BIND as soon as their release schedules permit; the NSFnet backbone will thank you for it, as will your customers. This BIND includes "dig" (from USC/ISI) and "host" (from Rutgers), as well as a large collection of contributed scripts, utilities, and documentation. The resolver has also been improved. This BIND is known to compile and run on ULTRIX/RISC 4.2-4.3, SunOS 4.1.x, BSD/386 1.0, NeXTstep 3.0, UMIPS/V, HP-UX 8.x, Alpha AXP OSF/1 1.2, and more. This BIND was funded by Digital Equipment Corporation and is hereby released into full public use, subject to the same restrictions as the U C Berkeley Networking 2 ("net2") release. There is a DIGITAL ("DEC") Copyright in each file but it's just noise for the lawyers -- no practical restrictions have been added other than DIGITAL's disclaimer of liability. I (Paul Vixie) was the principle contributor to this release, as well as code librarian and test/release coordinator. However, my efforts would have been wasted without the assistance and participation of the alpha test list, to whom special thanks are given in the new Bind Operations Guide ("BOG"). ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02798; 17 May 93 14:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02794; 17 May 93 14:07 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa11369; 17 May 93 14:07 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA26795; Mon, 17 May 93 12:05:04 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA13038; Mon, 17 May 93 12:04:44 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA13034; Mon, 17 May 93 12:04:43 MDT Received: from Sun.COM by p.lanl.gov (5.65/1.14) id AA26768; Mon, 17 May 93 12:04:43 -0600 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA24467; Mon, 17 May 93 10:58:25 PDT Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA02784; Mon, 17 May 93 10:57:21 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA12770; Mon, 17 May 93 10:57:08 PDT Date: Mon, 17 May 93 10:57:08 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Hinden Message-Id: <9305171757.AA12770@bigriver.Eng.Sun.COM> To: John Day Cc: tuba@lanl.gov In-Reply-To: <9305171500.AA17451@p.lanl.gov> Subject: Re: final word on pseudo-header John, > Then we do spend a lot more time debugging these networks than we do > using them. If we can't easily debug these networks, then we won't be able to use them. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04170; 17 May 93 14:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04164; 17 May 93 14:24 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12004; 17 May 93 14:24 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 17 May 93 14:23:30 EDT Received: from lobster.wellfleet.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 17 May 93 14:23:28 EDT Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA16979; Mon, 17 May 93 14:20:09 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA02703; Mon, 17 May 93 14:21:51 EDT Date: Mon, 17 May 93 14:21:51 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9305171821.AA02703@cabernet.wellfleet> To: Day@bbn.com, deering@parc.xerox.com Subject: Re: PROs/CONs of SIP/PIP/TUBA Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov > >1) Since hierarchical addresses tend to be deployed in a "sparse" manner, > >it unclear whether a 64 bit address space will adequately scale to meet > >every conceivable future addressing scenario. > > It is pretty clear that any fixed length will never be enough. Yes, in the sense that it is possible to conceive of an addressing scenario that uses an unbounded number of bits. Once we have infinitely fast routers with infinite memory, joined by links of infinite bandwidth, we could consider implementing an internet protocol with unbounded address length. Until then, we'll have to make an engineering choice of maximum address length. SIP's 64-bit address space is 10^7 times larger than the international telephone numbering space, and if managed sensibly (i.e., not just allowing everyone to cobble up their own favorite octet string and expect the world to be able to route on it) it will scale to handle many thousands of computers in every room and vehicle in this solar system. I think that this is such an important point that I will break my own rule (against public "my protocol is better" discussions) and reply (with apology to folks on all three lists): It seems from recent discussions that when folks talk about "scaling to a huge network" there are two different things that people mean by this: - Some folks seem to mean being able to find some way to set up addresses and some way to set up the topology so that it is possible to run routing protocols and deliver packets to everyone. - Some people mean being able to adminster, configure, and run the network of this size, including routing, but also including host configuration, address administration, subnet address determination (mapping IP-level addresses to subnet addresses) and whatever other address-related problems that you will face in whatever type of network that you might happen to find in a huge Internet (for whatever topology the world actually ends up setting up). The first problem therefore is a subset of the latter. I sort of think that the first problem can probably be solved with 64 bit addresses. My concern is the latter problem. For example: - How do you autoconfigure host addresses? - If this requires active address assignment at the time that the host is hooked up (rather than a more passive automatic address discovery based on already assigned parts of the address), then how do you assign these addresses, and how do you coordinate redundant address servers (assuming that you will need redundant servers for reliability)? - How do you assure that when a system is re-attached to the same network after some time away (for example, when I take my laptop with me for a two week vacation and two more weeks of business trips, and then return to the office), that when I return I will get the same address assigned to me again? (or if I don't, then how do you deal with filters?) - If you have many public service providers, each with 10,000,000 customers, where 9,999,900 of the customers are small stub networks (homes and/or small businesses) attached in only one location, then how do you map from the IP-level address to the addresses used in the service provider network? Will this work with the networks that people are already talking about building (and over the phone network, given that the cost of networking homes may mean that POTS is the networking infrastructure for much of the world for many years)? I can think of very simple solutions to these sorts of problems if I have large addresses (and can also think of straightforward ways to compress headers and/or forward large headers at high speed). I would really like to see complete proposals for each of these problems with small addresses (and I would expect that SIP advocates would want to see solutions for header compression and high speed forwarding for the proposals with larger headers and addresses). I understand that the SIP folks have started working on the first of these items (host autoconfiguration), but I think that it is worth waiting for solutions to all of these problems before we try to decide which solution is the best one for the next 20 years. Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08258; 17 May 93 14:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08254; 17 May 93 14:51 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa13195; 17 May 93 14:51 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA28200; Mon, 17 May 93 12:49:09 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA13351; Mon, 17 May 93 12:48:46 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA13347; Mon, 17 May 93 12:48:45 MDT Received: from LOBSTER.WELLFLEET.COM by p.lanl.gov (5.65/1.14) id AA28178; Mon, 17 May 93 12:48:45 -0600 Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA17086; Mon, 17 May 93 14:46:22 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA02745; Mon, 17 May 93 14:48:04 EDT Date: Mon, 17 May 93 14:48:04 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9305171848.AA02745@cabernet.wellfleet> To: dave@mail.bellcore.com, dino@cisco.com Subject: Re: final word on pseudo-header Cc: tuba@lanl.gov OK, then you are suggesting something different than what I believe we agreed to quite a while ago, (at Ross's insistence?), which was to leave the selector field of the source NSAPA field zero. I am quite comfortable having the selector set to PROTO value in both addresses. Is everyone else implementing this way? Are we happy with making this change to the clnp internet-draft? I would say "suggestion" rather than "insistence". I don't have a strong opinion on this. Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13079; 17 May 93 16:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13075; 17 May 93 16:42 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa17108; 17 May 93 16:42 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA02056; Mon, 17 May 93 14:38:23 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14059; Mon, 17 May 93 14:37:29 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14055; Mon, 17 May 93 14:37:27 MDT Received: from bridge2.NSD.3Com.COM by p.lanl.gov (5.65/1.14) id AA02038; Mon, 17 May 93 14:37:26 -0600 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA08445 (5.65c/IDA-1.4.4nsd for ); Mon, 17 May 1993 13:37:24 -0700 Received: by jaspar.NSD.3Com.COM id AA29919 (5.65c/IDA-1.4.4-910730); Mon, 17 May 1993 13:37:23 -0700 Date: Mon, 17 May 1993 13:37:23 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Cyndi M. Jung" Message-Id: <199305172037.AA29919@jaspar.NSD.3Com.COM> To: Day@bbn.com Subject: Re: final word on pseudo-header Cc: tuba@lanl.gov John Day says: >I can't answer Dino's question as to why it works, but I really do not >like the idea of the NSEL identifying the protocol in the next higher >layer. So, what would you like to use to identify the next higher layer protocol?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13462; 17 May 93 16:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13458; 17 May 93 16:59 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa17722; 17 May 93 16:59 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA02882; Mon, 17 May 93 14:56:54 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14201; Mon, 17 May 93 14:56:35 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14197; Mon, 17 May 93 14:56:35 MDT Received: from BBN.COM by p.lanl.gov (5.65/1.14) id AA02867; Mon, 17 May 93 14:56:35 -0600 Message-Id: <9305172056.AA02867@p.lanl.gov> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Day Subject: Re: final word on pseudo-header To: cmj@nsd.3com.com Cc: Day@p.lanl.gov, tuba@lanl.gov In-Reply-To: <199305172037.AA29919@jaspar.NSD.3Com.COM> Date: Mon, 17 May 93 17:00:13 EST Mail-System-Version: Cyndi, >>I can't answer Dino's question as to why it works, but I really do not >>like the idea of the NSEL identifying the protocol in the next higher >>layer. > >So, what would you like to use to identify the next higher layer protocol? In OSI addressing, there are no well-known sockets. The local system maintains the bindings between the layers. The semantics of what they bind is not embedded in the address. So while the network layer routes to a particular address, there is nothing fixed in the address that points to the given protocol. In other words, the network layer does not know what protocol is above only that it routes to a particular address. The semantics of the bindings are maintained by the Directory in the case of AETitles to T-SAP addresses and by the routing tables in the case of NSAP addresses to SNPA-addresses. So while in one sense the NSAP-address does identify the next higher layer protocol, it is not in the same sense that it does in TCP. See Clause 1 of SC21/N6918. This was an issue resolved in OSI in 1982. John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13933; 17 May 93 17:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13929; 17 May 93 17:24 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa18431; 17 May 93 17:24 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA04365; Mon, 17 May 93 15:21:49 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14352; Mon, 17 May 93 15:21:28 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14348; Mon, 17 May 93 15:21:28 MDT Received: from bridge2.NSD.3Com.COM by p.lanl.gov (5.65/1.14) id AA04344; Mon, 17 May 93 15:21:28 -0600 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA10066 (5.65c/IDA-1.4.4nsd for ); Mon, 17 May 1993 14:21:26 -0700 Received: by jaspar.NSD.3Com.COM id AA00118 (5.65c/IDA-1.4.4-910730); Mon, 17 May 1993 14:21:25 -0700 Date: Mon, 17 May 1993 14:21:25 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Cyndi M. Jung" Message-Id: <199305172121.AA00118@jaspar.NSD.3Com.COM> To: Day@bbn.com Subject: Re: final word on pseudo-header Cc: tuba@lanl.gov Still regarding: >>I can't answer Dino's question as to why it works, but I really do not >>like the idea of the NSEL identifying the protocol in the next higher >>layer. > >So, what would you like to use to identify the next higher layer protocol? For the moment, separate the two issues: 1. How does the network layer distinguish between multiple clients, and 2.) How are those distinguishing characteristics administered (well-known versus locally). So, just the first - how would you like the network layer protocol distinguish between multiple clients? >So while in one sense the NSAP-address does identify the next higher >layer protocol, it is not in the same sense that it does in TCP. Even if you want the whole NSAP address to identify the client, the constraints on the address imposed by IS-IS leave only the N-selector - independent of how it is administered.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14215; 17 May 93 17:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14211; 17 May 93 17:48 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa19214; 17 May 93 17:48 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA05225; Mon, 17 May 93 15:44:34 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14526; Mon, 17 May 93 15:44:15 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14522; Mon, 17 May 93 15:44:14 MDT Received: from vangogh.CS.Berkeley.EDU by p.lanl.gov (5.65/1.14) id AA05213; Mon, 17 May 93 15:44:15 -0600 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (ALPHA-6.59/6.28) id OAA24074; Mon, 17 May 1993 14:43:58 -0700 Date: Mon, 17 May 1993 14:43:58 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199305172143.OAA24074@vangogh.CS.Berkeley.EDU> To: tuba@lanl.gov Subject: re: use of NSEL to identify protocol John & Cyndi & Ross & Dave & all - First, I think that use of the NSEL in the destination NSAP to identify that this is a TCP bearing packet instead of a UDP or TP4 bearing packet is a different flavor of distinction that identifying that this packet is an FTAM, or Directory lookup or a telnet packet. If you want to coexist with TP4, it would be rather more akward to use a protocol Identifier of that sort as the first byte of the CLNP packet. (and I'm still talking about TCP versus UDP -> which level 4 protocol, not which application level protocol). Other than the NSEL, or the first byte of the payload, I don't think there is any other place to put it. Second, I'm rather adamantly in favor of being able to reverse the source and destination NSAPS in replying to TUBA packets. Thus, if somebody on mars wants to send TCP packets to me, I only care that he sends them to me with NSEL == 6, and I'm sure as heck going to make my outgoing TCP initiations have NSEL == 6 as the part of the source address for me, because that's where I want them sent. But if there is some means of me determining that the guy on mars wants TCP traffic sent to something other than 6, it would be great if I could deal with it.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15394; 17 May 93 19:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15390; 17 May 93 19:56 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa22253; 17 May 93 19:56 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA09821; Mon, 17 May 93 17:55:12 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14921; Mon, 17 May 93 17:54:38 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA14917; Mon, 17 May 93 17:54:37 MDT Received: from munnari.OZ.AU by p.lanl.gov (5.65/1.14) id AA09800; Mon, 17 May 93 17:54:33 -0600 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23682; Tue, 18 May 1993 09:53:20 +1000 (from kre@munnari.OZ.AU) To: John Day Cc: cmj@nsd.3com.com, tuba@lanl.gov Subject: Re: final word on pseudo-header In-Reply-To: Your message of "Mon, 17 May 1993 17:00:13 EST." <9305172056.AA02867@p.lanl.gov> Date: Tue, 18 May 1993 09:53:10 +1000 Message-Id: <11989.737682790@munnari.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Elz Date: Mon, 17 May 93 17:00:13 EST From: "John Day" Message-ID: <9305172056.AA02867@p.lanl.gov> So while in one sense the NSAP-address does identify the next higher layer protocol, it is not in the same sense that it does in TCP. See Clause 1 of SC21/N6918. This was an issue resolved in OSI in 1982. If you'll excuse me saying so, this is semantic drivel. First, comparing NSAP addresses (and CLNS or even CONS) with TCP is wrong, its IP that you should be comparing with. Now if I wanted to, I could define the IP address to be a concatenation of the src or dst addr field in the IP header, and the proto field - the syntax of how the address is encoded in the packet is not interesting (for these purposes) - then the only difference between IP and CLNS (etc) is that IP addresses would require the same final byte (NSEL some might call it) for the source and destination addresses, whereas CLNS (with NSAPs) doesn't require that. However, as has been said already, for practical purposes, you want the NSEL's to be well known (there are only a few, its not a great burden) in most cases - if sites are short on NSEL values, both protocols have only 8 bits for this, they can reuse one of the well known ones by arrangement with their peers - clearly they wouldn't be using the higher layer protocol that normally used that NSEL. The advantages are numerous - it makes filtering practical, it makes it possible to monitor passing packets and determine what's in them, which is useful both for debugging problems, and for keeping stats on what kinds of traffic are using the monitored wire, and it will lower directory searches - eg: if I couldn't expect the NSAP used for TCP to be deriveable from that used for UDP, then in order to do a DNS query, I may need to locate the UDP address of a server, query it, determine the answer is too big for UDP, then determine the TCP address of the server, and then make a TCP query - this adds to the directory overheads, slows queries, and makes the directorymuch larger and harder to maintain (harder for the humans to make sure its all correct). And all this for no practical benefit - if sites are going to use TCP, and each have to choose an NSEL to use for it, then they may as well all choose 6 (or whatever), no-one really saves anything if one site picks 13 and another 93. About all you can possibly gain by not requiring well known NSEL's is the ability to run duplicate TCP stacks - which is also possible by simply assigning a second NSAP (ie: different in octets other than the NSEL). kre   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15876; 17 May 93 20:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15872; 17 May 93 20:22 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa22827; 17 May 93 20:22 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA10718; Mon, 17 May 93 18:21:18 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA15014; Mon, 17 May 93 18:20:58 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA15010; Mon, 17 May 93 18:20:57 MDT Received: from bridge2.NSD.3Com.COM by p.lanl.gov (5.65/1.14) id AA10693; Mon, 17 May 93 18:20:58 -0600 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA16534 (5.65c/IDA-1.4.4nsd for ); Mon, 17 May 1993 17:20:57 -0700 Received: by jaspar.NSD.3Com.COM id AA00292 (5.65c/IDA-1.4.4-910730 for tuba@lanl.gov); Mon, 17 May 1993 17:20:55 -0700 Date: Mon, 17 May 1993 17:20:55 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Cyndi M. Jung" Message-Id: <199305180020.AA00292@jaspar.NSD.3Com.COM> To: cmj@nsd.3com.com Subject: Re: final word on pseudo-header Cc: tuba@lanl.gov There is something friendly about well-known numbers   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00508; 18 May 93 5:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00504; 18 May 93 5:53 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02026; 18 May 93 5:53 EDT Received: from p.lanl.gov by IETF.CNRI.Reston.VA.US id aa00499; 18 May 93 5:53 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA15824; Tue, 18 May 93 01:58:13 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA15489; Tue, 18 May 93 01:57:52 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA15485; Tue, 18 May 93 01:57:52 MDT Received: from dxmint.cern.ch by p.lanl.gov (5.65/1.14) id AA15812; Tue, 18 May 93 01:57:51 -0600 Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA25868; Tue, 18 May 1993 09:57:47 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA09077; Tue, 18 May 1993 09:57:46 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9305180757.AA09077@dxcern.cern.ch> Subject: Final word re: final word on pseudo-header To: tuba@lanl.gov Date: Tue, 18 May 1993 09:57:45 +0200 (MET DST) In-Reply-To: <199305180020.AA00292@jaspar.NSD.3Com.COM> from "Cyndi M. Jung" at May 17, 93 05:20:55 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 127 Why are we re-opening this? I though we agreed last year to use NSEL as PROTO, period. IETF is not supposed to loop. Brian   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00543; 18 May 93 5:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00539; 18 May 93 5:56 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02084; 18 May 93 5:56 EDT Received: from p.lanl.gov by IETF.CNRI.Reston.VA.US id aa00534; 18 May 93 5:56 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA15433; Tue, 18 May 93 01:36:24 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA15444; Tue, 18 May 93 01:35:56 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA15440; Tue, 18 May 93 01:35:55 MDT Received: from mwassocs.demon.co.uk by p.lanl.gov (5.65/1.14) id AA15417; Tue, 18 May 93 01:35:42 -0600 Date: Tue, 18 May 93 08:29:45 BST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Whyman Message-Id: <1441.whyman@mwassocs.demon.co.uk> To: Day@bbn.com Cc: pip <@caldera.usc.edu:pip@thumper.bellcore.com.sip>, tuba@lanl.gov Reply-To: whyman@mwassocs.demon.co.uk Subject: Re: PROs/CONs of SIP/PIP/TUBA X-Mailer: VE3PZR VIEW DIS V1.01. Lines: 29 John, In your reply to Eric Fleischman, there's a point which I think should be developed further: > > SIP Con > > > >1) Since hierarchical addresses tend to be deployed in a "sparse" manner, > >it unclear whether a 64 bit address space will adequately scale to meet > >every conceivable future addressing scenario. > > It is pretty clear that any fixed length will never be enough. This is a very significant issue as regards IPng selection and should be taken up on the "criteria" list. Built-in obsolescence should no longer be an acceptable feature of a communications protocol. -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00888; 18 May 93 7:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ac00876; 18 May 93 7:06 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa00943; 18 May 93 5:00 EDT Received: by thumper.bellcore.com (4.1/4.7) id for eric@isci.com; Tue, 18 May 93 03:36:34 EDT Received: from mwassocs.demon.co.uk by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Tue, 18 May 93 03:35:55 EDT Date: Tue, 18 May 93 08:29:45 BST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Whyman Message-Id: <1439.whyman@mwassocs.demon.co.uk> To: Day@bbn.com Cc: pip@thumper.bellcore.com, caldera.usc.edu@mwassocs.demon.co.uk, tuba@lanl.gov MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Reply-To: whyman@mwassocs.demon.co.uk Subject: Re: PROs/CONs of SIP/PIP/TUBA X-Mailer: VE3PZR VIEW DIS V1.01. Lines: 29 John, In your reply to Eric Fleischman, there's a point which I think should be developed further: > > SIP Con > > > >1) Since hierarchical addresses tend to be deployed in a "sparse" manner, > >it unclear whether a 64 bit address space will adequately scale to meet > >every conceivable future addressing scenario. > > It is pretty clear that any fixed length will never be enough. This is a very significant issue as regards IPng selection and should be taken up on the "criteria" list. Built-in obsolescence should no longer be an acceptable feature of a communications protocol. -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17298; 18 May 93 12:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17294; 18 May 93 12:30 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa12955; 18 May 93 12:30 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA02321; Tue, 18 May 93 10:21:33 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA16715; Tue, 18 May 93 10:19:00 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA16699; Tue, 18 May 93 10:18:53 MDT Received: from concorde.inria.fr by p.lanl.gov (5.65/1.14) id AA02109; Tue, 18 May 93 10:18:49 -0600 Received: from givry.inria.fr by concorde.inria.fr; Tue, 18 May 1993 18:18:47 +0200 Received: by givry.inria.fr; Tue, 18 May 1993 18:18:46 +0200 Message-Id: <199305181618.AA03556@givry.inria.fr> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Francis Dupont To: tuba@lanl.gov Subject: Re: Final word re: final word on pseudo-header In-Reply-To: Your message of Tue, 18 May 1993 09:57:45 +0200. <9305180757.AA09077@dxcern.cern.ch> Date: Tue, 18 May 1993 18:18:26 +0200 X-Orig-Sender: Francis.Dupont@inria.fr X-Charset: ASCII X-Char-Esc: 29 Perhaps it is more useful to clarify some obscure points in the draft-ietf-tuba-clnp-02.txt document (I suppose it is still the last one ?). There is a strange "Reserved" field after the source address in the proposed Internet header using CLNP (Figure 4-1. CLNP for TUBA). The text gives a false detail about the length of the addresses. In Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages: ----------------------------------|------------------------------------ Destination Unreachable (128) | Network Unreachable (3, 0) Destination Unknown (129) | Host Unreachable (3, 1) the difference between "Destination Unreachable" and "Destination Unknown" is not so clear (:-) and "Host Unreachable" is safer than "Network Unreachable". ICMP "Protocol Unreachable" (3, 2) is in fact a "Destination Unknown" case (reported by the destination ES) because the (IP) protocol is the (CLNS) NSEL. The ICMP "Port Unreachable" (3, 3) is very useful for UDP then I propose to map it into a "Destination Unknown" with a second octet of the discard reason option (which localizes the first octet of the erroneous field) pointing to the destination port field in the UDP header (i.e. equal to CLNP header length + 3). We need an up-to-date description of pseudo-headers with examples showing where are the paddings. Perhaps the best solution is to recommend the Keith Sklower's hack (precompute the checksum on the length+address structures and use the standard IP pseudo-header with the checksums at the place of the IP addresses. There is only one difficulty: the source checksum must be byte-swapped if the length of the CLNS destination address is even. Of course checksums are cached...). Francis.Dupont@inria.fr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17391; 18 May 93 12:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17386; 18 May 93 12:35 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa13059; 18 May 93 12:35 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA02975; Tue, 18 May 93 10:29:14 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA16804; Tue, 18 May 93 10:28:09 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA16800; Tue, 18 May 93 10:28:03 MDT Received: from LOBSTER.WELLFLEET.COM by p.lanl.gov (5.65/1.14) id AA02654; Tue, 18 May 93 10:28:01 -0600 Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA20534; Tue, 18 May 93 12:25:29 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA03149; Tue, 18 May 93 12:27:15 EDT Date: Tue, 18 May 93 12:27:15 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9305181627.AA03149@cabernet.wellfleet> To: sklower@vangogh.CS.Berkeley.ED, tuba@lanl.gov Subject: re: use of NSEL to identify protocol John & Cyndi & Ross & Dave & all - ... and Keith First, I think that use of the NSEL in the destination NSAP to identify that this is a TCP bearing packet instead of a UDP or TP4 bearing packet is a different flavor of distinction that identifying that this packet is an FTAM, or Directory lookup or a telnet packet. Actually, if we include the protocol field as the NSEL for TUBA uses, given that there is also a protocol field value specified for TP4, then the most sensible way to identify TP4 over CLNP would be basically the same way that we distinguish TCP, by using a special globally administered value of the SEL field (naturally TCP and TP4 use different values of the protocol/SEL field). Now, how to identify FTAM over TP4 is up to the TP4 and FTAM folks. In the context of TUBA I am not as concerned about this. If you want to coexist with TP4, it would be rather more akward to use a protocol Identifier of that sort as the first byte of the CLNP packet. (and I'm still talking about TCP versus UDP -> which level 4 protocol, not which application level protocol). Other than the NSEL, or the first byte of the payload, I don't think there is any other place to put it. Agreed. We need to think "practical", rather than "what fits an abstract model". Putting a protocol identifier in the SEL field is a sensible practical thing to do (for example, it certainly makes packet filtering a lot simpler than if you have to do a directory lookup to determine which protocol is associated with a particular selector value). Second, I'm rather adamantly in favor of being able to reverse the source and destination NSAPS in replying to TUBA packets. Thus, if somebody on mars wants to send TCP packets to me, I only care that he sends them to me with NSEL == 6, and I'm sure as heck going to make my outgoing TCP initiations have NSEL == 6 as the part of the source address for me, because that's where I want them sent. But if there is some means of me determining that the guy on mars wants TCP traffic sent to something other than 6, it would be great if I could deal with it. This is a good point. Thus both selectors should encode the protocol field. By the way, there is an implication here: If TUBA is adopted and CLNP becomes "the next generation of IP", then things that we do for TUBA in the Internet will effect the way that CLNP is used in the world (including the OSI and DECnet worlds). I think that this is perfectly reasonable, and that we should simply go ahead and make whatever restrictions that need to be made in order to make CLNP work as the IP replacement. This will help CLNP for other applications as well, since the sorts of practical restrictions on CLNP that we are going to be proposing (such as the use of the selector field to contain the IP protocol field) are also a good idea for other CLNP uses. Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05524; 19 May 93 12:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05520; 19 May 93 12:06 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa16131; 19 May 93 12:06 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA22432; Wed, 19 May 93 10:03:11 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24846; Wed, 19 May 93 09:59:26 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24842; Wed, 19 May 93 09:59:25 MDT Received: from survis.surfnet.nl by p.lanl.gov (5.65/1.14) id AA18449; Wed, 19 May 93 09:27:13 -0600 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <02907-0@survis.surfnet.nl>; Wed, 19 May 1993 17:26:35 +0200 To: Bob Hinden Cc: John Day , tuba@lanl.gov Subject: Re: presentation at JENC4 In-Reply-To: Your message of Mon, 17 May 93 10:57:08 -0700. <9305171757.AA12770@bigriver.Eng.Sun.COM> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Wed, 19 May 93 17:26:33 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Victor Reijs Message-Id: <"survis.sur.910:19.04.93.15.26.36"@surfnet.nl> Hello Bob, I heard your overview of the differences between TUBA/SIP and PIP during the JENC conference. It was in my opinion a good presentation (your personal/firm preferrens were not visible, so for an overview talk it was good). But I have one question. You said that CLNS was lacking the operational experience (this in relation to SIP and PIP). But to my knowledge there are some 4 networks in Europa that provide CLNS on a commercial bases, so they have some experience (CLNS over HDLC and CLNS over X.25, static routeing and IGRP or IS-IS routeing, IGRP coming up). I do not understand this drawback. I had the opinion that the other protocols were only doing 'SIP over IP' or 'PIP over IP' at this moment, but there are not yet continental/world networks providing SIP/PIP native connectivity. Or dit I misunderstood your argument? All the best, Victor   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09848; 19 May 93 16:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09844; 19 May 93 16:04 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24916; 19 May 93 16:04 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 19 May 93 16:04:15 EDT Received: from vela.acs.oakland.edu by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Wed, 19 May 93 16:04:12 EDT Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA16763 (5.65c+/IDA-1.4.4); Wed, 19 May 1993 15:59:31 -0400 Date: Wed, 19 May 93 12:34:26 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1186.bill.simpson@um.cc.umich.edu> To: whyman@mwassocs.demon.co.uk Cc: sip@caldera.usc.edu, pip@thumper.bellcore.com, tuba@lanl.gov Reply-To: bsimpson@morningstar.com Subject: Re: SIP Addressing Limitations Some of the other commenters on the SIP list have been too polite. Perhaps you should actually READ my proposed plan (based on > 100 hours of my work, considerable work and thought by Steve Deering, and many comments by others). You can find it in *sip-64bit-plan*, at any internet-drafts directory. Comments and improvements are welcome. The plan manages to allocate enough space to locate every "continent" or "region" or "country" or "state" or "province" or "metropolitan area" or "provider" (all at once) on the planet in the first 24 bits (and most in 8 or 16 bits), with more room reserved for the rest of the solar system. That leaves a conservative estimate of 2^40 bits for use within each country. For the worst case, China, there are only 360,000,000 (repeat, three hundred sixty million) per person (estimated 2025 population), WITHOUT using the *HALF* of the number space used by IPAE. You could abuse your number space very badly, say by putting the phone number in those 10 digits of BCD. This would still handle the U.S. (57-bits) with 99.9992% (131,071/131,072) left over, and the U.K. (55-bits) with 99.997% (32,767/32,768) left over. That's not counting the additional 99.5% (1 - (10/16)^10) of the space that is wasted within the 10 digit BCD. Any other "limitations"? Please provide actual numbers with your reasoning. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10089; 19 May 93 16:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10085; 19 May 93 16:40 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa25934; 19 May 93 16:40 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 19 May 93 16:40:20 EDT Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Wed, 19 May 93 16:38:49 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for whyman@mwassocs.demon.co.uk; Wed, 19 May 93 16:38:49 EDT Date: Wed, 19 May 93 16:38:49 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Paul Francis (formerly Paul Tsuchiya" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Message-Id: <9305192038.AA04035@tsuchiya.bellcore.com> To: bsimpson@morningstar.com, whyman@mwassocs.demon.co.uk Subject: Re: SIP Addressing Limitations Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov > > Some of the other commenters on the SIP list have been too polite. > > Perhaps you should actually READ my proposed plan (based on > 100 hours > of my work, considerable work and thought by Steve Deering, and many > comments by others). You can find it in *sip-64bit-plan*, at any > internet-drafts directory. > > Comments and improvements are welcome. > In preparation for making some comments on this message, I took another look at the plan, and found some things confusing. In particular, I can't understand the idea of clustering, and how that allows for provider assignments. I'm not even sure how to formulate questions, but let me start with this...... Given the following: - ---- ---- ---- Netherlands 15.3 16.7 0.6 C001 0000 010. .... Belgium 9.9 10.5 0.1 C001 0000 0110 .... Luxembourg 0.39 0.5e 1.1 C001 0000 0111 0000 0... .... ---- ---- ---- ---- United Kingdom 57.8 61.0 0.3 C001 0001 0... .... Ireland 3.5 5.0 -0.3 C001 0001 1000 0... Guernsey&Jersey(UK) 0.16 0.2e 0.8 C001 0001 1000 1000 00.. .... Isle of Man (UK) 0.064 <.1e 0.1 C001 0001 1000 1000 010. .... --- ---- ---- ---- Am I to deduce that Ireland, Guernsey&Jersey, and the Isle of Man are clustered? I'm interpreting the dashes as indicating the bits that are not common between the clustered countries. The UK has a 0 at the beginning of the second byte, and the other three have a 1 at the beginning of the second byte, thus I conclude that the UK is not clustered with the other three. But, this doesn't seem to follow common sense, so maybe I'm wrong. There is a statement that the clustering will facilitate provider based allocation, but I don't understand this (The quote is "This division provides the primary intersection between metropolitan and provider based allocation. Approximately 1/4 to 1/2 of the numbers in each cluster are reserved for provider based allocation and future expansion." Could you give me an example of how a provider would be assigned in the context of the above-mentioned cluster? Thanks, PX   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11366; 20 May 93 15:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11360; 20 May 93 15:38 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19334; 20 May 93 15:38 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Thu, 20 May 93 15:37:44 EDT Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Thu, 20 May 93 15:35:06 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for whyman@mwassocs.demon.co.uk; Thu, 20 May 93 15:35:05 EDT Date: Thu, 20 May 93 15:35:05 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Paul Francis (formerly Paul Tsuchiya" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Message-Id: <9305201935.AA05312@tsuchiya.bellcore.com> To: bsimpson@morningstar.com, whyman@mwassocs.demon.co.uk Subject: Re: SIP Addressing Limitations Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Another question. From where would you allocate space for a provider that doesn't fall under one of the clusters? For instance, a provider that has direct customers in the Northeastern USA and the far east (Singapore and Korea, say)? PX   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13888; 20 May 93 17:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13884; 20 May 93 17:55 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa23375; 20 May 93 17:55 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA26384; Thu, 20 May 93 15:49:34 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA05675; Thu, 20 May 93 15:46:19 MDT Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA05671; Thu, 20 May 93 15:46:18 MDT Received: from merit.edu by p.lanl.gov (5.65/1.14) id AA26264; Thu, 20 May 93 15:46:19 -0600 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA03121; Thu, 20 May 93 17:46:17 -0400 Date: Thu, 20 May 93 17:46:17 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Knopper Message-Id: <9305202146.AA03121@merit.edu> To: tuba@lanl.gov Subject: The intensive TUBA Hi. Would anyone be interested in having a TUBA working group meeting before the IETF? I was thinking that having an intensive all-day session in Ann Arbor on June 4 might be a possibility. I think we need to go over our action item and future planning list and develop a reasonable plan for the TUBA-future. If people are interested I would be happy to provide a conference room and maybe even a free lunch.... Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03968; 21 May 93 10:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03964; 21 May 93 10:10 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa03364; 21 May 93 10:10 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA20763; Fri, 21 May 93 08:05:33 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA08022; Fri, 21 May 93 08:04:50 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA08018; Fri, 21 May 93 08:04:48 MDT Received: from vela.acs.oakland.edu by p.lanl.gov (5.65/1.14) id AA20725; Fri, 21 May 93 08:04:47 -0600 Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA24963 (5.65c+/IDA-1.4.4); Fri, 21 May 1993 10:03:40 -0400 Date: Thu, 20 May 93 13:31:46 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1196.bill.simpson@um.cc.umich.edu> To: "Paul Francis (formerly Paul Tsuchiya" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Reply-To: bsimpson@morningstar.com Subject: Re: SIP Addressing Limitations > Given the following: > > Luxembourg 0.39 0.5e 1.1 C001 0000 0111 0000 0... .... > ---- ---- ---- ---- > United Kingdom 57.8 61.0 0.3 C001 0001 0... .... > Ireland 3.5 5.0 -0.3 C001 0001 1000 0... > Guernsey&Jersey(UK) 0.16 0.2e 0.8 C001 0001 1000 1000 00.. .... > Isle of Man (UK) 0.064 <.1e 0.1 C001 0001 1000 1000 010. .... [skipped] ---- ---- [Northern Ireland] C001 0001 1000 1001 > --- ---- ---- ---- [2nd provider] C001 0001 1111 1111 1111 1110 [1st provider] C001 0001 1111 1111 1111 1111 France 56.9 58.6 0.4 C001 0010 0... .... > > UK has a 0 at the beginning of the second byte, and the other > three have a 1 at the beginning of the second byte, thus I > conclude that the UK is not clustered with the other three. > But, this doesn't seem to follow common sense, so maybe I'm > wrong. > The --- separate the clusters, and indicate bits that may be used for provider assignment and future expansion. To quote (p 3): This division provides the primary intersection between metropolitan and provider based allocation. Approximately 1/4 to 1/2 of the numbers in each cluster are reserved for provider based allocation and future expansion. This is indicated by dashes (---) at the end of each cluster. Large regional providers should be assigned from the high-numbered portion of each cluster. New countries may be added to the low-numbered portion of each cluster. There also was a section that you must have missed on the careful attention paid to bit and octet alignment. The cluster in this case is C001 0001, which includes the U.K. The next cluster begins with France. The assignment is designed so that aggregation may occur during the normal operation of the routing algorithms. Viewed from France, the cluster may not aggregate at all, since Guernsey and Jersey are closer to France. But viewed from Germany, it is extremely likely to aggregate; from China, almost certain. > Could you give me an example of how a provider would be > assigned in the context of the above-mentioned cluster? > Providers which served more than one country in the cluster would be assigned from the end of the --- area, as illustrated above. If a new country is defined (say Northern Ireland), it might be assigned as above (assuming that is a good fit based on population). Note that internal assignment is a concern only of the country. Some governments -- like the U.K. -- are notoriously recalcitrant about plans designed in the U.S. All this plan says is, at the country level, if you use metropolitan or end-point based assignment, assign numbers for the metros from the low end, and assign end-points by metro. Providers which only serve a region within a country (say Scotland, within the U.K.), would be assigned from the high end of the country space, growing toward the others. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13175; 21 May 93 16:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13171; 21 May 93 16:02 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa16245; 21 May 93 16:02 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA16175; Fri, 21 May 93 13:58:15 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18483; Fri, 21 May 93 13:56:43 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA18479; Fri, 21 May 93 13:56:42 MDT Received: from crl.dec.com by p.lanl.gov (5.65/1.14) id AA16082; Fri, 21 May 93 13:56:37 -0600 Received: by crl.dec.com; id AA14643; Fri, 21 May 93 15:56:33 -0400 Received: by easynet.crl.dec.com; id AA29780; Fri, 21 May 93 15:55:48 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: perlman@radia.enet.dec.com Message-Id: <9305211955.AA29780@easynet.crl.dec.com> Received: from radia.enet; by crl.enet; Fri, 21 May 93 15:56:31 EDT Date: Fri, 21 May 93 15:56:31 EDT To: tuba@lanl.gov Apparently-To: tuba@lanl.gov Subject: Thing I promised to write up about TUBA advantages. Should this go anywhere other than the TUBA mailing list? Or do people have suggestions to improve this memo? -- Radia This is an attempt to write up the technical characteristics of TUBA (CLNP). A CLNP address looks like: .literal < 14 bytes 6 bytes 1 +---------------------+------------+-----+ | area address | ID | SEL | +---------------------+------------+-----+ .end literal A quick summary of the advantages: 1) autoconfiguration and autoacquisition of address, because of inclusion of the 6 byte ID field. 2) very flexible addressing hierarchy with virtually unlimited number of levels, because of the fact that level 2 routing is based on routing to longest matching address prefix 3) the ability to embed a point of attachment address into the area address, allowing routing for free (no protocol messages, no configuration) across a backbone WAN such as a public network provider. ************************************************************************ Now I'll explain these features in detail. 1) 6 byte ID field: The IEEE 6 byte address space is large enough so that every machine manufactured can include a ROM with a globally unique ID. It is not necessary to be attached to an IEEE LAN in order to have an IEEE 6 byte ID. It is not difficult or expensive to acquire a block of IEEE addresses. Although 6 bytes is probably sufficient for giving every node a unique address, it is not practical as a Network Layer address because there is no hierarchy, i.e., no routing hints. If the IEEE address were used as the Network Layer address, then the routers would have to keep track of every individual node in the entire world, and they could not afford the memory, the CPU, or the bandwidth necessary to keep and exchange information about every attached system. The CLNP address includes a 6 byte ID field. An end system which has a ROM with a guaranteed globally unique IEEE address can find out all the rest of its CLNP address from a neighbor router: "welcome to USA, Massachusetts, Littleton". Furthermore, the fact that routers have an ID field makes it easier to configure them, even though they cannot completely autoconfigure, since only the area address portion of the CLNP address need be configured. Aside from the convenience of not having to configure addresses, either into the end system or into some sort of boot server, in order for an end system to participate in a network, there are additional features of having a unique ID included as part of the address. For instance, it guarantees that an address will not be reused for a different node, which avoids confusion with misdelivery when name to address caches become stale. 2) Address prefix routing: Address prefixes are equivalent to the IP notion of masks with varying numbers of 1's, but since CLNP addresses are so much longer than IP addresses, the number of levels of hierarchy that can be obtained is much larger. The idea behind address prefix routing is that, with judicious use of the address space, large numbers of addresses can be summarized with a prefix. For example, assume that CLNP addresses were ascii strings and looked like postal addresses of the form country|state|county|city|street|ID. The routers on the boundary of the US might advertise that they can reach anything starting with "US", so they'd advertise the address prefix "US*". But in addition, to optimize routing somewhat, the ones on the West coast might advertise "USCAL*", and the ones on the east coast might advertise "USMA*". With address prefix routing it is not necessary to know how many octets of the address are used for country, or state, or even have the same breakdowns -- some states might not bother with county as part of the address. Some countries might not be subdivided into states. Routing does not have to understand the structure of an address. Routers just see addresses as a pile of bits, and they route towards the longest pile of bits that match the pile of bits which is the destination address of a packet. They do not need to know about AFIs, IDIs, and whether something is GOSIP format or something else. All routing requires is for someone configuring routers on the boundary of some region to make a decision about a sensible prefix to configure into the routers for advertising reachable addresses within that region, or for advertising as reachable addresses reachable outside that region. So routers on the boundary of a region are configured with a set of address prefixes to advertise outside the region that will summarize the addresses in the region. A router will advertise a configured prefix provided that at least one of the addresses reachable in the region matches the prefix. In addition it will advertise any addresses that are reachable that are not included in any of the configured summaries. In addition, for filtering reasons, there might be configured prefixes for addresses that should not be advertised outside the region. Similarly the boundary routers are configured with address prefixes to summarize into the region, with similar rules. Routing is to the longest matching address prefix. There are efficient algorithms (TRIE, binary search) for routing to the longest matching address prefix (I know of one routing implementation that can route CLNP at 50,000 packets per second, for instance). 3) embedded point of attachment addresses: Consider the following, very common topology. There is some sort of backbone network, say an SMDS network or an X.25 network. Let's say some business, like a bank, has thousands of branch offices, all interconnected via the backbone network. Each branch office has a little private Ethernet with perhaps 50 nodes on it, or it might be simply a single node, say an ATM machine. A very convenient use of the CLNP address is to embed the SMDS address of the router attached to the backbone network into the area address. In this way it is not necessary to do any "address resolution" type protocol to find the data link address on SMDS, since it is embedded in the CLNP address. Furthermore, it is not necessary to do any routing protocol to find the set of CLNP addresses reachable from a particular router, since all the addresses reachable from a particular router will be summarized with that router's SMDS address. Think of the CLNP address as: .literal +----------------+--------------------+---------+----+-----+ | which provider | "telephone number" | loc-area| ID | SEL | +----------------+--------------------+---------+----+-----+ .end literal The router attached to SMDS is configured with the magic prefix for "which provider" that defines the address as an SMDS address. Part of the driver for SMDS knows how to extract an SMDS telephone number from the "telephone number" part of the CLNP address. That router advertises into the other routers in its branch office the "which provider" prefix it has been configured with for the SMDS link. So all addresses reachable on SMDS are sent to that router, which merely extracts the SMDS number and sends the packets. In this way an unlimited number of branch offices are interconnected with very minimal configuration and no protocol overhead. +-------------------------+ +-----------+ | |---R1---|private net|--A | public network | +-----------+ | | +-------------------------+ | | R2--B C For instance, assume that R1's "phone number" on the public net is x. R2's is y, and C's is z. Let's assume that the "which provider" part of the address is "57". Then A's address would be 57.x.A, B's address would be 57.y.B, and C's address would be 57.z.C. Let's say A wants to talk to B. At some point in the past, B would have figured out its address, and registered itself in some naming service. A looks up B's name and gets the address 57.y.B. R1 will have advertised to the level 2 routers in that private net that anything that starts with 57 can be routed to it, since it's been configured with the knowledge that anything starting with 57 can be routed over its link to the public net. So the packet is sent to R1. When it gets to R1, R1's driver for the public net knows how to extract a phone number from the CLNP address. It extracts "y", dials it, and by magic, the packet is delivered, even though R1 and R2 did not explicitly know about each other and never exchanged routing information with each other. Now not all networks have such a simple topology. A branch office might be attached to SMDS with two routers, or it might be attached to SMDS and X.25. Most of such cases can be provided for with a little additional configuration, or the use of alias addresses. However, in some rare cases things will be so complex that the CLNP feature of embedded subnet addresses will not be helpful. In those rare cases, you are no worse off than an addressing scheme that did not provide this at all -- if 90% of your data can be routed "for free", then the complex cases can be handled with the appropriate combination of manual configuration and explicit exchange of routing information via a routing protocol. Just to show there are reasonable solutions for complicated cases, we'll discuss some complicated (and hopefully reasonably rare) cases. Suppose there is a private net hooked up to two backbone nets, say N1 and N2 via two routers. One possibility is for all the nodes in that private net to have two addresses. When someone looks up an address in the name server they will get back multiple addresses. Then they can choose which address to try. Presumably they'll try the address most similar to their own, or they could simply try them in the order given. Another possibility is for the nodes to all take their address from the point of attachment to one of the nets, say N1. For example, let's assume that R2's phone number on N2 is x. Let's say that R1's address on N1 is y. So A's CLNP address will be N1.x.A. R3 can be configured to know that the address prefix N1 is reachable on its link to N2 by dialing y. Alternatively, R3 can be configured with R2's address on N2 and they can communicate via a routing protocol. N1 N2--R3---private net---B \ / R1 R2 | | privatenet | A Yet another possibility is for N2 to route to CLNP addresses. For instance, N2 might be ATM. It might have its own addressing structure, for instance E.164. You'd get routing for free if you use your E.164 address on ATM as your CLNP address. However, if the owner of R2 was willing to pay extra to N2, R2 could advertise the prefix N1 into ATM. Then ATM would be smart enough to route packets for anything in N1 towards R2. How could R2 let N2 know which address prefixes R2 can reach? It could either be determined at subscription time, or there could be some sort of ES-IS type protocol in which R2 could dynamically, as it discovered address prefixes reachable in its private net, advertise them into N2.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14791; 21 May 93 17:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14787; 21 May 93 17:27 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa19294; 21 May 93 17:27 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA21145; Fri, 21 May 93 15:19:09 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19173; Fri, 21 May 93 15:18:26 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19169; Fri, 21 May 93 15:18:25 MDT Received: from thumper.bellcore.com by p.lanl.gov (5.65/1.14) id AA21107; Fri, 21 May 93 15:18:25 -0600 Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for tuba@lanl.gov; Fri, 21 May 93 17:18:24 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for tuba@lanl.gov; Fri, 21 May 93 17:18:23 EDT Date: Fri, 21 May 93 17:18:23 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Paul Francis (formerly Paul Tsuchiya" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Message-Id: <9305212118.AA00316@tsuchiya.bellcore.com> To: perlman@radia.enet.dec.com, tuba@lanl.gov Subject: Re: Thing I promised to write up about TUBA advantages. Should this go anywhere other than the TUBA mailing list? Or do people have suggestions to improve this memo? -- Radia > > Think of the CLNP address as: > > .literal > > +----------------+--------------------+---------+----+-----+ > | which provider | "telephone number" | loc-area| ID | SEL | > +----------------+--------------------+---------+----+-----+ > > .end literal > This doesn't look like the NSAPs I've seen. The one's I've seen look like: +----------------+--------------------+---------+----+-----+ |subaddress type | "telephone number" | loc-area| ID | SEL | +----------------+--------------------+---------+----+-----+ The subaddress type (X.121, E.164, etc.) doesn't really tell you which provider, or only does with a certain amount of number coordination (and subsequent routing) that doesn't yet exist. So, the format you have above seems good and necessary. Where has this format been published/discussed? PX   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15028; 21 May 93 17:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15024; 21 May 93 17:37 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19601; 21 May 93 17:37 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 21 May 93 17:36:08 EDT Received: from vela.acs.oakland.edu by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Fri, 21 May 93 17:36:07 EDT Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA11694 (5.65c+/IDA-1.4.4); Fri, 21 May 1993 17:33:13 -0400 Date: Fri, 21 May 93 13:01:37 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1200.bill.simpson@um.cc.umich.edu> To: Eric Fleischman To: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Reply-To: bsimpson@morningstar.com Subject: Re: PROs/CONs of SIP/PIP/TUBA Based on the comments thus far, I respectfully request that you remove "SIP Con" #1: > 1) Since hierarchical addresses tend to be deployed in a "sparse" manner, > it unclear whether a 64 bit address space will adequately scale to meet > every conceivable future addressing scenario. Add "SIP Pro" #5: 5) SIP has a 64 bit assignment plan which is demonstrated to provide for future growth well into the next millenium, while reducing today's routing table size by 2 to 4 orders of magnitude. The plan is based on multiple well known population projections, and well understood routing algorithms, rather than theoretical extingencies. The plan provides for at least 1/4 million numbers per person (in 2025), and 6 or more layers of heirarchy. Only 3/8 of the space is reserved, leaving the remainder available for long term future expansion. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15038; 21 May 93 17:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15034; 21 May 93 17:37 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19608; 21 May 93 17:37 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 21 May 93 17:35:27 EDT Received: from vela.acs.oakland.edu by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Fri, 21 May 93 17:35:20 EDT Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA11685 (5.65c+/IDA-1.4.4); Fri, 21 May 1993 17:32:52 -0400 Date: Fri, 21 May 93 12:29:06 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1199.bill.simpson@um.cc.umich.edu> To: "Paul Francis (formerly Paul Tsuchiya" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Reply-To: bsimpson@morningstar.com Subject: Re: SIP Addressing Limitations > >From where would you allocate space for a provider that > doesn't fall under one of the clusters? For instance, > a provider that has direct customers in the Northeastern > USA and the far east (Singapore and Korea, say)? > It is becoming apparent that you haven't really read the proposal. Try "Constraints", on page 2. I am unable to answer the question, since you didn't provide enough information. How many customers? 10,000,000? 10,000? 10? Where is it connected to the rest of the internet? What is the transit policy? What are the legal requirements of the countries where it provides service? Which allocation models are they using (provider, metro, or both)? Finally, I don't think the IANA would spend much time considering such a provider. Since it has a private trans-continental link, and a private trans-oceanic link (or a very very long trans-oceanic link around the Cape, or a very long multi-satellite path), it will be priced far in excess of the costs of its competitors. It will not receive funding from any but the most foolish investors, and have none but the most foolish customers. It will fail in the marketplace. Why are we wasting our time with theoretical examples of providers that aren't connected to the internet? Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19463; 21 May 93 22:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19459; 21 May 93 22:20 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26200; 21 May 93 22:19 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 21 May 93 22:19:28 EDT Received: from munnari.oz.au by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Fri, 21 May 93 22:19:22 EDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12344; Sat, 22 May 1993 12:18:31 +1000 (from kre@munnari.OZ.AU) To: bsimpson@morningstar.com Cc: "Paul Francis (formerly Paul\ Tsuchiya" , pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Re: SIP Addressing Limitations In-Reply-To: Your message of "Thu, 20 May 1993 13:31:46 EDT." <1196.bill.simpson@um.cc.umich.edu> Date: Sat, 22 May 1993 12:18:19 +1000 Message-Id: <13629.738037099@munnari.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Elz Date: Thu, 20 May 93 13:31:46 EDT From: "William Allen Simpson" Message-ID: <1196.bill.simpson@um.cc.umich.edu> The assignment is designed so that aggregation may occur during the normal operation of the routing algorithms. Viewed from France, the cluster may not aggregate at all, since Guernsey and Jersey are closer to France. But viewed from Germany, it is extremely likely to aggregate; from China, almost certain. It amuses me greatly that there's anyone who still seriously believes that network topology, and geography, are even remotely related when it comes to international connections. It may seem that way in Europe, at the minute, but that's largely the result of the EEC attempting to make the connections inside Europe stop being international (or that's how it seems from here) - it certainly wasn't that way a shortish while ago. Another area about the same size as Europe contains Libya, Egypt, Israel, Lebanon, Syria, Jordan, Iraq, Iran, and Kuwait. Does anyone really believe that routes from that area will form any kind of aggregation anytime in the forseeable future? Or to take a current obvious example, just look at the Malaysian pensinula - excluding Burma (Myramar (sp?)) as they're not connected at all, and so no-one has any idea what will happen with them. But Thailand, Malaysia, and Singapore all have internet connections, none are connected to any of the others, and what's more, their internet connectins all connect to the rest of the internet at widely dispersed locations (two at various places on the east cost side of the US, and one on the west coast). Last I heard, Japan as a single country couldn't even manage to present a unified routing interface to the rest of the world. International links are composed almost entirely out of politics, often expressed in the form of tarrifs set by various tellecommunication authorities, and proximity is rarely any kind of indicationas to what makes sense, financially, or politically in other eays. kre   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23045; 21 May 93 23:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23041; 21 May 93 23:13 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa27393; 21 May 93 23:13 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA02606; Fri, 21 May 93 21:11:32 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA20938; Fri, 21 May 93 21:11:06 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA20934; Fri, 21 May 93 21:11:04 MDT Received: from munnari.OZ.AU by p.lanl.gov (5.65/1.14) id AA02587; Fri, 21 May 93 21:11:01 -0600 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13933; Sat, 22 May 1993 13:09:22 +1000 (from kre@munnari.OZ.AU) To: perlman@radia.enet.dec.com Cc: tuba@lanl.gov Subject: Re: Thing I promised to write up about TUBA advantages. In-Reply-To: Your message of "Fri, 21 May 1993 15:56:31 EDT." <9305211955.AA29780@easynet.crl.dec.com> Date: Sat, 22 May 1993 13:09:11 +1000 Message-Id: <13643.738040151@munnari.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Elz Date: Fri, 21 May 93 15:56:31 EDT From: perlman@radia.enet.dec.com Message-ID: <9305211955.AA29780@easynet.crl.dec.com> 1) 6 byte ID field: The CLNP address includes a 6 byte ID field. An end system which has a ROM with a guaranteed globally unique IEEE address Unfortunately its a fiction to believe that any IEEE address is globally unique, or even necessarily locally unique. It's only intended to be. We have, at present, no means to verify that manufacturers actually do assign unique IEEE addresses to workstations, either by design, or because no-one is infallible. That means that it would be a rather poor idea to simply assume that you can use your IEEE address, combined with local net (area) addressing information to make a unique address - there needs to be a method to verify that the address assigned is actually unique. Unfortunately, currently at least, duplicate addresses are probably rare enough that most implementations won't bother actually verifying uniqueness, even assuming that there's a method. Worse, in the future, duplicate addresses will possibly become more common, as el-cheapo manufacturers with very cheap products (say light bulbs) that are net aware start to realise that the actual $ cost of a MAC address is a significant part of their manufacturing costs, probably after IEEE realise that 4 million manufacturer codes isn't really many, and that to avoid them being assigned to all kinds of random people they should drastically increase the cost. At that stage, some shonky manufacturers will start to assume that they can simply recycle their block of numbers when they run out (16 million light bulbs don't last very long), on the assumption that it will be very unlikely that anyone will receive a duplicate while the previous address is still in a bulb that works. Aside from the convenience of not having to configure addresses, either into the end system or into some sort of boot server, In any case, I don't actually agree that this is really a convenience. Not having to configure addresses in the end system itself is certainly a win, but having them simply appear on the network without any pre-configuration is not something I really want to happen, I want to know what systems are appearing on my net, and I don't want them to be able to work until they are correctly configured (somwehere). Editing one file to allocate an address (it needs to go in a directory somewhere anyway) is not a huge burden. I know that much of the claimed simplicity of appletalk is that it does allow anyone to connect anywhere without pre-arrangement (including using an address verification protocol to make reasonably sure the address is unique) - its also what makes appletalk one of the most painful networks to diagnose problems on, its almost impossible to work out just which node it is that is causing a problem without physically visiting every one to disconnect them and find which makes the problem go away - its only the small scale of appletalk nets that makes them work at all. That one is just not as much of a feature as you might think, it can still be useful as long as its limitations are understood, but this ... 3) embedded point of attachment addresses: is a positive disaster, and it amazes me that anyone would believe otherwise. Consider the following, very common topology. There is some sort of backbone network, say an SMDS network or an X.25 network. Let's say some business, like a bank, has thousands of branch offices, all interconnected via the backbone network. Each branch office has a little private Ethernet with perhaps 50 nodes on it, or it might be simply a single node, say an ATM machine. Sounds very reasonable to me. Quite a likely scenario I'd expect. In fact so likely, that its likely that more than one largish business will have their internal network set up just this way. Further, I wouldn't be at all surprised if those two businesses, and probably several others, were connected by a PDN type network, perhaps frame relay, or SMDS. Now to send a message from a system on one of those business's private nets, to a system on another you have 3 nets to traverse, each of which could usefully use an embedded address. Now a CLNP address (NSAP) has space for one of those three, but once all the boilerplate bits are included, including the IEEE id mentioned above, there's clearly not space for three, or even two, or not unless the 20 octet limit is raised - and if you do that I'll simply postulate slightly less likely scenarios that will overflow even the 255 byte absolute limit. Now in this situation the "problem" address, the one for which address resolution is going to be hardest, is going to be that of the PDN that connects the businesses, so the obvious solution is simply to encode that address, and omit the others. That looks plausible - the sending system can easily be configured to know where the gateway(s) to the PDN are located and, if necessary, pick one and route to it, without needing its address embedded in the packet. However, its not quite that easy at the receiving gateway from the PDN, the system at the exit point just gets the recipient NSAP, it doesn't contain any kind of embedded address, so it has to do some kind of address resolution to be able to reach any destination address on its local corporate WAN. Now either you create an address resolution method of some algorithmic nature, or ... In those rare cases, you are no worse off than an addressing scheme that did not provide this at all -- if 90% of your data can be routed "for free", then the complex cases can be handled with the appropriate combination of manual configuration and explicit exchange of routing information via a routing protocol. but you are much worse off, as now you need some "hack" kind of manual configuration/undefined routing, that will allow the PDU to be routed to its destination. If its not a hack, then everyone may as well use it for exchanging data on the local private WAN, and the supposed attractiveness of the embedded address for 90% of the traffic is totally lost. A "hack" is anything that is not reliable or effecient enough to route traffic in the ordinary cases. The conclusion is that either you don't need the embedded address on your WAN at all, or that external traffic can't reliably or effecienty be delivered. I'm aware of the "only a few systems need to be externally accessible" argument, and for some organisations its true, but its not true for all, there are plenty of large organisations (perhaps not commercial, but that doesn't matter) which have large private networks, on which almost everything is, and needs to be, accessible from outside the network. I believe that some kind of address resolution system tha can translate end system addresses to WAN addresses (X.121 or any other) is going to be necessary - once you have that you may as well use it everywhere for consistency, in fact you probably have to use it everywhere, as you can never be really sure any particular address you're presented with will have the correct embedded address for the particular WAN you're about to cross. If you have that, then the utility of embedded addresses seems to have vanished out the other side of usefulness somewhere. Further, if you can set up a net so that systems have and use local WAN embedded addresses for their internal traffic, and some other addresses when they're to be addressed from outside, then you create a situation (in scenarios that are easy to imagine) where the sending host has to choose which of those addresses it should use, indeed you say so... When someone looks up an address in the name server they will get back multiple addresses. Then they can choose which address to try. Presumably they'll try the address most similar to their own, or they could simply try them in the order given. Here you're essentially making the sending host perform a routing function, attempting to determine which address will be best to use to get to some random unknown remote destination. That's is going to require quite a bit of intelligence in the sending host, the kind of thing its really best to extract from hosts and put elsewhere. Perhaps hosts need to consult route servers to determine the addresses they should be using. If so, this had better be written somewhere. And the necessary protocols designed and tested - which includes somwhow inventing a method by which the route servers can determine which of several, basically unknown, embedded addresses is going to work best for any given far distant destination. kre   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23164; 21 May 93 23:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23160; 21 May 93 23:17 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27500; 21 May 93 23:17 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 21 May 93 23:17:09 EDT Received: from munnari.oz.au by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Fri, 21 May 93 23:17:03 EDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14055; Sat, 22 May 1993 13:16:41 +1000 (from kre@munnari.OZ.AU) To: bsimpson@morningstar.com Cc: Paul Francis , pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Subject: Re: SIP Addressing Limitations In-Reply-To: Your message of "Fri, 21 May 1993 12:29:06 EDT." <1199.bill.simpson@um.cc.umich.edu> Date: Sat, 22 May 1993 13:16:30 +1000 Message-Id: <13651.738040590@munnari.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Elz Date: Fri, 21 May 93 12:29:06 EDT From: "William Allen Simpson" Message-ID: <1199.bill.simpson@um.cc.umich.edu> Since it has a private trans-continental link, and a private trans-oceanic link (or a very very long trans-oceanic link around the Cape, or a very long multi-satellite path), it will be priced far in excess of the costs of its competitors. I think you don't very well understand international link costs. It costs me exactly the same to install a link to the east coast of the US as it does to the west coast. Making links that seem to be absurd is sometimes the most rational thing to do, and can often be cost effective. There are several links from Asian countries into US east coast receivers. Oten, even if perhaps not always, there are good economic reasons for those. Any scheme that simply assumes such things won't happen, or allows for them only in a seriously non-optimal way is not going to last a very long time at all. Extreme generality is a requirement. kre   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01887; 22 May 93 12:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01883; 22 May 93 12:37 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa10278; 22 May 93 12:37 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA10728; Sat, 22 May 93 10:35:07 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA21736; Sat, 22 May 93 10:34:19 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA21732; Sat, 22 May 93 10:34:18 MDT Received: from interlock.ans.net by p.lanl.gov (5.65/1.14) id AA10715; Sat, 22 May 93 10:34:17 -0600 Received: by interlock.ans.net id AA15922 (InterLock SMTP Gateway 1.1 for tuba@lanl.gov); Sat, 22 May 1993 12:33:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sat, 22 May 1993 12:33:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 22 May 1993 12:33:08 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dennis Ferguson Message-Id: <199305221633.AA50605@foo.ans.net> To: bsimpson@morningstar.com Cc: "Paul Francis (formerly Paul Tsuchiya" , pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Re: SIP Addressing Limitations In-Reply-To: (Your message of Fri, 21 May 93 12:29:06 EDT.) <1199.bill.simpson@um.cc.umich.edu> Date: Sat, 22 May 93 12:33:49 -0500 >> From where would you allocate space for a provider that >> doesn't fall under one of the clusters? For instance, >> a provider that has direct customers in the Northeastern >> USA and the far east (Singapore and Korea, say)? >> [...] > Finally, I don't think the IANA would spend much time considering such a > provider. Since it has a private trans-continental link, and a private > trans-oceanic link (or a very very long trans-oceanic link around the > Cape, or a very long multi-satellite path), it will be priced far in > excess of the costs of its competitors. It will not receive funding > from any but the most foolish investors, and have none but the most > foolish customers. It will fail in the marketplace. > > Why are we wasting our time with theoretical examples of providers that > aren't connected to the internet? > > Bill.Simpson@um.cc.umich.edu Somehow your response leaves me feeling a bit uncomfortable. I would point out that the current path from places in Thailand to places in Singapore appears to pass through Virginia and New Jersey, e.g. % traceroute -g gateway.chula.ac.th. solomon.technet.sg. traceroute to solomon.technet.sg (192.169.33.3), 30 hops max, 40 byte packets 1 en-0.ans-gw.ans.net (147.225.1.1) 6 ms 5 ms 4 ms 2 en-0.enss160.t3.ans.net (192.77.154.2) 8 ms 3 ms 5 ms 3 t1-2.New-York-cnss35.t3.ans.net (140.222.35.4) 6 ms 8 ms 8 ms 4 t3-3.New-York-cnss33.t3.ans.net (140.222.33.4) 6 ms 11 ms 8 ms 5 t3-3.New-York-cnss32.t3.ans.net (140.222.32.4) 6 ms 9 ms 8 ms 6 t3-1.Washington-DC-cnss56.t3.ans.net (140.222.56.2) 13 ms 13 ms 13 ms 7 t3-0.Washington-DC-cnss58.t3.ans.net (140.222.58.1) 14 ms 13 ms 13 ms 8 t3-0.enss136.t3.ans.net (140.222.136.1) 14 ms 13 ms 14 ms 9 College-Park.MD.ALTER.NET (192.41.177.249) 15 ms 15 ms 16 ms 10 Falls-Church1.VA.ALTER.NET (137.39.11.1) 18 ms 18 ms 16 ms 11 NetBlazer1.Falls-Church.VA.ALTER.NET (137.39.1.10) 19 ms 21 ms 19 ms 12 gateway.chula.ac.th (192.133.10.2) 900 ms 859 ms 877 ms 13 NetBlazer1.Falls-Church.VA.ALTER.NET (137.39.1.10) 918 ms 913 ms 899 ms 14 Falls-Church1.VA.ALTER.NET (137.39.1.1) 896 ms 908 ms 902 ms 15 College-Park.MD.ALTER.NET (137.39.11.2) 900 ms 925 ms 893 ms 16 en-0.ENSS136.t3.ANS.NET (192.41.177.253) 909 ms 894 ms 887 ms 17 t3-1.Washington-DC-cnss58.t3.ans.net (140.222.58.2) 897 ms 1038 ms 918 ms 18 t3-3.Washington-DC-cnss56.t3.ans.net (140.222.56.4) 908 ms 889 ms 887 ms 19 t3-0.New-York-cnss32.t3.ans.net (140.222.32.1) 897 ms 903 ms 906 ms 20 t3-0.New-York-cnss33.t3.ans.net (140.222.33.1) 912 ms 893 ms 897 ms 21 t3-0.enss137.t3.ans.net (140.222.137.1) 947 ms 955 ms 897 ms 22 trillian-gateway.jvnc.net (192.12.211.75) 903 ms 919 ms 896 ms 23 192.169.41.41 (192.169.41.41) 1590 ms 1579 ms 1569 ms 24 solomon.technet.sg (192.169.33.3) 1596 ms 1570 ms 1569 ms I can hardly wait to see where the packets go when people in Myanmar, or Viet Nam, decide they'd be best served by dealing with a European provider. Dennis Ferguson   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02154; 22 May 93 14:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02150; 22 May 93 14:07 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12183; 22 May 93 14:07 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Sat, 22 May 93 14:06:47 EDT Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Sat, 22 May 93 14:05:57 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for tuba@lanl.gov; Sat, 22 May 93 14:05:56 EDT Date: Sat, 22 May 93 14:05:56 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Paul Francis (formerly Paul Tsuchiya" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Message-Id: <9305221805.AA01476@tsuchiya.bellcore.com> To: bsimpson@morningstar.com, francis@thumper.bellcore.com Subject: Re: SIP Addressing Limitations Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov > > > >From where would you allocate space for a provider that > > doesn't fall under one of the clusters? For instance, > > a provider that has direct customers in the Northeastern > > USA and the far east (Singapore and Korea, say)? > > > It is becoming apparent that you haven't really read the proposal. Try > "Constraints", on page 2. Yes, I saw that section. I just wanted to make sure that I understood your intent to leave only 1/8 of the address space for everything that didn't fit your model..... (I understand that, in theory, the IPAE half will someday be given back, when all the IP hosts go away, but I think that won't happen for a very very long time....) > > I am unable to answer the question, since you didn't provide enough > information. > > How many customers? 10,000,000? 10,000? 10? > Well, let's say it is 50 today but grows to 500,000 in 10 years. It would be nice if it didn't matter how many customers it had..... > > Finally, I don't think the IANA would spend much time considering such a > provider. Since it has a private trans-continental link, and a private > trans-oceanic link (or a very very long trans-oceanic link around the > Cape, or a very long multi-satellite path), it will be priced far in > excess of the costs of its competitors. It will not receive funding > from any but the most foolish investors, and have none but the most > foolish customers. It will fail in the marketplace. > > Why are we wasting our time with theoretical examples of providers that > aren't connected to the internet? Well, I will confess that I baited you on this, which perhaps is unprofessional (I'm not sure, I'll accept people's opinions on this in private messages to me) but I must say you took the bait gloriously...... The provider topology I described is JVNCnet. Given the state of the infrastructure in certain places in the Far East and trans-pacific tariffs and Japanese tariffs and who knows for what other reasons, they and their Far East customers find it cost effective to connect to the internet via direct links to the northeastern USA. Maybe those are the traces that Dennis Ferguson put in his message--I don't know for sure. Now, maybe this is a temporary aberation and as soon as parts of the far east gets its infrastructure together this topology will be deemed silly, but I think in general it is dangerous to assume that the topology will always follow geographical boundaries..... To be fair, I think that the 64-bit SIP address will work, but it will require constant management. I have gone through the exercise of calculating how many hosts the 64 bit address can address. I don't remember the exact numbers, but with five levels of hierarchy (which I think would be necessary for 10^12 hosts), the SIP address could handle 10^12 hosts if it acheived about 2% efficiency per level of hierarchy. By 2% efficiency I mean that 2% of the possible address assignments (per level) are actually assigned. This is really low efficiency, and I think one can do better if one manages the addresses carefully and allows for re-assignment of addresses when the previous allocation strategy proves to have been wrong. But, without good allocation it is easy to do worse than 2% (the pre-CIDR IP address space is probably getting about this kind of efficiency). So, I don't think 64-bits is broken, but I think it will require constant work to keep it useable. You (Simpson) claimed to have spent 100 hours on the allocation strategy you made. That's a lot of time, and already we have counter-examples to your strategy. Address space wars are really painful, and I think it would be nice if we didn't have to have them in the future.... PX   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10534; 23 May 93 10:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10530; 23 May 93 10:17 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa01126; 23 May 93 10:17 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Sun, 23 May 93 10:17:43 EDT Received: from vela.acs.oakland.edu by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Sun, 23 May 93 10:17:41 EDT Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA19894 (5.65c+/IDA-1.4.4); Sun, 23 May 1993 10:13:42 -0400 Date: Sat, 22 May 93 10:44:27 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1202.bill.simpson@um.cc.umich.edu> To: Robert Elz Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Reply-To: bsimpson@morningstar.com Subject: Re: SIP Addressing Limitations > It amuses me greatly that there's anyone who still seriously > believes that network topology, and geography, are even remotely > related when it comes to international connections. > Apparently I am in good company. With Rehkter, Li, and the CIDR luminaries. Normally, your messages have better reasoning. It continues to distress me that people reply to messages without actually reading the plan. This is the last time I will bother replying to non-specific requests for wording changes. First, let's look at the actual plan: There are approximately 227 assigned countries and territories. This table size is 2 orders of magnitude smaller than currently handled by IP4 world-wide. An effective aggregation scheme would result from interconnection of all of the networks within each country. This may be likely in the long term (by fiat if not for practical reasons), but is not required for efficient operation of this plan. Splitting each country into 10 disconnected portions would still be an order of magnitude smaller than currently handled by IP4 world-wide. Are any of these numbers in dispute? > from here) - it certainly wasn't that way a shortish while ago. A shortish while ago, there was no internet at all. Let's try planning for the future, not the past. > Does anyone really believe that routes from that area will > form any kind of aggregation anytime in the forseeable future? The plan does not require that it be so. It merely takes advantage of the fact when it occurs. Dynamically. > with them. But Thailand, Malaysia, and Singapore all have > internet connections, none are connected to any of the others, According to public CIA reports, all 3 have communications links with each other, including radio, television, undersea cable, and satellite. Oh, you are limiting this to "internet" links? You expect that the current situation is permanent? Fine. Even if each country stays separate, the improvement in table size is 2 orders of magnitude better than we currently have, and *never* gets worse. > west coast). Last I heard, Japan as a single country couldn't > even manage to present a unified routing interface to the > rest of the world. > Again, even if Japan and every other country on the planet split into 10 parts which refuse to talk to each other except through a 3rd party, the plan provides an order of magnitude better than we currently have, and *never* gets worse. And since a 3rd party is likely to be geographically close, the plan will allow aggregation from the point of view of a more distant observer. > International links are composed almost entirely out of politics, > often expressed in the form of tarrifs set by various > tellecommunication authorities, and proximity is rarely any > kind of indicationas to what makes sense, financially, or > politically in other eays. > Yes. Which is why the plan clearly states: The basic administrative unit is the country. Past experience shows that political considerations often override practical concerns in the administration of networks. This plan seeks to align the practical with the political. > I think you don't very well understand international link > costs. It costs me exactly the same to install a link to > the east coast of the US as it does to the west coast. > Making links that seem to be absurd is sometimes the most > rational thing to do, and can often be cost effective. No, you are incorrect. Any link that you actually *build* will cost considerably more from Australia to the US east coast than to the west coast. You are talking about combining several shared links into a long path. These links are actually switched at various points. Any provider which can use the same links for intra-continental and inter-continental traffic will be in an enhanced position. Any provider that limits its connectivity will get its financial pants beaten, unless it can charge a hefty price for "enhanced security". The plan takes advantage of (and encourages) likely future increases in inter-connectivity. Most importantly, such increases do *NOT* make routing and addressing worse (as is currently the case). > There are several links from Asian countries into US east > coast receivers. Oten, even if perhaps not always, there > are good economic reasons for those. There are no trans-oceanic cables from any Asian country to the US east coast listed in any resource I have available. Perhaps you could be more specific? You may be referring to the fact that current US *internet* traffic from some Asian countries passes through somewhere on the east coast. That is merely an effect of US "policy" (single interconnect between providers), and has nothing to do with topology. That policy is already scheduled to be obsolete. Again, the plan treats the country as the basic administrative unit. For external countries, it doesn't matter that you are connected to the east coast or the west coast, only that you are connected. Now, do you have a better plan? One that has a guaranteed set of constraints, and a provable maximal routing table size? One that aggregates so that an international amateur radio operator sees a very small table? One that scales on an interplanetary basis? Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12218; 23 May 93 20:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12214; 23 May 93 20:10 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa11572; 23 May 93 20:10 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA27423; Sun, 23 May 93 18:05:17 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA22750; Sun, 23 May 93 18:02:10 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA22746; Sun, 23 May 93 18:02:09 MDT Received: from vela.acs.oakland.edu by p.lanl.gov (5.65/1.14) id AA27375; Sun, 23 May 93 18:02:11 -0600 Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA23865 (5.65c+/IDA-1.4.4); Sun, 23 May 1993 20:01:29 -0400 Date: Sun, 23 May 93 13:09:12 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1206.bill.simpson@um.cc.umich.edu> To: "Paul Francis (formerly Paul Tsuchiya" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Reply-To: bsimpson@morningstar.com Subject: Re: SIP Addressing Limitations > Now, maybe this is a temporary aberation and as soon as parts of > the far east gets its infrastructure together this topology will > be deemed silly, but I think in general it is dangerous to assume > that the topology will always follow geographical boundaries..... > Yes, which is why the constraint is that the system will demonstrably continue to operate with 10 times the partitioning of the best case model, using current technology. BTW, it is currently possibly to get over a dozen dedicated 56K links from Michigan to California for the price that Ameritech wants for one pair of local residential intra-LATA ISDN 2B+D operated 24 hours a day. I have to assume that this also is a "temporary aberation [sic]". > hosts), the SIP address could handle 10^12 hosts if it acheived > about 2% efficiency per level of hierarchy. By 2% efficiency > I mean that 2% of the possible address assignments (per level) > are actually assigned. > Then you will be glad to have read: While at first glance this may appear to be 89% efficiency in allocation, it is noted below that the two largest countries are assigned only half their proper allocation. The actual efficiency is closer to 60%, .... Leaves lots of room for error at the lower levels. > That's a lot of time, and already we have > counter-examples to your strategy. So far I haven't seen any. You have shown that there are 2 sites (not providers) that are in adjacent Asian countries (not the same country) that are connected to 2 U.S. nation-wide providers, which communicate through a 3rd U.S. nation-wide provider on the East coast. But even West coast U.S. customers of those providers communicate on the East coast. So, we are merely giving the Asians that same poor connectivity we have in the U.S. already. To quote (again): There are approximately 227 assigned countries and territories. This table size is 2 orders of magnitude smaller than currently handled by IP4 world-wide. An effective aggregation scheme would result from interconnection of all of the networks within each country. This may be likely in the long term (by fiat if not for practical reasons), but is not required for efficient operation of this plan. Splitting each country into 10 disconnected portions would still be an order of magnitude smaller than currently handled by IP4 world-wide. As a counter-example, you would have to show more than 100 disconnected networks for *every* country in the world which do not communicate *within* their local country. Even so, that efficiency would still be better than we are currently routing today for the U.S. > To be fair, I think that the 64-bit SIP address will work, but > it will require constant management. The idea behind country-based assignment is that it will take *NO* external management. Each country can manage their own affairs and the effects will be negligable outside the country. If they do the right things (interconnect with adjacent countries), it can get better. But it won't get worse. Paul, in my view it's time for you to put up or shut up. Show me this fine allocation plan of yours with: - a guaranteed set of constraints. - a provable maximal routing table size. - aggregates so that an international amateur radio operator sees a very small table (< 256 entries, preferably < 10). - scales on an inter-planetary basis. And is: - easy to administer. - amenable of politics. - supports metro, provider, and end-point allocation simultanously. - has a firm rationale for each division. - supports efficient distributed access. - aggregates better as the network grows. Otherwise, give me *contructive* criticism for my plan. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12231; 23 May 93 20:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12227; 23 May 93 20:10 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa11606; 23 May 93 20:10 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Sun, 23 May 93 20:06:12 EDT Received: from vela.acs.oakland.edu by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Sun, 23 May 93 20:06:11 EDT Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA23858 (5.65c+/IDA-1.4.4); Sun, 23 May 1993 20:01:13 -0400 Date: Sun, 23 May 93 12:57:35 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1205.bill.simpson@um.cc.umich.edu> To: Dennis Ferguson Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Reply-To: bsimpson@morningstar.com Subject: Asian assignment > Somehow your response leaves me feeling a bit uncomfortable. I would > point out that the current path from places in Thailand to places in > Singapore appears to pass through Virginia and New Jersey, e.g. > > I can hardly wait to see where the packets go when people in Myanmar, > or Viet Nam, decide they'd be best served by dealing with a European > provider. > Thank you for a concrete example, and thank you for making (inadvertantly, I'm sure) the case for metropolitan assignment. You cited 2 Asian countries have (indirect) internet links to 2 U.S. providers. Because of the silliness of AN_S (yet another provider) policy routing, all of their traffic goes through AN_S routers on the East Coast. Could you imagine the problems in those sites if they were assigned based on provider, and then changed to a local provider as they grew? Entire countries to be renumbered. Worse yet, assume those sites have the usual assignment strategy (first come, first served). As their internet grows, they end up with the hodge-podge mess we currently have in the U.S. Using early metro-based assignment, future assignments will aggregate naturally as connectivity increases. Provider-based assignment requires us to decide, years in advance, what the overall topology will be. Or is your point that we should all have AN_S provider addresses, because most of the world currently routes through you? Thus ensuring that it always will? Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19772; 24 May 93 2:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19768; 24 May 93 2:37 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa19464; 24 May 93 2:36 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA01410; Mon, 24 May 93 00:33:43 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23080; Mon, 24 May 93 00:33:07 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23076; Mon, 24 May 93 00:33:06 MDT Received: from lager.cisco.com by p.lanl.gov (5.65/1.14) id AA01384; Mon, 24 May 93 00:33:09 -0600 Received: by lager.cisco.com; Sun, 23 May 1993 23:32:53 -0700 Date: Sun, 23 May 1993 23:32:53 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199305240632.AA06553@lager.cisco.com> To: bsimpson@morningstar.com Cc: kre@munnari.oz.au, pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov In-Reply-To: "William Allen Simpson"'s message of Sat, 22 May 93 10:44:27 EDT <1202.bill.simpson@um.cc.umich.edu> Subject: SIP Addressing Limitations > It amuses me greatly that there's anyone who still seriously > believes that network topology, and geography, are even remotely > related when it comes to international connections. Apparently I am in good company. With Rehkter, Li, and the CIDR luminaries. Excuse me, but you have misread all of CIDR if you believe that to be true. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20199; 24 May 93 4:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20195; 24 May 93 4:51 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa21379; 24 May 93 4:50 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA04057; Mon, 24 May 93 02:47:12 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23180; Mon, 24 May 93 02:46:45 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA23176; Mon, 24 May 93 02:46:44 MDT Received: from concorde.inria.fr by p.lanl.gov (5.65/1.14) id AA04045; Mon, 24 May 93 02:46:43 -0600 Received: from givry.inria.fr by concorde.inria.fr; Mon, 24 May 1993 10:43:54 +0200 Received: by givry.inria.fr; Mon, 24 May 1993 10:43:54 +0200 Message-Id: <199305240843.AA08899@givry.inria.fr> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Francis Dupont To: tuba@lanl.gov Cc: wg4-clns@funet.fi Subject: TUBA for SunNet OSI Date: Mon, 24 May 1993 10:43:53 +0200 X-Orig-Sender: Francis.Dupont@inria.fr X-Charset: ASCII X-Char-Esc: 29 I propose the first version of a TUBA translator for SunNet OSI 7.0! The distribution is available by anonymous FTP (or FTAM) on ftp.inria.fr (IP 192.93.2.54) in {~ftp/}network/misc/tubad-1.0.tar.Z . The idea is to use an IP "tunnel" interface/driver (the same thing that we used for IP over X.25 before the last SunLink and SunNet X.25 :-) and a CLNP socket. The translator runs in user mode then the only kernel hack is the tunnel driver (if we can get a "moadloadable" version of it no reboot should be necessary :-). I am working on a second version using a CLNP "tunnel" interface/driver with UDP, fragmentation, ICMP, CLNP ER, ... Regards Francis.Dupont@inria.fr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22686; 24 May 93 9:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22682; 24 May 93 9:01 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26094; 24 May 93 9:01 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 24 May 93 09:01:15 EDT Received: from ftp.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 24 May 93 09:00:54 EDT Received: by ftp.com id AA07496; Mon, 24 May 93 08:59:22 -0400 Date: Mon, 24 May 93 08:59:22 -0400 Message-Id: <9305241259.AA07496@ftp.com> To: bsimpson@morningstar.com Subject: Re: SIP Addressing Limitations Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: francis@thumper.bellcore.com, pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Bill Simpson writes: > Why are we wasting our time with theoretical examples of providers that > aren't connected to the internet? In response to a note providing a hypothetical network configuration and asking how SIP addressing deals with it. The answer to your question, Bill, is extraordinarily simple. Because next decade, somone may build a network that has a configuration just like the one offered (or very similar) and IPng must be able to deal with it. The whole purpose of IPng is to allow the Internet to grow and evolve in different directions than it is currently doing. The problem is that we do not know in fact what will happen to the network over the next 10-20 years, so we have to come up with guesses and ideas of things that _may_ happen. Some of these may seem far-fetched by today's standards, but then I have a paper written about 10 years ago, by Jon Postel (and others) showing that we only need a 1-byte network number. At the time that paper was written, computers were still big expensive machines with lots of terminals -- and the original designers of IP4 assumed that the economics of computing would stay as they were in the 70's and early 80s. There would be a few very large networks, each providing service to large numbers of expensive machines. The original designers did not count on the fundamental change in computing economics to be brought about by PCs and workstations and LANs. And these were all technologies that were well known at the time. What new technologies will be developed and commercialized over the next 10 years? How will they affect (or be affected by) the Internet? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24582; 24 May 93 10:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24578; 24 May 93 10:39 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa29734; 24 May 93 10:39 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA13217; Mon, 24 May 93 08:35:45 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24118; Mon, 24 May 93 08:34:24 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24110; Mon, 24 May 93 08:34:23 MDT Received: from mail.bellcore.com by p.lanl.gov (5.65/1.14) id AA13098; Mon, 24 May 93 08:34:19 -0600 Received: from [128.96.90.196] (mac16.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA00715; Mon, 24 May 1993 10:31:09 -0400 Message-Id: <199305241431.AA00715@mail.bellcore.com> Date: Mon, 24 May 1993 10:41:18 -0500 To: tuba@lanl.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dave@mail.bellcore.com Subject: Re: final word on pseudo-header > OK, then you are suggesting something different than > what I believe we agreed to quite a while ago, (at Ross's insistence?), > which was to leave the selector field of the source NSAPA field > zero. I am quite comfortable having the selector set to PROTO value > in both addresses. Is everyone else implementing this way? Are we > happy with making this change to the clnp internet-draft? Ross, I made the change precisely because everyone was implementing NSEL=PROTO in SA/DA. IMHO, it's NBD. (Hmmmm... is that enough acronyms for one line, or not? --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) =======> I am now "dave@mail.bellcore.com"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24594; 24 May 93 10:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24590; 24 May 93 10:39 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa29736; 24 May 93 10:39 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA13207; Mon, 24 May 93 08:35:39 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24109; Mon, 24 May 93 08:34:20 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24105; Mon, 24 May 93 08:34:19 MDT Received: from mail.bellcore.com by p.lanl.gov (5.65/1.14) id AA13081; Mon, 24 May 93 08:34:16 -0600 Received: from [128.96.90.196] (mac16.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA00712; Mon, 24 May 1993 10:31:07 -0400 Message-Id: <199305241431.AA00712@mail.bellcore.com> Date: Mon, 24 May 1993 10:41:15 -0500 To: tuba@lanl.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dave@mail.bellcore.com Subject: final word on pseudo-header Dino sez... > There are two issues here: > > 1) Should the network layer use N-selectors to determine what > client/protocol gets the packet. > 2) When 1) is used should TCP/UDP use the N-selector in the > pseudo-header calculation. > > Dave's original note was a clarification of 2). You bring up 1). Well, now that you've brought us back to the original question, IS THE TEXT CORRECT? > One problem about moving away from 30-year old kludges is that today > people constantly ask "how can I filter FTAM packets". It can't be > done easily, is the answer. I favor well-known code-points. And there's always that small issue of "transition";-) --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) =======> I am now "dave@mail.bellcore.com"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24615; 24 May 93 10:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24611; 24 May 93 10:40 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa29779; 24 May 93 10:40 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA13233; Mon, 24 May 93 08:36:00 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24129; Mon, 24 May 93 08:34:39 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24125; Mon, 24 May 93 08:34:37 MDT Received: from mail.bellcore.com by p.lanl.gov (5.65/1.14) id AA13142; Mon, 24 May 93 08:34:32 -0600 Received: from [128.96.90.196] (mac16.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA00718; Mon, 24 May 1993 10:31:12 -0400 Message-Id: <199305241431.AA00718@mail.bellcore.com> Date: Mon, 24 May 1993 10:41:31 -0500 To: tuba@lanl.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dave@mail.bellcore.com Subject: Re: final word on pseudo-header Cyndi, you're wonderful! You've absolutely made my morning by reducing all this bantering over 8 bits to a single, tangible, meat-and-potatoes assertion... Thanks... >X-Station-Sent-From: eve.bellcore.com >Date: Mon, 17 May 1993 17:20:55 -0700 >From: "Cyndi M. Jung" >To: cmj@nsd.3com.com >Subject: Re: final word on pseudo-header >Cc: tuba@lanl.gov > > >There is something friendly about well-known numbers > > --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) =======> I am now "dave@mail.bellcore.com"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24626; 24 May 93 10:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24622; 24 May 93 10:40 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa29784; 24 May 93 10:40 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA13199; Mon, 24 May 93 08:35:23 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24100; Mon, 24 May 93 08:34:03 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24096; Mon, 24 May 93 08:34:02 MDT Received: from mail.bellcore.com by p.lanl.gov (5.65/1.14) id AA13059; Mon, 24 May 93 08:33:57 -0600 Received: from [128.96.90.196] (mac16.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA00706; Mon, 24 May 1993 10:30:48 -0400 Message-Id: <199305241430.AA00706@mail.bellcore.com> Date: Mon, 24 May 1993 10:40:57 -0500 To: tuba@lanl.gov Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dave@mail.bellcore.com Subject: Re: final word on pseudo-header Matt's reply to John's suggestion that we do not globalize NSEL for tuba... > >>> Managing what protocols are assigned to what addresses should be as much >>> a local matter as we can make it. It greatly decentralizes the operation >>> of the network. >> >>It also adds quite a bit of hair to the problem of setting up a >>network analyzer to, for example, "show me all the FTP traffic >>crossing this segment." John's retort... >Then we do spend a lot more time debugging these networks than we do >using them. > >John It's not merely a matter of debugging, John, we do a lot of traffic profiling and analysis of network utilization as well. (I was originally confused as to how one concludes one is doing FTP from NSEL, but I've assumed that Matt's looking first at IP-PROTO, then snooping in TCP and higher protocol segments...). --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) =======> I am now "dave@mail.bellcore.com"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25199; 24 May 93 11:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25193; 24 May 93 11:02 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa00986; 24 May 93 11:02 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA14712; Mon, 24 May 93 09:00:45 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24331; Mon, 24 May 93 09:00:12 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA24327; Mon, 24 May 93 09:00:11 MDT Received: from BBN.COM by p.lanl.gov (5.65/1.14) id AA14651; Mon, 24 May 93 09:00:09 -0600 Message-Id: <9305241500.AA14651@p.lanl.gov> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Day Subject: Re: final word on pseudo-header To: dave@mail.bellcore.com Cc: tuba@lanl.gov In-Reply-To: <199305241430.AA00706@mail.bellcore.com> Date: Mon, 24 May 93 11:01:28 EST Mail-System-Version: People, I will concede that there are advantages of using well-known addresses at the network layer and there aren't many protocols at the transport layer, so it is not a big deal. Although I believe it is a level administration that we could avoid. However, between transport and the application layer it can be quite a headache. It hasn't been because the internet hasn't had many applications. But in a real world production network there are going to be 1000s of application protocols many specific to various industry segments. Not only does this create unnecessary administrative overhead, but it requires everyone to allocate a well-known address for every application. Or more correctly not use certain addresses to avoid the inadvertent problems involved of applications connecting to addresses and not finding what they expected. Sure you could re-use them, but suppose you do and later discover you want to use that protocol, now a potentially large piece of your user community must be disturbed while you change the applications well-known address, etc. Well-known sockets were a nice expedient in 1971. They are no way to run a world-wide Internet. Take care, John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27570; 24 May 93 12:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27566; 24 May 93 12:54 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa07332; 24 May 93 12:54 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 24 May 93 12:53:07 EDT Received: from bridge2.NSD.3Com.COM by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 24 May 93 12:53:05 EDT Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA09597 (5.65c/IDA-1.4.4nsd for ); Mon, 24 May 1993 09:51:36 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA23243 (5.65c/IDA-1.4.4-910725); Mon, 24 May 1993 09:51:35 -0700 Message-Id: <199305241651.AA23243@remmel.NSD.3Com.COM> To: bsimpson@morningstar.com Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Subject: Re: SIP Addressing Limitations In-Reply-To: Your message of "Sun, 23 May 93 13:09:12 EDT." <1206.bill.simpson@um.cc.umich.edu> Date: Mon, 24 May 93 09:51:34 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: tracym@nsd.3com.com > Paul, in my view it's time for you to put up or shut up. Show me this > fine allocation plan of yours with: > > - a guaranteed set of constraints. > - a provable maximal routing table size. > - aggregates so that an international amateur radio operator sees a > very small table (< 256 entries, preferably < 10). > - scales on an inter-planetary basis. I take small exception to the last two features. Who cares that an international amateur radio operator using *today's* technology would have a very small routing table? I just don't see this as a technology driver. The phrase "scales on an inter-planetary basis," although probably true for anything we expect in the next 100 years (as far as interplanetary settlement is concerned), seems excessive. Usually scaling implies something like an order of magnitude or another level of hierarchy, but the "interplanetary" scaling here is a simple linear extension through the addition more population centers. The use of "interplanetary" seems like hype, to me. On the other hand, it is worthwhile simply to state that useful global routing can be accomplished with a relatively small routing table, and that there is plenty of room with the current addressing plan to extend geographically as well as numerically. Regards, Tracy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27659; 24 May 93 13:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27655; 24 May 93 13:05 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa08221; 24 May 93 13:05 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 24 May 93 13:03:50 EDT Received: from vela.acs.oakland.edu by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 24 May 93 13:03:46 EDT Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA23017 (5.65c+/IDA-1.4.4); Mon, 24 May 1993 13:02:00 -0400 Date: Mon, 24 May 93 11:52:05 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1211.bill.simpson@um.cc.umich.edu> To: Tony Li Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Reply-To: bsimpson@morningstar.com Subject: Re: SIP Addressing Limitations > Date: Sun, 23 May 1993 23:32:53 -0700 > From: Tony Li > > It amuses me greatly that there's anyone who still seriously > > believes that network topology, and geography, are even remotely > > related when it comes to international connections. > > Apparently I am in good company. With Rehkter, Li, and the CIDR luminaries. > > Excuse me, but you have misread all of CIDR if you believe that to be > true. > I was discombobulated and enervated to see this line from Tony. The plan is largely based on his previous writings. Apparently, having convinced me, he has repudiated his own previous thoughts. (Apologies to Rekhter for the typographical error.) In CIDR: 9. Recommendations The NIC should begin to hand out large blocks of class C addresses to network service providers. Each block must fall on bit boundaries and should be large enough to serve the provider for two years. Further, the NIC should distribute very large blocks to continental and national network service organizations to allow additional levels of aggregation to take place at the major backbone networks. Clearly says "continental and national". Of course, it advocates provider-based within that. My plan supports provider-based allocation, in addition to others. In TAP (p 2): As the network evolves, the topology, and necessarily the addressing, will also evolve. Thus, the addressing plan must also allow the flexibility to evolve. Further, political considerations also affect the addressing plan. For example, a single administration may control a certain aggregate and may wish to delegate sub-aggregates according to some particular scheme. Another administration performing the identical function may wish to use an entirely different scheme. The addressing plan must be able to support both. Thus my plan's requirement to support metropolitan, provider, and end-point assignment simultaneously, and follow political boundaries. In TAP (p 2): Aggregation in the addressing plan must be efficient and result in a small number of routing table entries within the hosts and routers on the network. ... Thus, an addressing plan should result in at most hundreds of aggregates in the common case, for all levels in the hierarchy combined. The basic division into countries meets the "hundreds" criteria, as well as the political criteria above. In TAP (p 4): Assigning the top level aggregates to large land masses aids the aggregation process in two ways. Since the top level aggregates are large, they describe significant portions of the address space. Entities which are topologically distant from a top level aggregate can perform aggregation to reduce routing table sizes as the distance from the top level increases. Performing aggregation where possible is very effective at localizing routing information to parts of the topology where it is most relevant. Since the natural divisions between large land masses constrain topology, they also provide natural locations to perform such aggregation. Experience with CIDR already has shown that continental aggregation is effective in containing routing table entropy [6,7,8]. Here is some of the argument for continental and regional aggregation. Note the reference to experience with CIDR. In TAP (p 5): As with other routing schemes that allow advertisement of aggregates, this scheme allows a single hierarchical level to be disconnected and to still retain connectivity by passing lower level routing information through the higher levels in the hierarchy. This introduces "noise" into the routing system and should be avoided where possible, but is sometimes unavoidable. The ability to advertise routes which are not aggregated is also sometimes useful when the topology As you can see, the draft peters out, so I'm not entirely sure where it is leading (probably an editting error when he submitted the draft). Note that my plan clearly allows for "noise". And has an explicit criterion that it continue to operate effectively when the noise is up to 10 times the base! As well as an intermediate "cluster" level between continents and countries to reduce noise at a regional level. I put in a lot of time reworking Steve Deering's straight list of countries (the original SIP plan) to meet Tony's ideas on continents, political contraints, and noise reduction. In designing those clusters, I researched current undersea cables, tropospheric scattering for telephone communications, regional participation in satellite television, etc. If you want to quibble about specifics, go ahead -- and cite your data. In the meantime, I'm pretty disgusted with a group that flames without reading the documents, and is revisionist about its own previous writing. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27880; 24 May 93 13:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27876; 24 May 93 13:27 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa09593; 24 May 93 13:27 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA28618; Mon, 24 May 93 11:26:17 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA25443; Mon, 24 May 93 11:25:46 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA25436; Mon, 24 May 93 11:25:44 MDT Received: from lobster.wellfleet.com by p.lanl.gov (5.65/1.14) id AA28574; Mon, 24 May 93 11:25:41 -0600 Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12900; Mon, 24 May 93 13:22:47 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA04317; Mon, 24 May 93 13:24:57 EDT Date: Mon, 24 May 93 13:24:57 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9305241724.AA04317@cabernet.wellfleet> To: kre@munnari.oz.au, perlman@radia.enet.dec.com Subject: Re: Thing I promised to write up about TUBA advantages. Cc: tuba@lanl.gov Date: Fri, 21 May 93 15:56:31 EDT From: perlman@radia.enet.dec.com Message-ID: <9305211955.AA29780@easynet.crl.dec.com> 1) 6 byte ID field: The CLNP address includes a 6 byte ID field. An end system which has a ROM with a guaranteed globally unique IEEE address Unfortunately its a fiction to believe that any IEEE address is globally unique, or even necessarily locally unique. It's only intended to be. We have, at present, no means to verify that manufacturers actually do assign unique IEEE addresses to workstations, either by design, or because no-one is infallible. Is this any different than IP addresses? Although IEEE addresses could in principle be erroneously assigned to be non-unique, I have not heard of this happening. In contrast, I have heard many cases of IP addresses being assigned erroneously. In the near future, we (the communications industry) are increasingly going to be selling data communications to non-technical folks. These folks are not going to have the same ability as university experts in configuring their systems (this is of course not limited to just addresses). I have more faith in a factory being able to assign unique ID values than I do in someone who can't configure their VCR at home being able to come into work and configuring their IP addresses to be unique (or, for that matter, being able to configure their home network). Do you have any suggestions regarding how to make address configuration easy for the future non-technical user? Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28108; 24 May 93 13:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28104; 24 May 93 13:38 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa09876; 24 May 93 13:38 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA29234; Mon, 24 May 93 11:37:04 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA25545; Mon, 24 May 93 11:36:43 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA25540; Mon, 24 May 93 11:36:42 MDT Received: from bells.cs.ucl.ac.uk by p.lanl.gov (5.65/1.14) id AA29213; Mon, 24 May 93 11:36:40 -0600 Message-Id: <9305241736.AA29213@p.lanl.gov> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 24 May 1993 18:34:13 +0100 To: Ross Callon Cc: kre@munnari.oz.au, perlman@radia.enet.dec.com, tuba@lanl.gov Subject: Re: Thing I promised to write up about TUBA advantages. In-Reply-To: Your message of "Mon, 24 May 93 13:24:57 EDT." <9305241724.AA04317@cabernet.wellfleet> Date: Mon, 24 May 93 18:34:07 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jon Crowcroft >Is this any different than IP addresses? Although IEEE addresses >could in principle be erroneously assigned to be non-unique, I have >not heard of this happening. In contrast, I have heard many cases >of IP addresses being assigned erroneously. precisely - but if you do this on an IP host (normal naive case), because the IP address is hierarchical, you only hurt people near you - and people who configure routers and might do more damage _are_ experts however, with a flat ID like a ieee address, you could configure a host in eastbourne to be the same as the main router for Japan - then you get security systems shuting the nikkei down (thats what most duplicate ip host detectors do, so i assume the same would apply:-) jon   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28626; 24 May 93 13:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28622; 24 May 93 13:57 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10645; 24 May 93 13:57 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 24 May 93 13:55:51 EDT Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 24 May 93 13:54:58 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for tuba@lanl.gov; Mon, 24 May 93 13:54:58 EDT Date: Mon, 24 May 93 13:54:58 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Paul Francis (formerly Paul Tsuchiya" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Message-Id: <9305241754.AA00917@tsuchiya.bellcore.com> To: bsimpson@morningstar.com, francis@thumper.bellcore.com Subject: Re: SIP Addressing Limitations Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov > > > > hosts), the SIP address could handle 10^12 hosts if it acheived > > about 2% efficiency per level of hierarchy. By 2% efficiency > > I mean that 2% of the possible address assignments (per level) > > are actually assigned. > > > Then you will be glad to have read: > > While at first glance this may appear to be 89% efficiency in > allocation, it is noted below that the two largest countries are > assigned only half their proper allocation. The actual efficiency > is closer to 60%, .... I wondered about this. What do you mean by 60% efficiency? I think it is impossible to talk about efficiency until you start really loading up an address space. For instance, if China and the existing third world stayed technologically poor for the next 20 years, while first world countries starting using some new technology that resulted in enormous numbers of address assignments, then your efficiency measure for those portions of the address assigned to third world countries would have low efficiency...... > > Paul, in my view it's time for you to put up or shut up. Show me this > fine allocation plan of yours with: > > - a guaranteed set of constraints. > - a provable maximal routing table size. > - aggregates so that an international amateur radio operator sees a > very small table (< 256 entries, preferably < 10). > - scales on an inter-planetary basis. > > And is: > > - easy to administer. > - amenable of politics. > - supports metro, provider, and end-point allocation simultanously. > - has a firm rationale for each division. > - supports efficient distributed access. > - aggregates better as the network grows. > I can't claim to have a plan that has all of these attributes, and I would argue that you don't either. I like provider-based addressing because it doesn't depend on the topology of providers, because I think it scales well over the near term, and because the provider numbers can be used as a hook for provider selection. I like Pip addressing because you don't have to go through the exercise you went for for SIP addresses--each level of the hierarchy carried explicitly in the packet so you don't have to worry about running out of space in one part of the hierarchy or another. I think it is virtually impossible to avoid widespread and periodic number reassignments in any scheme, and I don't even try. Rather, Pip strives to make number re-assignment as automatic and painless as possible. The SIP people are going to provide this for SIP as far as I know. It is mainly because of this that I don't object to much to the SIP addressing scheme (I don't mean your particular allocation--I mean 64-bits in general). That is, provided they have automatic prefix assignment, it will be possible to change the addressing scheme over time. > Otherwise, give me *contructive* criticism for my plan. > For what your plan purports to do, it seems to do a good job. You have set out to come up with a numbering plan that allows for onion-skins of aggregation based on geographic/political closenss. You seem to have done a nice job of it. I just generally disagree with your premise--that geographic/political closeness is of primary interest. As this discussion has already been had, I will shut-up..... PX   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28762; 24 May 93 14:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28754; 24 May 93 14:00 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa10740; 24 May 93 14:00 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA00529; Mon, 24 May 93 11:57:31 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA25791; Mon, 24 May 93 11:57:01 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA25787; Mon, 24 May 93 11:57:00 MDT Received: from lobster.wellfleet.com by p.lanl.gov (5.65/1.14) id AA00510; Mon, 24 May 93 11:56:59 -0600 Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13028; Mon, 24 May 93 13:54:16 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA04359; Mon, 24 May 93 13:56:26 EDT Date: Mon, 24 May 93 13:56:26 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9305241756.AA04359@cabernet.wellfleet> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: Thing I promised to write up about TUBA advantages. Cc: tuba@lanl.gov >Is this any different than IP addresses? Although IEEE addresses >could in principle be erroneously assigned to be non-unique, I have >not heard of this happening. In contrast, I have heard many cases >of IP addresses being assigned erroneously. precisely - but if you do this on an IP host (normal naive case), because the IP address is hierarchical, you only hurt people near you - and people who configure routers and might do more damage _are_ experts however, with a flat ID like a ieee address, you could configure a host in eastbourne to be the same as the main router for Japan - then you get security systems shuting the nikkei down (thats what most duplicate ip host detectors do, so i assume the same would apply:-) Jon; This depends upon what you are using the ID for. If you *only* use it to simplify address autoconfiguration (which is the current idea), then if you mess up and assign a non-unique ID then this is only a problem if another system with the same ID happens to be on the same network. Even then this is only a problem for the two systems on the same network who's IDs happen to clash. With current CLNP addressing the IDs need to be unique in an area, and an area could optionally be a bit larger than a single physical subnet. However, the problem is still contained to a single area. Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29129; 24 May 93 14:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29125; 24 May 93 14:13 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa11018; 24 May 93 14:13 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA01295; Mon, 24 May 93 12:10:17 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA25862; Mon, 24 May 93 12:05:55 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA25858; Mon, 24 May 93 12:05:54 MDT Received: from gosip.net.ohio.gov by p.lanl.gov (5.65/1.14) id AA01014; Mon, 24 May 93 12:05:53 -0600 Received: from gosip.net.ohio.gov by gosip.net.ohio.gov (PMDF #3232 ) id <01GYK0MQUVHS000NRP@gosip.net.ohio.gov>; Mon, 24 May 1993 14:02:18 EDT Date: 24 May 1993 14:02:18 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: warner@ohio.gov Subject: Re: Thing I promised to write up about TUBA advantages. To: tuba@lanl.gov Message-Id: <01GYK0MQUVHU000NRP@gosip.net.ohio.gov> X-Vms-To: IN%"tuba@lanl.gov" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT IN%"kre@munnari.OZ.AU" "Robert Elz" 21-MAY-1993 23:11:15.14 responds to: >> Aside from the convenience of not having to configure >> addresses, either into the end system or into some sort >> of boot server, With >In any case, I don't actually agree that this is really a >convenience. Not having to configure addresses in the end >system itself is certainly a win, but having them simply >appear on the network without any pre-configuration is not >something I really want to happen, I want to know what systems >are appearing on my net, and I don't want them to be able to >work until they are correctly configured (somwehere). Editing >one file to allocate an address (it needs to go in a directory >somewhere anyway) is not a huge burden. I know that much of >the claimed simplicity of appletalk is that it does allow >anyone to connect anywhere without pre-arrangement (including >using an address verification protocol to make reasonably sure >the address is unique) - its also what makes appletalk one of >the most painful networks to diagnose problems on, its almost >impossible to work out just which node it is that is causing a >problem without physically visiting every one to disconnect >them and find which makes the problem go away - its only the >small scale of appletalk nets that makes them work at all. Once network devices are as common as light bulb, it will be very annoying to have to update a file everytime you replace on! In future networks I do not think we will want to maintain large tables of information for directories. At least I don't! Hopefully the hosts themselves will inform the directory servers and register the services that they are able and willing to provide for others on the network. For example, when I plug my toaster in the power/network socket on the wall, it would find a directory server and register "Toast Services" on the network (Plus maybe find the "fire alarm server" in case it needs to tell someone the toast is a little over done.) There is one big advantage of the address allocation scheme proposed versus one similiar to Appletalk. If the same host will autoconfigure the same address each time, unless it is moved or is given a new EID. As you know in Appletalk this is not the case! I am almost finished with the draft describing the autoconfiguration mechanism that I promised to write at the Columbus IETF. I have a few minor issues I need to work out and hope to send it out the tuba list this week for comments. See ya, ww3 ---- William Warner, III (N8HJP) +1 614 644 3349 FAX State of Ohio - Telecommunications +1 614 466 6683 2151 Carmack Ave Call Toll Free in Ohio: dial 950-1OHI Columbus, Ohio 43221 then at the tone, dial 6-6683.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29714; 24 May 93 14:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29703; 24 May 93 14:33 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa11923; 24 May 93 14:33 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA02322; Mon, 24 May 93 12:30:26 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA26240; Mon, 24 May 93 12:29:44 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA26236; Mon, 24 May 93 12:29:43 MDT Received: from ftp.com by p.lanl.gov (5.65/1.14) id AA02265; Mon, 24 May 93 12:29:39 -0600 Received: by ftp.com id AA18864; Mon, 24 May 93 14:28:28 -0400 Date: Mon, 24 May 93 14:28:28 -0400 Message-Id: <9305241828.AA18864@ftp.com> To: rcallon@cabernet.wellfleet.com Subject: Re: Thing I promised to write up about TUBA advantages. Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: kre@munnari.oz.au, perlman@radia.enet.dec.com, tuba@lanl.gov > Unfortunately its a fiction to believe that any IEEE address > is globally unique, or even necessarily locally unique. It's > only intended to be. We have, at present, no means to verify > that manufacturers actually do assign unique IEEE addresses to > workstations, either by design, or because no-one is > infallible. > > Is this any different than IP addresses? Although IEEE addresses > could in principle be erroneously assigned to be non-unique, I have > not heard of this happening. In contrast, I have heard many cases > of IP addresses being assigned erroneously. Ross, Sorry to say, it has happened. A large vendor of enet cards screwed up a few years ago and instead of having each prom containing a different address..... Unfortunately, fixing this mistake is much harder than fixing a duplicate IP address (you can not simply edit a file). At the very least, it would require a PROM change on the enet adaptor. If the prom is not socketed then you have to replace the board (and if that board is also a system mother board....) or get out a soldering iron. You could simply program the enet chip to accept a different address, but how many people's software does that? Even if your software does this, you might lose since I recall that one common chip or adapter card (I do not recall which one, or the manufacturer) operates much much much slower when using a software-set enet address... > In the near future, we (the communications industry) are increasingly > going to be selling data communications to non-technical folks. These > folks are not going to have the same ability as university experts in > configuring their systems (this is of course not limited to just > addresses). I have more faith in a factory being able to assign unique > ID values than I do in someone who can't configure their VCR at home > being able to come into work and configuring their IP addresses to be > unique (or, for that matter, being able to configure their home > network). No argument here. However, the point that we should consider is that 802 numbers might have some flaws and we should know what those flaws are before settling on them as "The Answer" (trumpet fanfare in the background :-) -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00245; 24 May 93 14:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00236; 24 May 93 14:48 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa12435; 24 May 93 14:48 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA02912; Mon, 24 May 93 12:45:47 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA26357; Mon, 24 May 93 12:45:18 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA26353; Mon, 24 May 93 12:45:18 MDT Received: from LOBSTER.WELLFLEET.COM by p.lanl.gov (5.65/1.14) id AA02895; Mon, 24 May 93 12:45:17 -0600 Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13325; Mon, 24 May 93 14:42:30 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA04425; Mon, 24 May 93 14:44:41 EDT Date: Mon, 24 May 93 14:44:41 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ross Callon Message-Id: <9305241844.AA04425@cabernet.wellfleet> To: tuba@lanl.gov, warner@ohio.gov Subject: Re: Thing I promised to write up about TUBA advantages. Hopefully the hosts themselves will inform the directory servers and register the services that they are able and willing to provide for others on the network. For example, when I plug my toaster in the power/network socket on the wall, it would find a directory server and register "Toast Services" on the network (Plus maybe find the "fire alarm server" in case it needs to tell someone the toast is a little over done.) William; This is not a far fetched example at all. I have already seen a house which is entirely wired with a combined power/network infrastructure, with power, data, voice, and video over the wire. Admittedly this is a rather early prototype house, but a network in every home with toasters and thermostats on the network is a lot more real today than a local net in every large office building was 14 years ago (when I got into this business). And yes, the house did indeed have fire alarms on the network. As an active gardener, I was a bit disappointed to see that they did not *yet* have greenhouse alarms built in (so that you can be notified when the greenhouse temperature goes below 33 in the middle of the night), but the fellow who lived in the house did have plans to put this in. I think that it would be madness to design a new network infrastructure today which would either preclude an Internet including a network in every home, or expect "normal folks" to manually configure their home network. Ross   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01571; 24 May 93 16:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01567; 24 May 93 16:12 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa15665; 24 May 93 16:12 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA07517; Mon, 24 May 93 14:10:21 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA27513; Mon, 24 May 93 14:09:13 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA27509; Mon, 24 May 93 14:09:11 MDT Received: from regal.cisco.com by p.lanl.gov (5.65/1.14) id AA07380; Mon, 24 May 93 14:09:12 -0600 Received: by regal.cisco.com; Mon, 24 May 1993 13:07:55 -0700 Date: Mon, 24 May 1993 13:07:55 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dino Farinacci Message-Id: <199305242007.AA09570@regal.cisco.com> To: dave@mail.bellcore.com Cc: tuba@lanl.gov In-Reply-To: dave@mail.bellcore.com's message of Mon, 24 May 1993 10:41:15 -0500 <199305241431.AA00712@mail.bellcore.com> Subject: final word on pseudo-header >> Well, now that you've brought us back to the original question, >> IS THE TEXT CORRECT? The following text is in the January 6th draft: To compute the checksum on a UDP or TCP segment prior to transmission, implementations must compose a pseudo-header to the UDP/TCP segment consisting of the following information that will be used when composing the CLNP datagram: o+ Destination Address Length Indicator o+ Destination Address and PROTO o+ Source Address Length Indicator o+ Source Address and Reserved ------------------------------------------------------------------------ It is implied that the protocol value is used twice, once in the destination N-selector and once in the source N-selector. So it is correct but not explicitly clear. Also, the cisco implementation performs the checksum in the following order: Destination Address Length Indicator Destination Address (including N-selector) Source Address Length Indicator Source Address (including N-selector) Protocol number in a 16-bit field UDP/TCP Segment Length in a 16-bit field Your diagram needs correction because the 16-bit PROTO field is between the destination and source addresses. As I mentioned before the ordering is important when using variable length addresses (especially when the destination NSAP is a odd number of octets). I believe the diagram and the itemized list of fields should be changed to reflect the above order. Dino   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01834; 24 May 93 16:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01828; 24 May 93 16:24 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16168; 24 May 93 16:24 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 24 May 93 16:23:39 EDT Received: from lager.cisco.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 24 May 93 16:23:35 EDT Received: by lager.cisco.com; Mon, 24 May 1993 13:21:39 -0700 Date: Mon, 24 May 1993 13:21:39 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199305242021.AA15990@lager.cisco.com> To: bsimpson@morningstar.com Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov In-Reply-To: "William Allen Simpson"'s message of Mon, 24 May 93 11:52:05 EDT <1211.bill.simpson@um.cc.umich.edu> Subject: SIP Addressing Limitations > > It amuses me greatly that there's anyone who still seriously > > believes that network topology, and geography, are even remotely > > related when it comes to international connections. > > Apparently I am in good company. With Rehkter, Li, and the > CIDR luminaries. > > Excuse me, but you have misread all of CIDR if you believe that to be > true. > I was discombobulated and enervated to see this line from Tony. The plan is largely based on his previous writings. Apparently, having convinced me, he has repudiated his own previous thoughts. Bill, You're missing something here. Topology is NOT tied to international connections. The concept of "international" is a political concept that has limited bearing on the problem in that it affects the cost of links. Topology seems to be currently (and may continue to be) affected by significant geographical constraints, such as oceans. The concept of "addressing" must be tied to topology for aggregation to provide useful results for IPv4. However, "address administration" is primarily a political problem. As such, it is indeed (unfortunately) tied to international constraints. Thus, the body performing the administration is political, but the addresses being administered are topologically assigned. I think that you need to be very clear on the difference between politically based addressing and politically based address administration. The former is foolish. The latter is an unfortunate necessity. In any case, any statement to the effect that I agree with ANY facet of your addressing plan, or any thoughts or philosophy in constructing it is at best wildly erroneous. As you can see, the draft peters out, so I'm not entirely sure where it is leading (probably an editting error when he submitted the draft). Your copy is corrupt. The version that I have via shadowed anonymous FTP is complete. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04117; 24 May 93 18:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04113; 24 May 93 18:30 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa20823; 24 May 93 18:30 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA16637; Mon, 24 May 93 16:27:49 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA28755; Mon, 24 May 93 16:27:25 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA28751; Mon, 24 May 93 16:27:25 MDT Received: from bridge2.NSD.3Com.COM by p.lanl.gov (5.65/1.14) id AA16616; Mon, 24 May 93 16:27:25 -0600 Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA22890 (5.65c/IDA-1.4.4nsd for ); Mon, 24 May 1993 15:27:24 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA23598 (5.65c/IDA-1.4.4-910725 for ); Mon, 24 May 1993 15:27:22 -0700 Message-Id: <199305242227.AA23598@remmel.NSD.3Com.COM> To: tuba@lanl.gov Subject: Oldies but goodies - TUBA psuedo-header Date: Mon, 24 May 93 15:27:21 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: tracym@nsd.3com.com Dave/list: Here's the first of two old messages from the list. Among other things, I want to make sure that the pad octet, used when the source and destination addresses do not add up to an even number of octets, does not get lost. Tracy ------- Forwarded Message Date: Fri, 5 Feb 93 12:47:48 EST Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9302051747.AA09401@emu.ncsl.nist.gov> To: dave@mail.bellcore.com Subject: Re: let's close the book on tuba pseudo-header... Cc: tuba@lanl.gov, colella@nist.gov From: colella@nist.gov Dave, This is what I implemented (after talking to Keith). Just to make sure we are all on the same sheet, there is one point that doesn't show up in your picture. If the length of the {dst addr len + dst addr + src addr len + src addr} is an odd number of octets, then an additional pad octet of zero is inserted between the end of the src addr and the PAD (zero) field. This will result in two pad octets in some cases, but maintains the separation between the "addresses part" of the pseudo header and the rest. There's also Dino's comment that an odd number of nibbles must be padded out to an octet boundary (my code doesn't handle NSAPs with odd numbers of nibbles, but we ought to give the correct behavior so others will do it right). > From tuba-request@noc-gw.lanl.gov Fri Feb 5 10:42:53 1993 > Date: Fri, 5 Feb 93 10:41:34 -0500 > From: David M. Piscitello > To: tuba@lanl.gov > Subject: let's close the book on tuba pseudo-header... > Content-Length: 2114 > > Keith, based on your "clarification", is this the correct pseudo-header > layout? If not, post the data structure... > > Rich, does this differ from what you've implemented? > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Dest Addr Len | Destination Address... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Destination Address... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Destination Address... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Destination Address... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Destination Address... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Dest Address | Src Addr Len | Source Address... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Source Address... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Source Address... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Source Address... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Source Address... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... Source Address | PAD (zero) | PROTO | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | UDP/TCP segment length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > CLNP for TUBA: Figure 5-1. Pseudo-header > > ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04151; 24 May 93 18:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04147; 24 May 93 18:34 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa20885; 24 May 93 18:34 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA16842; Mon, 24 May 93 16:32:00 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA28777; Mon, 24 May 93 16:31:37 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA28773; Mon, 24 May 93 16:31:36 MDT Received: from bridge2.NSD.3Com.COM by p.lanl.gov (5.65/1.14) id AA16810; Mon, 24 May 93 16:31:36 -0600 Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA23082 (5.65c/IDA-1.4.4nsd for ); Mon, 24 May 1993 15:31:34 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA23613 (5.65c/IDA-1.4.4-910725 for ); Mon, 24 May 1993 15:31:33 -0700 Message-Id: <199305242231.AA23613@remmel.NSD.3Com.COM> To: tuba@lanl.gov Subject: Oldies - 2 Date: Mon, 24 May 93 15:31:33 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: tracym@nsd.3com.com (The "original" summary message;-) ------- Forwarded Message Date: Wed, 10 Feb 93 20:13:16 -0500 Message-Id: <9302110113.AA12762@worldlink.worldlink.com> From: David Piscitello To: tuba@lanl.gov Subject: Closure on Pseudoheader--check it out! Hi, I'm here with Dino and we've come to closure w/r/t the pseudoheader. Here is the layout we believe is correct and consistent with the TCP RFC. Destination LI - one octet Dest Address - "LI" number of octets, up to 20, includes PROTO/NSEL Source LI - one octet Source Address - "LI" number of octets, up to 20, includes PROTO/NSEL if the sum of the lengths of these fields is an odd number of octets, a one octet PAD containing binary zeroes is present. PROTO - two octets (the clnp/tuba draft shows one, this is an error) UDP/TCP segment length - two octets This, we understand, is consistent with the interpretation that SIP has applied to their pseudo-header. ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04176; 24 May 93 18:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04172; 24 May 93 18:44 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa21068; 24 May 93 18:44 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA17576; Mon, 24 May 93 16:42:54 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA28833; Mon, 24 May 93 16:42:34 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA28829; Mon, 24 May 93 16:42:33 MDT Received: from vangogh.CS.Berkeley.EDU by p.lanl.gov (5.65/1.14) id AA17560; Mon, 24 May 93 16:42:33 -0600 Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (ALPHA-6.61/6.28) id PAA03508; Mon, 24 May 1993 15:40:57 -0700 Date: Mon, 24 May 1993 15:40:57 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199305242240.PAA03508@vangogh.CS.Berkeley.EDU> To: tuba@lanl.gov Subject: re: final word on pseudo-header Cc: dave@mail.bellcore.com, dino@cisco.com Although this may sound different, I believe that Dino & I aggree on the quantity to be computed. An alternative way of describing the checksum calculation is to say that you start with the pseudo- header for a TCP/UDP packet and replace the 8 bytes of src and destination IP address, by the destination and source address portion of the CLNP packet, possibly extended to even length by a zero byte of padding. In the January 6th Draft, Dave indeed writes: To compute the checksum on a UDP or TCP segment prior to transmission, implementations must compose a pseudo-header to the UDP/TCP segment consisting of and later also writes: If needed, an octet of zero is added to the end of the UDP/TCP segment to pad the datagram to a length that is a multiple of 16 bits. In all other respects, rules for computing the checksum are consistent with RFC 793 and RFC 768. I would suggest that "prepend to" is more clear and in more common use than "compose to" (although admittedly less literate). There is also an octet of zero padding to be inserted **BEFORE** the UDP/TCP segment length in the case that the sum of the lengths of the source and destination NSAPs is odd. It would be worthwhile 'fessing up to the fact that the proto value is used **THREE** times in the combined header (as part of the src NSEL, dst NSEL, and proto field). This is completely unambiguous. The proto field must also be explicitly included if the diagram is to be drawn in this way, since it is not part of the UDP or TCP headers. However, I think that the document would be easier to read, although more tiresome to draw if at least the entire combined TCP pseudo header were shown, rather than just the equivalent to the IP-pseudo header replacement.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08477; 24 May 93 23:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08473; 24 May 93 23:04 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa26872; 24 May 93 23:04 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA26673; Mon, 24 May 93 21:02:29 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29526; Mon, 24 May 93 21:01:25 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29522; Mon, 24 May 93 21:01:24 MDT Received: from newt.phys.unsw.EDU.AU by p.lanl.gov (5.65/1.14) id AA26649; Mon, 24 May 93 21:01:20 -0600 Received: by newt.phys.unsw.edu.au (5.65/DEC-Ultrix/4.3) id AA04734; Tue, 25 May 1993 13:01:12 +1000 Message-Id: <9305250301.AA04734@newt.phys.unsw.edu.au> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Paul W. Brooks esq." Date: Tue, 25 May 1993 13:01:12 EST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: tuba@lanl.gov Subject: Duplicated IEEE addresses (was Re: Thing I promised to write up about Thus expounded Frank Kastenholz on May 24, 2:28pm: /-------------------- | > Unfortunately its a fiction to believe that any IEEE address | > is globally unique, or even necessarily locally unique. It's | > only intended to be. We have, at present, no means to verify | > that manufacturers actually do assign unique IEEE addresses to | > workstations, either by design, or because no-one is | > infallible. | > | > Is this any different than IP addresses? Although IEEE addresses | > could in principle be erroneously assigned to be non-unique, I have | > not heard of this happening. In contrast, I have heard many cases | > of IP addresses being assigned erroneously. | |Ross, | |Sorry to say, it has happened. A large vendor of enet cards screwed up |a few years ago and instead of having each prom containing a different |address..... Not to menton some of the 'clone' ethernet card builders. We bought two 'NE2000 compatible' cards from a Taiwanese company - they had the first three byte vendor prefix all zeros. When I asked if this was 'legal' they replied "so what prefix would you like in your cards next time? You can have any hardware address you like.." -- Paul Brooks |Internet: pwb@newt.phys.unsw.edu.au Uni. of N.S.W. | paul@abccomp.oz.au Kensington NSW 2033| AUSTRALIA | Microwave ovens: God's gift to bachelors   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00441; 25 May 93 5:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00437; 25 May 93 5:50 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa01772; 25 May 93 5:50 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA00696; Tue, 25 May 93 01:35:31 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29965; Tue, 25 May 93 01:35:04 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29961; Tue, 25 May 93 01:35:03 MDT Received: from dnlts0_e.research.ptt.nl by p.lanl.gov (5.65/1.14) id AA00682; Tue, 25 May 93 01:35:00 -0600 Received: from research.ptt.nl by research.ptt.nl (PMDF #2928 ) id <01GYL639UK0EBJWVG8@research.ptt.nl>; Tue, 25 May 1993 09:36:02 +0200 Date: 25 May 1993 09:36:02 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ALEX REIJNIERSE Subject: TUBA demonstration document JENC93 - portrait To: tuba@lanl.gov Cc: wg4-clns@funet.fi, sn3plus-clns@surfnet.nl Message-Id: <01GYL639UK00BJWVG8@research.ptt.nl> Organization: PTT Research, The Netherlands X-Envelope-To: tuba@lanl.gov X-Vms-To: IN%"tuba@lanl.gov" X-Vms-Cc: IN%"wg4-clns@funet.fi", IN%"sn3plus-clns@surfnet.nl" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Comments: This mail was sent by PMDF V4.1 %!PS-Adobe-3.0 EPSF-2.0 %%Creator: Windows PSCRIPT %%Title: Microsoft Word - TUBA-PIC.DOC %%BoundingBox: 18 10 577 825 %%DocumentNeededResources: (atend) %%DocumentSuppliedResources: (atend) %%Pages: 0 %%BeginResource: procset Win35Dict 3 1 /Win35Dict 290 dict def Win35Dict begin/bd{bind def}bind def/in{72 mul}bd/ed{exch def}bd/ld{load def}bd/tr/translate ld/gs/gsave ld/gr /grestore ld/M/moveto ld/L/lineto ld/rmt/rmoveto ld/rlt/rlineto ld /rct/rcurveto ld/st/stroke ld/n/newpath ld/sm/setmatrix ld/cm/currentmatrix ld/cp/closepath ld/ARC/arcn ld/TR{65536 div}bd/lj/setlinejoin ld/lc /setlinecap ld/ml/setmiterlimit ld/sl/setlinewidth ld/scignore false def/sc{scignore{pop pop pop}{0 index 2 index eq 2 index 4 index eq and{pop pop 255 div setgray}{3{255 div 3 1 roll}repeat setrgbcolor}ifelse}ifelse}bd /FC{bR bG bB sc}bd/fC{/bB ed/bG ed/bR ed}bd/HC{hR hG hB sc}bd/hC{ /hB ed/hG ed/hR ed}bd/PC{pR pG pB sc}bd/pC{/pB ed/pG ed/pR ed}bd/sM matrix def/PenW 1 def/iPen 5 def/mxF matrix def/mxE matrix def/mxUE matrix def/mxUF matrix def/fBE false def/iDevRes 72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt def/fPP false def/SS{fPP{ /SV save def}{gs}ifelse}bd/RS{fPP{SV restore}{gr}ifelse}bd/EJ{gsave showpage grestore}bd/#C{userdict begin/#copies ed end}bd/FEbuf 2 string def/FEglyph(G )def/FE{1 exch{dup 16 FEbuf cvrs FEglyph exch 1 exch putinterval 1 index exch FEglyph cvn put}for}bd/SM{/iRes ed/cyP ed /cxPg ed/cyM ed/cxM ed 72 100 div dup scale dup 0 ne{90 eq{cyM exch 0 eq{cxM exch tr -90 rotate -1 1 scale}{cxM cxPg add exch tr +90 rotate}ifelse}{cyP cyM sub exch 0 ne{cxM exch tr -90 rotate}{cxM cxPg add exch tr -90 rotate 1 -1 scale}ifelse}ifelse}{pop cyP cyM sub exch 0 ne{cxM cxPg add exch tr 180 rotate}{cxM exch tr 1 -1 scale}ifelse}ifelse 100 iRes div dup scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itransform translate}bd/SJ{1 index 0 eq{pop pop/fBE false def}{1 index/Break ed div/dxBreak ed/fBE true def}ifelse}bd/ANSIVec[ 16#0/grave 16#1/acute 16#2/circumflex 16#3/tilde 16#4/macron 16#5/breve 16#6/dotaccent 16#7/dieresis 16#8/ring 16#9/cedilla 16#A/hungarumlaut 16#B/ogonek 16#C/caron 16#D/dotlessi 16#27/quotesingle 16#60/grave 16#7C/bar 16#82/quotesinglbase 16#83/florin 16#84/quotedblbase 16#85 /ellipsis 16#86/dagger 16#87/daggerdbl 16#88/circumflex 16#89/perthousand 16#8A/Scaron 16#8B/guilsinglleft 16#8C/OE 16#91/quoteleft 16#92/quoteright 16#93/quotedblleft 16#94/quotedblright 16#95/bullet 16#96/endash 16#97 /emdash 16#98/tilde 16#99/trademark 16#9A/scaron 16#9B/guilsinglright 16#9C/oe 16#9F/Ydieresis 16#A0/space 16#A1/exclamdown 16#A4/currency 16#A5/yen 16#A6/brokenbar 16#A7/section 16#A8/dieresis 16#A9/copyright 16#AA/ordfeminine 16#AB/guillemotleft 16#AC/logicalnot 16#AD/hyphen 16#AE/registered 16#AF/macron 16#B0/degree 16#B1/plusminus 16#B2/twosuperior 16#B3/threesuperior 16#B4/acute 16#B5/mu 16#B6/paragraph 16#B7/periodcentered 16#B8/cedilla 16#B9/onesuperior 16#BA/ordmasculine 16#BB/guillemotright 16#BC/onequarter 16#BD/onehalf 16#BE/threequarters 16#BF/questiondown 16#C0/Agrave 16#C1/Aacute 16#C2/Acircumflex 16#C3/Atilde 16#C4/Adieresis 16#C5/Aring 16#C6/AE 16#C7/Ccedilla 16#C8/Egrave 16#C9/Eacute 16#CA /Ecircumflex 16#CB/Edieresis 16#CC/Igrave 16#CD/Iacute 16#CE/Icircumflex 16#CF/Idieresis 16#D0/Eth 16#D1/Ntilde 16#D2/Ograve 16#D3/Oacute 16#D4 /Ocircumflex 16#D5/Otilde 16#D6/Odieresis 16#D7/multiply 16#D8/Oslash 16#D9/Ugrave 16#DA/Uacute 16#DB/Ucircumflex 16#DC/Udieresis 16#DD/Yacute 16#DE/Thorn 16#DF/germandbls 16#E0/agrave 16#E1/aacute 16#E2/acircumflex 16#E3/atilde 16#E4/adieresis 16#E5/aring 16#E6/ae 16#E7/ccedilla 16#E8 /egrave 16#E9/eacute 16#EA/ecircumflex 16#EB/edieresis 16#EC/igrave 16#ED/iacute 16#EE/icircumflex 16#EF/idieresis 16#F0/eth 16#F1/ntilde 16#F2/ograve 16#F3/oacute 16#F4/ocircumflex 16#F5/otilde 16#F6/odieresis 16#F7/divide 16#F8/oslash 16#F9/ugrave 16#FA/uacute 16#FB/ucircumflex 16#FC/udieresis 16#FD/yacute 16#FE/thorn 16#FF/ydieresis ] def/reencdict 12 dict def/IsChar{basefontdict/CharStrings get exch known}bd/MapCh{dup IsChar not{pop/bullet}if newfont/Encoding get 3 1 roll put}bd/MapDegree{16#b0 /degree IsChar{/degree}{/ring}ifelse MapCh}bd/MapBB{16#a6/brokenbar IsChar{/brokenbar}{/bar}ifelse MapCh}bd/ANSIFont{reencdict begin/newfontname ed/basefontname ed FontDirectory newfontname known not{/basefontdict basefontname findfont def/newfont basefontdict maxlength dict def basefontdict{exch dup/FID ne{dup/Encoding eq{exch dup length array copy newfont 3 1 roll put}{exch newfont 3 1 roll put}ifelse}{pop pop}ifelse}forall newfont /FontName newfontname put 127 1 159{newfont/Encoding get exch/bullet put}for ANSIVec aload pop ANSIVec length 2 idiv{MapCh}repeat MapDegree MapBB newfontname newfont definefont pop}if newfontname end}bd/SB{FC /ULlen ed/str ed str length fBE not{dup 1 gt{1 sub}if}if/cbStr ed /dxGdi ed/y0 ed/x0 ed str stringwidth dup 0 ne{/y1 ed/x1 ed y1 y1 mul x1 x1 mul add sqrt dxGdi exch div 1 sub dup x1 mul cbStr div exch y1 mul cbStr div}{exch abs neg dxGdi add cbStr div exch}ifelse/dyExtra ed/dxExtra ed x0 y0 M fBE{dxBreak 0 BCh dxExtra dyExtra str awidthshow}{dxExtra dyExtra str ashow}ifelse fUL{x0 y0 M dxUL dyUL rmt ULlen fBE{Break add}if 0 mxUE transform gs rlt cyUL sl [] 0 setdash st gr}if fSO{x0 y0 M dxSO dySO rmt ULlen fBE{Break add}if 0 mxUE transform gs rlt cyUL sl [] 0 setdash st gr}if n/fBE false def}bd/font{/name ed/Ascent ed 0 ne/fT3 ed 0 ne/fSO ed 0 ne/fUL ed/Sy ed/Sx ed 10.0 div/ori ed -10.0 div/esc ed/BCh ed name findfont/xAscent 0 def/yAscent Ascent def/ULesc esc def ULesc mxUE rotate pop fT3{/esc 0 def xAscent yAscent mxUE transform /yAscent ed/xAscent ed}if [Sx 0 0 Sy neg xAscent yAscent] esc mxE rotate mxF concatmatrix makefont setfont [Sx 0 0 Sy neg 0 Ascent] mxUE mxUF concatmatrix pop fUL{currentfont dup/FontInfo get/UnderlinePosition known not{pop/Courier findfont}if/FontInfo get/UnderlinePosition get 1000 div 0 exch mxUF transform/dyUL ed/dxUL ed}if fSO{0 .3 mxUF transform /dySO ed/dxSO ed}if fUL fSO or{currentfont dup/FontInfo get/UnderlineThickness known not{pop/Courier findfont}if/FontInfo get/UnderlineThickness get 1000 div Sy mul/cyUL ed}if}bd/min{2 copy gt{exch}if pop}bd/max{2 copy lt{exch}if pop}bd/CP{/ft ed{{ft 0 eq{clip}{eoclip}ifelse}stopped{currentflat 1 add setflat}{exit}ifelse}loop}bd/patfont 10 dict def patfont begin /FontType 3 def/FontMatrix [1 0 0 -1 0 0] def/FontBBox [0 0 16 16] def/Encoding StandardEncoding def/BuildChar{pop pop 16 0 0 0 16 16 setcachedevice 16 16 false [1 0 0 1 .25 .25]{pat}imagemask}bd end/p{ /pat 32 string def{}forall 0 1 7{dup 2 mul pat exch 3 index put dup 2 mul 1 add pat exch 3 index put dup 2 mul 16 add pat exch 3 index put 2 mul 17 add pat exch 2 index put pop}for}bd/pfill{/PatFont patfont definefont setfont/ch(AAAA)def X0 64 X1{Y1 -16 Y0{1 index exch M ch show}for pop}for}bd/vert{X0 w X1{dup Y0 M Y1 L st}for}bd/horz{Y0 w Y1{dup X0 exch M X1 exch L st}for}bd/fdiag{X0 w X1{Y0 M X1 X0 sub dup rlt st}for Y0 w Y1{X0 exch M Y1 Y0 sub dup rlt st}for}bd/bdiag{X0 w X1{Y1 M X1 X0 sub dup neg rlt st}for Y0 w Y1{X0 exch M Y1 Y0 sub dup neg rlt st}for}bd/AU{1 add cvi 15 or}bd/AD{1 sub cvi -16 and}bd/SHR{pathbbox AU/Y1 ed AU/X1 ed AD/Y0 ed AD/X0 ed}bd/hfill{/w iRes 37.5 div round def 0.1 sl [] 0 setdash n dup 0 eq{horz}if dup 1 eq{vert}if dup 2 eq{fdiag}if dup 3 eq{bdiag}if dup 4 eq{horz vert}if 5 eq{fdiag bdiag}if}bd/F{/ft ed fm 256 and 0 ne{gs FC ft 0 eq{fill}{eofill}ifelse gr}if fm 1536 and 0 ne{SHR gs HC ft CP fm 1024 and 0 ne{/Tmp save def pfill Tmp restore}{fm 15 and hfill}ifelse gr}if}bd/S{PenW sl PC st}bd/m matrix def/GW{iRes 12 div PenW add cvi}bd/DoW{iRes 50 div PenW add cvi}bd/DW{iRes 8 div PenW add cvi}bd/SP{/PenW ed/iPen ed iPen 0 eq iPen 6 eq or{[] 0 setdash}if iPen 1 eq{[DW GW] 0 setdash}if iPen 2 eq{[DoW GW] 0 setdash}if iPen 3 eq{[DW GW DoW GW] 0 setdash}if iPen 4 eq{[DW GW DoW GW DoW GW] 0 setdash}if}bd/E{m cm pop tr scale 1 0 moveto 0 0 1 0 360 arc cp m sm}bd /AG{/sy ed/sx ed sx div 4 1 roll sy div 4 1 roll sx div 4 1 roll sy div 4 1 roll atan/a2 ed atan/a1 ed sx sy scale a1 a2 ARC}def/A{m cm pop tr AG m sm}def/P{m cm pop tr 0 0 M AG cp m sm}def/RRect{n 4 copy M 3 1 roll exch L 4 2 roll L L cp}bd/RRCC{/r ed/y1 ed/x1 ed/y0 ed/x0 ed x0 x1 add 2 div y0 M x1 y0 x1 y1 r arcto 4{pop}repeat x1 y1 x0 y1 r arcto 4{pop}repeat x0 y1 x0 y0 r arcto 4{pop}repeat x0 y0 x1 y0 r arcto 4{pop}repeat cp}bd/RR{2 copy 0 eq exch 0 eq or{pop pop RRect}{2 copy eq{pop RRCC}{m cm pop/y2 ed/x2 ed/ys y2 x2 div 1 max def/xs x2 y2 div 1 max def/y1 exch ys div def/x1 exch xs div def/y0 exch ys div def/x0 exch xs div def/r2 x2 y2 min def xs ys scale x0 x1 add 2 div y0 M x1 y0 x1 y1 r2 arcto 4{pop}repeat x1 y1 x0 y1 r2 arcto 4{pop}repeat x0 y1 x0 y0 r2 arcto 4{pop}repeat x0 y0 x1 y0 r2 arcto 4{pop}repeat m sm cp}ifelse}ifelse}bd/PP{{rlt}repeat}bd/OB{gs 0 ne{7 3 roll/y ed /x ed x y translate ULesc rotate x neg y neg translate x y 7 -3 roll}if sc B fill gr}bd/B{M/dy ed/dx ed dx 0 rlt 0 dy rlt dx neg 0 rlt cp}bd /CB{B clip n}bd/ErrHandler{errordict dup maxlength exch length gt dup{errordict begin}if/errhelpdict 12 dict def errhelpdict begin/stackunderflow(operand stack underflow)def /undefined(this name is not defined in a dictionary)def/VMerror(you have used up all the printer's memory)def /typecheck(operator was expecting a different type of operand)def /ioerror(input/output error occured)def end{end}if errordict begin /handleerror{$error begin newerror{/newerror false def showpage 72 72 scale/x .25 def/y 9.6 def/Helvetica findfont .2 scalefont setfont x y moveto(Offending Command = )show/command load{dup type/stringtype ne{(max err string)cvs}if show}exec/y y .2 sub def x y moveto(Error = )show errorname{dup type dup( max err string )cvs show( : )show/stringtype ne{( max err string )cvs}if show}exec errordict begin errhelpdict errorname known{x 1 add y .2 sub moveto errhelpdict errorname get show}if end /y y .4 sub def x y moveto(Stack =)show ostack{/y y .2 sub def x 1 add y moveto dup type/stringtype ne{( max err string )cvs}if show}forall showpage}if end}def end}bd end %%EndResource /SVDoc save def %%EndProlog %%BeginSetup Win35Dict begin ErrHandler %%EndSetup SS 0 0 25 23 776 1169 300 SM 1 lc 1 lj 0 0 0 pC 6 2 SP 192 192 192 fC /fm 256 def 269 1407 351 1472 6 8 RR 1 F S n 388 1407 469 1472 5 8 RR 1 F S n 506 1407 587 1472 6 8 RR 1 F S n 588 1522 M -319 0 1 PP S n 317 1473 M 0 49 1 PP S n 435 1473 M 0 49 1 PP S n 553 1473 M 0 49 1 PP S n 224 147 434 1455 E S n 32 0 0 38 38 0 0 0 34 /Helvetica /font8 ANSIFont font 0 0 0 fC 364 1537 159 (merit.edu) 159 SB 255 255 255 fC /fm 256 def 360 213 712 1013 E 1 F S n 32 0 0 22 22 0 0 0 20 /Helvetica /font8 ANSIFont font 0 0 0 fC 511 1371 85 (Michnetx) 85 SB 378 1371 113 (Glasshouse) 113 SB 264 1371 106 (Tschapperl) 106 SB 516 1426 56 (Cisco) 56 SB 388 1428 85 (RS/6000) 85 SB 280 1428 62 (NCSA) 62 SB 192 192 192 fC 352 490 434 555 6 8 RR 1 F S n 246 490 327 555 6 8 RR 1 F S n 128 490 209 555 5 8 RR 1 F S n 447 605 M -319 0 1 PP S n 399 555 M 0 50 1 PP S n 293 555 M 0 50 1 PP S n 175 555 M 0 50 1 PP S n 224 147 292 555 E S n 32 0 0 38 38 0 0 0 34 /Helvetica /font8 ANSIFont font 0 0 0 fC 210 620 211 (ncsl.nist.gov) 211 SB 32 0 0 22 22 0 0 0 20 /Helvetica /font8 ANSIFont font 141 453 68 (Cisco1) 68 SB 258 453 71 (3Com1) 71 SB 363 453 73 (Cursive) 73 SB 138 509 56 (Cisco) 56 SB 259 511 59 (3Com) 59 SB 362 511 62 (NCSA) 62 SB 32 0 0 38 38 0 0 0 34 /Helvetica /font8 ANSIFont font 518 718 156 (SURAnet) 156 SB 192 192 192 fC /fm 256 def 151 1128 233 1194 6 8 RR 1 F S n 32 0 0 22 22 0 0 0 20 /Helvetica /font8 ANSIFont font 0 0 0 fC 177 1092 67 (red-osi) 67 SB 162 1148 56 (Cisco) 56 SB 129 90 197 1168 E S n 32 0 0 38 38 0 0 0 34 /Helvetica /font8 ANSIFont font 104 1193 171 (cisco.com) 171 SB 104 964 156 (BARRnet) 156 SB 139 1015 M 24 114 1 PP S n 281 981 M 71 0 1 PP S n 577 768 M 0 50 1 PP S n 577 670 M 82 -64 1 PP S n 192 192 192 fC /fm 256 def 907 457 989 522 6 8 RR 1 F S n 801 457 883 522 6 8 RR 1 F S n 801 572 M 201 0 1 PP S n 955 523 M 0 49 1 PP S n 848 523 M 0 49 1 PP S n 171 147 901 521 E S n 0 0 0 fC 825 587 178 (3com.com) 178 SB 32 0 0 22 22 0 0 0 20 /Helvetica /font8 ANSIFont font 924 421 61 (Tuba1) 61 SB 814 478 59 (3Com) 59 SB 919 478 59 (3Com) 59 SB 818 421 61 (Tuba2) 61 SB 577 670 M 0 33 1 PP S n 32 0 0 38 38 0 0 0 34 /Helvetica /font8 ANSIFont font 634 560 82 (COS) 82 SB 435 524 M 142 146 1 PP S n 588 1424 M 71 -197 1 PP S n 192 192 192 fC /fm 256 def 978 1374 1060 1439 6 8 RR 1 F S n 872 1374 954 1439 6 8 RR 1 F S n 872 1489 M 201 0 1 PP S n 1026 1440 M 0 49 1 PP S n 919 1440 M 0 49 1 PP S n 171 147 971 1439 E S n 0 0 0 fC 919 1504 132 (lanl.gov) 132 SB 32 0 0 22 22 0 0 0 20 /Helvetica /font8 ANSIFont font 1001 1338 49 (Tuba) 49 SB 884 1395 62 (NCSA) 62 SB 979 1395 81 (BSDi4.4) 81 SB 892 1338 54 (Maze) 54 SB 813 1326 M 59 81 1 PP S n 32 0 0 66 66 0 0 0 60 /Helvetica /font8 ANSIFont font 606 905 224 (NSFnet) 224 SB 571 1003 295 (Backbone) 295 SB 32 0 0 38 38 0 0 0 34 /Helvetica /font8 ANSIFont font 754 1281 102 (ESnet) 102 SB 777 1276 M -35 -49 1 PP S n 255 255 255 fC /fm 256 def 289 212 1763 1046 E 1 F S n 0 0 0 fC 1309 1084 106 (CERN) 106 SB 1274 904 151 (SWITCH) 151 SB 1073 981 M 224 115 1 PP S n 1356 965 M 0 98 1 PP S n 1439 916 M 95 0 1 PP S n 32 0 0 66 66 0 0 0 60 /Helvetica /font8 ANSIFont font 1585 954 346 (EuropaNET) 346 SB 1611 1052 295 (Backbone) 295 SB 192 192 192 fC 1569 506 1651 571 6 8 RR 1 F S n 1463 506 1544 571 5 8 RR 1 F S n 1345 506 1426 571 5 8 RR 1 F S n 1663 621 M -319 0 1 PP S n 1616 572 M 0 49 1 PP S n 1510 572 M 0 49 1 PP S n 1392 572 M 0 49 1 PP S n 224 147 1508 571 E S n 32 0 0 38 38 0 0 0 34 /Helvetica /font8 ANSIFont font 0 0 0 fC 1404 636 241 (research.ptt.nl) 241 SB 32 0 0 22 22 0 0 0 20 /Helvetica /font8 ANSIFont font 1355 470 73 (Tuba20) 73 SB 1473 470 73 (Tuba10) 73 SB 1578 470 77 (Lsdm10) 77 SB 1352 525 62 (NCSA) 62 SB 1474 527 62 (NCSA) 62 SB 1582 527 56 (Cisco) 56 SB 32 0 0 38 38 0 0 0 34 /Helvetica /font8 ANSIFont font 1711 675 154 (SURFnet) 154 SB 1652 539 M 130 131 1 PP S n 1782 719 M 0 115 1 PP S n 192 192 192 fC /fm 256 def 1829 1472 1911 1538 6 8 RR 1 F S n 1947 1472 2029 1538 6 8 RR 1 F S n 1841 1587 M 201 0 1 PP S n 1876 1538 M 0 49 1 PP S n 1994 1538 M 0 49 1 PP S n 170 147 1940 1537 E S n 0 0 0 fC 1864 1602 177 (upm.dit.es) 177 SB 32 0 0 22 22 0 0 0 20 /Helvetica /font8 ANSIFont font 1828 1436 97 (Cisco_iso) 97 SB 1959 1494 62 (NCSA) 62 SB 1842 1494 56 (Cisco) 56 SB 1951 1436 87 (Tuba-PC) 87 SB 192 192 192 fC /fm 256 def 2160 490 2241 555 5 8 RR 1 F S n 2053 490 2135 555 6 8 RR 1 F S n 1935 490 2017 555 6 8 RR 1 F S n 2254 605 M -319 0 1 PP S n 2207 555 M 0 50 1 PP S n 2101 555 M 0 50 1 PP S n 1982 555 M 0 50 1 PP S n 224 147 2100 555 E S n 32 0 0 38 38 0 0 0 34 /Helvetica /font8 ANSIFont font 0 0 0 fC 2042 620 144 (sintef.no) 144 SB 32 0 0 22 22 0 0 0 20 /Helvetica /font8 ANSIFont font 1954 453 56 (Cisco) 56 SB 2067 453 68 (Tuba-1) 68 SB 2173 453 68 (Tuba-2) 68 SB 1946 509 56 (Cisco) 56 SB 2065 511 62 (NCSA) 62 SB 2170 511 62 (NCSA) 62 SB 1841 834 M 94 -311 1 PP S n 192 192 192 fC /fm 256 def 1427 1374 1509 1439 18 24 RR 1 F S n 0 0 0 fC 1430 1338 89 (mercurey) 89 SB 1431 1393 69 (SunOS) 69 SB 112 90 1468 1414 E S n 32 0 0 38 38 0 0 0 34 /Helvetica /font8 ANSIFont font 1415 1445 108 (inria.fr) 108 SB 1829 1505 M -95 -245 1 PP S n 1427 1407 M -71 -262 1 PP S n 32 0 0 98 98 0 0 0 91 /Helvetica-Bold /font9 ANSIFont font 322 231 1715 (TUBA CONNECTIVITY AT JENC 1993) 1715 SB 32 0 0 33 33 0 0 0 31 /Helvetica /font8 ANSIFont font 946 328 442 (Alex Reijnierse, May 17th 1993) 442 SB 718 555 M 83 -65 1 PP S n 151 1162 M -106 -82 1 PP S n 45 1080 M 0 -492 1 PP S n 45 588 M 83 -65 1 PP S n 65 787 166 (Nist / Cisco) 166 SB 90 819 99 (Tunnel) 99 SB EJ RS %%PageTrailer %%Trailer SVDoc restore end % TrueType font name key: % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT31c4c5 = 366fDTimes New RomanF0000002e000001900000 % MSTT31c4d2 = 366fDArialF00000026000001900000 % MSTT31c4dd = 366fDArialF00000016000001900000 % MSTT31c4e8 = 366fDArialF00000042000001900000 % MSTT31c4f3 = 366fDArialF00000062000002bc0000 % MSTT31c4fe = 366fDArialF00000021000001900000 % MSTT31c509 = 366fDTimes New RomanF00000010000001900000 % MSTT31c516 = 366fDTimes New RomanF0000002a000001900000 %%DocumentSuppliedResources: procset Win35Dict 3 1 %%DocumentNeededResources: font Helvetica %%+ font Helvetica-Bold %%EOF   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00457; 25 May 93 5:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00453; 25 May 93 5:55 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa01840; 25 May 93 5:55 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA00660; Tue, 25 May 93 01:34:19 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29947; Tue, 25 May 93 01:33:44 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29943; Tue, 25 May 93 01:33:41 MDT Received: from dnlts0_e.research.ptt.nl by p.lanl.gov (5.65/1.14) id AA00610; Tue, 25 May 93 01:33:26 -0600 Received: from research.ptt.nl by research.ptt.nl (PMDF #2928 ) id <01GYL5RU40ZOBJWVG8@research.ptt.nl>; Tue, 25 May 1993 09:33:34 +0200 Date: 25 May 1993 09:33:32 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ALEX REIJNIERSE Subject: TUBA demonstration document JENC93 To: tuba@lanl.gov Cc: wg4-clns@funet.fi, sn3plus-clns@surfnet.nl Message-Id: <01GYL5RU4AMUBJWVG8@research.ptt.nl> Organization: PTT Research, The Netherlands X-Envelope-To: tuba@lanl.gov X-Vms-To: IN%"tuba@lanl.gov" X-Vms-Cc: IN%"wg4-clns@funet.fi", IN%"sn3plus-clns@surfnet.nl" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Comments: This mail was sent by PMDF V4.1 Hello All, Here's the demonstration document of TUBA that was distributed at the JENC93 conference in Norway. I have incorporated all the latest comments from the implementors and participants. Please feel free to comment on it some more, because the status of the implementations changes constantly. - Alex P.S. i'll send a separate mail containing the connectivity picture on a portrait page. There were some problems with printing the picture on printers that do not support landscape. ------------------------- %!PS-Adobe-3.0 EPSF-2.0 %%Creator: Windows PSCRIPT %%Title: Microsoft Word - TUBADEMO.DOC %%BoundingBox: 18 10 577 825 %%DocumentNeededResources: (atend) %%DocumentSuppliedResources: (atend) %%Pages: 0 %%BeginResource: procset Win35Dict 3 1 /Win35Dict 290 dict def Win35Dict begin/bd{bind def}bind def/in{72 mul}bd/ed{exch def}bd/ld{load def}bd/tr/translate ld/gs/gsave ld/gr /grestore ld/M/moveto ld/L/lineto ld/rmt/rmoveto ld/rlt/rlineto ld /rct/rcurveto ld/st/stroke ld/n/newpath ld/sm/setmatrix ld/cm/currentmatrix ld/cp/closepath ld/ARC/arcn ld/TR{65536 div}bd/lj/setlinejoin ld/lc /setlinecap ld/ml/setmiterlimit ld/sl/setlinewidth ld/scignore false def/sc{scignore{pop pop pop}{0 index 2 index eq 2 index 4 index eq and{pop pop 255 div setgray}{3{255 div 3 1 roll}repeat setrgbcolor}ifelse}ifelse}bd /FC{bR bG bB sc}bd/fC{/bB ed/bG ed/bR ed}bd/HC{hR hG hB sc}bd/hC{ /hB ed/hG ed/hR ed}bd/PC{pR pG pB sc}bd/pC{/pB ed/pG ed/pR ed}bd/sM matrix def/PenW 1 def/iPen 5 def/mxF matrix def/mxE matrix def/mxUE matrix def/mxUF matrix def/fBE false def/iDevRes 72 0 matrix defaultmatrix dtransform dup mul exch dup mul add sqrt def/fPP false def/SS{fPP{ /SV save def}{gs}ifelse}bd/RS{fPP{SV restore}{gr}ifelse}bd/EJ{gsave showpage grestore}bd/#C{userdict begin/#copies ed end}bd/FEbuf 2 string def/FEglyph(G )def/FE{1 exch{dup 16 FEbuf cvrs FEglyph exch 1 exch putinterval 1 index exch FEglyph cvn put}for}bd/SM{/iRes ed/cyP ed /cxPg ed/cyM ed/cxM ed 72 100 div dup scale dup 0 ne{90 eq{cyM exch 0 eq{cxM exch tr -90 rotate -1 1 scale}{cxM cxPg add exch tr +90 rotate}ifelse}{cyP cyM sub exch 0 ne{cxM exch tr -90 rotate}{cxM cxPg add exch tr -90 rotate 1 -1 scale}ifelse}ifelse}{pop cyP cyM sub exch 0 ne{cxM cxPg add exch tr 180 rotate}{cxM exch tr 1 -1 scale}ifelse}ifelse 100 iRes div dup scale 0 0 transform .25 add round .25 sub exch .25 add round .25 sub exch itransform translate}bd/SJ{1 index 0 eq{pop pop/fBE false def}{1 index/Break ed div/dxBreak ed/fBE true def}ifelse}bd/ANSIVec[ 16#0/grave 16#1/acute 16#2/circumflex 16#3/tilde 16#4/macron 16#5/breve 16#6/dotaccent 16#7/dieresis 16#8/ring 16#9/cedilla 16#A/hungarumlaut 16#B/ogonek 16#C/caron 16#D/dotlessi 16#27/quotesingle 16#60/grave 16#7C/bar 16#82/quotesinglbase 16#83/florin 16#84/quotedblbase 16#85 /ellipsis 16#86/dagger 16#87/daggerdbl 16#88/circumflex 16#89/perthousand 16#8A/Scaron 16#8B/guilsinglleft 16#8C/OE 16#91/quoteleft 16#92/quoteright 16#93/quotedblleft 16#94/quotedblright 16#95/bullet 16#96/endash 16#97 /emdash 16#98/tilde 16#99/trademark 16#9A/scaron 16#9B/guilsinglright 16#9C/oe 16#9F/Ydieresis 16#A0/space 16#A1/exclamdown 16#A4/currency 16#A5/yen 16#A6/brokenbar 16#A7/section 16#A8/dieresis 16#A9/copyright 16#AA/ordfeminine 16#AB/guillemotleft 16#AC/logicalnot 16#AD/hyphen 16#AE/registered 16#AF/macron 16#B0/degree 16#B1/plusminus 16#B2/twosuperior 16#B3/threesuperior 16#B4/acute 16#B5/mu 16#B6/paragraph 16#B7/periodcentered 16#B8/cedilla 16#B9/onesuperior 16#BA/ordmasculine 16#BB/guillemotright 16#BC/onequarter 16#BD/onehalf 16#BE/threequarters 16#BF/questiondown 16#C0/Agrave 16#C1/Aacute 16#C2/Acircumflex 16#C3/Atilde 16#C4/Adieresis 16#C5/Aring 16#C6/AE 16#C7/Ccedilla 16#C8/Egrave 16#C9/Eacute 16#CA /Ecircumflex 16#CB/Edieresis 16#CC/Igrave 16#CD/Iacute 16#CE/Icircumflex 16#CF/Idieresis 16#D0/Eth 16#D1/Ntilde 16#D2/Ograve 16#D3/Oacute 16#D4 /Ocircumflex 16#D5/Otilde 16#D6/Odieresis 16#D7/multiply 16#D8/Oslash 16#D9/Ugrave 16#DA/Uacute 16#DB/Ucircumflex 16#DC/Udieresis 16#DD/Yacute 16#DE/Thorn 16#DF/germandbls 16#E0/agrave 16#E1/aacute 16#E2/acircumflex 16#E3/atilde 16#E4/adieresis 16#E5/aring 16#E6/ae 16#E7/ccedilla 16#E8 /egrave 16#E9/eacute 16#EA/ecircumflex 16#EB/edieresis 16#EC/igrave 16#ED/iacute 16#EE/icircumflex 16#EF/idieresis 16#F0/eth 16#F1/ntilde 16#F2/ograve 16#F3/oacute 16#F4/ocircumflex 16#F5/otilde 16#F6/odieresis 16#F7/divide 16#F8/oslash 16#F9/ugrave 16#FA/uacute 16#FB/ucircumflex 16#FC/udieresis 16#FD/yacute 16#FE/thorn 16#FF/ydieresis ] def/reencdict 12 dict def/IsChar{basefontdict/CharStrings get exch known}bd/MapCh{dup IsChar not{pop/bullet}if newfont/Encoding get 3 1 roll put}bd/MapDegree{16#b0 /degree IsChar{/degree}{/ring}ifelse MapCh}bd/MapBB{16#a6/brokenbar IsChar{/brokenbar}{/bar}ifelse MapCh}bd/ANSIFont{reencdict begin/newfontname ed/basefontname ed FontDirectory newfontname known not{/basefontdict basefontname findfont def/newfont basefontdict maxlength dict def basefontdict{exch dup/FID ne{dup/Encoding eq{exch dup length array copy newfont 3 1 roll put}{exch newfont 3 1 roll put}ifelse}{pop pop}ifelse}forall newfont /FontName newfontname put 127 1 159{newfont/Encoding get exch/bullet put}for ANSIVec aload pop ANSIVec length 2 idiv{MapCh}repeat MapDegree MapBB newfontname newfont definefont pop}if newfontname end}bd/SB{FC /ULlen ed/str ed str length fBE not{dup 1 gt{1 sub}if}if/cbStr ed /dxGdi ed/y0 ed/x0 ed str stringwidth dup 0 ne{/y1 ed/x1 ed y1 y1 mul x1 x1 mul add sqrt dxGdi exch div 1 sub dup x1 mul cbStr div exch y1 mul cbStr div}{exch abs neg dxGdi add cbStr div exch}ifelse/dyExtra ed/dxExtra ed x0 y0 M fBE{dxBreak 0 BCh dxExtra dyExtra str awidthshow}{dxExtra dyExtra str ashow}ifelse fUL{x0 y0 M dxUL dyUL rmt ULlen fBE{Break add}if 0 mxUE transform gs rlt cyUL sl [] 0 setdash st gr}if fSO{x0 y0 M dxSO dySO rmt ULlen fBE{Break add}if 0 mxUE transform gs rlt cyUL sl [] 0 setdash st gr}if n/fBE false def}bd/font{/name ed/Ascent ed 0 ne/fT3 ed 0 ne/fSO ed 0 ne/fUL ed/Sy ed/Sx ed 10.0 div/ori ed -10.0 div/esc ed/BCh ed name findfont/xAscent 0 def/yAscent Ascent def/ULesc esc def ULesc mxUE rotate pop fT3{/esc 0 def xAscent yAscent mxUE transform /yAscent ed/xAscent ed}if [Sx 0 0 Sy neg xAscent yAscent] esc mxE rotate mxF concatmatrix makefont setfont [Sx 0 0 Sy neg 0 Ascent] mxUE mxUF concatmatrix pop fUL{currentfont dup/FontInfo get/UnderlinePosition known not{pop/Courier findfont}if/FontInfo get/UnderlinePosition get 1000 div 0 exch mxUF transform/dyUL ed/dxUL ed}if fSO{0 .3 mxUF transform /dySO ed/dxSO ed}if fUL fSO or{currentfont dup/FontInfo get/UnderlineThickness known not{pop/Courier findfont}if/FontInfo get/UnderlineThickness get 1000 div Sy mul/cyUL ed}if}bd/min{2 copy gt{exch}if pop}bd/max{2 copy lt{exch}if pop}bd/CP{/ft ed{{ft 0 eq{clip}{eoclip}ifelse}stopped{currentflat 1 add setflat}{exit}ifelse}loop}bd/patfont 10 dict def patfont begin /FontType 3 def/FontMatrix [1 0 0 -1 0 0] def/FontBBox [0 0 16 16] def/Encoding StandardEncoding def/BuildChar{pop pop 16 0 0 0 16 16 setcachedevice 16 16 false [1 0 0 1 .25 .25]{pat}imagemask}bd end/p{ /pat 32 string def{}forall 0 1 7{dup 2 mul pat exch 3 index put dup 2 mul 1 add pat exch 3 index put dup 2 mul 16 add pat exch 3 index put 2 mul 17 add pat exch 2 index put pop}for}bd/pfill{/PatFont patfont definefont setfont/ch(AAAA)def X0 64 X1{Y1 -16 Y0{1 index exch M ch show}for pop}for}bd/vert{X0 w X1{dup Y0 M Y1 L st}for}bd/horz{Y0 w Y1{dup X0 exch M X1 exch L st}for}bd/fdiag{X0 w X1{Y0 M X1 X0 sub dup rlt st}for Y0 w Y1{X0 exch M Y1 Y0 sub dup rlt st}for}bd/bdiag{X0 w X1{Y1 M X1 X0 sub dup neg rlt st}for Y0 w Y1{X0 exch M Y1 Y0 sub dup neg rlt st}for}bd/AU{1 add cvi 15 or}bd/AD{1 sub cvi -16 and}bd/SHR{pathbbox AU/Y1 ed AU/X1 ed AD/Y0 ed AD/X0 ed}bd/hfill{/w iRes 37.5 div round def 0.1 sl [] 0 setdash n dup 0 eq{horz}if dup 1 eq{vert}if dup 2 eq{fdiag}if dup 3 eq{bdiag}if dup 4 eq{horz vert}if 5 eq{fdiag bdiag}if}bd/F{/ft ed fm 256 and 0 ne{gs FC ft 0 eq{fill}{eofill}ifelse gr}if fm 1536 and 0 ne{SHR gs HC ft CP fm 1024 and 0 ne{/Tmp save def pfill Tmp restore}{fm 15 and hfill}ifelse gr}if}bd/S{PenW sl PC st}bd/m matrix def/GW{iRes 12 div PenW add cvi}bd/DoW{iRes 50 div PenW add cvi}bd/DW{iRes 8 div PenW add cvi}bd/SP{/PenW ed/iPen ed iPen 0 eq iPen 6 eq or{[] 0 setdash}if iPen 1 eq{[DW GW] 0 setdash}if iPen 2 eq{[DoW GW] 0 setdash}if iPen 3 eq{[DW GW DoW GW] 0 setdash}if iPen 4 eq{[DW GW DoW GW DoW GW] 0 setdash}if}bd/E{m cm pop tr scale 1 0 moveto 0 0 1 0 360 arc cp m sm}bd /AG{/sy ed/sx ed sx div 4 1 roll sy div 4 1 roll sx div 4 1 roll sy div 4 1 roll atan/a2 ed atan/a1 ed sx sy scale a1 a2 ARC}def/A{m cm pop tr AG m sm}def/P{m cm pop tr 0 0 M AG cp m sm}def/RRect{n 4 copy M 3 1 roll exch L 4 2 roll L L cp}bd/RRCC{/r ed/y1 ed/x1 ed/y0 ed/x0 ed x0 x1 add 2 div y0 M x1 y0 x1 y1 r arcto 4{pop}repeat x1 y1 x0 y1 r arcto 4{pop}repeat x0 y1 x0 y0 r arcto 4{pop}repeat x0 y0 x1 y0 r arcto 4{pop}repeat cp}bd/RR{2 copy 0 eq exch 0 eq or{pop pop RRect}{2 copy eq{pop RRCC}{m cm pop/y2 ed/x2 ed/ys y2 x2 div 1 max def/xs x2 y2 div 1 max def/y1 exch ys div def/x1 exch xs div def/y0 exch ys div def/x0 exch xs div def/r2 x2 y2 min def xs ys scale x0 x1 add 2 div y0 M x1 y0 x1 y1 r2 arcto 4{pop}repeat x1 y1 x0 y1 r2 arcto 4{pop}repeat x0 y1 x0 y0 r2 arcto 4{pop}repeat x0 y0 x1 y0 r2 arcto 4{pop}repeat m sm cp}ifelse}ifelse}bd/PP{{rlt}repeat}bd/OB{gs 0 ne{7 3 roll/y ed /x ed x y translate ULesc rotate x neg y neg translate x y 7 -3 roll}if sc B fill gr}bd/B{M/dy ed/dx ed dx 0 rlt 0 dy rlt dx neg 0 rlt cp}bd /CB{B clip n}bd/ErrHandler{errordict dup maxlength exch length gt dup{errordict begin}if/errhelpdict 12 dict def errhelpdict begin/stackunderflow(operand stack underflow)def /undefined(this name is not defined in a dictionary)def/VMerror(you have used up all the printer's memory)def /typecheck(operator was expecting a different type of operand)def /ioerror(input/output error occured)def end{end}if errordict begin /handleerror{$error begin newerror{/newerror false def showpage 72 72 scale/x .25 def/y 9.6 def/Helvetica findfont .2 scalefont setfont x y moveto(Offending Command = )show/command load{dup type/stringtype ne{(max err string)cvs}if show}exec/y y .2 sub def x y moveto(Error = )show errorname{dup type dup( max err string )cvs show( : )show/stringtype ne{( max err string )cvs}if show}exec errordict begin errhelpdict errorname known{x 1 add y .2 sub moveto errhelpdict errorname get show}if end /y y .4 sub def x y moveto(Stack =)show ostack{/y y .2 sub def x 1 add y moveto dup type/stringtype ne{( max err string )cvs}if show}forall showpage}if end}def end}bd end %%EndResource /SVDoc save def %%EndProlog %%BeginSetup Win35Dict begin ErrHandler %%EndSetup SS 0 0 25 23 776 1169 300 SM 32 0 0 125 125 0 0 0 112 /Times-Roman /font28 ANSIFont font 0 0 0 fC 937 264 455 (JENC 93) 455 SB 255 255 255 fC /fm 256 def 2027 3 151 255 B 1 F n 0 0 0 fC 5 11 139 243 B 1 F n 11 5 139 243 B 1 F n 5 5 145 249 B 1 F n 5 5 145 249 B 1 F n 2027 5 151 243 B 1 F n 2027 5 151 249 B 1 F n 5 11 2185 243 B 1 F n 11 5 2179 243 B 1 F n 5 5 2179 249 B 1 F n 5 5 2179 249 B 1 F n 5 150 139 255 B 1 F n 5 150 145 255 B 1 F n 5 150 2179 255 B 1 F n 5 150 2185 255 B 1 F n 11 150 2191 255 B 1 F n 443 411 1444 (TUBA DEMONSTRATION) 1444 SB 255 255 255 fC 2027 3 151 553 B 1 F n 0 0 0 fC 5 11 139 557 B 1 F n 11 5 139 563 B 1 F n 5 5 145 557 B 1 F n 5 5 145 557 B 1 F n 2027 5 151 557 B 1 F n 2027 5 151 563 B 1 F n 2027 11 151 569 B 1 F n 11 23 2191 557 B 1 F n 23 11 2179 569 B 1 F n 5 11 2185 557 B 1 F n 11 5 2179 563 B 1 F n 5 5 2179 557 B 1 F n 5 5 2179 557 B 1 F n 5 150 139 406 B 1 F n 5 150 145 406 B 1 F n 5 150 2179 406 B 1 F n 5 150 2185 406 B 1 F n 11 150 2191 406 B 1 F n 32 0 0 58 58 0 0 0 53 /Times-Roman /font28 ANSIFont font 161 688 874 (Participating TUBA Implementations:) 874 SB 32 0 0 42 42 0 0 0 38 /Times-Italic /font27 ANSIFont font 161 857 506 (HOST IMPLEMENTATIONS:) 506 SB 32 0 0 42 42 0 0 0 42 /Symbol font gs 180 3396 0 0 CB 161 976 19 (\267) 19 SB gr 32 0 0 67 67 0 0 0 60 /Times-Roman /font28 ANSIFont font 236 958 390 (PC//MS-DOS:) 390 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 461 1091 584 (Internet Applications supported:) 584 SB 1061 1091 646 (- Non data-transfer FTP commands) 646 SB 1061 1146 357 (- TELNET initiator) 357 SB 1061 1201 348 (- FINGER initiator) 348 SB 1061 1256 459 (- DNS access for NSAPs) 459 SB 1061 1311 449 (- Long term ping version) 449 SB 461 1366 236 (Future work:) 236 SB 1061 1366 838 (- FTP initiator and responder, ES-IS, TRACE) 838 SB 461 1421 476 (Information contact-point:) 476 SB 1061 1421 630 (Richard Colella \(colella@nist.gov\)) 630 SB 32 0 0 42 42 0 0 0 42 /Symbol font gs 180 3396 0 0 CB 161 1550 19 (\267) 19 SB gr 32 0 0 67 67 0 0 0 60 /Times-Roman /font28 ANSIFont font 236 1532 372 (PC//BSDi4.4:) 372 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 461 1665 584 (Internet Applications supported:) 584 SB 1061 1665 623 (- TELNET initiator and responder) 623 SB 1061 1720 570 (- SMTP initiator and responder) 570 SB 1061 1775 449 (- Long term ping version) 449 SB 1061 1830 459 (- DNS access for NSAPs) 459 SB 461 1885 236 (Future work:) 236 SB 1061 1885 242 (- FTP, TFTP) 242 SB 461 1940 476 (Information contact-point:) 476 SB 1061 1940 681 (Peter Ford \(peter@goshawk.lanl.gov\)) 681 SB 32 0 0 42 42 0 0 0 42 /Symbol font gs 180 3396 0 0 CB 161 2069 19 (\267) 19 SB gr 32 0 0 67 67 0 0 0 60 /Times-Roman /font28 ANSIFont font 236 2051 389 (RS6000//AIX:) 389 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 461 2184 584 (Internet Applications supported:) 584 SB 1061 2184 15 (-) 15 SB 1061 2239 449 (- Long term ping version) 449 SB 461 2294 236 (Future work:) 236 SB 1061 2294 47 (- ?) 47 SB 461 2349 476 (Information contact-point:) 476 SB 1061 2349 545 (Susan Hares \(skh@merit.edu\)) 545 SB 32 0 0 42 42 0 0 0 42 /Symbol font gs 180 3396 0 0 CB 161 2478 19 (\267) 19 SB gr 32 0 0 67 67 0 0 0 60 /Times-Roman /font28 ANSIFont font 236 2460 379 (SUN//SunOS:) 379 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 461 2593 584 (Internet Applications supported:) 584 SB 1061 2593 623 (- TELNET initiator and responder) 623 SB 1061 2648 449 (- Long term ping version) 449 SB 1061 2703 382 (- FINGER responder) 382 SB 1061 2758 942 (- IP small services \(time, daytime, echo, discard, ...\)) 942 SB 461 2813 236 (Future work:) 236 SB 1061 2813 908 (- all standard Internet applications \(including FTP) 908 SB 1061 2868 994 ( with LPORT and DNS\), \(integrated\) IS-IS and IDRP) 994 SB 461 2923 476 (Information contact-point:) 476 SB 1061 2923 754 (Francis Dupont \(francis.dupont@inria.fr\)) 754 SB 32 0 0 33 33 0 0 0 29 /Times-Roman /font28 ANSIFont font 161 3134 1623 (TUBA Demonstration Coordinator: Alex Reijnierse, PTT Research, The Netherlands, e-mail: A.A.Reijnierse@research.ptt.nl) 1623 SB 255 255 255 fC 2027 3 151 3129 B 1 F n 0 0 0 fC 2 2 148 3126 B 1 F n 2 2 148 3126 B 1 F n 2027 2 151 3126 B 1 F n 2 2 2179 3126 B 1 F n 2 2 2179 3126 B 1 F n 255 255 255 fC 2027 3 151 3171 B 1 F n 0 0 0 fC 2 2 148 3175 B 1 F n 2 2 148 3175 B 1 F n 2027 2 151 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 45 148 3129 B 1 F n 2 45 2179 3129 B 1 F n 1156 3217 17 (1) 17 SB EJ RS %%PageTrailer SS 0 0 25 23 776 1169 300 SM 32 0 0 42 42 0 0 0 38 /Times-Italic /font27 ANSIFont font 0 0 0 fC 161 233 563 (ROUTER IMPLEMENTATIONS:) 563 SB 32 0 0 42 42 0 0 0 42 /Symbol font gs 180 3396 0 0 CB 161 357 19 (\267) 19 SB gr 32 0 0 67 67 0 0 0 60 /Times-Roman /font28 ANSIFont font 236 339 581 (Cisco TUBA version:) 581 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 461 472 584 (Internet Applications supported:) 584 SB 1061 472 623 (- TELNET initiator and responder) 623 SB 1061 527 614 (- FINGER initiator and responder) 614 SB 1061 582 628 (- TFTP initiator \(network booting\)) 628 SB 1061 637 459 (- DNS access for NSAPs) 459 SB 1061 692 449 (- Long term ping version) 449 SB 461 747 236 (Future work:) 236 SB 1061 747 201 (- Unknown) 201 SB 461 802 476 (Information contact-point:) 476 SB 1061 802 613 (Dino Farinacci \(dino@cisco.com\)) 613 SB 32 0 0 42 42 0 0 0 42 /Symbol font gs 180 3396 0 0 CB 161 931 19 (\267) 19 SB gr 32 0 0 67 67 0 0 0 60 /Times-Roman /font28 ANSIFont font 236 913 592 (3Com TUBA version:) 592 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 461 1046 584 (Internet Applications supported:) 584 SB 1061 1046 623 (- TELNET initiator and responder) 623 SB 1061 1101 605 ( \(supported in upcoming release\)) 605 SB 1061 1156 449 (- Long term ping version) 449 SB 461 1211 236 (Future work:) 236 SB 1061 1211 658 (- Extending CLNS functionality like) 658 SB 1061 1266 521 ( IDRP and Integrated IS-IS) 521 SB 1061 1321 459 (- DNS access for NSAPs) 459 SB 461 1376 476 (Information contact-point:) 476 SB 1061 1376 617 (Cyndi Jung \(cmj@nsd.3com.com\)) 617 SB 32 0 0 33 33 0 0 0 29 /Times-Roman /font28 ANSIFont font 161 3134 1623 (TUBA Demonstration Coordinator: Alex Reijnierse, PTT Research, The Netherlands, e-mail: A.A.Reijnierse@research.ptt.nl) 1623 SB 255 255 255 fC /fm 256 def 2027 3 151 3129 B 1 F n 0 0 0 fC 2 2 148 3126 B 1 F n 2 2 148 3126 B 1 F n 2027 2 151 3126 B 1 F n 2 2 2179 3126 B 1 F n 2 2 2179 3126 B 1 F n 255 255 255 fC 2027 3 151 3171 B 1 F n 0 0 0 fC 2 2 148 3175 B 1 F n 2 2 148 3175 B 1 F n 2027 2 151 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 45 148 3129 B 1 F n 2 45 2179 3129 B 1 F n 1156 3217 17 (2) 17 SB EJ RS %%PageTrailer SS 0 0 25 23 776 1169 300 SM 32 0 0 58 58 0 0 0 53 /Times-Roman /font28 ANSIFont font 0 0 0 fC 161 233 683 (Participating TUBA Systems:) 683 SB 32 0 0 42 42 0 0 0 33 /Courier /font0 ANSIFont font 161 355 175 (#######) 175 SB 161 400 1400 (####### Alex Reijnierse \(A.A.Reijnierse@research.ptt.nl\)) 1400 SB 161 445 950 (####### The Netherlands - PTT Research) 950 SB 161 490 425 (####### The Hague) 425 SB 161 580 725 (name=tuba10.research.ptt.nl; ) 725 SB 911 580 225 (# NCSA PC) 225 SB 311 625 1250 (hostnsap=39528F11000009100000000040bbbbaaaa001000;) 1250 SB 161 670 700 (name=tuba20.research.ptt.nl;) 700 SB 911 670 225 (# NCSA PC) 225 SB 311 715 1250 (hostnsap=39528F11000009100000000040bbbbaaaa002000;) 1250 SB 161 760 700 (name=lsdm10.research.ptt.nl;) 700 SB 911 760 575 (# Cisco router \(jenc93\)) 575 SB 311 805 1250 (hostnsap=39528F1100000910000000004000000c03df7d00;) 1250 SB 161 895 175 (#######) 175 SB 161 940 1050 (####### David Fernandez \(david@dit.upm.es\)) 1050 SB 161 985 1525 (####### Spain - Universidad Politecnica de Madrid and RedIRIS) 1525 SB 161 1030 350 (####### Madrid) 350 SB 161 1120 650 (name=cisco_iso.upm.dit.es;) 650 SB 911 1120 575 (# Cisco router \(jenc93\)) 575 SB 311 1165 1250 (hostnsap=39724F1001000000020001000113800400200900;) 1250 SB 161 1210 600 (name=tuba-pc.upm.dit.es;) 600 SB 911 1210 225 (# NCSA PC) 225 SB 311 1255 1250 (hostnsap=39724F1001000000020001000100000000001000;) 1250 SB 161 1345 175 (#######) 175 SB 161 1390 1200 (####### Francis Dupont \(francis.dupont@inria.fr\)) 1200 SB 161 1435 550 (####### France - INRIA) 550 SB 161 1480 175 (#######) 175 SB 161 1570 575 (name=mercurey.inria.fr;) 575 SB 761 1570 1025 (# SunOS 4.1.2 + BSDi + TUBA \(fish/jenc93\)) 1025 SB 311 1615 1250 (hostnsap=39250F0000020000000000000412809300801706;) 1250 SB 161 1705 175 (#######) 175 SB 161 1750 1275 (####### Olav Kvittem \(Olav.Kvittem@delab.sintef.no\)) 1275 SB 161 1795 1000 (####### Norway - Universitetet Trondheim) 1000 SB 161 1840 425 (####### Trondheim) 425 SB 161 1930 750 (name=tuba-1.jenc93.uninett.no;) 750 SB 1061 1930 225 (# NCSA PC) 225 SB 311 1975 1250 (hostnsap=4700230000000500000002010212924116002200;) 1250 SB 161 2020 750 (name=tuba-2.jenc93.uninett.no;) 750 SB 1061 2020 225 (# NCSA PC) 225 SB 311 2065 1250 (hostnsap=4700230000000500000002010212924116002300;) 1250 SB 161 2110 725 (name=cisco.jenc93.uninett.no;) 725 SB 1061 2110 600 (# Cisco router \(jenc93\) ) 600 SB 311 2155 1250 (hostnsap=4700230000000500000002010212924116002400;) 1250 SB 161 2245 175 (#######) 175 SB 161 2290 1050 (####### Richard Colella \(colella@nist.gov\)) 1050 SB 161 2335 1475 (####### US - National Institute of Standards and Technology) 1475 SB 161 2380 750 (####### Gaithersburg, Maryland) 750 SB 161 2470 675 (name=cursive.ncsl.nist.gov;) 675 SB 911 2470 225 (# NCSA PC) 225 SB 311 2515 1250 (hostnsap=47000580005a0000000001e137eeeeee00008500;) 1250 SB 161 2560 650 (name=cisco1.ncsl.nist.gov;) 650 SB 911 2560 350 (# Cisco router) 350 SB 311 2605 1250 (hostnsap=47000580005a0000000001e13788888800018100;) 1250 SB 161 2650 625 (name=3com1.ncsl.nist.gov;) 625 SB 911 2650 325 (# 3Com router) 325 SB 311 2695 1250 (hostnsap=47000580005a0000000001e13711111100011100;) 1250 SB 161 2785 175 (#######) 175 SB 161 2830 925 (####### Cyndi Jung \(cmj@nsd.3com.com\)) 925 SB 161 2875 725 (####### US - 3Com corporation) 725 SB 161 2920 775 (####### Santa Clara, California) 775 SB 161 3010 500 (name=tuba1.3com.com;) 500 SB 761 3010 325 (# 3Com router) 325 SB 311 3055 950 (hostnsap=4700040035110011111111111100;) 950 SB 32 0 0 33 33 0 0 0 29 /Times-Roman /font28 ANSIFont font 161 3134 1623 (TUBA Demonstration Coordinator: Alex Reijnierse, PTT Research, The Netherlands, e-mail: A.A.Reijnierse@research.ptt.nl) 1623 SB 255 255 255 fC /fm 256 def 2027 3 151 3129 B 1 F n 0 0 0 fC 2 2 148 3126 B 1 F n 2 2 148 3126 B 1 F n 2027 2 151 3126 B 1 F n 2 2 2179 3126 B 1 F n 2 2 2179 3126 B 1 F n 255 255 255 fC 2027 3 151 3171 B 1 F n 0 0 0 fC 2 2 148 3175 B 1 F n 2 2 148 3175 B 1 F n 2027 2 151 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 45 148 3129 B 1 F n 2 45 2179 3129 B 1 F n 1156 3217 17 (3) 17 SB EJ RS %%PageTrailer SS 0 0 25 23 776 1169 300 SM 32 0 0 42 42 0 0 0 33 /Courier /font0 ANSIFont font 0 0 0 fC 161 231 500 (name=tuba2.3com.com;) 500 SB 761 231 325 (# 3Com router) 325 SB 311 276 950 (hostnsap=4700040035110022222222222200;) 950 SB 161 366 175 (#######) 175 SB 161 411 975 (####### Dino Farinacci \(dino@cisco.com\)) 975 SB 161 456 650 (####### US - Cisco Systems) 650 SB 161 501 750 (####### Menlo Park, California) 750 SB 161 591 475 (name=red.cisco.com;) 475 SB 761 591 350 (# Cisco router) 350 SB 311 636 1250 (hostnsap=47000580ffef0000000001594016008906402200;) 1250 SB 161 726 175 (#######) 175 SB 161 771 1550 (####### Mark Knopper/Susan Hares \(mak@merit.edu/skh@merit.edu\)) 1550 SB 161 816 450 (####### US - MERIT) 450 SB 161 861 675 (####### Ann Arbor, Michigan) 675 SB 161 951 650 (name=glasshouse.merit.edu;) 650 SB 911 951 325 (# IBM RS/6000) 325 SB 311 996 1250 (hostnsap=47000580ffff000000040000000000232a015500;) 1250 SB 161 1041 600 (name=michnetx.merit.edu;) 600 SB 911 1041 350 (# Cisco router) 350 SB 311 1086 1250 (hostnsap=47000580ffff0000000400000000002301010b00;) 1250 SB 161 1131 650 (name=tschapperl.merit.edu;) 650 SB 911 1131 225 (# NCSA PC) 225 SB 311 1176 1250 (hostnsap=47000580ffff000000040000000000232a015e00;) 1250 SB 161 1266 175 (#######) 175 SB 161 1311 1075 (####### Peter Ford \(peter@goshawk.lanl.gov\)) 1075 SB 161 1356 1075 (####### US - Los Alamos National Laboratory) 1075 SB 161 1401 750 (####### Los Alamos, New Mexico) 750 SB 161 1491 475 (name=maze.lanl.gov;) 475 SB 761 1491 225 (# NCSA PC) 225 SB 311 1536 1250 (hostnsap=47000580005700000001400001feededfeeded00;) 1250 SB 161 1581 475 (name=tuba.lanl.gov;) 475 SB 761 1581 875 (# BSDi/4.4 BSD PC \(Tguest/TUBATest\)) 875 SB 311 1626 1250 (hostnsap=4700058000570000000140000100608cb11eb800;) 1250 SB 32 0 0 33 33 0 0 0 29 /Times-Roman /font28 ANSIFont font 161 3134 1623 (TUBA Demonstration Coordinator: Alex Reijnierse, PTT Research, The Netherlands, e-mail: A.A.Reijnierse@research.ptt.nl) 1623 SB 255 255 255 fC /fm 256 def 2027 3 151 3129 B 1 F n 0 0 0 fC 2 2 148 3126 B 1 F n 2 2 148 3126 B 1 F n 2027 2 151 3126 B 1 F n 2 2 2179 3126 B 1 F n 2 2 2179 3126 B 1 F n 255 255 255 fC 2027 3 151 3171 B 1 F n 0 0 0 fC 2 2 148 3175 B 1 F n 2 2 148 3175 B 1 F n 2027 2 151 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 45 148 3129 B 1 F n 2 45 2179 3129 B 1 F n 1156 3217 17 (4) 17 SB EJ RS %%PageTrailer SS 0 0 25 23 776 1169 300 SM 32 0 0 58 58 0 0 0 53 /Times-Roman /font28 ANSIFont font 0 0 0 fC 161 233 787 (Basic Demonstration Capabilities:) 787 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 161 357 245 (From the PC:) 245 SB 161 467 211 (CLNPING ) 211 SB 32 0 0 46 46 0 0 0 42 /Times-Italic /font27 ANSIFont font 372 467 77 (host) 77 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 611 467 759 (Long term 'ping' to host \(reachability test\)) 759 SB 161 522 187 (TELNET ) 187 SB 32 0 0 46 46 0 0 0 42 /Times-Italic /font27 ANSIFont font 348 522 77 (host) 77 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 611 522 440 (Virtual Terminal to host) 440 SB 161 577 187 (TELNET ) 187 SB 32 0 0 46 46 0 0 0 42 /Times-Italic /font27 ANSIFont font 348 577 77 (host) 77 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 425 577 69 (#21) 69 SB 611 577 1042 (Issue of non data-transfer FTP commands \(to NCSA PC\)) 1042 SB 161 632 220 (FINGER @) 220 SB 32 0 0 46 46 0 0 0 42 /Times-Italic /font27 ANSIFont font 381 632 77 (host) 77 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 611 632 571 (Finger host \(user identification\)) 571 SB 161 742 401 (From the cisco router:) 401 SB 161 852 249 (PING CLNS ) 249 SB 32 0 0 46 46 0 0 0 42 /Times-Italic /font27 ANSIFont font 410 852 77 (host) 77 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 611 852 759 (Long term 'ping' to host \(reachability test\)) 759 SB 32 0 0 46 46 0 0 0 42 /Times-Italic /font27 ANSIFont font 161 907 77 (host) 77 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 611 907 440 (Virtual Terminal to host) 440 SB 32 0 0 46 46 0 0 0 42 /Times-Italic /font27 ANSIFont font 161 962 135 (host 79) 135 SB 32 0 0 46 46 0 0 0 42 /Times-Roman /font28 ANSIFont font 611 962 571 (Finger host \(user identification\)) 571 SB 32 0 0 33 33 0 0 0 29 /Times-Roman /font28 ANSIFont font 161 3134 1623 (TUBA Demonstration Coordinator: Alex Reijnierse, PTT Research, The Netherlands, e-mail: A.A.Reijnierse@research.ptt.nl) 1623 SB 255 255 255 fC /fm 256 def 2027 3 151 3129 B 1 F n 0 0 0 fC 2 2 148 3126 B 1 F n 2 2 148 3126 B 1 F n 2027 2 151 3126 B 1 F n 2 2 2179 3126 B 1 F n 2 2 2179 3126 B 1 F n 255 255 255 fC 2027 3 151 3171 B 1 F n 0 0 0 fC 2 2 148 3175 B 1 F n 2 2 148 3175 B 1 F n 2027 2 151 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 45 148 3129 B 1 F n 2 45 2179 3129 B 1 F n 1156 3217 17 (5) 17 SB EJ RS %%PageTrailer %%BeginPageSetup %%EndPageSetup SS 0 0 25 23 776 1169 300 SM 1 lc 1 lj 0 0 0 pC 6 3 SP 192 192 192 fC /fm 256 def 546 1653 650 1736 7 10 RR 1 F S n 696 1653 800 1736 7 10 RR 1 F S n 846 1653 950 1736 7 10 RR 1 F S n 951 1799 M -405 0 1 PP S n 606 1737 M 0 62 1 PP S n 756 1737 M 0 62 1 PP S n 906 1737 M 0 62 1 PP S n 285 187 755 1715 E S n 32 0 0 48 48 0 0 0 45 /Helvetica /font8 ANSIFont font 0 0 0 fC 666 1816 200 (merit.edu) 200 SB 255 255 255 fC /fm 256 def 458 270 1108 1154 E 1 F S n 32 0 0 28 28 0 0 0 26 /Helvetica /font8 ANSIFont font 0 0 0 fC 851 1607 111 (Michnetx) 111 SB 683 1607 147 (Glasshouse) 147 SB 537 1607 137 (Tschapperl) 137 SB 860 1677 69 (Cisco) 69 SB 695 1680 111 (RS/6000) 111 SB 560 1680 78 (NCSA) 78 SB 192 192 192 fC 651 489 755 573 7 10 RR 1 F S n 516 489 620 573 7 10 RR 1 F S n 365 489 470 573 7 10 RR 1 F S n 771 635 M -405 0 1 PP S n 711 573 M 0 62 1 PP S n 576 573 M 0 62 1 PP S n 426 573 M 0 62 1 PP S n 285 187 575 571 E S n 32 0 0 48 48 0 0 0 45 /Helvetica /font8 ANSIFont font 0 0 0 fC 471 652 264 (ncsl.nist.gov) 264 SB 32 0 0 28 28 0 0 0 26 /Helvetica /font8 ANSIFont font 383 443 85 (Cisco1) 85 SB 530 443 91 (3Com1) 91 SB 665 443 93 (Cursive) 93 SB 380 513 69 (Cisco) 69 SB 533 516 75 (3Com) 75 SB 665 516 78 (NCSA) 78 SB 32 0 0 48 48 0 0 0 45 /Helvetica /font8 ANSIFont font 861 777 201 (SURAnet) 201 SB 192 192 192 fC /fm 256 def 395 1300 500 1383 7 10 RR 1 F S n 32 0 0 28 28 0 0 0 26 /Helvetica /font8 ANSIFont font 0 0 0 fC 429 1254 84 (red-osi) 84 SB 410 1324 69 (Cisco) 69 SB 165 115 455 1351 E S n 32 0 0 48 48 0 0 0 45 /Helvetica /font8 ANSIFont font 336 1380 213 (cisco.com) 213 SB 336 1089 201 (BARRnet) 201 SB 381 1156 M 30 144 1 PP S n 561 1113 M 90 0 1 PP S n 936 843 M 0 62 1 PP S n 936 718 M 105 -82 1 PP S n 192 192 192 fC /fm 256 def 1356 447 1461 531 7 10 RR 1 F S n 1221 447 1326 531 7 10 RR 1 F S n 1221 594 M 256 0 1 PP S n 1417 531 M 0 63 1 PP S n 1282 531 M 0 63 1 PP S n 218 188 1348 530 E S n 0 0 0 fC 1252 611 222 (3com.com) 222 SB 32 0 0 28 28 0 0 0 26 /Helvetica /font8 ANSIFont font 1377 401 79 (Tuba1) 79 SB 1238 474 75 (3Com) 75 SB 1372 474 75 (3Com) 75 SB 1242 401 79 (Tuba2) 79 SB 936 718 M 0 42 1 PP S n 32 0 0 48 48 0 0 0 45 /Helvetica /font8 ANSIFont font 1009 577 104 (COS) 104 SB 756 533 M 180 185 1 PP S n 951 1674 M 90 -249 1 PP S n 192 192 192 fC /fm 256 def 1446 1611 1551 1695 7 10 RR 1 F S n 1311 1611 1416 1695 7 10 RR 1 F S n 1312 1758 M 255 0 1 PP S n 1507 1695 M 0 63 1 PP S n 1372 1695 M 0 63 1 PP S n 218 188 1438 1694 E S n 0 0 0 fC 1372 1775 166 (lanl.gov) 166 SB 32 0 0 28 28 0 0 0 26 /Helvetica /font8 ANSIFont font 1476 1565 63 (Tuba) 63 SB 1327 1638 78 (NCSA) 78 SB 1447 1638 104 (BSDi4.4) 104 SB 1338 1565 67 (Maze) 67 SB 1237 1551 M 75 103 1 PP S n 32 0 0 83 83 0 0 0 74 /Helvetica /font8 ANSIFont font 976 1018 281 (NSFnet) 281 SB 932 1143 370 (Backbone) 370 SB 32 0 0 48 48 0 0 0 45 /Helvetica /font8 ANSIFont font 1161 1492 131 (ESnet) 131 SB 1191 1487 M -45 -62 1 PP S n 255 255 255 fC /fm 256 def 368 271 2444 1195 E 1 F S n 0 0 0 fC 1867 1242 137 (CERN) 137 SB 1824 1014 190 (SWITCH) 190 SB 1567 1113 M 285 146 1 PP S n 1927 1092 M 0 125 1 PP S n 2032 1030 M 120 0 1 PP S n 32 0 0 83 83 0 0 0 74 /Helvetica /font8 ANSIFont font 2221 1081 434 (EuropaNET) 434 SB 2253 1205 370 (Backbone) 370 SB 192 192 192 fC 2197 510 2302 593 7 10 RR 1 F S n 2062 510 2167 593 7 10 RR 1 F S n 1912 510 2017 593 7 10 RR 1 F S n 2318 656 M -406 0 1 PP S n 2258 594 M 0 62 1 PP S n 2122 594 M 0 62 1 PP S n 1972 594 M 0 62 1 PP S n 285 187 2121 593 E S n 32 0 0 48 48 0 0 0 45 /Helvetica /font8 ANSIFont font 0 0 0 fC 1987 673 304 (research.ptt.nl) 304 SB 32 0 0 28 28 0 0 0 26 /Helvetica /font8 ANSIFont font 1925 464 95 (Tuba20) 95 SB 2075 464 95 (Tuba10) 95 SB 2207 464 102 (Lsdm10) 102 SB 1922 534 78 (NCSA) 78 SB 2078 536 78 (NCSA) 78 SB 2216 536 69 (Cisco) 69 SB 32 0 0 48 48 0 0 0 45 /Helvetica /font8 ANSIFont font 2378 723 198 (SURFnet) 198 SB 2303 552 M 165 166 1 PP S n 2468 781 M 0 145 1 PP S n 192 192 192 fC /fm 256 def 2528 1736 2632 1820 7 10 RR 1 F S n 2678 1736 2782 1820 7 10 RR 1 F S n 2543 1882 M 255 0 1 PP S n 2588 1820 M 0 62 1 PP S n 2738 1820 M 0 62 1 PP S n 217 187 2669 1819 E S n 0 0 0 fC 2573 1900 221 (upm.dit.es) 221 SB 32 0 0 28 28 0 0 0 26 /Helvetica /font8 ANSIFont font 2528 1690 120 (Cisco_iso) 120 SB 2694 1763 78 (NCSA) 78 SB 2546 1763 69 (Cisco) 69 SB 2683 1690 111 (Tuba-PC) 111 SB 192 192 192 fC /fm 256 def 2948 489 3053 573 7 10 RR 1 F S n 2813 489 2918 573 7 10 RR 1 F S n 2663 489 2767 573 7 10 RR 1 F S n 3068 635 M -405 0 1 PP S n 3008 573 M 0 62 1 PP S n 2873 573 M 0 62 1 PP S n 2723 573 M 0 62 1 PP S n 285 187 2873 571 E S n 32 0 0 48 48 0 0 0 45 /Helvetica /font8 ANSIFont font 0 0 0 fC 2798 652 181 (sintef.no) 181 SB 32 0 0 28 28 0 0 0 26 /Helvetica /font8 ANSIFont font 2689 443 69 (Cisco) 69 SB 2829 443 88 (Tuba-1) 88 SB 2965 443 88 (Tuba-2) 88 SB 2677 513 69 (Cisco) 69 SB 2829 516 78 (NCSA) 78 SB 2962 516 78 (NCSA) 78 SB 2543 926 M 120 -395 1 PP S n 192 192 192 fC /fm 256 def 2017 1611 2122 1695 22 31 RR 1 F S n 0 0 0 fC 2020 1565 115 (mercurey) 115 SB 2020 1635 92 (SunOS) 92 SB 142 115 2068 1663 E S n 32 0 0 48 48 0 0 0 45 /Helvetica /font8 ANSIFont font 2002 1700 132 (inria.fr) 132 SB 2528 1778 M -120 -311 1 PP S n 2017 1654 M -90 -333 1 PP S n 32 0 0 125 125 0 0 0 116 /Helvetica-Bold /font9 ANSIFont font 615 161 2175 (TUBA CONNECTIVITY AT JENC 1993) 2175 SB 32 0 0 42 42 0 0 0 38 /Helvetica /font8 ANSIFont font 1397 285 581 (Alex Reijnierse, May 17th 1993) 581 SB 1116 573 M 105 -83 1 PP S n 396 1342 M -135 -104 1 PP S n 261 1238 M 0 -624 1 PP S n 261 614 M 105 -83 1 PP S n 286 867 212 (Nist / Cisco) 212 SB 317 909 128 (Tunnel) 128 SB 32 0 0 33 33 0 0 0 29 /Times-Roman /font28 ANSIFont font 258 2100 1623 (TUBA Demonstration Coordinator: Alex Reijnierse, PTT Research, The Netherlands, e-mail: A.A.Reijnierse@research.ptt.nl) 1623 SB 255 255 255 fC /fm 256 def 2927 3 248 2095 B 1 F n 0 0 0 fC 2 2 245 2092 B 1 F n 2 2 245 2092 B 1 F n 2927 2 248 2092 B 1 F n 2 2 3176 2092 B 1 F n 2 2 3176 2092 B 1 F n 255 255 255 fC 2927 3 248 2137 B 1 F n 0 0 0 fC 2 2 245 2141 B 1 F n 2 2 245 2141 B 1 F n 2927 2 248 2141 B 1 F n 2 2 3176 2141 B 1 F n 2 2 3176 2141 B 1 F n 2 45 245 2095 B 1 F n 2 45 3176 2095 B 1 F n 1703 2183 17 (6) 17 SB EJ RS %%PageTrailer %%BeginPageSetup %%EndPageSetup SS 0 0 25 23 776 1169 300 SM 32 0 0 33 33 0 0 0 29 /Times-Roman /font28 ANSIFont font 0 0 0 fC 161 3134 1623 (TUBA Demonstration Coordinator: Alex Reijnierse, PTT Research, The Netherlands, e-mail: A.A.Reijnierse@research.ptt.nl) 1623 SB 255 255 255 fC /fm 256 def 2027 3 151 3129 B 1 F n 0 0 0 fC 2 2 148 3126 B 1 F n 2 2 148 3126 B 1 F n 2027 2 151 3126 B 1 F n 2 2 2179 3126 B 1 F n 2 2 2179 3126 B 1 F n 255 255 255 fC 2027 3 151 3171 B 1 F n 0 0 0 fC 2 2 148 3175 B 1 F n 2 2 148 3175 B 1 F n 2027 2 151 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 2 2179 3175 B 1 F n 2 45 148 3129 B 1 F n 2 45 2179 3129 B 1 F n 1156 3217 17 (7) 17 SB EJ RS %%PageTrailer %%Trailer SVDoc restore end % TrueType font name key: % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT310000 = % MSTT31c3ea = 360fDTimes New RomanF0000002e000001900000 % MSTT31c3f7 = 360fDTimes New RomanF00000021000001900000 %%DocumentSuppliedResources: procset Win35Dict 3 1 %%DocumentNeededResources: font Courier %%+ font Helvetica %%+ font Helvetica-Bold %%+ font Symbol %%+ font Times-Italic %%+ font Times-Roman %%EOF   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00812; 25 May 93 7:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ai00768; 25 May 93 7:09 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa01257; 25 May 93 5:19 EDT Received: by thumper.bellcore.com (4.1/4.7) id for grega@zippysun.math.uakron.edu; Tue, 25 May 93 02:12:05 EDT Received: from Valinor.Stanford.EDU by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Tue, 25 May 93 02:12:04 EDT Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA23306; Mon, 24 May 93 23:11:11 -0700 Date: Mon, 24 May 93 23:11:10 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Vince Fuller To: bsimpson@morningstar.com Cc: Robert Elz , pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: SIP Addressing Limitations In-Reply-To: Your message of Sat, 22 May 93 10:44:27 EDT Message-Id: > It amuses me greatly that there's anyone who still seriously > believes that network topology, and geography, are even remotely > related when it comes to international connections. > Apparently I am in good company. With Rehkter, Li, and the CIDR luminaries. I guess the fact that my name appears first on the CIDR document makes me a "CIDR luminary", so I'd like to emphatically refute your assertion. CIDR is basically a hack which attempts to provide, with minimal impact on Internet hosts, better scaling of routing in a system which has horribly confused the two distinct concepts of Name (that which uniquely identifies a communicating object) and Address (that which describes where an object is located). The techniques described in CIDR should most definitely NOT be used as an example of a well-designed naming, addressing, and routing architecture. If the best SIP/IPAE can come up with for dealing with the addressing/naming problem is to be "just like CIDR", than the Internet is in real trouble in the long run. If you read CIDR carefully, you will see that for it to work really well, fairly constraints must be placed on the topology of the Internet (i.e. most sites are singly-homed and provider mobility is relatively rare). As the Internet topology becomes more complex and as entropy (i.e. network mobility) is introduced into the system, the benefits of CIDR-style aggregation are much diluted over time. Until SIP/IPAE can produce a real solution to the "re-addressing problem" (which applies to both geographic- and provider-based "addressing"), you can spend multi-100's of hours on an "addressing" plan which simply won't produce good aggregation in a poorly-constrained Internet topology. --Vince   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00837; 25 May 93 7:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id an00768; 25 May 93 7:09 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa01720; 25 May 93 5:49 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA00511; Tue, 25 May 93 01:27:21 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29913; Tue, 25 May 93 01:26:57 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29909; Tue, 25 May 93 01:26:56 MDT Received: from crl.dec.com by p.lanl.gov (5.65/1.14) id AA00487; Tue, 25 May 93 01:26:59 -0600 Received: by crl.dec.com; id AA23528; Tue, 25 May 93 03:26:58 -0400 Received: by easynet.crl.dec.com; id AA05630; Mon, 24 May 93 14:02:09 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: perlman@radia.enet.dec.com Message-Id: <9305241802.AA05630@easynet.crl.dec.com> Received: from radia.enet; by crl.enet; Mon, 24 May 93 14:13:13 EDT Date: Mon, 24 May 93 14:13:13 EDT To: tuba@lanl.gov Apparently-To: tuba@lanl.gov Subject: non-unique IEEE addresses First of all, I think it's less likely that manufacturers will misconfigure the addresses than the people configuring the routers. But regardless, if somehow two systems get assigned the same IEEE address it really isn't that much of a problem. If the two systems are in different areas, there is no problem at all. They each autoconfigure, get different network layer addresses (because one is USA.MASS.Radia and the other is Albania.Radia), and nobody will ever know or care. If it did happen that there were two Radias in the same area, then the only problems are for those two systems. I don't think the probability of a problem is high enough to worry about it, but here's a nice simple solution that might be worth doing because it would be nice for other reasons. How about having the naming service not only have a mapping from name to NL address, but also have the naming service have a mapping from NL address to name. That way, when your system comes up and discovers its address, it registers itself in the Naming Service in both places. If, when it tries to register its NL address it discovers there's already that address registered with a different name, then people can sort out what the problem is, if any. Having the inverse mapping in the naming service (NL address to name) is undoubtedly going to be useful for management reasons anyway. Radia   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00844; 25 May 93 7:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ao00768; 25 May 93 7:09 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa01730; 25 May 93 5:49 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA00356; Tue, 25 May 93 01:14:07 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29898; Tue, 25 May 93 01:13:43 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA29894; Tue, 25 May 93 01:13:42 MDT Received: from crl.dec.com by p.lanl.gov (5.65/1.14) id AA00344; Tue, 25 May 93 01:13:44 -0600 Received: by crl.dec.com; id AA20083; Tue, 25 May 93 03:13:38 -0400 Received: by easynet.crl.dec.com; id AA08995; Mon, 24 May 93 16:37:28 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: perlman@radia.enet.dec.com Message-Id: <9305242037.AA08995@easynet.crl.dec.com> Received: from radia.enet; by crl.enet; Mon, 24 May 93 16:37:39 EDT Date: Mon, 24 May 93 16:37:39 EDT To: tuba@lanl.gov Apparently-To: tuba@lanl.gov Subject: Some suggestions for use of CLNP I assume that TUBA doesn't necessarily have to accept CLNP completely as is. There are some minor things that I think would make CLNP even more useful. They're not even necessarily "changes" per se, but instead might be "how we're going to use CLNP". Anyway, here goes: 1) maybe we want to fix the address length at 20 octets, instead of having it be variable length 2) I think the AFI for E.164 should have a "which provider" field, preferably globally administered, though we could do the usual trick of having half the addresses globally administered and half local. I'll explain this in depth at the end of the message. The best way to provide this is with a new AFI, which means "E.164 plus provider" 3) As long as we're doing a new AFI, let's define it as having the padding on the right rather than the left, so that address prefix routing works a little better with variable length telephone numbers 4) We maybe ought to specify that ESs don't need to advertise every NSAP in ES Hellos. I think routers ignore the SEL octet, so why not simplify things by saying that routers will ignore the SEL octet, and if you advertise with a single SEL value (say 0), that means you want to receive any NSAP that matches up to the final octet. OK, now to explain 2. E.164 is unfortunately geographically based, which means that if there's an ISDN net and an SMDS net both in NJ, there's no address prefix that would specify which network something is on. If you were indeed attached to both nets and had the option of forwarding the packet into one or the other, the only way you could make an intelligent decision would be to have complete listings of all the individual phone numbers on each net. Some people claim it doesn't matter -- that all the nets that provide E.164 addressing are supposed to be able to forward to one another. That may be true, but it will definitely give you better service to get right to the correct network, not to have to depend on lots of inter-network gateways. The current NSAP with E.164 looks like: 1 8 up to 11 # of bytes +-----+-------+-----------------+ | AFI | E.164 | rest of address | +-----+-------+-----------------+ The proposed new AFI would look like: 1 2 8 2 6 1 +-----+---------+-------+----------+----+-----+ | new | which | E.164 | Loc-area | ID | SEL | | AFI | network | | | | | +-----+---------+-------+----------+----+-----+ All that's required is to assign an AFI for this purpose. There's enough room for a 2-octet "which network" field. I'd guess that there will be a difference of opinion on whether the field ought to be globally assigned, so I'd suggest that TUBA allocate half of them for global assignment and half for local assignment. And, while we're at it, the E.164 address, if it isn't 8 octets, should be padded on the right rather than the left, since this is more convenient for address prefix routing. Adding the "which network" field still has enough room so that a private network hanging off an E.164 network can use its E.164 address in an embedded manner and also be so large that there's 2 octets worth of hierarchy for use in the private network.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02255; 25 May 93 8:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02249; 25 May 93 8:42 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa05247; 25 May 93 8:42 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA07804; Tue, 25 May 93 06:36:33 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00473; Tue, 25 May 93 06:34:18 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00469; Tue, 25 May 93 06:34:17 MDT Received: from worldlink.com by p.lanl.gov (5.65/1.14) id AA07726; Tue, 25 May 93 06:34:14 -0600 Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA23242; Tue, 25 May 93 08:34:11 -0400 Date: Tue, 25 May 93 08:34:11 -0400 Message-Id: <9305251234.AA23242@worldlink.worldlink.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David M. Piscitello" To: tuba@lanl.gov Subject: FYI: Paul Traina's request for sunOS tuba, Paul Traina's "request" Since we appear to be posting "wish-list" items, I'll trade the following for a MACHten tuba implementation: - a circa 1960 Brooks Robinson signature baseball glove (kidsize) - 2 softballs - a 4/10 XT clone, dual-floppy - an 8-track cassette - an ascii version of 9542 and 8473 (I'm doing this anyway, but I may as well leverage everything I can out of the work:-) - a set of Denver the Dinosaur stickers - 3 tickets to a "breakfast with Barney" ------ Forwarded Message I'll trade a DNS for TUBA for a SunOS implementation. :-) ------ End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02426; 25 May 93 8:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02422; 25 May 93 8:57 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa05647; 25 May 93 8:57 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA08298; Tue, 25 May 93 06:55:35 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00539; Tue, 25 May 93 06:55:03 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00535; Tue, 25 May 93 06:55:01 MDT Received: from concorde.inria.fr by p.lanl.gov (5.65/1.14) id AA08266; Tue, 25 May 93 06:54:59 -0600 Received: from givry.inria.fr by concorde.inria.fr; Tue, 25 May 1993 14:53:17 +0200 Received: by givry.inria.fr; Tue, 25 May 1993 14:53:16 +0200 Message-Id: <199305251253.AA10676@givry.inria.fr> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Francis Dupont To: Keith Sklower Cc: tuba@lanl.gov, dave@mail.bellcore.com, dino@cisco.com Subject: Re: final word on pseudo-header In-Reply-To: Your message of Mon, 24 May 1993 15:40:57 PDT. <199305242240.PAA03508@vangogh.CS.Berkeley.EDU> Date: Tue, 25 May 1993 14:53:11 +0200 X-Orig-Sender: Francis.Dupont@inria.fr X-Charset: ASCII X-Char-Esc: 29 In your previous mail you wrote: Although this may sound different, I believe that Dino & I aggree on the quantity to be computed. An alternative way of describing the checksum calculation is to say that you start with the pseudo- header for a TCP/UDP packet and replace the 8 bytes of src and destination IP address, by the destination and source address portion of the CLNP packet, possibly extended to even length by a zero byte of padding. => I can confirm: Dino & you agree on the checksum (I've verified with an odd destination address). I prefer your alternative way of describing the pseudo-header even if it is not exactly the best way to implement it (but it shows the good way to implement TCP/UDP checksum update in a IP<->CLNP translator: intermediate_checksum <- checksum(incoming_pseudo_header,incoming_checksum) outgoing_checksum <- checksum(outgoing_pseudo_header,intermediate_checksum) and it is possible to use only the changing part of pseudo-headers, i.e. addresses). Regards Francis.Dupont@inria.fr PS: here is my current code: nlen macro return NSAP address length (including NSEL) nsap macro return NSAP address (including NSEL) cnt is the length of the CLNP data part (i.e. TCP header and data) inet_cksum works on the pseudo-header plen and the buffer with CLNP data /* verify the TCP checksum */ phead[0] = nlen(tdst); (void) bcopy(nsap(tdst), phead+1, nlen(tdst)); plen = 1 + nlen(tdst); phead[plen++] = nlen(tsrc); (void) bcopy(nsap(tsrc), phead+plen, nlen(tsrc)); plen += nlen(tsrc); if ((plen & 1) == 0) phead[plen++] = 0; phead[plen++] = IPPROTO_TCP; phead[plen++] = cnt >> 8; phead[plen++] = cnt & 0xff; cksum = inet_cksum(plen, cnt); if (cksum != 0) fprintf(stderr, "tcp header cksum = %d\n", cksum);   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02705; 25 May 93 9:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02701; 25 May 93 9:11 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa06200; 25 May 93 9:11 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA09320; Tue, 25 May 93 07:09:35 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00614; Tue, 25 May 93 07:07:06 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA00610; Tue, 25 May 93 07:07:03 MDT Received: from mts-gw.pa.dec.com by p.lanl.gov (5.65/1.14) id AA09052; Tue, 25 May 93 07:06:56 -0600 Received: by mts-gw.pa.dec.com; id AA22488; Tue, 25 May 93 06:06:46 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3) id AA13891; Tue, 25 May 1993 09:06:38 -0400 To: perlman%radia.dnet.dec.com@sneezy.lkg.dec.com Subject: Re: non-unique IEEE addresses In-Reply-To: <9305241802.AA05630@easynet.crl.dec.com> References: <9305241802.AA05630@easynet.crl.dec.com> Cc: tuba@lanl.gov X-Mailer: Poste 2.1 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Oran Date: Tue, 25 May 93 09:06:38 -0400 Message-Id: <930525090638.430@sneezy.lkg.dec.com.-v> >...but here's > a nice simple solution that might be worth doing because it would > be nice for other reasons. How about having the naming service > not only have a mapping from name to NL address, but also have > the naming service have a mapping from NL address to name. That > way, when your system comes up and discovers its address, it > registers itself in the Naming Service in both places. If, when > it tries to register its NL address it discovers there's already > that address registered with a different name, then people can > sort out what the problem is, if any. Having the inverse mapping > in the naming service (NL address to name) is undoubtedly going > to be useful for management reasons anyway. > Some major Naming services I know about (DNS, DECdns) already keep reverse mappings. However, there are two flies in this ointment. The first is is how you deal with name changes. These may not happen as often as address changes, but you need to distinguish this case, possibly by the host remembering some of its "past names". The other is how you eliminate spoofing of the reverse mappings, since the host must be allowed to re-register mappings when its address changes (e.g. for mobility reasons). If there is an encryption-based authentication procedure independent of the name-to-address mappings available for tlaking to the nameing service, this can be done without too much pain. Unfortunately, however, many naming services use the reverse map itself for authentication purposes (most TCP applications, DECnet Phase V, etc.) and this leads to circular dependencies and in one case I know in fact led to an infinite recursion. Dave Oran.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06543; 25 May 93 12:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06539; 25 May 93 12:50 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa12998; 25 May 93 12:50 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA26933; Tue, 25 May 93 10:45:58 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA02587; Tue, 25 May 93 10:44:59 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA02582; Tue, 25 May 93 10:44:57 MDT Received: from munnari.OZ.AU by p.lanl.gov (5.65/1.14) id AA26784; Tue, 25 May 93 10:44:43 -0600 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08687; Tue, 25 May 1993 15:22:39 +1000 (from kre@munnari.OZ.AU) To: Ross Callon Cc: perlman@radia.enet.dec.com, tuba@lanl.gov Subject: Re: Thing I promised to write up about TUBA advantages. In-Reply-To: Your message of "Mon, 24 May 1993 13:24:57 EDT." <9305241724.AA04317@cabernet.wellfleet> Date: Tue, 25 May 1993 15:22:27 +1000 Message-Id: <14380.738307347@munnari.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Elz Date: Mon, 24 May 93 13:24:57 EDT From: rcallon@cabernet.wellfleet.com (Ross Callon) Message-ID: <9305241724.AA04317@cabernet.wellfleet> Unfortunately its a fiction to believe that any IEEE address is globally unique, or even necessarily locally unique. Is this any different than IP addresses? In effect when it happens, no, not a lot. Although IEEE addresses could in principle be erroneously assigned to be non-unique, I have not heard of this happening. Frank K has said something about this, and I'd heard of it happening from another source, in general its not going to be easy to detect, we may easily have dup IEEE addresses on this campus, but we currently have no way to know that, as they'd only be detected if they were on the same cable (so ARP started thrashing), and in general the numbers of devices on each cable is small enough that its not likely. In contrast, I have heard many cases of IP addresses being assigned erroneously. Certainly, I'd say that this is far more likely. There is one major difference though, one huge difference... In the near future, we (the communications industry) are increasingly going to be selling data communications to non-technical folks which is the basic problem of course. Let it be understood that I am not in any way suggesting that IPv4 address assignment methods are ideal, or anything even close, so keep that in mind - but even with IPv4 there's a major advantage over any automatic method that isn't fail proof. If I (as any non-technical user), read the manual, or whatever it takes (or try something, have it fail, and then read the manual) and configure my IP address, then receive diagnostics saying "duplicate IP address" or similar, then see in the manual something about "addresses must be unique", even as the most naive of users I'm going to have a pretty good idea what has gone wrong, and how to fix it - after all I just invented the IP address, and the system is complaining that the one I invented is no good - clearly I need to invent a different one and try that. This is no more conceptually difficult than coping with imperial bolts that almost, but not quite, fit in metric nuts... On the other hand, if the system complains about duplicate addresses when I plug it in, or even worse, if it doesn't even bother to check, and simply assumes its address is OK, then connections randomly fail when half the packets go to the wrong place - then the naive user has a real problem, they've done nothing wrong at all, followed the instructions faithfully, and things still don't work. This is not nice at all. Automation is fine, and certainly its nice to have things simply happen, but if its going to work that way, it HAS to work reliably, every time, and not be prone to mysterious failures, and certainly not to mysterious failures that we can forsee now, as opposed to things that may happen in practice that we can't currently imagine. If that level of reliability can't be guaranteed, then its better to simply make the users learn a bit more, and do a bit more work, it will certainly be more difficult, and that will be a barrier, but at least its not promising something that can't be delivered. Do you have any suggestions regarding how to make address configuration easy for the future non-technical user? Not a lot - but one is that worrying about the serial numbering of individual boxes on the net is the wrong place to start to worry - that's something even the most non-technical can probably manage. The major problem with IPv4 addresses isn't assigning the lowest octet (or whatever) of the address, people can usually manage 1 2 3 ..., its the rules for forming the rest of the address, and what is permitted, and what isn't. Automating the assignment of the least significant part of the address isn't solving the difficult problem, its solving the easy part (though certainly the boring repititious part). The challenge is to find an automated way to assign the upper part of the address in a fashion that meets the requirements of the (wide area) net that the system will be connected to, and either make that work when that net is not yet known (people buy their PC first, use it at home, then learn about networking later, the same will be true of home lans), or have the system adjust the upper part of the address automatically when a connection is made to a WAN where the current addressing is unsuitable. This is true for IPv4, TUBA, and SIP, and perhaps PIP, I'm less sure about that one. If we can solve this challenge, then handling the lower order numbering shouldn't be too difficult - it doesn't necessarily mean having a human sit typing names/addresses into some file, though sometime, somehow, commodity parts need to be configured for their local uses - that may be by assuming that bus/ring nets won't be what's used, and that future nets may be star based, with an intelligent star controller, and that configuring the local net will be a matter of configuring the star controller. Once told that port 127 is "master bedroom overhead light bulb number 2", then nothing needs to change as the light bulb is replaced, and yet the user (or his system) still has a way to communicate with that light bulb in particular. On the other hand, if we still have common use nets, and MAC type addresses, then perhaps the right method is for the system to use its MAC address as a key to communicate with a server of some kind (which should probably be one of the functions of a router - if there's no server, ie: no router, then local cable broadcast can be used to validate an address which must, or necessity, be of local significance only). The server can see if it has assigned an address to that particular MAC address before, if it has and the system appears to be the same one as last time - some additional information would need to be passed, system type, serial number if its available, ... - then assign the same address, and in other cases, create a new one dynamically, insert it in a directory if an automated means to do that is available (this is a challenge, as something, somewhere, needs to invent the human recognisable description of the node to go in the directory with the address), and return it to the node. If the MAC addresses are duplicates, then all should still work unless they're both connected to the same cable. kre   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07065; 25 May 93 13:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07061; 25 May 93 13:49 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa14603; 25 May 93 13:49 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA01402; Tue, 25 May 93 11:47:59 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03367; Tue, 25 May 93 11:47:15 MDT Return-Path: <@bronze.bbn.com:jcurran@nic.near.net> Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA03363; Tue, 25 May 93 11:47:14 MDT Received: from nic.near.net by p.lanl.gov (5.65/1.14) id AB01286; Tue, 25 May 93 11:47:14 -0600 Message-Id: <9305251747.AB01286@p.lanl.gov> Received: from BRONZE.BBN.COM by nic.near.net id aa16056; 25 May 93 13:46 EDT To: Robert Elz Cc: Ross Callon , perlman@radia.enet.dec.com, tuba@lanl.gov Subject: Re: Thing I promised to write up about TUBA advantages. In-Reply-To: Your message of Tue, 25 May 1993 15:22:27 +1000. <14380.738307347@munnari.OZ.AU> Date: Tue, 25 May 1993 13:44:12 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Curran -------- From: Robert Elz Subject: Re: Thing I promised to write up about TUBA advantages. Date: Tue, 25 May 1993 15:22:27 +1000 ... On the other hand, if the system complains about duplicate addresses when I plug it in, or even worse, if it doesn't even bother to check, and simply assumes its address is OK, then connections randomly fail when half the packets go to the wrong place - then the naive user has a real problem, they've done nothing wrong at all, followed the instructions faithfully, and things still don't work. This is not nice at all. I agree: things should work reliably. This means that systems should check for such items as duplicate addresses, or we should engineer it such that a duplicate address is not possible. ... On the other hand, if we still have common use nets, and MAC type addresses, then perhaps the right method is for the system to use its MAC address as a key to communicate with a server of some kind (which should probably be one of the functions of a router - if there's no server, ie: no router, then local cable broadcast can be used to validate an address which must, or necessity, be of local significance only). The server can see if it has assigned an address to that particular MAC address before, if it has and the system appears to be the same one as last time - some additional information would need to be passed, system type, serial number if its available, ... - then assign the same address, and in other cases, create a new one dynamically, insert it in a directory if an automated means to do that is available (this is a challenge, as something, somewhere, needs to invent the human recognisable description of the node to go in the directory with the address), and return it to the node. If the MAC addresses are duplicates, then all should still work unless they're both connected to the same cable. Unless I'm mistaken, the net result is the same: Non-duplicate MAC addresses work fine (with KRE autoconfig or ESIS) Duplicate MAC addresses prevent proper functioning (until one of the systems is manually configured to a new global or local IEEE id) There only difference is that your scheme uses server generated addresses, whereas the current autoconfiguration simply uses a sysid value which happens to the taken from the IEEE id in the common case. If either case, there had better be a very well worded message if two systems using the same MAC address appear on the local network, regardless of network layer autoconfiguration. Look folks, if systems are shipped with presumably unique identifier, then we have a default behavior which is useful. It does not inhibit anyone from using IPv4 address, employee ids, or office numbers for their system id's if they desire. /John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07754; 25 May 93 14:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07750; 25 May 93 14:16 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa15415; 25 May 93 14:16 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 25 May 93 14:16:24 EDT Received: from munnari.oz.au by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-pip X-pip; Tue, 25 May 93 14:16:17 EDT Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00425; Wed, 26 May 1993 01:18:44 +1000 (from kre@munnari.OZ.AU) To: bsimpson@morningstar.com Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov Subject: Re: SIP Addressing Limitations In-Reply-To: Your message of "Sat, 22 May 1993 10:44:27 EDT." <1202.bill.simpson@um.cc.umich.edu> Date: Wed, 26 May 1993 01:18:33 +1000 Message-Id: <14546.738343113@munnari.OZ.AU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Elz Date: Sat, 22 May 93 10:44:27 EDT From: "William Allen Simpson" Message-ID: <1202.bill.simpson@um.cc.umich.edu> According to public CIA reports, all 3 have communications links with each other, including radio, television, undersea cable, and satellite. Oh, you are limiting this to "internet" links? Of course I am, internet topology is what we're talking about isn't it? What happens with radio, TV, or almost anything else isn't relevant at all. I assume you're not seriously suggesting that we should base internet addressing on which TV programs we get to watch? You expect that the current situation is permanent? No. I expect that I have no idea whatever what will happen in the future, and nor does anyone else. Again, even if Japan and every other country on the planet split into 10 parts which refuse to talk to each other except through a 3rd party, the plan provides an order of magnitude better than we currently have, and *never* gets worse. And since a 3rd party is likely to be geographically close, no no no ... this is exactly what I first sent the message to complain about - there is absolutely no liklihood of any such thing, its no more likely than that the 3rd party may be the furthest possible place. But talking exclusively through a third part is the easy case, and also the one that's not likely to happen, the difficult one is where they talk to each other locally, but refuse to handle international traffic for each other - and that's the likely one. No, you are incorrect. Any link that you actually *build* will cost considerably more from Australia to the US east coast than to the west coast. No, you are incorrect - any link *I* build will cost me exactly the same. But note that neither I, nor any other internet provider I imagine (including MCI etc) actually do the physical work in building intercontinental links, that's done by companies (generally owned by consortia of the phone companies, and governments) that do nothing else. It costs me (or did until recently, I haven't checked in the past year or so) exactly the same for link to New Zealand as it does to either US coast (note that a link to somewhere in the middle of the continental US costs rather more). You are talking about combining several shared links into a long path. These links are actually switched at various points. Certainly - but that's done by whoever I buy the link from. As long as they don't charge me any more, why should I care. As there are usually reasons why these links of links are made (enough to offset the slightly increased failure rate to be expected, and the slightly longer transit delay) if it costs the same, I'll do it that way if the advantage is great enough. (Before paccom appeared, an east coast link for Aust was exactly what I was planning). Whether the carrier who sells me the service makes less profit if I buy the east coast link than they do if I buy the west coast one, and why they'd want to charge the same in that case is something I neither know nor care about. You may be referring to the fact that current US *internet* traffic from some Asian countries passes through somewhere on the east coast. Again, yes, of course, the internet is all that is relevant here. That is merely an effect of US "policy" (single interconnect between providers), and has nothing to do with topology. That policy is already scheduled to be obsolete. US policy has nothing whatever to do with most of this, the links arrive at the US east coast for totally unrelated reasons. In one case I know of it was inertia (a bitnet link turned into an internet link was installed to the same site), in another it was taking advantage of the generosity of the provider (they charge nothing to house the US end of the link). These kind of factors will continue influence where links go more than geography. Now, do you have a better plan? No, and if you read my messages, you'll see that I didn't object to it as such - just to the use of an example suggesting that geographic proximity would have some effect on where links would be installed. Forget geography, addresses matter based on (inter)net topology, that's how routes aggregate. Having addresses assignable by countries (or regions) is politcally attractive, and economically attractive (its much easier to provide just the right amount of funding to support these activities inside a politiocal entity than outside it). Actually assigning addresses that are based on political boundaries is much less attractive. kre   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08496; 25 May 93 15:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08492; 25 May 93 15:06 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa17077; 25 May 93 15:06 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA12799; Tue, 25 May 93 13:04:27 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA04045; Tue, 25 May 93 13:03:49 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA04041; Tue, 25 May 93 13:03:48 MDT Received: from atc.boeing.com by p.lanl.gov (5.65/1.14) id AA12755; Tue, 25 May 93 13:03:49 -0600 Received: by atc.boeing.com (5.57) id AA21175; Tue, 25 May 93 12:07:55 -0700 Date: Tue, 25 May 93 12:07:55 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eric Fleischman Message-Id: <9305251907.AA21175@atc.boeing.com> To: perlman@radia.enet.dec.com, tuba@lanl.gov Subject: Re: Some suggestions for use of CLNP Cc: ericf@p.lanl.gov Dear Radia, The purpose of this note is to strongly object to the key suggestion of your latest message. This key element is as follows: >From: perlman@radia.enet.dec.com >2) I think the AFI for E.164 should have a "which provider" field, > preferably globally administered, though we could do the usual > trick of having half the addresses globally administered and half > local. I'll explain this in depth at the end of the message. > The best way to provide this is with a new AFI, which means "E.164 > plus provider" ... > Adding the "which network" field still has enough room so that > a private network hanging off an E.164 network can use its E.164 > address in an embedded manner and also be so large that there's > 2 octets worth of hierarchy for use in the private network. Before I state my objection, I first of all wish to acknowledge that I may have "mis-read" what you are proposing. This possibility is conceivable because we have had *extreme* problems with provider-based addressing in the X.400 domain and so I have a very-emotional "gut-level" reaction to most provider-based schemes. Unfortunately, this emotionalism may cause me to inadequately "hear" what you have written. If so, I apologize in advance. With the above warning, I wish to state that I *STRONGLY OBJECT* to any NSAP addressing scheme which inbeds network provider information within the NSAP. Addressing is a very difficult, complex, and expensive proposition for very large companies. Even with automated addressing techniques such as DHCP (for IP) and DECnet/OSI auto-addressing, it remains a surprisingly difficult feat to account for (i.e., not lose) addresses and to correctly map those addresses to names within the very tight (and non-forgiving) constraints demanded by our users. Many TCP/IP protocol implementations (e.g. DNS) are currently unsuitable for our production environments simply because the products which implement them can not meet the demands of these environments. This is mentioned solely to alert you to the great seriousness of the current failure of many essential and venerable protocols to adequately perform as vendors expected: current technologies are marginally robust at best for large deployments. "Shaking the boat" with significant and new deployment directions is a frightening concept unless there exists adequate time to thoroughly test these new directions in large-scale test environments. All this is to say that your provider-information idea may appear trivial from where you sit but it appears as a risky proposition from where I sit. As the Internet becomes an increasingly competitive environment with a variety of network providers, most companies will desire to have its addresses de-coupled from whatever service provider currently provides its networking services. There are a variety of reasons which may cause an end-user to rapidly switch between network providers -- or to simultaneously use different providers for different environments. Such changes in providers must not imply a need to re-address corporate entities. This difficulty will become immediately obvious if one views the number of (corparate) hosts in the hundreds-of-thousands rather than merely in the thousands. If this allusion to granularity size of the deployment did not communicate the direct implications of scale to the matter at hand, please contact me for a more adequate explanation of this obvious point. CCITT X.400-1984 had a number of serious problems which were ultimately resolved in the MOTIS (ISO 10021) "equivalent standard". Among them was the required use of the ADMD (i.e., the equivalent of "network provider") in the X.400 application address. This requirement presupposed that each PRMD (e.g., the end-user company) would have at most one ADMD to service it. In any case, all X.400 addresses of that vintage required that the company's X.400 address must have both the ADMD and PRMD specified as address components. As a point of fact, many companies have multiple ADMDs and the X.400-1984 requirement that each of these X.400 "nodes" be addressed with multiple addresses (differing only in ADMD value) proved to be untenable. For this reason, the MOTIS varient, which made it possible for ADMD values to be "wild-carded" (unassigned), proved to be a hard requirement to make X.400 "deployable". Note: the motivation for the original flawed X.400-1984 approach was parallel to your current argument. Also note that the original provider-identification feature of X.400-1984 was one of the chief roadblocks hindering X.400 deployments. Main point of paragraph: do not bind addresses to providers. Interdomain IS-IS presupposes that each communicating domain conducts up-front "negotiations" with each other to decide a number of important policy matters such as security. It may well be that we will use different providers for different customers/suppliers. However, the paths to those customers/suppliers must remain unconstrained and flexible. Embedding provider information into the network address does not accomplish this goal and needlessly constrains our options. For those of us with deployed OSI nodes, one of the advantages of TUBA was that TUBA was flexible enough to accomodate our current deployments. A specific TUBA AFI may be desirable as a migration approach (e.g., IPAE-like approach to indicate that the lower four octets are an IP address) for TUBA, but the approach as a whole needs to accomodate our existing US GOSIP NSAPs -- or whatever else we may have deployed. However, a similar thing could also be accomplished via other mechanisms (e.g., use the US GOSIP "reserved" field to signify such an embedding). The single goal of the above was to state that NSAP addressing should be decoupled from whichever provider "temporarily" is used to deliver the message. This message did not address in any way the implications of a provider-based scheme such as PIP which is designed to explicitly remove much of the provider-related "penalty". That is, the topic for this discussion is solely limited to NSAP-based addressing rather than provider-based addressing in general. Sincerely yours, --Eric Fleischman   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08748; 25 May 93 15:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08744; 25 May 93 15:29 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa17909; 25 May 93 15:29 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA14576; Tue, 25 May 93 13:26:23 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA04392; Tue, 25 May 93 13:26:02 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA04388; Tue, 25 May 93 13:26:01 MDT Received: from is.rice.edu by p.lanl.gov (5.65/1.14) id AA14532; Tue, 25 May 93 13:26:01 -0600 Received: from sabine.is.rice.edu by is.rice.edu (AA24629); Tue, 25 May 93 14:25:57 CDT Received: by sabine.is.rice.edu (AA02382); Tue, 25 May 93 14:25:56 CDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Manning Message-Id: <9305251925.AA02382@sabine.is.rice.edu> Subject: Re: Thing I promised to write up about TUBA advantages. To: Robert Elz Date: Tue, 25 May 93 14:25:54 CDT Cc: rcallon@cabernet.wellfleet.com, perlman@radia.enet.dec.com, tuba@lanl.gov In-Reply-To: <14380.738307347@munnari.OZ.AU>; from "Robert Elz" at May 25, 93 3:22 pm X-Mailer: ELM [version 2.3 PL11] > Frank K has said something about this, and I'd heard of it > happening from another source, in general its not going to > be easy to detect, we may easily have dup IEEE addresses on > this campus, but we currently have no way to know that, as > they'd only be detected if they were on the same cable (so > ARP started thrashing), and in general the numbers of devices > on each cable is small enough that its not likely. ... > MAC type addresses, then perhaps the right method is for the > system to use its MAC address as a key to communicate with > a server of some kind (which should probably be one of the > functions of a router - if there's no server, ie: no router, > then local cable broadcast can be used to validate an address > which must, or necessity, be of local significance only). ... > directory with the address), and return it to the node. If > the MAC addresses are duplicates, then all should still work > unless they're both connected to the same cable. > I concur with Frank. I used to work on a global bridged network & ran into this very problem. And, if I am reading the ATM activity with even limited understanding, one of the ATM choices will look a lot like a huge local cable. Troubleshoot that one.... -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10554; 25 May 93 17:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10550; 25 May 93 17:49 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa22553; 25 May 93 17:49 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA28558; Tue, 25 May 93 15:46:10 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA05903; Tue, 25 May 93 15:44:36 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA05899; Tue, 25 May 93 15:44:34 MDT Received: from relay.hp.com by p.lanl.gov (5.65/1.14) id AA28123; Tue, 25 May 93 15:44:31 -0600 Received: from hpindda.cup.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA15981; Tue, 25 May 93 14:44:28 -0700 Received: by hpindda.cup.hp.com (15.11/15.5+IOS 3.20+cup+OMrelay) id AA08248; Tue, 25 May 93 14:46:55 pdt Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eva Kuiper Message-Id: <9305252146.AA08248@hpindda.cup.hp.com> Subject: Re: Some suggestions for use of CLNP To: ericf@atc.boeing.com Date: Tue, 25 May 93 14:46:52 PDT Cc: perlman@radia.enet.dec.com, tuba@lanl.gov, ericf@p.lanl.gov In-Reply-To: <9305251907.AA21175@atc.boeing.com>; from "Eric Fleischman" at May 25, 93 12:07 (noon) Mailer: Elm [revision: 64.9] Dear Eric, I think that you and Radia are both right, in different ways. I look at E.164 the same as X.121 where we have the provider and "routing" information built into the address. The DNIC followed by what looks a lot like a phone number with area code etc serves to route through all the switches between me and the next site, and on through X.75 if necessary. So in this way this type of addressing is useful. When you change providers you, of course, have to go through the pain of informing everyone that your address has changed if you maintain application layer as well as network layer connectivity with other folks. You need to change your end system configuration as well. So this is an inconvenience if it is one system as well as a very real pain if it is a whole company network! Now if folks were working on the auto-configuration ideas you have been suggesting over the years, then we could use Radia's ideas and then apply yours to them when the provider changes and all would be well! Eva > > Dear Radia, > > The purpose of this note is to strongly object to the key suggestion > of your latest message. This key element is as follows: > > >From: perlman@radia.enet.dec.com > >2) I think the AFI for E.164 should have a "which provider" field, > > preferably globally administered, though we could do the usual > > trick of having half the addresses globally administered and half > > local. I'll explain this in depth at the end of the message. > > The best way to provide this is with a new AFI, which means "E.164 > > plus provider" > ... > > Adding the "which network" field still has enough room so that > > a private network hanging off an E.164 network can use its E.164 > > address in an embedded manner and also be so large that there's > > 2 octets worth of hierarchy for use in the private network. > > Before I state my objection, I first of all wish to acknowledge that I > may have "mis-read" what you are proposing. This possibility is > conceivable because we have had *extreme* problems with provider-based > addressing in the X.400 domain and so I have a very-emotional "gut-level" > reaction to most provider-based schemes. Unfortunately, this > emotionalism may cause me to inadequately "hear" what you have written. > If so, I apologize in advance. > > With the above warning, I wish to state that I *STRONGLY OBJECT* to any > NSAP addressing scheme which inbeds network provider information within > the NSAP. > > Addressing is a very difficult, complex, and expensive proposition for > very large companies. Even with automated addressing techniques such as > DHCP (for IP) and DECnet/OSI auto-addressing, it remains a surprisingly > difficult feat to account for (i.e., not lose) addresses and to correctly > map those addresses to names within the very tight (and non-forgiving) > constraints demanded by our users. Many TCP/IP protocol implementations > (e.g. DNS) are currently unsuitable for our production environments simply > because the products which implement them can not meet the demands of > these environments. This is mentioned solely to alert you to the great > seriousness of the current failure of many essential and venerable > protocols to adequately perform as vendors expected: current > technologies are marginally robust at best for large > deployments. "Shaking the boat" with significant and new > deployment directions is a frightening concept unless there exists > adequate time to thoroughly test these new directions in large-scale > test environments. All this is to say that your provider-information > idea may appear trivial from where you sit but it appears as a risky > proposition from where I sit. > > As the Internet becomes an increasingly competitive environment with a > variety of network providers, most companies will desire to have its > addresses de-coupled from whatever service provider currently provides > its networking services. There are a variety of reasons which may > cause an end-user to rapidly switch between network providers -- or > to simultaneously use different providers for different environments. Such > changes in providers must not imply a need to re-address corporate entities. > This difficulty will become immediately obvious if one views the number of > (corparate) hosts in the hundreds-of-thousands rather than merely in > the thousands. If this allusion to granularity size of the deployment > did not communicate the direct implications of scale to the matter > at hand, please contact me for a more adequate explanation of this > obvious point. > > CCITT X.400-1984 had a number of serious problems which were ultimately > resolved in the MOTIS (ISO 10021) "equivalent standard". Among them was > the required use of the ADMD (i.e., the equivalent of "network provider") > in the X.400 application address. This requirement presupposed > that each PRMD (e.g., the end-user company) would have at most one > ADMD to service it. In any case, all X.400 addresses of that vintage > required that the company's X.400 address must have both the ADMD and > PRMD specified as address components. As a point of fact, many companies > have multiple ADMDs and the X.400-1984 requirement that each of these > X.400 "nodes" be addressed with multiple addresses (differing only in ADMD > value) proved to be untenable. For this reason, the MOTIS varient, > which made it possible for ADMD values to be "wild-carded" (unassigned), > proved to be a hard requirement to make X.400 "deployable". Note: the > motivation for the original flawed X.400-1984 approach was parallel to > your current argument. Also note that the original > provider-identification feature of X.400-1984 was one of the chief > roadblocks hindering X.400 deployments. Main point of paragraph: do > not bind addresses to providers. > > Interdomain IS-IS presupposes that each communicating domain conducts > up-front "negotiations" with each other to decide a number of important > policy matters such as security. It may well be that we will use > different providers for different customers/suppliers. However, the > paths to those customers/suppliers must remain unconstrained and > flexible. Embedding provider information into the network address does > not accomplish this goal and needlessly constrains our options. > > For those of us with deployed OSI nodes, one of the advantages of TUBA > was that TUBA was flexible enough to accomodate our current deployments. > A specific TUBA AFI may be desirable as a migration approach (e.g., IPAE-like > approach to indicate that the lower four octets are an IP address) for > TUBA, but the approach as a whole needs to accomodate our existing US > GOSIP NSAPs -- or whatever else we may have deployed. However, a > similar thing could also be accomplished via other mechanisms (e.g., use > the US GOSIP "reserved" field to signify such an embedding). > > The single goal of the above was to state that NSAP addressing should be > decoupled from whichever provider "temporarily" is used to deliver > the message. This message did not address in any way the implications of > a provider-based scheme such as PIP which is designed to explicitly > remove much of the provider-related "penalty". That is, the > topic for this discussion is solely limited to NSAP-based addressing > rather than provider-based addressing in general. > > Sincerely yours, > > --Eric Fleischman > > > > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08542; 26 May 93 12:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08538; 26 May 93 12:45 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa15025; 26 May 93 12:45 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA04131; Wed, 26 May 93 10:32:20 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA09531; Wed, 26 May 93 10:31:10 MDT Return-Path: Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA09527; Wed, 26 May 93 10:31:09 MDT Received: from concorde.inria.fr by p.lanl.gov (5.65/1.14) id AA04032; Wed, 26 May 93 10:31:04 -0600 Received: from givry.inria.fr by concorde.inria.fr; Wed, 26 May 1993 18:30:35 +0200 Received: by givry.inria.fr; Wed, 26 May 1993 18:30:35 +0200 Message-Id: <199305261630.AA12051@givry.inria.fr> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Francis Dupont To: tuba@lanl.gov Cc: wg4-clns@funet.fi Subject: TUBA for SunNet OSI Date: Wed, 26 May 1993 18:30:30 +0200 X-Orig-Sender: Francis.Dupont@inria.fr X-Charset: ASCII X-Char-Esc: 29 I've just finished the second version of my IP<->TUBA translator for SunNet OSI 7.0. If someone has used the first version and known how to setup OSI routes with SunNet OSI he/she can send a mail to me. I use two "tunnel" interface/driver, one for IP and one for CLNS (the name "tunnel" is traditional but misleading because here packets are translated (i.e. addresses are mapped and checksums updated) and *not* encapsulated). It is a full translator: any IP traffic routed through it is converted into TUBA traffic and vice-versa. I am working on: - test of the fragment support. - translation between ICMP and CLNP ER. - automatic address mapping between IP and TUBA world (today a static table is used). Regards Francis.Dupont@inria.fr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21976; 26 May 93 23:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21972; 26 May 93 23:04 EDT Received: from p.lanl.gov by CNRI.Reston.VA.US id aa03406; 26 May 93 23:04 EDT Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14) id AA08806; Wed, 26 May 93 21:02:09 -0600 Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA13643; Wed, 26 May 93 21:01:05 MDT Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA13639; Wed, 26 May 93 21:01:04 MDT Received: from merit.edu by p.lanl.gov (5.65/1.14) id AA08782; Wed, 26 May 93 21:01:06 -0600 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA21277; Wed, 26 May 93 23:01:05 -0400 Date: Wed, 26 May 93 23:01:05 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Knopper Message-Id: <9305270301.AA21277@merit.edu> To: tuba@lanl.gov Subject: TUBA documents directory Hi. For convenience I have made all of the official TUBA documents available for anon ftp on merit.edu in the directory pub/tuba-docs. I'll try to keep this up to date. Mark