home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / tuba / tuba-minutes-93jul.txt < prev    next >
Text File  |  1993-09-25  |  13KB  |  374 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by John Scudder/Merit
  5.  
  6. Minutes of the TCP/UDP over CLNP-Addressed Networks Working Group (TUBA)
  7.  
  8.  
  9. Summary
  10.  
  11.    o Tasks
  12.    o Documents to be moved to Proposed Standard or Informational
  13.    o To-do list
  14.    o Presentations
  15.  
  16.  
  17. Tasks
  18.  
  19.    o David Piscitello and Brian Carpenter will present
  20.      draft-ietf-tuba-sysids-01.txt to the ATM Forum.
  21.  
  22.    o Ross Callon will edit RFC 1237 (NSAP Allocation Guidelines) and
  23.      send a note to the mailing list, before the next IETF.
  24.  
  25.    o Richard Colella and Bill Manning will edit TUBA DNS Internet-Draft
  26.      for the next IETF.
  27.  
  28.    o 957x will be translated to ASCII text.  (Mark Knopper to work on
  29.      doing this, Lyman Chapin, Yakov Rekhter and David Piscitello to
  30.      provide raw dox.)
  31.  
  32.    o David Piscitello is changing 9542 to ASCII, Lyman 8473, Kunzinger
  33.      has done 10747.  IS-IS and 957x need to be done.  All will be
  34.      recommended as Proposed Standards and made available both in text
  35.      and as PostScript.
  36.  
  37.    o Peter Ford and John Curran will write a transition document and
  38.      notify the mailing list before the next IETF.
  39.  
  40.    o Dave Katz will edit EON RFC and recommend it as a Proposed
  41.      Standard.
  42.  
  43.    o John Scudder will try out BSD/386 EON.
  44.  
  45.    o Ross was requested to write a paper on address translation and
  46.      publish it as an Internet-Draft.
  47.  
  48.    o Mark has an outstanding item to write TUBA FAQ.
  49.  
  50.  
  51.  
  52. Documents to be Moved to Proposed Standard or Informational
  53.  
  54.    o CLNP for TUBA [draft-ietf-tuba-clnp-03.txt]
  55.      Will be presented to the area director to be moved to Proposed
  56.      Standard.
  57.  
  58.    o Sysids [draft-ietf-tuba-sysids-01.txt]
  59.      Will be presented to the area director to be moved to Proposed
  60.      Standard.  This is already how OSI hosts at Merit are addressed.
  61.      It was suggested to present this to the ATM Forum---David
  62.      Piscitello and Brian Carpenter will pursue this off-line.
  63.  
  64.    o NSAP Allocation Guidelines [RFC 1237]
  65.      This document is currently a Proposed Standard.  Ross Callon
  66.      suggests that it needs editing (and volunteers to do it, too).
  67.      Ross will edit it, place it in the tuba-docs directory on
  68.      merit.edu, and send a notice to the mailing list (maybe to the NOOP
  69.      list too).
  70.      RFC 1237 will be recommended to be moved to Draft Standard after
  71.      editing is complete (before the next IETF).
  72.  
  73.    o FUBAR (FTP and UDP with Bigger Addresses)
  74.      [draft-piscitello-ftp-bigports-01.txt, tuba-only version]
  75.      TUBA and TP/IX implementations of FUBAR supposedly exist.
  76.      There was quite a bit of discussion about problems with FUBAR and
  77.      TUBA translating gateways.
  78.      Some editing is needed on the document:  five-letter commands need
  79.      to be changed to four-letter, and various frivolities need to be
  80.      elided.  An appendix is to be written specifying use of FUBAR for
  81.      TUBA.
  82.      In the spirit of compromise between problems with FUBAR over
  83.      translating gateways and the need for some specification for big
  84.      address FTP, there was agreement to move for Experimental status
  85.      now, to be reviewed at the next IETF and then moved to Proposed
  86.      Standard.
  87.  
  88.    o DNS forward lookup (name ! NSAP lookup)
  89.      There is a document for forward lookup only, no inverse lookup.
  90.      RFC 1238 needs to be moved to Historical, since reverse lookup is
  91.      ``broken.''  Inverse lookup has been implemented, but is very slow.
  92.      There is a new Internet-Draft that does not include reverse lookup.
  93.      Richard Colella and Bill Manning will edit the Internet-Draft for
  94.      next time.  RFC 1238 will be left in place for now.
  95.      A DNS guru volunteer is needed.  Richard is interested in working
  96.      with this guru.
  97.      This will be discussed in Wednesday's DNS meeting.
  98.  
  99.    o Routing and Addressing Architecture
  100.      There is already such an architecture published in ISO 957x (David
  101.      Piscitello or Dave Katz may know the real number).
  102.      957x will be translated to ASCII text.  (Mark Knopper will work on
  103.      doing this, Lyman Chapin, Yakov Rekhter and David Piscitello will
  104.      provide a raw document.)
  105.      David Piscitello is changing 9542 to ASCII, Lyman is changing 8473,
  106.      and Kunzinger has changed 10747.  IS-IS and 957x need to be done.
  107.      All will be recommended as Proposed Standards and made available
  108.      both in ASCII and PostScript.
  109.      Relevant ISO documents are available (in PostScript) for anonymous
  110.      FTP from merit.edu.
  111.  
  112.    o EON
  113.      Will be recommended as a Proposed Standard.
  114.  
  115.  
  116.  
  117. To-do List
  118.  
  119.    o DNS inverse lookup (mentioned above)
  120.  
  121.    o Transition plan
  122.  
  123.      To be discussed at the next meeting.  Some anxiety was expressed
  124.      that the plan needs to be finished well before the next IETF.
  125.      Peter Ford and John Curran are working on a transition plan.
  126.      A rough transition outline is:
  127.  
  128.           Dual-stacked hosts
  129.           CLNP in routers
  130.           CLNP over IP infrastructure
  131.           IP over CLNP infrastructure
  132.  
  133.  
  134.      This segued into a discussion of the existing infrastructure, which
  135.      led to discussion of EON: the EON RFC (RFC 1070) is still in
  136.      Experimental status.  There was some discussion about whether
  137.      changes to EON are needed and worthwhile.  Dave Katz volunteered to
  138.      edit it and recommend it as a Proposed Standard.  John Scudder will
  139.      try out EON in BSD/386.
  140.      It might also be useful to have an IP in CLNP tunneling documents.
  141.  
  142.    o Mobile hosts:  Yakov Rekhter commented that TUBA will adopt
  143.      whatever the Internet community decides on for IP.
  144.  
  145.    o Formulate RFC 1380 responses.
  146.  
  147.    o Working groups we have/want liaison with:  DNS, FTP, ATM, RARE,
  148.      NOOP, and any working groups arising from the OSIEXTND BOF.
  149.  
  150.  
  151.  
  152. Presentations
  153.  
  154.  
  155. Autoconfiguration ``a la'' DEC (Chris Gunner)
  156.  
  157. NSAP structure:
  158.  
  159.  
  160.         |-Area Address---------|-ID-------|-SEL-|
  161.          <------n octets------> <-6 oct--> <-1->
  162.  
  163.  
  164.    o Routers are configured (by hand) with area addresses
  165.    o End-systems ``know'' their IDs (e.g.  MAC address) and ``know''
  166.      SEL(s)
  167.    o Routers send IS hellos (ISO 9542) with NET (NSAP)
  168.    o End-systems receive IS Hello and:
  169.  
  170.       -  Extract area address
  171.       -  Create NSAP(s) (area address + ID + SEL(s))
  172.       -  Send ES Hello(s) with NSAP(s)
  173.  
  174.  
  175. The migration to new area addresses is said to be pretty easy since an
  176. end-system can have both an ``old area'' and a ``new area'' NSAP.
  177.  
  178. Named objects, e.g.  ``node'' (system), may have protocol ``stack''
  179. attribute information, e.g.:  (in DEC DNS)
  180.  
  181.  
  182.         +---------------+     +-------------+
  183.         | Upper Layers  | ==> | SNMP        |
  184.         | CLNP, NSAP(s) |     | UDP, Port # |
  185.         +---------------+     | CLNP, NSAPs |
  186.                               +-------------+
  187.  
  188.  
  189. When an end system's NSAP(s) change:
  190.  
  191.  
  192.    o Update naming service entry for objects for that system
  193.    o Requires name service protocol to do update
  194.    o System needs to have write access to these objects
  195.  
  196.  
  197. This is basically a way for end-systems to update the DNS automatically
  198. when their addresses change.  There was some concern of how to do this
  199. in the current DNS---Yakov commented that when standard IP DNS knows how
  200. to do this, TUBA will adopt it unchanged.
  201.  
  202. Issues:
  203.  
  204.  
  205.    o Frequency of updates
  206.  
  207.    o Update failure -- e.g.  no write access -- requires manual DNS
  208.      override ability
  209.  
  210.    o System state information about interaction with name service
  211.      (transient failures)
  212.  
  213.  
  214.  
  215. Multicast (Dave Katz)
  216.  
  217.  
  218.    o Group NSAP addresses hack
  219.      Parallel AFI space (10-99 ! A0-F9) (since AFI is in BCD)
  220.  
  221.       -  Synactically distinct but parallel space
  222.       -  Hierarchy possible (unlike IP multicast space)
  223.  
  224.    o CLNP
  225.  
  226.       -  Multicast Data (MD) PDU
  227.          Distinct from DT PDU
  228.       -  Scope control options?  (``I want this packet to go only this
  229.          many administrative hops.'')
  230.  
  231.    o ES-IS
  232.  
  233.       -  NSAP ! SNPA dynamic binding
  234.       -  Group membership announcement
  235.       -  Extra unicast hop -- if you want to send multicast, you unicast
  236.          your packet to an IS which then forwards it appropriately.  You
  237.          never get a redirect to start multicasting on the LAN.
  238.  
  239.    o IS-IS
  240.  
  241.       -  Could be changed to be MOSPF-like
  242.       -  No active work
  243.  
  244.    o IDRP
  245.      No work yet
  246.  
  247.    o For more information see OSI Extensions for use in the Internet BOF
  248.  
  249.  
  250. ES-IS Address Administration (Dave Katz)
  251.  
  252. See ES-IS second edition.  PostScript file on merit.edu.
  253.  
  254.  
  255.         ES                             IS
  256.         --------                     --------
  257.         "who am I?"      --->
  258.         (to ask for an
  259.         address)
  260.                               <---    "You are foo" (for 18 hours)
  261.                               <---    "You are bar"
  262.                                       (offers some addresses, guaranteed
  263.                                       to be reserved for ES for holding
  264.                                       timer duration)
  265.         "I am bar" (ESH) --->
  266.         (to notify IS of
  267.         who ES has decided
  268.         to be, incl holding
  269.         time of up to 18
  270.         hours)
  271.  
  272.  
  273. Issues:
  274.  
  275.  
  276.    o May not really want automatic assignment (security concerns)
  277.  
  278.    o IS does not know some host information (e.g., IP address)---it
  279.      might be nice to provide this input to construct the NSAP (or MAC
  280.      address, other host-specific info)
  281.  
  282.    o How can we deny service to undesired hosts?  (e.g., send an
  283.      end-system a bogus address to ``shut him up''
  284.  
  285.  
  286. Attendees
  287.  
  288. Nick Alfano              alfano@mpr.ca
  289. James Allard             jallard@microsoft.com
  290. Bernt Allonen            bal@tip.net
  291. Josee Auber              Josee_Auber@hpgnd.grenoble.hp.com
  292. Anders Baardsgaad        anders@cc.uit.no
  293. John Ballard             jballard@microsoft.com
  294. Rebecca Bostwick         bostwick@es.net
  295. Jim Bound                bound@zk3.dec.com
  296. Thomas Brunner           brunner@switch.ch
  297. Ross Callon              rcallon@wellfleet.com
  298. Brian Carpenter          brian@dxcern.cern.ch
  299. George Chang             gkc@ctt.bellcore.com
  300. Richard Colella          colella@nist.gov
  301. David Conrad             davidc@iij.ad.jp
  302. Tim Dixon                dixon@rare.nl
  303. Kurt Dobbins             dobbins@ctron.com
  304. Jeffrey Dunn             dunn@neptune.nrl.navy.mil
  305. Francis Dupont           francis.dupont@inria.fr
  306. Dino Farinacci           dino@cisco.com
  307. Stefan Fassbender        stf@easi.net
  308. Eric Fleischman          ericf@act.boeing.com
  309. Osten Franberg           euaokf@eua.ericsson.se
  310. Peter Furniss            p.furniss@ulcc.ac.uk
  311. Eugene Geer              ewg@cc.bellcore.com
  312. David Ginsburg           ginsb@us-es.sel.de
  313. Chris Gunner             gunner@dsmail.lkg.dec.com
  314. Patrick Hanel            hanel@yoyodyne.trs.ntc.nokia.com
  315. Susan Hares              skh@merit.edu
  316. Denise Heagerty          denise@dxcoms.cern.ch
  317. Jack Houldsworth         J.Houldsworth@ste0906.wins.icl.co.uk
  318. Chris Howard             chris_howard@inmarsat.org
  319. Geoff Huston             g.huston@aarnet.edu.au
  320. Phil Irey                pirey@relay.nswc.navy.mil
  321. David Jacobson           dnjake@vnet.ibm.com
  322. J. Jensen                jensen@ic.dk
  323. Thomas Johannsen         thomas@ebzaw1.et.tu-dresden.de
  324. Dale Johnson             dsj@merit.edu
  325. Philip Jones             p.jones@jnt.ac.uk
  326. Cyndi Jung               cmj@3com.com
  327. Anders Karlsson          sak@cdg.chalmers.se
  328. Daniel Karrenberg        daniel@ripe.net
  329. Frank Kastenholz         kasten@ftp.com
  330. Dave Katz                dkatz@cisco.com
  331. Peter Kaufmann           kaufmann@dfn.dbp.de
  332. Mark Knopper             mak@merit.edu
  333. Ton Koelman              koelman@stc.nato.int
  334. Tony Li                  tli@cisco.com
  335. Susan Lin                suelin@vnet.ibm.com
  336. Robin Littlefield        robin@wellfleet.com
  337. Bill Manning             bmanning@rice.edu
  338. David Marlow             dmarlow@relay.nswc.navy.mil
  339. Cynthia Martin           martin@spica.disa.mil
  340. Peter Merdian            merdian@rus.uni-stuttgart.de
  341. Jun Murai                jun@wide.ad.jp
  342. Peder Chr.  Noergaard    pcn@tbit.dk
  343. Masataka Ohta            mohta@cc.titech.ac.jp
  344. Andrew Partan            asp@uunet.uu.net
  345. David Piscitello         dave@mail.bellcore.com
  346. Willi Porten             porten@gmd.de
  347. Aiko Pras                pras@cs.utwente.nl
  348. Juergen Rauschenbach     jrau@dfn.de
  349. Alex Reijnierse          a.a.reijnierse@research.ptt.nl
  350. Victor Reijs             reijs@surfnet.nl
  351. Yakov Rekhter            yakov@watson.ibm.com
  352. Robert Reschly           reschly@brl.mil
  353. Georg Richter            richter@uni-muenster.de
  354. Luc Rooijakkers          lwj@cs.kun.nl
  355. Henry Sanders            henrysa@microsoft.com
  356. John Scudder             jgs@merit.edu
  357. Keith Sklower            sklower@cs.berkeley.edu
  358. Michael St.  Johns       stjohns@darpa.mil
  359. Henk Steenman            henk@sara.nl
  360. Vladimir Sukonnik        sukonnik@process.com
  361. Fumio Teraoka            tera@csl.sony.co.jp
  362. Kamlesh Tewani           ktt@arch2.att.com
  363. Richard Thomas           rjthomas@bnr.ca
  364. Paul Traina              pst@cisco.com
  365. Antoine Trannoy          trannoy@crs4.it
  366. Willem van der Scheun    scheun@sara.nl
  367. Marcel Wiget             wiget@switch.ch
  368. Kirk Williams            kirk@sbctri.sbc.com
  369. Sam Wilson               sam.wilson@ed.ac.uk
  370. Noriko Yokokawa          norinori@wide.ad.jp
  371. Jessica Yu               jyy@merit.edu
  372. James Zmuda              zmuda@mls.hac.com
  373. Romeo Zwart              romeo@sara.nl
  374.