Comments on draft-ietf-catnip-base-02.txt

[Greg Minshall <[e-mail]>]

All,

Here are some comments on the latest catnip document.  My main attention
was centered on sections 1-6.  I am reading the document as a potential
successor to RFC-791; thus, i am concerned with making sure that the
document is to the point and does not include comments which detract from
its role as a specification of an internetworking protocol.

Doesn't this document expire 24 *JULY* 1994?

I would suggest breaking this document into various documents.  The first
should define CATNIP (datagram format, procedures).  Others would define
IPv4<>CATNIP; CLNP<>CATNIP; IPX<>CATNIP.  Another would define routing.

[1]  The two paragraphs starting with "The first version of this memo..."
should be deleted.

[1]  "(and possibly TUBA)" should be deleted.  If TUBA does adopt this
work, then it should be stated.

[3]  "... so that the resulting network protocol data units are identical
in format."  Please add "to each other", or some such.

[3]  The relationship between "cache handles" and "flow identifiers" is
fairly unclear to me.

[3]  "Any intermediate model between the connection oriented and the
connectionless service can thus be provided over cooperating routers."  The
truth of this statement is by no means obvious.

[3.1]  I would remove the text beginning "While it is common in the IP
Internet" through the end of the succeeding paragraph ("IP is in third
place.").

[3.1]  "there isn't any way to do network layer alignment."  This is
awkward and confusing.

[3.1]  Is the correct usage "*the* CATNIP", or just "CATNIP"?

[3.1.1]  "The number of 'little changes' suggested by some proposals, and
the utterly enormous amount of documentation, training, and administrative
effort then required astounds the present author."  I would remove this.

[3.1.1]  "There are also no external requirements ... no requirement that
administrators ... add things to the DNS."  However, CATNIP *is* going to
require changes to DNS (to add NSAP entries, for example).

[3.1.1]  "The CATNIP definitions provide stateless translation of network
datagrams to and from CATNIP and by implication directly between the other
network layer protocols.  A CATNIP capable system implementing the full set
of definitions will be able to interoperate with any of the existing
protocols."  This is a laudable goal.  I don't see any actual proof of this
in the document.

[3.1.3]  "IPX systems with registered network numbers may gain the most." 
It would seem a good goal to support independently numbered IPX (as well as
IPv4 in the future) end systems.

[3.1.4]  "This specification defines a common network layer packet format
and basic architecture.  It intentionally does not specify ES-IS methods,
routing, naming systems, autoconfiguration and other subjects not part of
the core Internet wide architecture.  The related problems and their (many)
solutions are not within the scope of the specification of the basic common
network layer."  This, to me, is both good and bad.  Within the confines of
*this* document, these things do not need to be defined.  Within the
context of a submission of CATNIP as the IPng, these things need to be
addressed.  Within the full specification of CATNIP as *the* IPng, these
things will need to be fully specified.

[3.3]  This entire section seems to be *philosophy* rather than *terminology*.

[4.2]  "This is the approach taken in the first published version of IPv7,
described in RFC1475."  Delete.

[4.2]  "similar to the development work preceding RFC1475 on version 7,
(and, interestingly, very similar to the ideas developed independently in
the IAB proposal of June 1992)".  Delete.

[4.3]  "I can do what I please ... (IDI=1617247959)".  The correct IDI
*seems* to be "IDI=16172477959".

[4.4]  "One mistake that will not be made..."  This is the wrong voice.
This is supposed to be a protocol specification, not an informal survey of
networking.

[4.4]  "Using the current state of processor technology as a reference, the
fixed header is all loaded into CPU registers on the first memory cycle,
and all fits within the operation bandwidth."  This seems to border on the
blathering, frankly.  First off, there is no "current state of processor
technology" that defines a "reference" in any well-defined way.  There are
all sorts of different processorts out there.  Second, i, personally, don't
know any processor/memory subsystem technology that allows 32 bytes to be
delivered to CPU registers from memory in *ONE* memory cycle.  Third, i
have NO idea what "all fits within the operation bandwidth" means.  This
sounds like some sort of repitition of some random buzzword-ology to me...

[4.4]  "FCI" is used before being defined.

[4.4]  "On very slow and low performance networks, it is still fairly small
..."  "It"?   What "it"?

[4.4]  "In between, it fits nicely into ATM cells ...".  I.e., it only
takes up some 32 bytes of the ATM 48 byte payload?  That, somehow, is nice?

[4.4.2]  "Header Length"  This is labeled "Header Size" in the diagram. 
One or the other should be the name.

[4.4.3]  "This may be useful."  Either it is or it isn't.  If it is, say so
and why.  If it isn't...

