The Routing Over Large Clouds Mailing List Archive by date

[Andrew Smith <asmith@baynetworks.com>]

> From atmpost@matmos.hpl.hp.com Mon Nov 27 20:20:50 1995
> Date: Mon, 27 Nov 95 19:33:54 PST
> From: bryang@eng.adaptec.com (Bryan Gleeson)
> To: salo@msc.edu
> Subject: Re: ARP and NHRP question
> Cc: ip-atm@matmos.hpl.hp.com, rolc@nexen.com

Bryan,

> We should allow clients to use _one_ address
> resolution protocol, namely NHRP. We should require that NHRP servers
> also implement ATMARP server functionality, so that a client can use
> either ATMARP or NHRP. 

I still don't understand the need for a son-of-1577 spec to *mandate* that a
server implement both ATMARP and NHRP: isn't it sufficient to state
that there exist two protocols and that servers may come across clients
implementing both. This is the approach that IETF specs have always taken in 
the past and implementors decide what makes sense in their products. I don't 
believe this approach would lead to many "wrong" choices in this case.

> There should definitely not be a requirement
> that a client must try ATMARP first, and then NHRP, or NHRP first
> and then ATMARP. This is just the principle of pushing the complexity
> into a small number of servers rather than a large number of clients.

(I use the term "ATMARPv2" to mean "whichever one we choose for son-of-1577")

I agree. But in addition, I think that the 1577v2 client behaviour
should not mention ATMARPv1. It only needs to mention ATMARPv2. A 1577v2
client implementor should not need to go back and refer to 1577 itself.

This is an entirely seperate issue from whether a ATMARPv2 server has to 
understand ATMARPv1 which I think is an implementation choice.

It is also interesting to note that this issue becomes much simpler because
of the fact that ATMARP requests do not get relayed to clients for
answering.


Andrew

********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy Unit				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	asmith@baynetworks.com
Santa Clara, CA
********************************************************************************