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
- Re: ARP and NHRP question James Watt
- Re: ARP and NHRP question James Watt
- Re: ARP and NHRP question Tim Salo
- Re: ARP and NHRP question James Watt
- Re: ARP and NHRP question Eric W. Gray
- Re: ARP and NHRP question James Watt
- Re: ARP and NHRP question Tim Salo
- Re: ARP and NHRP question Grenville Armitage
- Re: ARP and NHRP question Mark Laubach
- Re: ARP and NHRP question Andrew Smith
- Re: ARP and NHRP question Bryan Gleeson
- Re: ARP and NHRP question Juha Heinanen
- Re: ARP and NHRP question Grenville Armitage
- Re: ARP and NHRP question James Watt
- Re: ARP and NHRP question Mark Laubach
- Re: ARP and NHRP question Andrew Smith
- Re: ARP and NHRP question Carl Marcinik
- Re: ARP and NHRP question Mark Laubach
- Re: ARP and NHRP question Mark Laubach
- Re: ARP and NHRP question Andrew Smith
- Re: ARP and NHRP question Carl Marcinik
- Re: ARP and NHRP question Juha Heinanen
- Re: ARP and NHRP question Bryan Gleeson
- Re: ARP and NHRP question Curtis Villamizar
- Re: ARP and NHRP question Mark Laubach
- Re: ARP and NHRP question Andrew Smith