Re: The Hole in my proposal

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, j.garrett writes:
> In message <[e-mail]>om>, [e-mail] write
> s:
> 
> > John,
> > 
> > The ARP for large clouds is NHRP.  It used to be NARP, be we decided
> > to make it more complicated.  :-)
> > 
> > Now we are back to facing the fact that NHRP cannot be used for
> > multihomed destinations.  So we have a real routing protocol (I use
> > BGP or IDRP as examples, but OSPF with LSA type 8, or the newer OSPF
> > with an opaque LSA to accomplish the same, would do fine).  In
> > addition we have NHRP sering as ARP for the LC.  We also have NHRP
> > serving as proxy ARP for the single homed nets.
> > 
> > I never suggested that we use directed ARP.
> > 
> > Curtis
> 
> Curtis,
> 
> I hope my mail did not suggest that you suggested that we use Directed ARP.
> However, the mail quoted above clearly suggests that we use real routing
> protocols to find the real next-hop, completely consistent with
> RFC1433, and completely inconsistent with NHRP.  

Wrong.  NHRP acknowledges (sort of) that it has limitastions.  It used
to be (and I think still is) section 8.1.  It just says "if ...
routers ... (don't use it)" [paraphrased obviously].

NHRP is still useful, but only for reaching destinations that are
local to the LC and things that are single homed to the LC.  If you
use it for that, you can also use it as an ARP.

> In addition, you
> suggest using NHRP serving as ARP for the LC.  Unfortunately,
> NHRP as defined in the current internet draft is inconsistent
> with using the real routing protocol to find the real next-hop.

If you have a routing protocol that gives you a next hop which is at
the far end of the LC (advertising router for IDRP or OSPF with LSA
type-8 aka opaque LSA carrying BGP/IDRP attributes), then there is
nothing to prevent you from asking NHRP how to reach that destination
(the address at the other end, not the ultimate destination).  If the
route changes, the NHRP mapping doesn't (just like ARP entries don't
change when routes change).

You are saying get rid of NHRP and use directed ARP.  There is no need
to do this.  Just get rid of the fantacy that NHRP solves all routing
problems.

> To whom does the an NHRP router forward the NHRP request?
> Certainly not to the next-hop router chosen by the real
> routing protocol unless address resolution of that next-hop
> has already been done (and therefore NHRP is not needed).

In IDRP with flooding, or OSPF (always flooding) there is both a next
hop (computed in OSPF after the SPF is run) and an address that
originated the route (router ID originating the LSA in OSPF).  NHRP
follows the next hop, computed by an SPF, and requests the physical
address of the originating router for the LSA.  In IDRP, that physical
address can be carried in an attribute.  A long time ago, I proposed
an attribute for BGP to carry similar information across BGP AS
handoffs end to end through the LC (at that time for use with NARP).
These are essentially the same types of proposals.

> If the subnetwork (e.g., ATM) address of the next-hop needs to
> be determined, and the next-hop is not in the same LIS, a
> reasonable place to send the inquiry is to the peer router
> that advertised the real next-hop. This is the fundamental
> observation of Directed ARP (RFC1433) , and is completely
> missed by NHRP.  Without this fundamental piece, the protocol
> details are irrelevant.  When this fundamental piece is finally
> observed, the protocol details are relatively easy, and of
> course, there are many variations that will work fine.

That's the key.  The next hop for normal routing is on the LIS.  The
next hop for short cut routing is carried in a routing attribute (or
router ID or carried elsewhere by a real routing protocol).

We are also not claiming that the routing protocols won't need a small
amount of change to acoomodate this.  IDRP loses the originating
router when a RD boundary is crossed (the originating router is in the
new RD which isn't all the way across the LC).

> John Garrett

Curtis