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

[Bob Briscoe <[e-mail]>]

On 18/05/2019 09:14, Gorry Fairhurst wrote:
> 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.

I'm not sure whether you're using 'sender' to mean 'tunnel ingress' or 
the original sender. I've repeated the sentence with explanations in [], 
'cos I'm not quite sure what problem you're having with it.

* it [the tunnel ingress] SHOULD be able to be configured to zero the 
outer ECN field [the ECN field in the outer header].


For instance, if a tunnel ingress with no specific ECN logic had a 
configuration capability to refer to the last 2 bits of the old ToS Byte 
of the outer (e.g. with a 0x3 mask) and set them to zero, while also 
being able to allow the DSCP to be mapped or set to something, that 
would be sufficient to satisfy both the implementation requirements.

In fact, I think I'll add that as an example.


Bob

>
>
> 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/>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/