[4.6.2]  If CATNIP is defining a new fragmentation format, i would suggest
including the length of the original (unfragmented) datagram.

[4.6.3]  This section seems to imply that dropping not-totally-reassembled
datagrams can be driven by the arrival of future fragments (especially
those with Last Fragment set).  However, you still need clocks to toss
things after MSL.

[4.6.4]  An appropriate ICMP message is sent ..."[u]nless, of course, the
datagram is an ICMP message."  However, if i understand correctly, the test
will *NOT* be for ICMP message, but rather the test will be to check the
ERS bit.

[4.6.5]  It is not clear to me at what point in the path the ICMP
"Translation Failed/Don't Translate Set" is supposed to be generated...

[4.6.6]  "The multicast enable option (type 5, usually class 1) permits
multicast forwarding of the CATNIP datagram on subnetworks that directly
support media layer multicasting; a vanishing species, even in 10 Mbps
Ethernet, given the increasing prevalence of switching hubs.  It also
(perhaps more usefully) permits a router to forward the datagram on
multiple paths when a multicast routing algorithm has established such
paths.  There is no option data."  This is fairly unclear in terms of
intent.  I *think* that what the document is saying is "the current IP
subnet multicast technology is not useful."  I challenge this statement. 
Additionally, there must be some thought that sometimes a source will, and
sometimes will not, set this bit.  I have no idea what (non-trivial)
algorithm a source would use to make such a decision.

[4.6.6]  "Note that there is no special address space for multicasting in
the CATNIP."  This might be somewhat of a management problem, since it is
nice looking at a packet to be able to determine that it is, or isn't, a
multicast packet.

[4.6.6]  "... withing the entire level I area or to repeat..."  Probably
"1", not "I".

[4.7]  "This field's value is derived from ICMP messages sent back by the
next hop router..."  How does the *next hop* router know the *current*
router's CATNIP (or any network layer!) address?

[4.7.1]  "When a router sends code 0, the recieving [sic] router is
instructed to clear all cache entries"  Append something like "associated
with the sending router".

[4.7.2]  What does this section have to do with, say, CATNIP?

[4.7.2]  "Of course, the routers will validate the Ri's received ... and
probalby check that the route in fact describes the destination of the
datagram."  I think it is quite important to specify what fields a router
will look at to verify the FCI (in order to have some handle on the failure
modes).

[4.7.2]  "Note, this may happen well upstream of the point at which the
routes actually diverge."  An example might help me understand this point.

[4.7.3]  What, actually, is the difference between "flows" and "FCI"?

[4.8.3]  I didn't understand this section.

[5.3]  I worry about the fact that the "Don't Fragment" semantics are
*lost* when going into the CATNIP domain.

[5.3]  The ERS flag should *also* be set if the received datagram is
addressed to a multicast destination or if it was received via a link-level
multicast.

[5.3]  Don't you also need to set the datagram length?

[5.4]  There is some dispute on this, but i would suggest when creating a
CLNP packet that the low order byte of the source NSAP (the NSEL) be made
zero (0).

[6.1]  "While the address (DSP) is initially always the 4 byte version 4
address, it can be extended to arbitrary levels of subnetting within the
existing Internet numbering plan."  What does this mean?

[6.3]  Delete the paragraph which starts "Digression".

[6.3]  The destination and source lengths are set at 7.  However, in some
hybrid systems, it might be useful to allow a length of, say, 15, so that
the high order IPv4 address is globally unique while the low order IPv4
address is only locally unique.

[6.4]  You seem to be saying that you can't translate packets which have
already been fragmented.  Why?

[6.4]  "If source is class D..." *Destination*, not source.

[6.4]  Again, i am concerned about losing the DF semantics when translating
to CATNIP.

[6.5]  "If length is greater than (about) 65549, fail."  Details, details. 
But, the details are important.

[6.5]  Again, why can't fragments be translated.

[6.5]  In the document, you discuss an option for IPv4 hosts to carry the
extra bytes of a CATNIP address.  Yet, in this section, you fail the
translation if both hosts were not 192 hosts.  This is confusing.

[7.1]  "IPX uses a 32-bit LAN network number, implicitly concatenated with
the 48-bit MAC layer address..."  *Explicitly* is more like it.  (And, nits
which to *me* are important :) : not LAN, not necessarily MAC layer.)

[7.1]  *I* would probably put the padding bytes at the top rather than the
bottom.

[7.2]  It is not necessarily the case that the maximum hop count for IPX
will always be 16.  I think, though, that 255 is a firm upper bound for
now.

Greg Minshall