Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sat, 18 May 2019 08:14 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F8B1200B7 for <tsvwg@ietfa.amsl.com>; Sat, 18 May 2019 01:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tjqo2j2uk88T for <tsvwg@ietfa.amsl.com>; Sat, 18 May 2019 01:14:17 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4E120089 for <tsvwg@ietf.org>; Sat, 18 May 2019 01:14:16 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 449811B00082; Sat, 18 May 2019 09:14:12 +0100 (BST)
Message-ID: <5CDFBED3.7070207@erg.abdn.ac.uk>
Date: Sat, 18 May 2019 09:14:11 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Black, David" <David.Black@dell.com>
CC: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <CE03DB3D7B45C245BCA0D243277949363055BC3F@MX307CL04.corp.emc.com> <CE03DB3D7B45C245BCA0D243277949363055BDDC@MX307CL04.corp.emc.com> <89e67cfc-9574-c7a7-b837-c909c2180595@bobbriscoe.net> <CE03DB3D7B45C245BCA0D243277949363056D070@MX307CL04.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949363056D070@MX307CL04.corp.emc.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/uBETvWeN6gnINuFJ9y9Bj1p4Zr0>
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 May 2019 08:14:20 -0000
Just one check below: On 17/05/2019, 16:34, Black, David wrote: > > Before going further down the compliance rathole, let me suggest an > alternative that might resolve this quickly. > > The crucial text (whose technical correctness is not in question) is: > > In order that the network operator can comply with the above > > safety rules, even if an implementation of a tunnel ingress does > > not claim to support RFC 6040, RFC 4301 or the full functionality > > mode of RFC 3168: > > * it MUST make propagation of the ECN field between inner and > > outer IP headers independent of any configuration of Diffserv > > codepoint propagation; > > * it SHOULD be able to be configured to zero the outer ECN field. > > The headaches are being caused by treating that text as an update to > RFC 6040, but looking at it now, > > it reads like a best current practice recommendation, so … > > Would it be reasonable to move that text into the ecn-encapsulation > draft (which is intended to become > > a BCP)? Doing that would sidestep the entire discussion of > consequences of the consequences of > > updating RFC 6040 with that text. > > If that sounds plausible, we should take a look at whether any of the > other RFC 6040 update text in section > > 4 should likewise be moved to the ECN encapsulation draft. > I had to read this several times, and wasn't quite sure: * it SHOULD be able to be configured to zero the outer ECN field. Was the intention that: * the configuration SHOULD allow a sender to zero the ECN field in the outer header. Gorry > Thanks, --David > > *From:*Bob Briscoe <ietf@bobbriscoe.net> > *Sent:* Thursday, May 16, 2019 7:44 PM > *To:* Black, David; tsvwg@ietf.org > *Subject:* Re: [tsvwg] David Black's WGLC review of > draft-ietf-tsvwg-rfc6040update-shim-08 > > [EXTERNAL EMAIL] > > David, > > I'll split your email in two and solely deal with the major issue > first. See inline. > > On 09/05/2019 02:08, Black, David wrote: > > idnits found a couple of minor things: > > * Current reference for IKEv2 is RFC 7296 instead of RFC 5996 > * If any text was copied from pre-5378 RFCs, an additional > boilerplate disclaimer is required. > > Thanks, --David > > *From:* Black, David > *Sent:* Wednesday, May 8, 2019 8:50 PM > *To:* tsvwg@ietf.org <mailto:tsvwg@ietf.org> > *Subject:* David Black's WGLC review of > draft-ietf-tsvwg-rfc6040update-shim-08 > > This is a solidly written draft on updating tunnel protocols that > use shim headers to propagate ECN according to RFC 6040. > > Unfortunately, I found a major issue with the updates [1] along > with a few minor issues (easily dealt with) and a bunch of > editorial items. > > The major issue [1] on updates creating non-compliant > implementations looks like it will need WG discussion on what > should be done, as the “right thing to do” appears to be in > potential conflict with deployed “running code”. > > --- Major --- > > [1] Compliance with RFC 6040 update > > Section 3.1 says: > > However, an RFC has no jurisdiction over implementations that choose > > not to comply with it or cannot comply with it, including all those > > implementations that pre-dated the RFC. Therefore it would have been > > unreasonable to add such a requirement to RFC 6040. > > But then Section 4 goes on to do exactly that by updating RFC 6040 to > > add this text: > > In order that the network operator can comply with the above > > safety rules, even if an implementation of a tunnel ingress does > > not claim to support RFC 6040, RFC 4301 or the full functionality > > mode of RFC 3168: > > * it MUST make propagation of the ECN field between inner and > > outer IP headers independent of any configuration of Diffserv > > codepoint propagation; > > * it SHOULD be able to be configured to zero the outer ECN field. > > followed by this attempt to excuse the result: > > There might be concern that the above "MUST" makes compliant > > equipment non-compliant at a stroke. However, any equipment that is > > still treating the former ToS octet (IPv4) or the former Traffic > > Class octet (IPv6) as a single 8-bit field is already non-compliant, > > and has been since 1998 when the upper 6 bits were separated off for > > the Diffserv field [RFC2474], [RFC3260]. For instance, copying the > > ECN field as a side-effect of copying the DSCP is a seriously unsafe > > bug that risks breaking the feedback loops that regulate load on a > > tunnel. > > These three chunks of text need to be aligned.. I'm not sure what > should > > be done here, as the concern about updating RFC 6040 to cause > non-compliance > > is an important concern. > > [BB] This draft proposes to update RFC6040, which in turn updated > RFC3168, which in turn updated RFC2474 (there were other RFCs in the > tree of updates ending at RFC6040, but those updates were not with > respect to the Diffserv/ECN fields). > > I fully agree that we have to be careful not to make any equipment > that already complies with any of these RFCs non-compliant. And we > don't... > > If any equipment does not satisfy the proposed 'MUST' statement above, > it will not be treating the DSCP and the ECN fields independently. > Such equipment would not have complied with RFC2474, which separated > out the last 2 bits of the ToS byte, which made it possible to specify > ECN in the first place. > > So the proposed 'MUST' statement does not make any equipment that > complied with any of these RFCs non-compliant, unless it was already > non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. > So the equipment would already be non-compliant with all these RFCs. > > Now, check the detailed wording: > > even if an implementation of a tunnel ingress does > > not claim to support RFC 6040, RFC 4301 or the full functionality > > mode of RFC 3168: > > * it MUST make propagation of the ECN field between inner and > > outer IP headers independent of any configuration of Diffserv > > codepoint propagation; > > > You'll notice RFC2474 is not in the list of RFCs that an > implementation might even not claim to support. That's because the > MUST is about Diffserv configuration. If equipment offers any Diffserv > configuration, it already has to comply with RFC2474. However, if it > doesn't already comply with this MUST, it already doesn't comply with > RFC2474. > > So again, this MUST does not make any equipment that complied with any > of the chain of RFCs non-compliant, unless they were already > non-compliant with RFC2474, and therefore non-compliant with all the > RFCs in the chain of updates up to RFC6040, because RFC2474 > grandfathered the chain. > > > > Analogous non-compliance concerns apply to the updates to other > RFCs in > > Section 5 to varying degrees. > > If you accept my arguments above, but can still find other > non-compliance concerns, please do point them out. > > Nonetheless, I'm pretty sure I've been similarly careful to avoid > introducing any non-compliance surprises. > > > > Bob > > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ <http://bobbriscoe..net/>
- [tsvwg] David Black's WGLC review of draft-ietf-t… Black, David
- Re: [tsvwg] David Black's WGLC review of draft-ie… Black, David
- Re: [tsvwg] David Black's WGLC review of draft-ie… Bob Briscoe
- Re: [tsvwg] David Black's WGLC review of draft-ie… Black, David
- Re: [tsvwg] David Black's WGLC review of draft-ie… Bob Briscoe
- Re: [tsvwg] David Black's WGLC review of draft-ie… Bob Briscoe
- Re: [tsvwg] David Black's WGLC review of draft-ie… Bob Briscoe
- Re: [tsvwg] David Black's WGLC review of draft-ie… Gorry Fairhurst
- Re: [tsvwg] David Black's WGLC review of draft-ie… Bob Briscoe
- Re: [tsvwg] David Black's WGLC review of draft-ie… Black, David
- Re: [tsvwg] David Black's WGLC review of draft-ie… Black, David
- Re: [tsvwg] David Black's WGLC review of draft-ie… Black, David
- [tsvwg] ECN tunnel update to UDP Guidelines (was:… Bob Briscoe
- Re: [tsvwg] David Black's WGLC review of draft-ie… Bob Briscoe
- Re: [tsvwg] ECN tunnel update to UDP Guidelines Gorry Fairhurst
- Re: [tsvwg] ECN tunnel update to UDP Guidelines Bob Briscoe
- Re: [tsvwg] ECN tunnel update to UDP Guidelines Black, David