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

["Black, David" <[e-mail]>]

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.

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