Re: recent changes requested on the list

[James Luciani <[e-mail]>]

Bruce,

[Bruce Cole wrote on: Wed, 25 Oct 1995 16:12:08]
> >    8) Added the new "S" bit to the Next Hop entry since each next hop entry
> >       would need to be identified as stable.  As it was, there was only one
> >       bit in the reply for all next hop entries.
> 
> Why does each next hop entry need to carry this bit?  Seems to me that under
> realistic scenarios, the settings for these bits will be constant for all
> next hop entries specified in a reply.  Can you (anyone?) give an example of
> when one might want to provide multiple next hop entries in an NHRP reply,
> with bits specifying differing values for different next hop entries?

You are quite right. There is probably no practical reason for this.


[Bruce Cole wrote on: Wed, 25 Oct 1995 16:12:08]
> > 5.2 NHRP Request
> > 
> >    The NHRP Request packet has a Type code of 1.  The NHRP Request packet
> >    is used to register a client with the clients NHS by making a request for
> >    itself.  This is done by setting the source address equal the destination 
> >    address (which also equals client address) and the reply received serves 
> >    as the acknowledgment for the registration.
> 
> I think you're complicating the semantics of request
> packets in order to fold in the register packet functionality.  Apparently
> this is just to make the semantics analogous to what the 1577 folks have.  I

Alignment with 1577++ and ipmc are good reasons but they are not the best reason.
There is currently no method for acknowledgement of a registration in the current 
NHRP specification which IMHO is a fundamental flaw.  If you are not registered you 
are not participating in the protocol fully as a client.  Therefore it is extrememly 
important that you are registered and that you can proceed as if that were the case. 
Registration cries out for an acknowledgement mechanism.  Using the SRC=DST in 
request and reply packets fixes this hole and aligns this protocol with other 
address resolution protocols. Why replicate code in the registration packet 
processing when a simple "if" statement would suffice?

Contrast this with a Purge request.  "There is no real need for an acknowledgement 
here since we already have to deal with the scenario in which the purge is never 
sent because the station that should have sent the purge crashed."
The only true way to be sure a cache entry has been purged is for the entry
to time out. BTW, you did not address this in the note you sent out a few days ago.
I had suggested the removal of the ack for purges but this was not mentioned
in your note of 10/31 where you included the new v5 of the NHRP spec. There is
support for this action. See the original text I sent below:
[Jim Luciani wrote on: Wed, 25 Oct 1995 11:45:15]
>>   It is difficult to justify the need for an acknowledgement for a purge 
>> when there are timers to age out entries.  I would like to suggest that a purge 
>> become a unidirectional request and there be no acknowledgement.  At best, 
>> a purge is an optimization in this scenario. I would not, for example, keep 
>> a station around that is going off-line merely to time out and retry a purge 
>> if I do not get an ack.  

Regards,
-- Jim Luciani
__________________________________________________________________________
James V. Luciani    Ascom Nexion                    voice: [phone]
[e-mail]   289 Great Rd., Acton MA 01720   FAX: [phone]