Re: NHRP/MARS version number location.
James Luciani <luciani@nexen.com> Fri, 29 December 1995 22:42 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17954;
29 Dec 95 17:42 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa17950;
29 Dec 95 17:42 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by
guelah.nexen.com (8.6.12/8.6.12) with ESMTP id RAA14082;
Fri, 29 Dec 1995 17:11:18 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
RAA03774 for rolc-out; Fri, 29 Dec 1995 17:22:12 -0500
Received: from shovel.nexen.com (shovel.nexen.com [204.249.98.39]) by
maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id RAA03765;
Fri, 29 Dec 1995 17:22:09 -0500
Received: from localhost (luciani@localhost) by shovel.nexen.com
(8.6.12/8.6.12) with SMTP id RAA05958; Fri, 29 Dec 1995 17:26:08 -0500
Message-Id: <199512292226.RAA05958@shovel.nexen.com>
To: salo@msc.edu
cc: gja@thumper.bellcore.com, ip-atm@matmos.hpl.hp.com, rolc@nexen.com
Subject: Re: NHRP/MARS version number location.
Date: Fri, 29 Dec 1995 17:26:07 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: James Luciani <luciani@nexen.com>
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: [Un]Subscribe to rolc-request@nexen.com, submissions to rolc@nexen.com
X-Info: Email archive at ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
X-Info: Hypermail archive at http://cell-relay.indiana.edu/mail/archives/rolc/
X-Info: FTP archive at ftp://ftp.nexen.com/pub/rolc/
> > > However, as you show below, the MARS header doesn't really have a > > > version number... > > > > What is ar$op.version then? > > [...] > > As you say below, it identifies a protocol, not a version of a protocol. I am honestly mystified as to why you feel that we cannot have versions of address resolution protocols. ar$op.version=2 is not defined yet but it could be the next NHRP or the next MARS or it could be an address resolution mechanism that solves a separate address resolution problem but does not want to inflict the writing of new parsers, state machines, etc. unnecessarily on some poor defenseless programmer. If the variation from the existing address resolution mechanisms is so great that the existing machinery can't be used then it will have a separate LLC/SNAP code point. > I don't believe that NHRP and MARS are versions in the sense that one > in intended to replace the other. No! They are intended to merge, IMHO, at some point in the future but their respective aims at present are too diverse to be included in the same document. Basically we need to know a bit more about both technologies before we can realistically expect them to work and play well with others. > (Do we need to solicit opinions from the broader IETF community about > the appropriate definition of the term "version?") I assume your kidding right? I assume you are not suggesting that we waste a couple of terebytes of disk space with email over the sophistry of the deeper, truer meaning of the word "version". Sounds to me like I need to brush the dust off "Being and Nothingness" over New Years :-) > > > So, it appears that what you have been calling a "version" number is > > > really a protocol identifier. In other words, there is no protocol > > > version number within the MARS header, only a [mislabeled] field which > > > indicates the protocol. > > > > Again, you missed the point of the harmonization of the NHRP and MARS. > > The version number identifies the instance of the address resolution > > protocol. > > It sounds like you just affirmed my assertion that the MARS "version" > number is actually a protocol identifier. Again... It is the version of the address resolution protocol being used. > As I mentioned earlier, you might find it instructive to examine the > use of the version field other Internet protocols. To be perfectly honest, you might find it instructive to note that (as I pointed out in a previous note) THE Internet Protocol has a differenct PID between v4 (PID=0x0800) and v6 (PID=0x86DD). And, you'll note that the fixed part (the IP header) is so different that any attempt at parsing them in the same way would be futile.
- Re: NHRP/MARS version number location. Grenville Armitage
- Re: NHRP/MARS version number location. Tim Salo
- Re: NHRP/MARS version number location. Grenville Armitage
- Re: NHRP/MARS version number location. James Luciani
- Re: NHRP/MARS version number location. Tim Salo
- Re: NHRP/MARS version number location. Grenville Armitage
- Re: NHRP/MARS version number location. James Watt
- Re: NHRP/MARS version number location. James Luciani