comments on NHRP IV

[Scott W Brim <[e-mail]>]

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

Thanks ... pesky Scott


<<Excerpts from a message from Scott W Brim>>

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?

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.

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.

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.

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.

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

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

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.

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.

<<End excerpts from Scott W Brim>>