NHRP V6 Problems

[[e-mail]]

Jim,

   Before I start I would like to say that I am impressed with the number
   of changes that have been made to the document and the overall 
   quality of the draft.  As with everything in life, there is a caveat.

   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]


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.


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.

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.  


>   Preference
>     This field specifies the preference of the Next Hop entry, relative
>     to other Next Hop entries in this NHRP Next Hop Resolution Reply
>     packet which may be in the Additional Next Hop Entries Extension
>     for the given internetworking protocol.  Higher values indicate
>     more preferable Next Hop entries.  Action taken when multiple next
>     hop entries have the highest preference value is a local matter.
>     Set to 0 on a NAK.

[... other stuff]

>   There may be multiple Next Hop entries returned in the Next Hop
>   Resolution Reply by including the Additional Next Hop Entries
>   Extension.  See Section 5.3.9 for use of these entries.  The most
>   preferable Next Hop must be specified in the mandatory part of the
>   Next Hop Resolution Reply.


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.


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?

    I would guess based on the usage for Request/Reply that I would want
    to use the same number for all refreshes, because presumably the entry
    is still in the NHS cache.  Maybe?  

    Please clarify.


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.

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.





Repectfully submitted,

-chris