Re: NHRP V6 Problems

[James Luciani <[e-mail]>]

Chris,
>    Just a few questions and problems with the Version 6 draft.
> 
> 1.  Is the LLC/SNAP encapsulation referred to in the document finalized?
> 
> >   NHRP packets are encapsulated using the native formats used on the
> >   particular NBMA network over which NHRP is carried.  For example,
> >   SMDS networks always use LLC/SNAP encapsulation at the NBMA layer,
> >   and an NHRP packet is preceded by the following LLC/SNAP
> >   encapsulation:
> >
> >   [0xAA-AA-03] [0x00-00-5E] [0x00-03]
> 
I think this is the best choice given the deliberate attempt to align with
ipmc (i.e., ipmc uses this PID to mean a control packet).

> 2.  Refering to the Request ID for both Request and Reply messages:
> 
> >   Request ID
> >     A value which, when coupled with the address of the source,
> >     provides a unique identifier for the information contained in a
> >     Request and its associated Next Hop Resolution Reply, and any
> >     subsequent Purge.  This  value can be used by the source to aid in
> >     matching requests with replies.  This value could also be sent
> >     across a virtual circuit (in SVC environments) to aid in matching
> >     NHRP transactions with virtual circuits (this use is for further
> >     study).
> 
>    The reference to the purge needs to be deleted.
Darn... yes... I tried to make as few errors of this sort as possible but...

> 3.   We discussed this point before, and agreed on the outcome.  I think the
>      discussion of alignment for the protocol address should be consist with 
>      the way it is described for the NBMA address.  IE.  in the address
>      field discription, not in the length field discription.  I like the
>      wording that is currently being used for NBMA address.
Would you restate this.  There are a few issues to which the above could be
applied and I am not sure which one you meant.

> 
> How about following changes?
> 
> 
>    Proto Length
>      The length in octets, of the internetwork layer protocol addresses
>      appearing in this packet.
> 
> [... other stuff]
> 
>    Source Protocol Addresses
>      This is the protocol address of the station which initially issued
>      an NHRP Request packet.  It is zero-filled to the nearest 32-bit 
>      boundary.
> 
>    Destination Protocol Address
>      This is the protocol address of the station for which the NBMA next
>      hop is desired.  It is zero-filled to the nearest 32-bit boundary.
> 
> 
> 4.  For NHRP replies, why do we need a "Preference" field in the mandatory
>     part?  Since the hop in the mandatory part is supposed to be the most
>     prefered hop any way.  Not that I am opposed to it, just curious.  
Because there may be multiple numerically "best" next hops (let's say we
are doing load balancing of some sort and we have multiple equally desirable
next hops, the choice of which to accept is "a local matter".

> 5.  This one is a big one IMO.  The following text is on page 20, in the 
>     discussion of the Reply packet.
> 
> >   Any extensions present in the Next Hop Resolution Request packet MUST
> >   be present in the NHRP Next Hop Resolution Reply packet, except for
> >   the case of unrecognized non-Compulsory extensions.
> 
> This paragraph makes it sound like an NHS can drop any extentions that
> it does not recognized and that are non-Compulsory.  Obviously, this in not
> the intent as it directly conflicts with the paragraph below which is from
> page 30, section 5.3 Extensions Part.
> 
> 
> >   The Compulsory bit provides for a means to add to the extension set.
> >   If the bit is set, the NHRP request cannot be satisfied unless the
> >   extension is processed, so the responder MUST return an Error
> >   Indication of type Unrecognized Extension.  If the bit is clear, the
> >   extension can be safely ignored, though unrecognized extensions so
> >   ignored that were received in an NHRP Request packet MUST be returned
> >   unchanged in the corresponding NHRP Reply.
> 
> This clear states that ALL extentions that were present in the Request
> packet must be returned in the Reply packet regardless of recognition or
> the compulsory bit.  I would suggest dropping the clause starting with 
> "except for ..." and just say:
> 
>    Any extensions present in the Next Hop Resolution Request packet MUST
>    be present in the NHRP Next Hop Resolution Reply packet.
Fine by me.  Anyone have a differing opinion? 
Also, it should say here the vendor private extension additions can be made
to the reply packet when they were not in the request.  This is stated earlier
in the text but not restated here.

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

     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.

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


> 7.  In section 5.3 Extensions Part:
> 
> >   The Extensions Part, if present, carries one or more extensions in
> >   {Type, Length, Value} triplets.  Extensions are only present in a
> >   Reply if they were present in the corresponding Request;  therefore,
> >   minimal NHRP station implementations that do not act as an NHS and do
> >   not transmit extensions need not be able to receive them.  An
> >   implementation that is incapable of processing extensions SHALL
> >   return an Error Indication of type Unrecognized Extension when it
> >   receives an NHRP packet containing extensions.
> 
> 
> Might I suggest that we create a another error type along the lines of
> "Extensions Not Supported".  This way an implementation can be very specfic
> about this failure condition.  Using the "Unrecognized Extension" error 
> code could lead the requestor to believe that a SPECIFIC extension is not 
> supported and could result in wasted time and network traffic to resolve 
> the problem.  
> 
> IE.  I as a client could decide that the NHS means that it does not 
>      support the first extension, so I remove that extension and resend
>      the query leaving the rest of the extensions intact.  Of course the
>      error returned is going to be the same and so the client will respond
>      in the same manner as before until I have stripped all of the 
>      extensions from the packet.  Obviously, a smart client could be 
>      created, to deal with this problem, by why?  An explict error
>      message indicating that no extentions were supported would make
>      things much easier.
This will not happen.  There is an offset field in the error indication field
which would be set to point to the offending extension.

> 8.  In Section 6.3 Use of the Destination Prefix Extension
> 
> >   The NHRP Destination Prefix Extension should be used with restraint,
> >   in order to avoid NHRP stations choosing suboptimal transit paths
> >   when overlapping prefixes are available.  This extension SHOULD only
> >   be used in an NHRP Reply when either:
> >
> >     (a) All destinations covered by the prefix are on the NBMA network, or
> >     (b) All destinations covered by the prefix are directly attached to
> >         the NHRP responding station.
> >
> >   For other cases, there may be no single optimal transit path for
> >   destinations encompassed by the address prefix, and an NHRP station
> >   may fail to choose the optimal transit path simply because it is not
> >   aware of all such paths.  So for cases not covered by (a) and (b), an
> >   NHRP Reply packet should not include the NHRP Destination Prefix
> >   Extension.
> 
> 
> Hold on here, I agree that a certain amount of care is required when 
> dealing with the destination prefix extention, but that last 
> paragraph really make me nervous.  This is sounding kind of like number
> five above.  I was under the impression that ALL extensions that were
> present in a request packet must be returned in the reply packet.  That is 
> NOT what the above paragraph says though.  I think that it need to be phrased
> such that it does not allow aggregate routes to be returned, but NOT that 
> the extension is not returned at all.
This needs some attention.  Most of the v6 changes were to the packet format
only.  I think this should say that the extension would still exist (or declare
an error maybe) but have a mask of FF.FF.FF.FF in the case of ipv4.

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