Re: r2r NHRP - Target Size

[Dimitry Haskin <[e-mail]>]

Adrian,

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

You are right that typically a host route (i.e. mask of all ones) will 
be queried and therefore the inclusion of the Destination Prefix Extention
in a Request message wouldn't be necessary. Nevertheless, there is no reason
to limit the R2R NHRP capability to only host route cases.

One example:

Let's assume a forwarder A wants to build a single shortcut to a default
router which mainains a complete routing table and can act as a traffic
de-multiplexer for A.  The domain topology may look like that:

                     E
                     |
      A -- B -- C -- D -- F
                     |
                     G

where D is a proxy router for E, G, and F exit forwarders.  D injects a default
into IGP.  To resolve the shortcat destination, A sends request for the default 
route (i.e. 0.0.0.0/0) along ABCD path.  When request reaches D, D would be obliged
to reply to A since it has more specific routes than the requested default route. D
specifies itself as the shortcut endpoint.

Dimitry





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