[arch-d] Fwd: some comments on draft-iab-protocol-transitions-05

Joe Touch <touch@isi.edu> Wed, 11 January 2017 00:56 UTC

References: <3277f3d0-b937-a984-299f-b26983c37e5f@isi.edu>
To: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
From: Joe Touch <touch@isi.edu>
Message-ID: <1b5f66a7-7980-b610-1691-7a145294fa67@isi.edu>
Date: Tue, 10 Jan 2017 16:55:36 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <3277f3d0-b937-a984-299f-b26983c37e5f@isi.edu>
Content-Type: multipart/alternative; boundary="------------B5466B082AADCB2645909448"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/mEJHX3-SgGIKfTsAQ85wLUFJfXk>
Cc: IAB IAB <iab@iab.org>
Subject: [arch-d] Fwd: some comments on draft-iab-protocol-transitions-05
Precedence: list

Hi, all,

I posted some comments on this doc to the stackevo list.

Joe



-------- Forwarded Message --------
Subject: 	some comments on draft-iab-protocol-transitions-05
Date: 	Tue, 10 Jan 2017 14:50:25 -0800
From: 	Joe Touch <touch@isi.edu>
To: 	stackevo-discuss@iab.org <stackevo-discuss@iab.org>
CC: 	Dave Thaler <dthaler@microsoft.com>



Hi, Dave (et al.),

I had some thoughts on this doc, summarized below. I hope they're useful.

Joe

-------

The discussion of IPv4-6 transition might include a discussion of paths
not taken in IPv4, e.g., earlier versions included variable length
addressing.

Regarding new features, it might be useful to discuss how options are
handled. We include them to future-proof a protocol, to ease the
transition to new features. However, we too often succumb to commercial
pressures to ignore this flexibility in favor of performance or economy.
That's why IPv4 fragments are being dropped, why IPv6 options are now
limited in total length, and why options are generally deprecated for
traffic that expects to successfully traverse the Internet. It's also
how we're boxing ourselves into needing IPv-next rather than augmenting
what we have in our hands.

There are a few design lessons here that might be useful to point out. A
discussion of TLV vs. fixed tag encodings would be useful. Reasons to
put version IDs, or demuxing tags in most protocols would be useful too
(as we learned for the TCP Experimental option codepoints). It might be
useful to have a more detailed discussion of handling "TBD" fields,
e.g., when they MUST be set to X by legacy sources, MUST be ignored vs.
discarded if not zero by legacy receivers, and when to use each strategy.

I.e., we're constantly oscillating between considering a "thin waist"
either ossification or stability; the former when we actually need new
capabilities (like more addresses), the latter when we actually want
things to work (like running DNS over HTTP). We need to understand that
to know whether and how we want to support transitions like these.

------

[arch-d] Fwd: some comments on draft-iab-protocol… Joe Touch