Re: Latest NHRP draft

[Andrew Smith <[e-mail]>]

Thanks for the clarifications included in draft-ietf-rolc-nhrp-04.txt

I thought that the text that was added for section 6.4 is a little 
too much hand waving on an important issue that Scott Brim brought up:

>6.4 Use of the Destination Prefix Extension
>
>   A certain amount of care needs to be taken when using the Destination
>   Prefix Extension, in particular with regard to the prefix length
>   advertised (and thus the size of the equivalence class specified by
>   it).  Assuming that the routers on the NBMA subnetwork are exchanging
>   routing information, it should not be possible for an NHS to create a
>   black hole by advertising too large of a set of destinations, but
>   suboptimal routing can result.  For example, it should not be assumed
>   that the proper prefix to advertise is the one provided by the
>   routing system (especially if the prefix is determined from the
>   default route).
>
>   The approach used to determine the prefix width is likely to vary
>   based on the particulars of the situation.  Information could be
>   gleaned from local topology, routing protocols, and other sources.
>
>   In general, the width of the prefix should be handled conservatively
>   (erring toward a longer prefix).
>
>   If multiple cache entries match the desired destination address (due
>   to overlapping prefixes), the longest prefix MUST be used.


This section is supposed to be a part of the protocol definition and 
words such as "handled conservatively" and "likely to vary based on 
the particulars of the situation" are somewhat nebulous. I think that some 
more explicit rules should be defined here or in the currently-empty 
pseudo-code section. This is one of the more ugly parts of the protocol 
anyway (this option is something of a hack to get better scaling) and 
needs more careful definition.


Andrew


********************************************************************************
Andrew Smith					TEL:	[phone]
Technology Synergy Unit				FAX:	[phone]
Bay Networks, Inc.				E-m:	[e-mail]
Santa Clara, CA
********************************************************************************