r2r NHRP - Target Size

["M.J. Robinson" <[e-mail]>]

Yakov, Dimitry and other ROLCers,
	Your discussion of ways in which r2r NHRP and OSPF could be
deployed in a network helped clarify the intended operation of r2r NHRP.
However, using r2r as described seems awkward when routes are aggregated
(in this case by OSPF Area Border Routers).
	It _may_ be that there are _some_ situations, in which it is best
not to aggregate routes, in which case all NHRP has to do is provide a
mapping from IP addresses to NBMA addresses. 
	However, assuming that aggregation at ABRs is to be used,
determining valid target sizes is a problem. The example below 
shows the nature of the difficulty (at least as I understand things):

	Router A (in OSPF area 1 alone) has a route to 199.199.64.0/18 via
its ABR(s). Router A then wishes to establish a shortcut to Host Z which
has IP address 199.199.75.6. This host is connected to an ethernet which
has a netmask of length 24.  Router B connects this ethernet to the NBMA
and is in OSPF area 2 alone. 
	Router A now has a problem when deciding what NHRP Target to use
for its Request. It could use 199.199.75.6/32 (Host Z's address alone).
However, if a short while later Router A also wishes to establish a
short-cut to Host Y at 199.199.75.5 (on the same ethernet) then another
NHRP Request will have to be sent (with attendant processing and state). 
	An alternative approach might be to try a large Target to start
with, and then reduce it every time an error is received. This seems
wasteful and will usually slow down the establishment of a shortcut. 
	In some scenarios, it may be possible to configure a minimum 
Target size. However, as soon as hosts are directly connected to the NBMA 
this approach fails (min target size = 1 IP address).

	Therefore it seems a good idea to me to have some mechanism
whereby the Requester can say "I want to know the cut-through to w.x.y.z,
and to know which other destinations this is a correct cut-through for."
	A way in which this could be achieved is by having a field which
starts off all zeros. At each router, including the Requester, this field
MUST be ORed with the netmask of the forwarding route. The Responder can
then lengthen this mask further if necessary. This method is needed as it
may be that in some situations the Responder alone will choose too short a
netmask (example available on request). 
	Given the way in which r2r NHRP has been specified at present,
this modified Request/Response pair should leave all routers which must
monitor routes with the correct state information. It could also be
naturally extended to cope with Border Routers between different
(instances of) routing protocols. 

	Hope this is relevant,

		Matthew Robinson.