Re: router-router NHRP

[Dimitry Haskin <[e-mail]>]

Yakov,

> > 
> > OK. Let assume a transit routing domain with around 300 forwarding
> > devices (this example is not quite arbitrary but is based on an existing
> > FR network).  This domain must be aware of up to 40,000 external networks.
> > These external networks are distributed behind the forwarding devices in
> > such a way that no high scale aggregation is possible. 
> >  
> > Every forwarding device/router is inexpensive lower-end box that is
> > capable to handle a few thousand (~5000) packet streams at a time,
> > can support forwarding cache of a few thousand entries (10,000 max), but
> > unable to maintain a full set of potential target (i.e. 40,000 routes).
> > 
> > To make our task easier, let assume that we can convince the domain owner
> > to install 20-30 high end routers to handle routing load.
> > 
> > Can you explain how your R2R proposal will handle the described setup?
> > I really try to understand your proposal and hope your explanations would help
> > me. Sorry if I am the only one on the list who doesn't see the obvious.
> 
> I'll be glad to explain how the R2R proposal would handle the described
> setup, but I need one more piece of information from you. Specifically,
> I'd like to understand how do you plan to organize routing without shortcuts
> (without NHRP) in the scenario you described. Remember that NHRP is just a 
> mechanism to discover shortcuts, and that routing should be able to work 
> correctly (although without shortcuts) in the absence of NHRP.
> 
> 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) acquire
  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.

  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.

  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.

  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.

Dimitry