comments on NHRP IV

[Dave Katz <[e-mail]>]

   X-Authentication-Warning: enigma.acton.timeplex.com: Host localhost.acton.timeplex.com didn't use HELO protocol
   Reply-To: [e-mail]
   Date: Tue, 25 Apr 1995 12:04:32 -0400
   From: Andy Malis <[e-mail]>

   Scott,

   > I'd like to ask these questions again, since I never heard back the
   > first time.  Dave?  Anyone?

   Dave's been doing some world traveling lately ... I don't know if he's
   had a chance to do much email since the IETF.  I'll try my best to
   fill in.

I've been travelling the galaxy, only stopping in occasionally on Earth.
Santa Cruz is like that.  ;-)

   > p. 4:  I'm not sure that the concept of encapsulation is useful.  To me
   > that means placing a whole packet within another packet.  The *data* of
   > an NHRP request is placed in an IP packet, yes, but are you doing
   > anything more than that?  If so is it really necessary?

   I think this is a comment on Dave's terminology more than what's
   actually going on.  NHRP is encapsulated in IP as much as TCP or UDP
   or EGP (or anything else that has an IP protocol number).  You know
   what's going on - how would you better describe it?

I've thought of saying that it "packages" the request in an IP packet,
or something of the sort, but I guess I don't have as strict a definition
of "encapsulation" as you do.  I welcome suggestions here.

   > p. 6:  The first pages of the document keep link, network, and internet
   > layer concepts nicely separated, but about here things get mushy.  The
   > NBMA layer is clearly a network.  You don't want to talk about "Network
   > layer filtering", you want internet layer filtering.  You don't mean
   > link layer filtering in e.g. X.25 or SMDS (since they are not a link
   > layer), you mean network layer filtering.

   This is a very good suggestion, although many of us now tend to think
   of IP as the network layer, and anything beneath IP in the stack as
   the link layer.  We should probably have some basic definitions at the
   front of the document, and stick with them all the way through.  I
   recall that this suggestion was made (by you?) in the meeting as well.

I settled on "internetwork layer" and "subnetwork layer."  Still not
wonderful, but perhaps less loaded than "network."

   > p. 6:  In the last paragraph you say "when a source station is unable
   > to communicate with the responder" - this word is too vague, please be
   > more specific.

   How about "destination"?

I assume that the confusion was around the phrase "unable to communicate"?
I added a parenthetical insertion giving SVC setup failure as an example.

   > p. 6:  Replying with aggregated next hop information can be risky.  It
   > assumes that X knows enough about the NBMA-level connectivity of the
   > area it is advertising (D') to do so, and coordinates with anything
   > else which might be connecting D'.  I'd like to see this stated
   > explicitly.  Perhaps it can be tied into statements on the bottom of
   > page 8 wrt external destinations.

   Good suggestion.

Yep.

   > somewhere: mention that NHRP messages are sent unreliably, repeating
   > for some time until the current sender gives up and sends an error back
   > toward its sender.

   Another good suggestion.

Sure.

   > p. 9: top paragraph.  Should "it is expected" imply a MUST in this mode?

   No - see the paragraph split between pages 9 and 10.  The only MUST is
   that the egress and internal filtering routers are NHRP-capable.

I changed the "In particular" sentence to carry a MUST, which I think
expresses this.

   > p. 10: "link layer network" isn't a phrase one should use willingly.
   > Change it to NBMA network, perhaps.  (here & elsewhere)

   Agree.

After my global replace I ended up with "subnetwork layer network."  ;-)
It's now just "subnetwork" (with a suitable definition at the front).

   > p. 16: Source holding time: I don't want to trust hosts.  I want a NHS
   > to be allowed to be configured to ignore the source holding time and
   > use some other value (e.g. selecting from a set of configured ones)
   > when its management thinks it necessary.

   Hmmm... one would think that the source host would know best about
   such details as how mobile or immobile it is, which was one of the
   main reasons we have the source holding time field.  Can you provide a
   good reason for overriding it?

As far as I can tell, the only loser if the host gets this wrong is the
host itself.  It's also the case that the holding time is related to
the rate at which the information is refreshed (via periodic queries/
registers), and only the host controls that.  Black holes can easily
result.

   > p. 22: The Network ID Mismatch message, and errors in general: it
   > should be explicit that these messages are sent to the previous sender,
   > not to the originating host.

   Yes.

Hm.  I actually figured that all errors would go back to the originator
(since the previous hop isn't necessarily known, nor particularly relevant).
The intent is to give the originator a clue as to why the request isn't
being satisfied.  A number of the errors are out of the control of the
originator (particularly the (sub)Network ID) but telling the originator
is the kind and decent thing to do.  Providing some information to 
network management is certainly a useful thing to do as well, of course.


I should have the 04 draft out in the next couple of days.

--Dave