Re: ARP and NHRP question

Mark Laubach <laubach@terra.com21.com> Wed, 29 November 1995 22:17 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29564; 29 Nov 95 17:17 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa29560; 29 Nov 95 17: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 QAA27241; Wed, 29 Nov 1995 16:45:04 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id QAA06013 for rolc-out; Wed, 29 Nov 1995 16:54:52 -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 QAA06004 for <rolc@nexen.com>; Wed, 29 Nov 1995 16:54:49 -0500
Received: from terra.com21.com (terra.com21.com [140.174.223.21]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id QAA27201 for <rolc@nexen.com>; Wed, 29 Nov 1995 16:40:18 -0500
Received: (laubach@localhost) by terra.com21.com (8.6.10/8.6.5) id OAA10366; Wed, 29 Nov 1995 14:14:20 -0800
Date: Wed, 29 Nov 1995 14:14:20 -0800 (PST)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Laubach <laubach@terra.com21.com>
To: Andrew Smith <asmith@baynetworks.com>
cc: bryang@eng.adaptec.com, ip-atm@matmos.hpl.hp.com, rolc@nexen.com
Subject: Re: ARP and NHRP question
In-Reply-To: <9511290329.AA14306@milliways-le0.engwest>
Message-ID: <Pine.BSI.3.91.951129140939.9634G-100000@terra.com21.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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.
 
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