Re: ARP and NHRP question

[Andrew Smith <[e-mail]>]

> Date: Wed, 29 Nov 1995 14:14:20 -0800 (PST)
> From: Mark Laubach <[e-mail]>
> To: Andrew Smith <[e-mail]>
> Cc: [e-mail], [e-mail], [e-mail]
> Subject: Re: ARP and NHRP question

Mark,

> > 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.

You didn't answer the question: what is the need for the spec to mandate this
behaviour? As I remember the Danvers meeting, the concensus was very rough and
very approximate and based mainly on the fact that very little work had been
done on NHRP up to that point: I think that NHRP is specified a lot better now
than it was then. 

> It is still the same ATMARP from the clients perspective, please call it
> the same. 

I am refering to required *server* behaviour here, not client behaviour.

> > 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%. 

We'll have to agree to differ on that one then.

> Backward
> compatibility is very important.  This is only an update to RFC1577
> really, not a replacement. 

Of course it is important but it is something that markets and $$$ decide, not
protocol specs. I view son-of-1577 as a replacement for 1577 and I believe
now is the least painful (and probably last) chance to realign all these 
DOA protocols (as Curtis calls them) onto the same track. The more you hang
onto the old ATMARP packet formats and keep them in current standards track
drafts and RFC, the more divergent these work efforts will all become and the 
more time we will all have to spend reading the E-mail and attending the meetings 
of more overlapping working groups.

> Mark
>  

Andrew


********************************************************************************
Andrew Smith					TEL:	[phone]
Technology Synergy 				FAX:	[phone]
Bay Networks, Inc.				E-m:	[e-mail]
Santa Clara, CA
********************************************************************************