Re: router-router NHRP

[Yakov Rekhter <[e-mail]>]

Dimitry,

> > You are certainly correct. So, for example a domain that uses default
> > for exterior routing could just carry the default route and use
> > this default route for NHRP. NHRP doesn't alter the amount of routes 
> > that need to be carried.
> > 
> > Yakov.
> > 
> 
> Well.. then, IMO, the "first constraint" makes your R2R proposal
> uninteresting.  I hope NHRP's R2R will allow to limit the number of
> forwarding devices that need to carry a full set of routes. I believe
> that it is possible to design R2R such that external routes (whatever
> amount is to be carried) are carried and stored to full extend only by
> limited number of NHRP servers that can serve routing information on
> demand to a much larger group of a lower-end access devices.  I've thought
> that it was the original intend of NHRP.  To boot, I don't think we need
> to design a new routing protocol to do what you are proposing since we have
> already protocols that can do exactly that.

We certainly failed to communicate. The R2R proposal I sent to the ROLC
list certainly allows to accomplish what you are asking for - the
ability of a router to augment (on demand) its existing routing
information (acquired via conventional routing protocols) with
additional routing information acquired via NHRP.

So, for example an OSPF router that is not in area 0 could just
maintain routes to the destinations within its own area, and a single
default route to all other destinations.  This routing information
could be augmented *on demand* using NHRP to discover shortcuts to
destinations either in other areas, or even in other routing domains.

Perhaps it would help if you'll give me an example of what you think
the current NHRP R2R proposal can't do.

Yakov.