comments on proposed TUBA charter.

[[e-mail]]

>
>TCP and UDP with Bigger Addresses  (tuba)
>
>Charter 

>Chair(2nd class):
        
Vice-chair, please, we have no 2nd class citizens in the Internet (oh, I
forgot, this is perceived as an OSI effort:-)

>Internet Area Director(s) 
>
>     Philip Almquist <[e-mail]>

I don't see this as going to the transport area; the impact of TUBA/CLNP
extends through application/transport/internet as do other proposed
solutions. You could make a case for this being in the OSI area, but I
think there will be more than a few folks who would view this as wrong
for several reasons. I think Phil A. is going to be overwhelmed by this,
and we may need to consider expanding the AD for Internet to save Phil
from being crushed by the burden of activities in his area.


>can be effectively addressed and routed.  The TUBA effort will enhance
                                                                *expand*


>The TUBA group proposes to continue to use TCP and UDP as well as the 
>protocols which commonly use TCP and UDP, such as FTP, SMTP,
>Telnet, etc.  An enhancement to the current system is mandatory due to
>the limitations of the current 32 bit IP addresses.  TUBA seeks to
>upgrade the current system by a transition from the use of the
>Internet Protocol to ISO/IEC 8473 (CLNP).   
>

I suggest "TUBA specifies the continued use of Internet Transport
Protocols,
in particular TCP and UDP, but encapsulated in ISO 8473 (CLNP) packets.
This
will allow the continued use of Internet application protocols such as FTP,
SMTP, Telnet, etc."  

>The TUBA approach will place significant emphasis on the  engineering
>and operational requirements of a large, global, multilateral public
>data network.  TUBA will work to  maximize interoperatability 
>with  the routing and addressing architecture of the global CLNP
>infrastructure.  The TUBA working group will work closely with the IETF
>NOOP and IPRP-for-IP working groups to coordinate a viable CLNP based
>Internet which supports the applications which Internet users depend on
>such as Telnet, FTP, SMTP, NFS, X, etc.  The TUBA working group will
>also work collaboratively with  communities which are also using the
>CLNP protocol, such as RARE-WG4, GOSIP, and ISO/IEC to
>will consider issues such as interoperability, applications coexisting
>on top of multiple transports, and the evolution of global public
>connectionless datagram networks.

Three comments:(1) we do not mention what discovery
and intra-domain routing protocols we will investigate (ES/IS and ISIS?
a revision of ARP, OSPF?). I know what I've been assuming all along,
but I'd like to confirm this with others, and have it be known from
the outset. (2) we do not mention that we will explicitly seek and
factor in the operational needs and impact of TUBA/CLNP. (3) we do not
mention network management; I think it is useful to point out that
significant instrumentation (SNMP MIB Modules for CLNP, CLNP Echo, RFC1139)
exists to facilitate the transition period and beyond.


>The TUBA working group will investigate using IP addresses as  unique
>Endpoint Identifiers such  that TCP and UDP may use these addresses
>which are embedded  into  NSAPs as IDs.  In addition, the TUBA group
>will work on the issues of transitioning TCP and UDP addresses to
>overcome  the  eventual runout of IP addresses.  By decoupling the use
>of IP addresses from the routing system it should be possible to assign
>IP addresses far more compactly than is currently done and greatly
>extend the lifetime and utility of IP addresses.  Using IP addresses as
>NSAP IDs also has the advantage of being able to use the Domain Name
>System (DNS) to map IDs to NAMEs.  The TUBA strategy will require a
>new  mapping in the DNS from NAMEs to NSAP addresses.

Does the previous text suggest that 32-bit EIDs is agreeable to all?

>The rationale RFC (RFC-1347) documents issues of transition and
>coexistence, among unmodified ``IP'' hosts and hosts which support
>``TUBA'' hosts.  Hosts wishing full Internet connectivity will need to
>support TUBA.  



>Goals and Milestones: 

I think we need to be more specific about the output documents and
timeframes; we need at least:

RFC1347 bis -- a revision that records what we have learned over the
past months on tuba mailing list, i.e., one that describes the 
addressing architecture, routing architecture, global effects of these
on applications, specific effects on applications

CLNP for TUBA -- draft available, but with known deficiencies; also, much
of the grumping I've seen about this draft emanates from the appendices
on addressing, which probably belong elsewhere and can be referenced by
this I-D.

Some form of Operations plan document, i.e., something that explains
"how are we going to do this?", what instrumentation is required, what
administration is required for addressing, etc. I'm just a dumb engineer
and even dumber end user, but I suspect that folks like Dennis and Brian
and John have a lot of useful things to say about how they and others 
will operate networks with TUBA in place.

A set of I-Ds that document changes to applications affected by the
presence of TUBA, i.e., the DNS document. Are we sure this is the
only application protocol affected by the introduction of TUBA/CLNP?

Routing documents? Do we envisage (what a yucky ISO word...) foresee a need
for updates to any routing documents? Would anyone expect that an OSPF for
CLNP might be desired (thanks, Dave, for opening up yet another can of
slimy squirmy worms).

---------
David M. Piscitello
Bellcore NVC 1C322
331 Newman Springs Road
Red Bank, NJ 07701
(908)-758-2286
(908)-785-4177 (Fax)