Subject: [arch-d] The proper fole of version numbers

From: Dave Crocker <[email-masked]>
Date: Wed, 06 Feb 2008 09:13:30 -0800

Folks,

Howdy.

Some specifications embed a version number in the protocol or format data.  Most 
IETF protocols do not.

Over the years, I've come to believe that the lesson to us has been that version 
numbers really aren't all that helpful and that the proper way to distinguish 
truly incompatible versions is through use of a different value in the 
underlying multiplexing field.  So, different IP <protocol> field, different 
<port> number, different DNS underscore "attribute", etc.

As a recent, private discussion has progressed, I've started to consider the 
topic more interesting than I had previously thought and wondered whether there 
was interest amongst others to pursue it?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Architecture-discuss mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: John Day <[email-masked]>
Date: Wed, 6 Feb 2008 12:24:57 -0500

After years of looking at the problem and first realizing that 
protocol id field couldn't identify the protocol in the layer above, 
I concluded it was identifying the syntax of the protocol in the 
layer above.  However further consideration determined that that was 
not so much wrong but the wrong direction.  I finally came to the 
conclusion that:

Any requirement for a protocol id field is an indication of either 
the layer boundary being in the wrong place or a poorly designed 
layer.  Protocol id fields are unnecessary.

If you need one, you have done something wrong somewhere else. Go 
back and re-work it.

Take care,
John

---

From: [email-masked]
Date: Wed, 6 Feb 2008 09:44:08 -0800

Quoting Dave Crocker <[email-masked]>:

> Folks,
> 
> Howdy.
> 
> Some specifications embed a version number in the protocol or format data. 
> Most IETF protocols do not.

I noted this when a blanket request for "lessons learned" went out. 

> Over the years, I've come to believe that the lesson to us has been that
> version numbers really aren't all that helpful and that the proper 
> way to distinguish truly incompatible versions is through use of a 
> different value in the  underlying multiplexing field. 
>  So, different IP <protocol> field, different

I'd like to understand this more. There are two muxing fields - one defined in
the higher level (e.g., Ethernet frames), and one inside the protocol (e.g., IP
version). The pair <eth_proto><ip_ver> is the overall demuxing; the key
question is whether ethernet needs to demux IPv4 differently from IPv6 (FWIW,
it currently does, rendering the IP version field moot for
ethernet-encapsulated frames).

IMO, versioning is the responsibility of the protocol itself, not the parent
protocol. Version changes are defined and should thus be contained entirely
within a protocol. It doesn't make sense to consume shared demux space at the
outer layer protocol to handle problems created by only a subset of protocols.

The cost of putting the version field inside the protocol itself is the cost of
pinning the first bits of header, and often also then requires the chunksize
(8, 16, 32, ... bits), bit, and word order to be fixed through at least the
version area. I don't consider this a big issue; if a protocol changes word
order, then it can be issued a new higher-level <proto> number.

IMO, the two (<proto><vers>) should be considered major/minor revision numbers.
There are cases where it is appropriate to increment either; I don't see a
great argument to force all increments to occur in either side of that overall
field, though I prefer to err on the "keep your mess to yourself" position that
says "think twice before incrementing <proto>, then don't unless there's no
other way".

> topic more interesting than I had previously thought and wondered whether
> there was interest amongst others to pursue it?

Count me in, obviously...

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Feb 2008 13:57:51 -0500

This is something I have debated in quite a few contexts.
It seems to me that there are a range of needs, and that a version 
number can be useful for a specific subset of that range.  People 
frequently tend to treat it much too broadly.

I will start however with a caveat.  While the following theoretical 
perspective seems to suggest significant value for a version number, and 
I frequently try to design one in for these needs, I note that there are 
few or no places where it has actually been both needed and effective. 
So the following may be a classic case of something that looks good in 
theory, but not in practice.

With most of the protocols we design, we use a core basic mechanism, and 
then some form of extension or addition.  We hope and try to get it 
right that the extension mechanisms will be sufficient for what we need.
However, it seems sensible to also design for needing to change the 
basic mechanism (the mandatory fields in the basic message header, or 
similar core items.)  If one wants to deploy such a change, the ability 
to negotiate which basic header one is using, or at least to confirm 
compatibility of that basic header, seems very useful.
Even if one is not negotiating, the ability to support more than one 
variation, and to use the one that the other party supports, is 
conceptually powerful.
This seems to work better in pairwise protocols with an opening 
negotiation (such as BGP or PNNI) than in protocols for more dynamic 
communication establishment (such as IP or SIP)

Yours,
Joel

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 6 Feb 2008 14:33:03 -0500

> <port> number, different DNS underscore "attribute", etc.

I think there's a place for both approaches, but I do agree that the
encapsulating layer mux/dispatch-point isn't used as often as it
should be.

> was interest amongst others to pursue it?

A BCP for protocol versioning sounds like a good idea.

FWIW, at the top of the protocol stack is data versioning, which the
W3C TAG (BCCd, because I'm sure they'd be interested) has been
exploring;

http://www.w3.org/2001/tag/doc/versioning

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
_______________________________________________
Architecture-discuss mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Feb 2008 09:50:26 +1300

I'd be grateful if people interested in this question would
have a look at
http://tools.ietf.org/id/draft-carpenter-extension-recs-02.txt
and say whether
(a) it's worth resuming work on it
(b) what it has to say about versioning makes sense.

fwiw I think the abstract value of version numbers depends very
much on whether the versioning handles backwards compatibility
or not. If you break compatibility, the version number
effectively says "this is a new protocol." But since
protocol numbers and assigned ports are finite resources,
maybe that's what we have to do.

   Brian

---

From: Tony Li <[email-masked]>
Date: Wed, 6 Feb 2008 14:09:30 -0800

> communication establishment (such as IP or SIP)

I'll have to largely agree with this.  In my experience, encoding  
first for extensibility is a requirement (e.g., TLVs).  Once you've  
done this, you've necessarily made some design choices that involve  
finite fields (e.g., how many type codes do you have?).  Having a  
version number elsewhere in the packet is some cheap insurance  
against running out of type codes or making the type field much  
larger than would seem optimal.  The same reasoning would seem to  
apply to avoiding issues of an inadequate or oversized length field.   
A version number also allows you to make other changes to the fixed  
header in the message,

Tony

---

From: John Day <[email-masked]>
Date: Wed, 6 Feb 2008 20:28:19 -0500

I would have to agree with Tony and Joel on version number fields. 
They seem better in theory than useful in practice. Probably a waste 
of time.  Better to simply design the protocol to be extensible.  But 
from what I have seen of the modern class of protocols, extensibility 
is essentially the degenerate case.

Version numbers were interesting 20 years ago, but not now.  And as 
Joel indicated, even then it looked better in theory than it turned 
out in practice.

Take care,

---

From: "tom.petch" <[email-masked]>
Date: Fri, 8 Feb 2008 18:11:11 +0100

I suspect that it depends on where you are sitting in software development
process.

If you introduce a new version number, then the software for the old version
number must be updated to demux the new version to the appropriate handler.

If you use the SAP of the underlying protocol, then your software can continue
unaltered, but the software of the underlying protocol must be updated to demux
to something else.

But if you are a user, who looks at protocol decodes to determine why a network
is not working as it should, then having the information all in one place, a
version number in the protocol header is always to be preferred, as 'helpful'
protocol decoders have a habit of stripping off the lower, 'less interesting'
layers.

I think that SNMP, retaining the header format and updating the version number,
gets it absolutely right.

Tom Petch