The Routing Over Large Clouds Mailing List Archive by date

[Dimitry Haskin <dhaskin@baynetworks.com>]

Matthew,

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

You have a very valid concern.  My assumption (though it is not explicitly
stated in the Yakov's proposal) is that what you ask for can be accomplished by
including the Destination Prefix Extention (see section 5.7.1 of NHRP spec)
into Reply (and, possibly, Request).

Dimitry