The Routing Over Large Clouds Mailing List Archive by date

[Adrian Smith <adrian@msn.bt.co.uk>]

Dimitry, 

Given the operation you suggest, I'm having difficulty seeing what event
would cause an NHRPP request with a target netmask other than all ones.
Surely, the only event generating a r2r NHRP request would be the need
to forward a packet to a remote destination.  Setting the netmask of the
target to anything other than all ones requires additional configuration
or state info in the router which sources the request.

--Adrian.
  

According to Dimitry Haskin:
> 
> 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
>