Re: router-router NHRP

[Yakov Rekhter <[e-mail]>]

Dimitry,

> > >   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 h
as
> never seen the corresponding Request in the first place.  Isn't it so?  I did
n't
> see any mechanism in your proposal to handle that.

Consider a router X within an OSPF domain, ASBR Y of that domain, and
router Z (outside of the OSPF domain) that peers with Y using BGP.  Z
advertises to Y a route to some destination D, and puts its own address
as the next hop. Y injects this route into OSPF.  When X originates an
NHRP Request for D, and the Request reaches Y, Y has a route to D, but
the next hop on this route is not Y, but Z. Y returns Z as the next hop
in the NHRP Reply. Since Y certainly sees any changes in this route, Y
would be able to send to X a Purge message once Y notices the changes.

Yakov.