Re: Internet-draft of CLNP for TUBA

["Cyndi M. Jung" <[e-mail]>]

>>	There is a protocol ID assigned to TP4 over IP - so I expect TP4 over
>>	this "CLNP for TUBA" could use that.  CLNP error reports into ICMP
>>	semantics would lose some of the granularity of the errors - perhaps
>>	the TP4 clients should get the full semantic of a CLNP ERR PDU.

>Net result:  Systems running TP4/CLNP applications cannot communicate 
>with TP4/TUBA/CLNP applications.  Stated another way: "Everything worked
>fine with my OSI applications, until they upgraded my IP stuff to v7..."

>Without sounding iconoclastic, I'm not sure that killing native TP4/CLNP
>operation for TUBA/CLNP is fair trade.

>Thoughts? 

Maybe I need to look more closely, but I don't see why a TP4/TUBA/CLNP
stack can't work with a TP4/CLNP stack.  The N-selector would probably
be different on the two machines - TP4/TUBA would use 29 as per RFC1340,
and the TP4/CLNP would use whatever it felt like, which could also be 29.
The database where the addressing information is stored would need to
reflect the change (X.500 if you're lucky, isoentities-like file if you
are not), but unless I'm really overlooking something, it can work.

Also, it shouldn't need to look like TP4/TUBA/CLNP, rather just TP4/CLNP -
the TUBA client of CLNP would get the CLNP packets where the N-selector
is 6 (TCP) and 17 (UDP), including the ERR PDUs, and do whatever
is necessary to make TCP and UDP "happy", which would include the mapping
of ERR PDU semantics into the ICMP semantics.  CLNP shouldn't really be aware
of this, provided it is already doing client demultiplexing based on the
N-selector.

What worries me is the statement in 4.15.4 and 4.15.5 (Source Routing and
Record Route) that says "A complete description of the parameter value of this
option is deferred until format and semantics of addressing is better defined."
What is that supposed to mean?  Those options are processed by routers that
hopefully have no idea what kind of data is being carried in the NPDU, and
that's the way it should be.  If the CLNP for TUBA is going to modify the
semantics of the contents of this option (make it a sequence of RDI's or
NSAP prefixes), I will be concerned.

I also think that TUBA should not be so strongly linked with the NSAP address
format for ISOC - it should be able to use any of the address formats.  The
issues of creating an address administration for the Internet community
should not be woven into the issues of running TCP and UDP over CLNP.
Implementations of TUBA should be able to even use AFI 49 addresses - it is 
only the semantics of the N-selector that are under TUBA control, and those 
semantics are only taken into consideration by the receiving station when 
examining the destination NSAP.  Systems on the Internet that are already
running with dual stacks (TP4/CLNP and TCP/IP) are the likely candidates to 
also run TUBA (one would think) and they should not be forced to change their 
NSAP addresses, or to use additional NSAPs, just to support the mapping of TCP
and UDP over CLNP.  The only obstacle to decoupling the use of TUBA from
the ISOC address format would be if the TCP/UDP pseudoheader could only
be computed using special fields in the TUBA address - RFC1347 sites the 
details of the pseudoheader as subject for further study, so it isn't
locked into ISOC addresses only yet.  The DNS will need to carry any 
length NSAP, and not just the ISOC length.  If applications carry IP addresses
and need to be modified to carry NSAPs, and they want fixed length, they 
should have a fixed length field large enough for the 20 octet NSAP plus its
length field - waste a few bytes here and there.

Those are my thoughts.

Cyndi