Re: ARP and NHRP question

Carl Marcinik <carlm@fore.com> Thu, 30 November 1995 01:17 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04503; 29 Nov 95 20:17 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa04499; 29 Nov 95 20:17 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.98.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id TAA29251; Wed, 29 Nov 1995 19:47:23 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id UAA08080 for rolc-out; Wed, 29 Nov 1995 20:00:17 -0500
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id UAA08070 for <rolc@nexen.com>; Wed, 29 Nov 1995 20:00:13 -0500
Received: from fore.com (relay.fore.com [169.144.1.1]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id TAA29243 for <rolc@nexen.com>; Wed, 29 Nov 1995 19:45:43 -0500
Received: from dolphin (dolphin.fore.com [169.144.1.16]) by fore.com (8.6.11/8.6.11) with SMTP id TAA07203; Wed, 29 Nov 1995 19:53:33 -0500
Received: from adapsw-atm by dolphin (4.1/SMI-4.1) id AA20912; Wed, 29 Nov 95 19:51:46 EST
Message-Id: <9511300051.AA20912@dolphin>
To: Mark Laubach <laubach@terra.com21.com>
Cc: Andrew Smith <asmith@baynetworks.com>, bryang@eng.adaptec.com, ip-atm@matmos.hpl.hp.com, rolc@nexen.com, carlm@fore.com
Subject: Re: ARP and NHRP question
In-Reply-To: Your message of "Wed, 29 Nov 1995 14:14:20 PST."
Date: Wed, 29 Nov 1995 19:51:45 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Carl Marcinik <carlm@fore.com>
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

>> 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.
>
>The "son-of-1577" spec mandate is based on the consensus decision(s) made at 
>the Danver's meeting in the joint rolc & ip-atm session.

Well, consensus can change based on new understanding, etc. It seems that
in the ARP/NHRP case it has.

> 
>It is still the same ATMARP from the clients perspective, please call it
>the same. 
> 
>> 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.
>
>Especially since RFC1577++ obsoletes RFC1577.
>
>> This is an entirely seperate issue from whether a ATMARPv2 server has to 
>> understand ATMARPv1 which I think is an implementation choice.
>
>It goes without saying that I disagree with this 100%.  Backward
>compatibility is very important.  This is only an update to RFC1577
>really, not a replacement. 
>
>Mark
>