Re: ARP and NHRP question

[Carl Marcinik <[e-mail]>]

>> From [e-mail] Mon Nov 27 20:20:50 1995
>> Date: Mon, 27 Nov 95 19:33:54 PST
>> From: [e-mail] (Bryan Gleeson)
>> To: [e-mail]
>> Subject: Re: ARP and NHRP question
>> Cc: [e-mail], [e-mail]
>
>Bryan,
>
>> We should allow clients to use _one_ address
>> resolution protocol, namely NHRP. We should require that NHRP server
>s
>> 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 client
>s
>implementing both. This is the approach that IETF specs have always ta
>ken 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.
>

I more or less agree with you here and with most of the other 
sentiment that supports keeping the ARP/NHRP issues separate. I agree
with you that we need not mandate that any server require support
for any other protocol other than that which it natively supports.
If a LIS contains both ATMARP and NHRP clients then a server that 
supports both is an implicit requirement. The way in which the 
server accomplishes this should be a local matter and need not be
subject to standardization. As long as the external behavior is
correct in either (the ATMARP and NHRP) case it shouldn't matter.
We have implemented and deployed a prototype ARP/NHRP server that
allows clients to support only their native address resolution 
protocol. While we still need to gain more experience with the 
prototype, I don't see any glaring issues with this approach.

I'm not too keen on mandating support for dual (ARP and NHRP) clients 
either.  That decision should be left for implementation as well. From 
my perspective, client behavior should be as simple as possible. Vendors
desiring to implement dual clients or both clients (separately) or 
only one of the clients should be allowed to do so. It might be nice
in LISes where both types of clients are deployed (possibly in a
dual role) to dynamically determine if their "preferred" service is
available and thereafter just use that service, period! But again,
this behavior need not be mandated. People who design, implement,
and maintain networks should be able to make the decision as to what
kind and what level of service they want in their networks. Obviously,
they can only choose from what is provided, however, I am sure they
will be given adequate choices.

>> 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 complexit
>y
>> 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")

BTW, the approach proposed in the alternate scheme for multiple ARP
server support assumes only native support for ATMARP. This 
clarification (along with a few other fairly important issues) did not
make it into the draft because of time constraints.

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

Agreed.

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

Disagree. This is not a big deal for the most part. I think we would be
remiss in not mandating backward compatibility for RFC 1577 clients
in ATMARPv2 servers.

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

Carl Marcinik
FORE Systems

>**********************************************************************
>**********
>Andrew Smith					TEL:	[phone]
>Technology Synergy Unit				FAX:	+1 408 
>988 5525
>Bay Networks, Inc.				E-m:	asmith@baynetwo
>rks.com
>Santa Clara, CA
>**********************************************************************
>**********
>