Re: router-router NHRP

[Yakov Rekhter <[e-mail]>]

Dimitry,

> I think I now understand how your scheme works. Let me try to apply it
> to the above setup and see if we are in the agreement:
> 
>   Domain edge (border) routers (which can be lower-end access devices) acquir
e
>   a subset external routing information, say via BGP, and inject this
>   information into IGP, say OSPF.  OSPF area 0 high-end routers are able to
>   maintain a complete set of the external routes which are advertised to them
>   by border routers. An area 0 router don't propagate this complete set
>   of routes to lower-end routers in other areas, but advertise the default
>   route with the next hop pointing to this area 0 router. At this point, each
>   domain edge router has only external routes that it acquired via BGP in
>   addition to the default route(s) that it received from one or more area 0
>   router.

One correction. I wold assume that at the border of the domain you would
need to place not low-end access devices, but high-end routers. In fact,
only routers in area 0 would be able to inject BGP information into IGP.
So, you would probably place low-end devices within non-0 areas, and you
wouldn't use these devices as the area border routers. This way, each
low-end device would need only to maintain routes to the destinations
within its own area, and one default route that would cover all other
destinations.

>   When an access router needs to establish a shortcut toward an external
>   network for which there is no more specific than default route entry in
>   the local FIB,  it sends a Request along the default route path, i.e. to
>   the area 0 router. Since area 0 maintains a full set of routes it can
>   easily determine which border router is the exit point for the target
>   (provided that the target forms a subset of a single route) and
>   re-sends Request to that router.  The exit edge router responds and
>   the originating access router get all information it needs to establish
>   a shortcut.  So far so good.

Correct.

>   Now there are still a case which troubles me.   Let's assume that
>   a shortcut was established from edge router A to to edge router B.  If
>   B loses a route to a target it sends Purge to A - which is good.  But what
>   if after the shortcut was established, another edge router C also learns
>   a route to the same target network and becomes a much better exit router
>   to that target?  It seems that neither A nor B has no way to detect 
>   a better route since the states of their FIBs would not be affected by
>   a new route at C.  Perhaps A needs periodically re-request information
>   about the existing shortcut targets to see if any relevant routing change
>   occured.

Correct. As a matter of fact, the example you described applies not
only to the R2R case, but to the case where NHRP is originated by a host
(just replace edge router A with host H, and leave the rest of you example
intact).

>   Another case which I believe is not supported by the proposal is
>   "third party advertisements", i.e. when an exit forwarder is not
>   the same device as a router that acquires a route.  But may be it is
>   not an important case to support.

Actually the proposal does support this case. So, if a border router
receives a BGP route (which carries NEXT_HOP information), the border
router may pass the next hop information (rather than its own address)
in response to an NHRP Request.

Yakov.