Re: router-router NHRP

[Dimitry Haskin <[e-mail]>]

Yakov,

If I understand your R2R NHRP proposal correctly, it requires that *all*
participating routers keep in their FIBs all routes that might be
distributed by the intra-domain protocol of choice regardless if these
routes are actually being used for shortcuts or not.  In many cases
it can be tens of thousand routes mandating that all R2R routers are
higher end routers.  I'm not sure if it's a desirable outcome of your proposal.

In my opinion, it would be more attractive if we could come up with
a mechanism that would allow to limit the number of routers that need
to carry a complete FIB and permit a larger group of lower-end forwarders
to cache only those routes that have been used to establish currently active 
shortcuts.  My crystal tells me that future networks are dominated by
low-end access devices which may not be up to the task of maintaining
complete routing tables (note that my crystal excluded the internet 
backbone due to its insignificance in the global picture).  Frankly
speaking, IMO, designing a R2R NHRP which requires a full routing at all
forwarders is not worth the effort -- we have already protocols supporting
such a paradigm.

In order to make my message more constructive I'll attempt to outline
one of possible approaches (it covers intra-domain shortcuts only):

   There is two types of routers: NH Servers (NHS) and
   NH Clients-Forwarders (NHC).

   All NH Servers fully participate in a intra-domain routing protocol.
    [I would mind if the choice of such protocols was limited to those
     that carry addresses of border routers so there wouldn't be a need
     for a NHS to send messages to resolve a shortcut's egress endpoint].
   Routes to both internal and external to routing domain targets are
   present in the NHS' FIBs.

   NH Clients also participate in a intra-domain routing protocol but
   store only internal routes in their FIBs.  

   When a NH Client wants to establish a shortcut toward a target that
   is outside its routing domain, it sends a NHRP Request to a designated
   NHS and caches the NHRP Reply (it may allow some purge optimizations
   if such a Replay includes an internet route that is used to construct
   such a reply).

   NHC learns about routing changes (see below) and, if a change affecting
   an existing shortcut is detected,  the new information pertaining to
   the shortcut target should be requested from the designated NHS.  If
   Reply dictates that a new shortcut be established, the affected
   shortcut is rebuilt.

   One of the following mechanism can be adopted for NHC to monitor routing 
   changes:

     a) NHCs participate in the intra-domain routing protocol along with HN
        Servers.  The difference is that an NHC does not store routing
        information that is propagated by the protocol but listen to it to
        detect changes that may affect the current shortcuts.

     b) For the every changed route NH Server sends Purge packets to
        the clients that it has provided shortcut information (this is
        where the network mask in the NHRP Purge packet would be helpful).
        Depending on the amount of state information about the clients that
        is kept at the server, it may be possible to do some optimization
        of the purge traffic -- at worst, purges are sent about all changed
        routes to all clients regardless actual client needs (effect is
        the same as a)).

   In order to ensure that the shortcuts egress router is alive, NHC can
   monitor it's state by sending keepalives or use mechanisms provided by
   the intra-domain routing protocol (remember that NHC keeps internal
   routes).  

Regards,
  Dimitry