Draft Minutes of the Columbus TUBA

[Mark Knopper <[e-mail]>]

                       Minutes of the TUBA WG
                       ======================


Chair:  Mark Knopper (Merit)

Scribe: Richard Colella (NIST)

Meeting Dates: 3/29/93 and 4/1/93

Location: Columbus, OH



Agenda
======

- Implementation Status and Demonstration

- Document Status

- Prioritization of TUBA Work
	o Questions asked at Opening Plenary
	o Dynamic Host Address Assignment
	o Mobile Hosts
	o Routing and Addressing Plan
	o Transition Strategies
	o Discussion of Technical Advantages of CLNP

- Demo and Implementation Targets



Implementation Status and Demonstration
=======================================

The current status of TUBA implementations is:

- cisco: has telnet and finger initiators and responders, tftp
	initiator, and SNMP agent.  The effort took a long weekend,
	the hardest part being getting the TCP checksum right. Paul
	Traina indicated that cisco intends to modify tftpd to 
	operate over UDP/CLNP as soon as operating system support
	is available.

- 3Com: has telnet initiator and responder.  This work took
	about one week.

- BSDi: has telnet and SMTP initiators and responders; currently a
	bit buggy.  This implementation is the BSDi distribution with
	Keith Sklower's modified 4.4 BSD network code.

- NCSA Telnet: has telnet and finger initiators; ftp responder works
	for command connection (support for data connection is a future
	work item).

- SunOS: Francis Dupont (at INRIA) has grafted the 4.4 BSD modified
	network code onto SunOS 4.1.2, and has added support for UDP
	over CLNP.  No application information was available (Francis
	was not at the TUBA WG meeting).  Francis has also modified
	tcpdump to understand TUBA; contact [e-mail] for
	details.

- AIX 3.2: IBM ported the 4.4 BSD modified network code to AIX 3.2.
	Merit will be testing the port.  Yakov Rekhter will modify
	ftp for TUBA after Merit completes the kernel work.  It
	wasn't clear what the status is for other applications.


The cisco, 3Com, BSDi, and NCSA Telnet implementations were running
in the IETF terminal room.  CLNP connectivity was available from the
terminal room via an NSFNET EON encapsulator to other TUBA hosts at:

- cisco via Barrnet

- 3Com via SURANet and COS

- NIST via SURANet

- Merit via the NSFNET

- LANL via ESNet

- NORDUNET and other Sites in Europe 




Document Status
===============

Existing Documents:
-------------------

- RFC 1347 (the original TUBA proposal): No identified changes.

- "CLNP for TUBA" I-D (draft-ietf-tuba-clnp-02.txt): Dave Piscitello
  will polish the pseudoheader checksum calculation description.

  Dino Faranacci suggested that we need to think about MTU discovery.
  We might want to use the ER PDU to return the MTU size.

  The idea of padding the CLNP header to obtain word alignment for
  the TCP header was reopened briefly.  It was decided that this had
  already been discussed in the past and we would stick to the
  conclusion that this is not something that can be guaranteed, given
  the number of different subnet services that CLNP operates over.

  Given the implementation experience, the group decided that it
  would ask for this document to be moved to Proposed Standard.
  Dave P. will take this as an action.

- "Addressing and End Point Identification, For Use with TUBA"
  (draft-ietf-tuba-address-00.ps):  Everyone should go back and
  (re)read this and send comments to the mailing list.

- "DNS NSAP RRs" I-D (draft-manning-dns-nsap-01.txt):  This I-D is
  the successor to RFC 1348.  It contains a better treatment of the
  inverse mapping for NSAPs than was in 1348, but this aspect is
  still subject to change.  [Note: Bill Manning has posted this I-D
  already.]


New Documents:
--------------

- Catalog of TUBA implementations:  We decided that it would be useful
  to collect the information about what implementations are available
  and who to contact.  Mark agreed to take this as an action.

- CLNP changes from London ISO meeting:  There was a document describing
  possible changes for CLNP that was distributed in a recent SC 6 meeting
  in London.  Mark took the action of getting a copy on-line.

- TUBA Frequently Asked Questions:  In keeping with the theme of needing
  better organization of the TUBA documentation, Mark suggested we
  write a FAQ.  Mark will produce a first draft.

- CLNP Multicast work:  SC6 is working on multicast extensions for CLNP
  and related routing protocols.  Radia Perlman said she will ask Dave
  Oran to post a summary status of this work on the mailing list.



Prioritization of TUBA Work
===========================

Questions During Opening Plenary:
---------------------------------

1) What upper layer changes are necessary?

The core applications -- including ftp, smtp, telnet, and dns -- were
mentioned.  It was decided that we should create a single document
that catalogues what changes, if any, need to be made to these for
TUBA.  In most cases, the required changes are minimal.  Mark
agreed to take a first cut at this document.  Dave P. agreed to
provide the ftp-specific section.  Peter Ford, Yakov Rekhter, and
Richard Colella agreed to modify ftp from this spec.

