Re: comments on NHRP IV

[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.

> Thanks ... pesky Scott

Well, sometimes pesky :-)

> 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?

> 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.

> 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"?

> 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.

> 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.

> 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.

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

Agree.

> 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?

> 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.

Cheers,
Andy
__________________________________________________________________________
Andrew G. Malis   [e-mail]             [phone]
Ascom Nexion      289 Great Rd., Acton MA 01720 USA   FAX: [phone]