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

[Bob Briscoe <[e-mail]>]

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]
> *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 Briscoe                               http://bobbriscoe.net/