Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

[Gorry Fairhurst <[e-mail]>]

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 <[e-mail]>
> *Sent:* Thursday, May 16, 2019 7:44 PM
> *To:* Black, David; [e-mail]
> *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:* [e-mail] <mailto:[e-mail]>
>     *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/>