The Routing Over Large Clouds Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <199503080736.CAA19272@maelstrom.acton.timeplex.com>, Juha Heinanen 
writes:
> one could also separate the next hop resolution problem from the address
> resolution problem.  
> 
> when i saw about two years ago that nhrp has its problems, i proposed a
> simple, scalable protocol called nbma arp to solve the address
> resolution part.  nbma arp can be thought as an extension of atmarp and
> we could have proceed with in in ipoveratm wg.  it was not, however,
> done, since some people believed that nhrp (which ramesh and i also
> wrote the first drafts of) could be enhanced to get rid of the loop
> problems.
> 
> now two years have passed and we don't have anything!  perhaps ipoveratm
> group should take another serious look at nbma arp as the atmarp
> extension and consider nhrp again once rolc has the definite solution
> (if such even exists).
> 
> -- juha


Juha,

Do you have implementation experience?  If so, I for one would like to
hear about it.  If travel to Danvers is a problem, perhaps you could
just provide an update to the list.

Perhaps we should discuss NBMA ARP (NARP) and decide whether to
continue to promote NHRP or stick with the simpler solution.  We still
need a solution for directly connected hosts and might want the
ability to proxy NARP for single homed destinations.

If there are features in NHRP (like perhaps prefix lengths so you can
proxy ARP a whole prefix at once), then maybe we need to trim NHRP to
eliminate support for things that just won't work.  Either that or
extend NARP slightly if needed and move it from and Experimental RFC
back onto a standards track and drop NHRP.

IMO we should at least be willing to discuss this at the next IETF.

Curtis