Re: router-router NHRP

[Dimitry Haskin <[e-mail]>]

Yakov,

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

Well.. I can't place high-end routers at every exit point in my domain
since there are too many of them and the goal is to use only few high-end
routers. But then I don't understand you statement that "only routers in
area 0 would be able to inject BGP information into IGP" -- I'm not aware
of such an OSPF restriction.


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

But, in this case, how would forwarders at each end of a shortcut monitor
the viability of the route that was used for the shortcut?  Since they don't
run BGP and only have the default route in their FIBs they wouldn't see any
routing change unless they are somehow informed of such a change by the border
BGP router which responded to the Request.  The shortcut's egress forwarder
would't be even able to associate a shortcat with a specific route since it has
never seen the corresponding Request in the first place.  Isn't it so?  I didn't
see any mechanism in your proposal to handle that.


Dimitry



> Yakov.
>