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

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

+1 on Bob's comments - both the "MUST" and "SHOULD" statements in this discussion apply to the tunnel ingress.

Thanks, --David

> -----Original Message-----
> From: Bob Briscoe <[e-mail]>
> Sent: Monday, May 20, 2019 6:26 AM
> To: [e-mail]; Black, David
> Cc: [e-mail]
> Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-
> rfc6040update-shim-08
> 
> 
> [EXTERNAL EMAIL]
> 
> 
> 
> 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/