Re: The Hole in my proposal

["j.garrett" <[e-mail]>]

In message <[e-mail]>om>, [e-mail] writes:

> 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.  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.
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).
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.

John Garrett