Keith Sklower mentioned a draft description of a replacement for
gethostbyname that he and Eric Allman had devised.  Called
getconninfo, it is more general than gethostbyname, accomodating
address families other than AF_INET.  This will make TUBA
(and other IPng proposals) more transparent to the applications.
Keith agreed to post the writeup as an Internet Draft.

2) What is the transition scheme?

The majority of this discussion focused on a problem that John
Veizades sees: there is a community of users that do not generally
have the resources necessary to upgrade their small, older routers to
accomodate CLNP to support TUBA (e.g., universities).  After some
discussion it became clear that, whereas some thought that this
was not a serious issue, John was not convinced.  Dino Faranacci
and John agreed to take this particular issue off-line.  In any
case, it was clear that the TUBA work needs a transition document
to answer just this kind of question.  Peter Ford and John
Curran agreed to draft a transition plan.

3) Address assignments -- how do we get them?

This question is fully answered by the NSAP allocation scheme outlined
in RFC 1237, Guidelines for OSI NSAP Allocation in the Internet,
July, 1991. There is already a well-defined method of obtaining and 
assigning NSAP addresses. In the US, address space can be obtained
from either the US GSA or from ANSI.

4) How does TUBA address mobile hosts?

Deferred due to lack of time.

5) Are there any known boundary conditions?

There were no known boundary conditions involving TUBA.

6) What about Scaling?

In response, reference was made to a seminal paper from 1971 by
Kleinrock and ?.  

Stev Knowles asked, "What if you have one million networks?  How
does CLNP and it's routing protocols handle this?"  A lively
discussion ensued; there was not a specific response 
as it's a complex question.

It was agreed that the TUBA working group should discuss the topics
of scaling and mobile hosts.


Discussion of Technical Advantages of CLNP:
-------------------------------------------

Radia Perlman wanted to make the point that we need to recognize the
technical strengths of CLNP.  She enumerated three in particular.

1) Autoconfiguration -- By using a unique System ID in the NSAP, it is
relatively easy to do address autoconfiguration.  This would greatly
reduce administrative overhead in assigning and changing addresses,
and allow for easier portability of systems.

2) Infinite scaling property -- Given the size and flexibility of NSAP
addresses, address prefix routing provides a large number of potential
levels in the routing hierarchy, assuming that prefixes are based on
nibble boundaries.

3) "Free" routing across WANs -- Embedded subnet addressing can be
used to simplify routing in environments that make use of WANs for
interconnection.  This entails assigning NSAPs with a WAN-based
subnet address in the high-order part of the NSAP.  The WAN-based
part of the subnet address would then be used to perform the
cross-WAN routing hop (e.g., from one routing domain to another,
both connected to the same WAN).  Note that domains not connected
to the same WAN would continue to route using the normal routing
protocols (i.e., ISIS and IDRP).


Dynamic Host Address Assignment
-------------------------------

One part of the solution to dynamic host address assignment is ES-IS,
which is reasonably straightforward.  Bill Warner agreed to draft
text that describes how ES-IS is used to do dynamic address
assignment.

Another part of dynamic host address assignment is how to get the
information into DNS.  This is not so obvious.  John Curran agreed to
write some text for this.


Routing and Addressing Plan
---------------------------

Ross Callon wrote a routing and addressing I-D for TUBA in October.
Everyone was assigned to (re)read this and comment (see I-D
draft-ietf-tuba-address-00.[txt,ps]).

The subject of globally unique EIDs was raised once more.  There was
violent agreement that we should do this in the NSAP System ID
field.  However, there was some disagreement on the mechanics.  Ross
suggested mandating that the System ID field be taken from a single,
globally-coordinated 48-bit number space (*not* synonymous with IEEE
MAC addresses).  Keith had a somewhat different idea, allowing
variable size EIDs and, hence, variable sized System IDs.  Each proponent
was asked to write a short description of their proposal and post it
to the mailing list.  Dave P. agreed to write up Ross's
proposal. 



Demonstration and Implementation Targets
========================================

It was recognized that the TUBA demonstrations could benefit from
better planning and coordination.  George Chang agreed to take
the lead in this area.



Summary of Action Items
=======================

CLNP for TUBA doc (update) and submit for Proposed Standard - Piscitello

Addressing doc (update) - Callon, comments needed from group

DNS for NSAPs I-D (RFC 1348 update) - Manning, Colella

Catalog of TUBA implementations - Knopper

CLNP changes from London ISO meeting (make doc available) - Knopper

TUBA Frequently Asked Questions - Knopper

Status of CLNP Multicast work - Perlman

Application changes doc (what needs to change for each) - Knopper

FTP for alternative network layers: Spec - Piscitello
				    Implementation - Ford, Rekhter, Colella

Tftpd - implementation: Traina

getconninfo Internet Draft (replacement for gethostbyname) - Sklower

Transition document - Ford, Curran

Autoconfig (dynamic host address assignment using ES-IS) - 
	spec: Warner
    NSAP insertion into DNS text: Curran
	implementation: Piscitello

EID administration text - Piscitello

Demo PR and coordination - George Chang

"Cron job" to update the group on status weekly - Knopper
  (This item refers to the offer Mark made to remind the group periodically
   on the status of each action item and what is left to be done.)