home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / tuba / tuba-minutes-93mar.txt < prev    next >
Text File  |  1993-04-30  |  15KB  |  378 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Mark Knopper/Merit
  5.  
  6. Minutes of the TCP/UDP over CLNP-addressed Networks Working Group (TUBA)
  7.  
  8. Agenda
  9.  
  10.  
  11.    o Implementation Status and Demonstration.
  12.    o Document Status.
  13.    o Prioritization of TUBA Work.
  14.  
  15.       -  Questions asked at Opening Plenary
  16.       -  Dynamic Host Address Assignment
  17.       -  Mobile Hosts
  18.       -  Routing and Addressing Plan
  19.       -  Transition Strategies
  20.       -  Discussion of Technical Advantages of CLNP
  21.  
  22.    o Demo and Implementation Targets
  23.  
  24.  
  25. Implementation Status and Demonstration
  26.  
  27. The current status of TUBA implementations is:
  28.  
  29.  
  30. cisco:        Has telnet and finger initiators and responders, tftp
  31.               initiator, and SNMP agent.  The effort took a long
  32.               weekend, the hardest part being getting the TCP checksum
  33.               right.  Paul Traina indicated that cisco intends to
  34.               modify tftpd to operate over UDP/CLNP as soon as
  35.               operating system support is available.
  36. 3Com:         Has telnet initiator and responder.  This work took about
  37.               one week.
  38. BSDi:         Has telnet and SMTP initiators and responders; currently
  39.               a bit buggy.  This implementation is the BSDi
  40.               distribution with Keith Sklower's modified 4.4 BSD
  41.               network code.
  42. NCSA Telnet:     Has telnet and finger initiators; ftp responder works
  43.               for command connection (support for data connection is a
  44.               future work item).
  45. SunOS:        Francis Dupont (at INRIA) has grafted the 4.4 BSD
  46.               modified network code onto SunOS 4.1.2, and has added
  47.               support for UDP over CLNP. No application information was
  48.               available (Francis was not at the TUBA Working Group
  49.               meeting).  Francis has also modified tcpdump to
  50.  
  51.                                    1
  52.  
  53.  
  54.  
  55.  
  56.  
  57.               understand TUBA; contact Francis.Dupont@inria.fr for
  58.               details.
  59. AIX 3.2:      IBM ported the 4.4 BSD modified network code to AIX 3.2.
  60.               Merit will be testing the port.  Yakov Rekhter will
  61.               modify ftp for TUBA after Merit completes the kernel
  62.               work.  It wasn't clear what the status is for other
  63.               applications.
  64.  
  65.  
  66. The cisco, 3Com, BSDi, and NCSA Telnet implementations were running in
  67. the IETF terminal room.  CLNP connectivity was available from the
  68. terminal room via an NSFNET EON encapsulator to other TUBA hosts at:
  69.  
  70.  
  71.    o cisco via Barrnet
  72.    o 3Com via SURANet and COS
  73.    o NIST via SURANet
  74.    o Merit via the NSFNET
  75.    o LANL via ESNet
  76.    o NORDUNET and other Sites in Europe
  77.  
  78.  
  79. Existing Document Status
  80.  
  81.  
  82.    o RFC 1347 (the original TUBA proposal):  No identified changes.
  83.  
  84.    o ``CLNP for TUBA'' Internet-Draft (draft-ietf-tuba-clnp-02.txt):
  85.      Dave Piscitello will polish the pseudoheader checksum calculation
  86.      description.
  87.      Dino Faranacci suggested that we need to think about MTU discovery.
  88.      We might want to use the ER PDU to return the MTU size.
  89.      The idea of padding the CLNP header to obtain word alignment for
  90.      the TCP header was reopened briefly.  It was decided that this had
  91.      already been discussed in the past and we would stick to the
  92.      conclusion that this is not something that can be guaranteed, given
  93.      the number of different subnet services that CLNP operates over.
  94.      Given the implementation experience, the Group decided that it
  95.      would ask for this document to be moved to Proposed Standard.  Dave
  96.      Piscitello will take this as an action.
  97.  
  98.    o ``Addressing and End Point Identification, For Use with TUBA''
  99.      (draft-ietf-tuba-address-00.ps):  Everyone should go back and
  100.      (re)read this and send comments to the mailing list.
  101.  
  102.    o ``DNS NSAP RRs'' Internet-Draft (draft-manning-dns-nsap-01.txt):
  103.      This Internet-Draft is the successor to RFC 1348.  It contains a
  104.      better treatment of the inverse mapping for NSAPs than was in 1348,
  105.      but this aspect is still subject to change.  [Note:  Bill Manning
  106.      has posted this Internet-Draft already.]
  107.  
  108.                                    2
  109.  
  110.  
  111.  
  112.  
  113.  
  114. New Documents
  115.  
  116.  
  117.    o Catalog of TUBA implementations:  We decided that it would be
  118.      useful to collect the information about what implementations are
  119.      available and who to contact.  Mark agreed to take this as an
  120.      action.
  121.  
  122.    o CLNP changes from London ISO meeting:  There was a document
  123.      describing possible changes for CLNP that was distributed in a
  124.      recent SC 6 meeting in London.  Mark took the action of getting a
  125.      copy on-line.
  126.  
  127.    o TUBA Frequently Asked Questions:  In keeping with the theme of
  128.      needing better organization of the TUBA documentation, Mark
  129.      suggested we write a FAQ. Mark will produce a first draft.
  130.  
  131.    o CLNP Multicast work:  SC6 is working on multicast extensions for
  132.      CLNP and related routing protocols.  Radia Perlman said she will
  133.      ask Dave Oran to post a summary status of this work on the mailing
  134.      list.
  135.  
  136.  
  137. Prioritization of TUBA Work
  138.  
  139. Several questions were asked during the Opening Plenary.
  140.  
  141.  
  142.   1. What upper layer changes are necessary?
  143.      The core applications -- including ftp, smtp, telnet, and dns --
  144.      were mentioned.  It was decided that we should create a single
  145.      document that catalogues what changes, if any, need to be made to
  146.      these for TUBA. In most cases, the required changes are minimal.
  147.      Mark agreed to take a first cut at this document.  Dave Piscitello
  148.      agreed to provide the ftp-specific section.  Peter Ford, Yakov
  149.      Rekhter, and Richard Colella agreed to modify ftp from this
  150.      specification.
  151.      Keith Sklower mentioned a draft description of a replacement for
  152.      gethostbyname that he and Eric Allman had devised.  Called
  153.      getconninfo, it is more general than gethostbyname, accommodating
  154.      address families other than AF_INET. This will make TUBA (and other
  155.      IPng proposals) more transparent to the applications.  Keith agreed
  156.      to post the write up as an Internet-Draft.
  157.  
  158.   2. What is the transition scheme?
  159.      Most of this discussion focused on a problem that John Veizades
  160.      sees:  there is a community of users that do not generally have the
  161.      resources necessary to upgrade their small, older routers to
  162.      accommodate CLNP to support TUBA (e.g., universities).  After some
  163.      discussion it became clear that, whereas some thought that this was
  164.      not a serious issue, John was not convinced.  Dino Faranacci and
  165.      John agreed to take this particular issue off-line.  In any case,
  166.  
  167.                                    3
  168.  
  169.  
  170.  
  171.  
  172.  
  173.      it was clear that the TUBA work needs a transition document to
  174.      answer just this kind of question.  Peter Ford and John Curran
  175.      agreed to draft a transition plan.
  176.  
  177.   3. Address assignments -- how do we get them?
  178.      This question is fully answered by the NSAP allocation scheme
  179.      outlined in RFC 1237, Guidelines for OSI NSAP Allocation in the
  180.      Internet, July, 1991.  There is already a well-defined method of
  181.      obtaining and assigning NSAP addresses.  In the U.S., address space
  182.      can be obtained from either the US GSA or from ANSI.
  183.  
  184.   4. How does TUBA address mobile hosts?
  185.      Deferred due to lack of time.
  186.  
  187.   5. Are there any known boundary conditions?
  188.      There were no known boundary conditions involving TUBA.
  189.  
  190.   6. What about Scaling?
  191.      In response, reference was made to a seminal paper from 1971 by
  192.      Kleinrock and ?.
  193.      Stev Knowles asked, ``What if you have one million networks?  How
  194.      does CLNP and it's routing protocols handle this?''  A lively
  195.      discussion ensued; there was not a specific response as it's a
  196.      complex question.
  197.  
  198.  
  199. It was agreed that the TUBA Working Group should discuss the topics of
  200. scaling and mobile hosts.
  201.  
  202. Discussion of Technical Advantages of CLNP
  203.  
  204. Radia Perlman wanted to make the point that we need to recognize the
  205. technical strengths of CLNP. She enumerated three in particular.
  206.  
  207.  
  208.   1. Autoconfiguration -- By using a unique System ID in the NSAP, it is
  209.      relatively easy to do address autoconfiguration.  This would
  210.      greatly reduce administrative overhead in assigning and changing
  211.      addresses, and allow for easier portability of systems.
  212.  
  213.   2. Infinite scaling property -- Given the size and flexibility of NSAP
  214.      addresses, address prefix routing provides a large number of
  215.      potential levels in the routing hierarchy, assuming that prefixes
  216.      are based on nibble boundaries.
  217.  
  218.   3. ``Free'' routing across WANs -- Embedded subnet addressing can be
  219.      used to simplify routing in environments that make use of WANs for
  220.      interconnection.  This entails assigning NSAPs with a WAN-based
  221.      subnet address in the high-order part of the NSAP. The WAN-based
  222.      part of the subnet address would then be used to perform the
  223.      cross-WAN routing hop (e.g., from one routing domain to another,
  224.  
  225.                                    4
  226.  
  227.  
  228.  
  229.  
  230.  
  231.      both connected to the same WAN). Note that domains not connected to
  232.      the same WAN would continue to route using the normal routing
  233.      protocols (i.e., ISIS and IDRP).
  234.  
  235.  
  236. Dynamic Host Address Assignment
  237.  
  238. One part of the solution to dynamic host address assignment is ES-IS,
  239. which is reasonably straightforward.  Bill Warner agreed to draft text
  240. that describes how ES-IS is used to do dynamic address assignment.
  241.  
  242. Another part of dynamic host address assignment is how to get the
  243. information into DNS. This is not so obvious.  John Curran agreed to
  244. write some text for this.
  245.  
  246. Routing and Addressing Plan
  247.  
  248. Ross Callon wrote a routing and addressing Internet-Draft for TUBA in
  249. October.  Everyone was assigned to (re)read this and comment (see
  250. Internet-Draft draft-ietf-tuba-address-00.[txt,ps]).
  251.  
  252. The subject of globally unique EIDs was raised once more.  There was
  253. violent agreement that we should do this in the NSAP System ID field.
  254. However, there was some disagreement on the mechanics.  Ross suggested
  255. mandating that the System ID field be taken from a single,
  256. globally-coordinated 48-bit number space (*not* synonymous with IEEE MAC
  257. addresses).  Keith had a somewhat different idea, allowing variable size
  258. EIDs and, hence, variable sized System IDs.  Each proponent was asked to
  259. write a short description of their proposal and post it to the mailing
  260. list.  Dave Piscitello agreed to write up Ross's proposal.
  261.  
  262. Demonstration and Implementation Targets
  263.  
  264. It was recognized that the TUBA demonstrations could benefit from better
  265. planning and coordination.  George Chang agreed to take the lead in this
  266. area.
  267.  
  268. Summary of Action Items
  269.  
  270.  
  271. Dave Piscitello     CLNP for TUBA document (update) and submit for
  272.                     Proposed Standard.
  273.                     FTP for alternative network layers:  Specification.
  274.                     The implementation will be done by Peter Ford, Yakov
  275.                     Rekhter and Richard Colella.
  276.                     EID administration text.
  277. Ross Callon         Addressing doc (update), comments needed from Group.
  278. Manning and Colella   DNS for NSAPs I-D (RFC 1348 update).
  279.  
  280.                                    5
  281.  
  282.  
  283.  
  284.  
  285.  
  286. Mark Knopper        Catalog of TUBA implementations.
  287.                     CLNP changes from London ISO meeting (make document
  288.                     available).
  289.                     TUBA Frequently Asked Questions.
  290.                     Application changes document (what needs to change
  291.                     for each).
  292.                     ``Cron job'' to update the Group on status weekly.
  293.                     (This item refers to the offer Mark made to remind
  294.                     the Group periodically on the status of each action
  295.                     item and what is left to be done.)
  296. Radia Perlman       Status of CLNP Multicast work.
  297. Paul Traina         Tftpd - implementation.
  298. Keith Sklower       getconninfo Internet-Draft (replacement for
  299.                     gethostbyname).
  300. Ford and Curran     Transition document.
  301. Bill Warner         Autoconfig (dynamic host address assignment using
  302.                     ES-IS), specification.
  303. John Curran         NSAP insertion into DNS text.  The implementation
  304.                     will be handled by Dave Piscitello.
  305. George Chang        Demo PR and coordination.
  306.  
  307.  
  308.  
  309. Attendees
  310.  
  311. Philip Almquist          almquist@jessica.stanford.edu
  312. Jim Barnes               barnes@xylogics.com
  313. Russell Blaesing         rrb@one.com
  314. Rebecca Bostwick         bostwick@es.net
  315. George Chang             gkc@ctt.bellcore.com
  316. John Chang               jrc@uswest.com
  317. Enke Chen                enke@merit.edu
  318. William Chimiak          chim@relito.medeng.wfu.edu
  319. Richard Colella          colella@nist.gov
  320. Michael Collins          collinsms@es.net
  321. John Curran              jcurran@nic.near.net
  322. Dino Farinacci           dino@cisco.com
  323. Eric Fleischman          ericf@act.boeing.com
  324. Francois Fluckiger       fluckiger@vxcern.cern.ch
  325. Peter Ford               peter@goshawk.lanl.gov
  326. Vince Fuller             vaf@stanford.edu
  327. Peter Furniss            p.furniss@ulcc.ac.uk
  328. John Gawf                gawf@compatible.com
  329. Eugene Geer              ewg@cc.bellcore.com
  330. Tony Hain                alh@es.net
  331.  
  332.                                    6
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Susan Hares              skh@merit.edu
  339. Woody Huang              yuh@merit.edu
  340. David Jacobson           dnjake@vnet.ibm.com
  341. Laurent Joncheray        lpj@merit.edu
  342. Mark Knopper             mak@merit.edu
  343. Paul Lustgraaf           grpjl@iastate.edu
  344. Carl Madison             carl@startek.com
  345. Tracy Mallory            tracym@3com.com
  346. Bill Manning             bmanning@sesqui.net
  347. Jun Matsukata            jm@eng.isas.ac.jp
  348. David Meyer              meyer@ns.uoregon.edu
  349. Dennis Morris            morrisd@imo-uvax.disa.mil
  350. Matthew Morrisey         morrisey@wpsp01.hq.aflc.af.mil
  351. Peder Norgaard           pcn@tbit.dk
  352. Laura Pate               pate@gateway.mitre.org
  353. Maryann Perez            perez@cmf.nrl.navy.mil
  354. Radia Perlman            perlman@dsmail.enet.dec.com
  355. David Piscitello         dave@mail.bellcore.com
  356. Willi Porten             porten@gmd.de
  357. Yakov Rekhter            yakov@watson.ibm.com
  358. Ben Robinson             ben_robinson@vnet.ibm.com
  359. Yzhak Ronen              y.ronen@homxa.att.com
  360. Michael Safly            saf@tank1.msfc.nasa.gov
  361. Paul Serice              serice@cos.com
  362. Roxanne Streeter         streeter@nsipo.arc.nasa.gov
  363. Steve Suzuki             suzu@fet.com
  364. Wayne Tackabury          wayne@cayman.com
  365. John Tavs                tavs@vnet.ibm.com
  366. Kamlesh Tewani           ktt@arch2.att.com
  367. Richard Thomas           rjthomas@bnr.ca
  368. Paul Traina              pst@cisco.com
  369. John Veizades            veizades@apple.com
  370. William Warner           warner@ohio.gov
  371. Linda Winkler            lwinkler@anl.gov
  372. Cathy Wittbrodt          cjw@barrnet.net
  373. Charles Young            Charles.E.Young@att.com
  374.  
  375.  
  376.  
  377.                                    7
  378.