Re: NHRP V6 Problems

[[e-mail]]

Jim,

> Chris,

> >    The reference to the purge needs to be deleted.
> Darn... yes... I tried to make as few errors of this sort as possible but...
I'd say that you did a pretty good job with there being so many changes.


> > 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.
This is not intended as a comment on how the system works, simply in how it is
worded in the document.  Jim and I talked about the fact that the length of both
NBMA and the internetwork layer protocol addresses should be expressed in the
same unit, either bits or octets.  At the same time I also stated that I thought 
the document should describe the process of aligning things on 32-bit boundaries
in the same way.  This is only a small semantic change.  However, as Grenville
Armitage stated on Nov 22:

> Anyway, as part of the
> effort to converge on packet construction/parsing rules similar to
> MARS and ATMARP I let an error slip through. Padding of address
> fields (either protocol or NBMA) is _not_ meant to occur. The new
> text was meant to say that protocol and NBMA address fields have
> exactly the number of octets allocated in the packet as are indicated
> by their length fields, and that their length fields indicate exactly
> the number of valid octets in the corresponding address field.

If this is indeed true, then I guess any discussion of how to word the 
alignment requirement is irrelevant.
 


> > 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".
That is kind of what I thought.  Just wanted to check.   Thanks.

> > 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.
I can't find where it says that anywhere in the text.  Please clarify.

While we're talking about extensions, can I use multiple vendor private
extension within a packet with the SAME vendor ID?  I see in the text where is
says:

>              The vendor-private extension may occur multiple times
>   in a packet, to allow for extensions which do not share the same
>   vendor ID to be represented.

I would assume I could, but I just want to double check.

Also, what about a compulsory vendor private extension?  I can imagine 
situations where this would be needed.  For instance, say a vendor extension
is used to further clarify a query request.  If the server did not understand
this extension and simply ignored it, the client could receive the wrong 
information.  But, if the client knew the server did not support the 
extension, then it could reformat the query.  Comments?



> > 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.
I took the existence of the offset field into account with my orginal 
question.  If a server does not support any extensions, it will return an
"Unrecognized Extension" error message and the offset would point to the 
start of the extensions field.  Correct?  This will also be the start of
the first extension.  From this a client would assume that the server means 
that the first extension is unrecognized.  This would lead to the 
situation described above.  



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

Agreed.

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

thanks.

-chris