Re: NHRP V6 Problems

[[e-mail]]

Jim,

> > 6.  First, why did the Request ID field get inserted into the Registration
> >     Request packet?  Second, since it is in there, what is the policy on
> >     its use?  Do I have to use the same ID for all refreshes?  Or do I 
> >     have to generate a new number for each refresh?
> You use the request ID in the registration request for the same reason you
> use it in the resolution request.

Given that the request ID has been removed from the Purge message, I think
we need to reexamine the usefulness of the field.  I don't see anywhere in
the draft where the server even looks at the number.  It simply parrots  
back to the client what ever was sent.  If this is true, the client should
be able to use this field in anyway it chooses.  It could for example, put
a timestamp of some sort in this field, or the client could choose to 
ignore the field totally.  Comments?

> 
>      A value which, when coupled with the address of the source,
>      provides a unique identifier for the information contained in a
>      Registration Request packet.  This value is copied directly from a
>      Registration Request packet into the associated Registration Reply.
> 
> I probably should have also added the following in the Request ID part of
> Registration Request description:
> 
>      The value is taken from a 32 bit counter that is incremented each
>      time a new request is transmitted.  The same value MUST be
>      used when sending another request for the same destination when a
>      previous request is still active or pending, i.e., when
>      retransmitting a Next Hop Registration Request because a Next Hop
>      Registration Reply was not received, or when refreshing an existing
>      entry to avoid holding timer expiration.  A new value MUST be used
>      when sending a request when no cache entry is present, or a
>      previous cache entry was deleted for any reason.
> 

I think my comments above related to Request/Reply also apply in the
Registration/Acknowledge case.

> Despite the above, I would prefer to see a "larger" number on the refresh 
> because we do not want to be concerned about old registration requests 
> appearing right after a purge or something of that ilk.  Also, refreshes
> are small in number by comparison to resolution requests (and, hopefully :-),
> by comparison to purge and error) so I should not think this would cause
> problems in terms of cycling.
>
 
I am not sure how this number will have any effect on the purge mechanism
because the Request ID was removed from the Purge Message.  But it sounds
to me that you are describing a sequence number, which seems like it would
be much more useful than the current Request ID mechanism.  Honestly, I 
have never seen the benefit in the current scheme.  You will have to 
excuse me if this was discussed in the past as I have only been following
this for a short time.

> I should also probably put some words in there about what it means to be 
> "a more recent request ID"; i.e.,  if we have requests M and N where 
> numerically M>N then M is "a more recent value than" N iff M-N < (2^32-1)/2
> otherwise N is "a more recent value than" M.
> I have not thought of a reason to wait for convergence (as in using
> the lollipop approach).

Lollipop approach?


-chris