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

From: "Black, David" <[email-masked]>
Date: Thu, 9 May 2019 00:50:06 +0000

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.

Analogous non-compliance concerns apply to the updates to other RFCs in
Section 5 to varying degrees.

--- Minor ---

[A] Updated RFCs.

Need to be explicit about what the updates are to each of the updated RFCs.
The updates are scattered throughout the draft - a possible approach is to
add a section that summarizes the update(s) to each RFC and provides pointers
to the section(s) that contain the update(s).

[B] Section 4

      *  if it is known that the tunnel egress does not support
         propagation of the ECN field (RFC 6040, RFC 4301 or the full
         functionality mode of RFC 3168)

The parenthetical listing of RFCs is unclear - I think these all do support
ECN field propagation, so edits are needed to make this clear.

[C] Section 4

   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.

This text comes immediately after the text in issue [1].  The problem with
this text is that it's implicitly assuming that the tunnel egress discards
the outer header including any congestion indication that it may contain.

That needs to be stated/explained.

[D] Section 5

   Section 3.1.11 of the UDP usage guidelines [RFC8085] already explains
   that a tunnel that encapsulates an IP header directly within a UDP/IP
   datagram needs to follow RFC 6040 when propagating the ECN field
   between inner and outer IP headers.  The requirements in Section 4
   update RFC 6040 so, by reference, they automatically update RFC 8085
   to add the important but previously unstated requirement that, if the
   UDP tunnel egress does not, or might not, support ECN propagation, a
   legacy UDP tunnel ingress has to clear the outer IP ECN field to
   0b00, e.g. by configuration.

That's too clever/subtle - this draft should explicitly update RFC 8085.

[E] Have the L2TP changes been reviewed by L2TP experts?

[F] Have the AMT changes been reviewed by AMT experts?

--- Editorial ---

Abstract

It surveys widely deployed IP tunnelling
   protocols separated by such shim header(s)

separated by -> that use

Section 4

   Permanently zeroing the outer ECN field is safe, but it is not
   sufficient to claim compliance with RFC 6040 because it does not meet
   the aim of introducing ECN support to tunnels (see Section 4.3 of
   [RFC6040]).

"Permanently" is not the right word.  Suggest rephrasing start of paragraph to

   Zeroing the ECN field in the outer header of all packets is safe, ...

IANA Considerations

The "[TO BE REMOVED: ..." text is not the "right thing to do" - do this instead:

OLD
   IANA is requested to assign the following L2TP Control Message
   Attribute Value Pair:
NEW
   IANA is requested to assign the following L2TP Control Message
   Attribute Value Pair in the Layer Two Tunneling Protocol "L2TP"
   registry (https://www.iana.org/assignments/l2tp-parameters/l2tp-
   parameters.xhtml):
END

IANA will edit this text after performing the assignment and can
remove the link if appropriate.

Thanks, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754
[email-masked]<mailto:[email-masked]>
----------------------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Thu, 9 May 2019 01:08:22 +0000

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: [email-masked]
Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

--- Major ---

Section 3.1 says:

--- Minor ---

[A] Updated RFCs.

[B] Section 4

[C] Section 4

[D] Section 5

--- Editorial ---

Abstract

separated by -> that use

Section 4

IANA Considerations

OLD

Thanks, --David

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 17 May 2019 00:43:52 +0100

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:
> *From:* Black, David
> *Sent:* Wednesday, May 8, 2019 8:50 PM
> *To:* [email-masked]
> *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 ---
>
> These three chunks of text need to be aligned..  I'm not sure what should
>
[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

       mode of RFC 3168:

          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.

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

---

From: "Black, David" <[email-masked]>
Date: Fri, 17 May 2019 15:34:37 +0000

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:

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 <[email-masked]>
Sent: Thursday, May 16, 2019 7:44 PM
To: Black, David; [email-masked]
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:

Thanks, --David

From: Black, David
Sent: Wednesday, May 8, 2019 8:50 PM
To: [email-masked]<mailto:[email-masked]>
Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

--- Major ---

Section 3.1 says:

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.

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.

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

--

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 17 May 2019 23:54:37 +0100

David,

As promised, here's my response to the 'Minor' half of your review...

On 09/05/2019 02:08, Black, David wrote:
> [snip]
Each update to each RFC within S.5.1 says exactly what text in the 
original RFC is updated and exactly what it becomes. Surely it couldn't 
be more explicit?

> to the section(s) that contain the update(s).
The normative updates for each RFC are all in section 5.1. under the 
subsection for each protocol. That's the only place those interested in 
that RFC will look. So that's where it is safest to put each update.

All updates are extremely explicit, and all concentrated in one 
subsection, so I'm not sure how these criticisms have arisen.

> ECN field propagation, so edits are needed to make this clear.
Sry, I've changed it to read:

       *  if it is known that the tunnel egress does not support any

          of the RFCs that define propagation of the ECN field (RFC 6040,

          RFC 4301 or the full functionality mode of RFC 3168)

> That needs to be stated/explained.
You're right. Without context this text is dangerous. Thx. I've changed 
it to:

If a tunnel ingress does not have any ECN logic, 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.

Note, it didn't say it /will/ break; it just says it /risks/ breaking. 
The point is, if it doesn't have ECN logic, it cannot have checked the 
egress ECN capability. Indeed, if the ingress doesn't have ECN logic 
it's quite likely the egress doesn't either, assuming both ends of many 
tunnels are deployed at the same time.

> That's too clever/subtle - this draft should explicitly update RFC 8085.
Not happy about this. Followed to its logical conclusion, as well as 
updating RFC6040, this draft would then need to update every RFC that 
already normatively references RFC6040 (e.g. GUE, Geneve, etc).

Wouldn't such an update get kicked out during IESG review, as a 
duplicate update? Certainly it might make the ID nits checker issue a 
high-pitched scream as it runs round a tight loop of "Updates" headers.

So, instead, how about stating the above para in the opposite order as 
follows:

    This document indirectly updates the UDP usage guidelines [RFC8085]

    0b00, e.g. by configuration. Section 3.1.11 of RFC 8085 already 
explains

    between inner and outer IP headers. And the requirements in Section 4

    update RFC 6040 so, by reference, they indirectly update RFC 8085.

> [E] Have the L2TP changes been reviewed by L2TP experts?
Of course. Each protocol modification was done in collaboration with an 
expert on that protocol. I wouldn't have felt confident to modify all 
these protocols otherwise.

  * L2TP update: Carlos was particularly helpful, but also Ignacio, and
    it was all properly discussed on the L2TPEXT list
  * Similarly, CAPWAP in OPSAWG with Margaret Wasserman/Cullen, Benoit,
    Warren Kumari, Mahalingam Mani, Dorothy Gellert, Dorothy Stanley,
    Michael Montemurro. But once I dug into CAPWAP, it turned out not to
    require any changes.
  * GRE was covered by INT-AREA, particularly Mohamed Boucadair. Early
    on INT-AREA and Alia Atlas did significant reviewing to find which
    protocols it should cover as well.
  * See the ACKs section for the names of all the significant helpers.

> [F] Have the AMT changes been reviewed by AMT experts?
Yup - text suggested by Jake Holland (also ACK'd).

Herding all these cats has involved a fair amount of work and cajoling, 
particularly 'cos it's unfamiliar territory for many people, and it's 
rarely their priority.

> "Permanently" is not the right word..  Suggest rephrasing start of 
> paragraph to
>
I've taken all the above verbatim.
> <https://www..iana.org/assignments/l2tp-parameters/l2tp->
>
> parameters.xhtml):
>
> END
>
I followed RFC5226 "Guidelines for Writing an IANA Considerations 
Section in RFCs" verbatim:

          When
          referring to an already existing registry, providing a URL to
          precisely identify the registry is helpful.  All such URLs,
          however, will be removed from the RFC prior to final
          publication.  For example, documents could contain: [TO BE
          REMOVED: This registration should take place at the following
          location:http://www.iana.org/assignments/foobar-registry]

Bob

> +1 (774) 350-9323 *New *   Mobile: +1 (978) 394-7754
>
> [email-masked] <mailto:[email-masked]>
>

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 18 May 2019 00:27:06 +0100

David,

Three push backs and a question:
a) The MUST and SHOULD you quote below are surely not BCP, they are 
straight protocol implementation spec.

b) I believe it is important that this safety update to RFC6040 is 
formally flagged as an update, so it gets noticed and hopefully acted upon.

c) Also, all the updates to specific protocols in the shim draft start 
with a section like the following example:

          5.1.4.1
          <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-08#section-5.1.4.1>.
          Safe Configuration of a 'Non-ECN' Ingress AMT Relay

    The following text is appended toSection 4.2.2 of [RFC7450]  <https://tools.ietf.org/html/rfc7450#section-4.2.2>  as an
    update to the AMT specification:

       The operator of an AMT relay that does not supportRFC 6040  <https://tools.ietf.org/html/rfc6040>  or one
       of its compatible predecessors (RFC 4301  <https://tools.ietf.org/html/rfc4301>  or the full functionality
       mode ofRFC 3168  <https://tools.ietf.org/html/rfc3168>) MUST follow the configuration requirements in
       Section 4  <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-08#section-4>  of RFCXXXX to ensure it clears the outer IP ECN field to
       zero. {RFCXXXX refers to the present document so it will need to
       be inserted by the RFC Editor}

For implementers updating a particular protocol (e.g. AMT) it would be 
gratuitously weird to have moved Section 4 into a different RFC 
(especially one that did not have PS status).

d) Do you agree with my assessment that the MUST you quote below doesn't 
make anything non-compliant that wasn't already non-compliant with 2474. 
And anything that wants to claim support for anything to do with ECN has 
to comply with the aspect of 2474 that split off the last 2 bits from 
the ToS byte?

If so, there's no longer a problem to solve. Let's move on. This has 
dragged on long enough.

Bob

PS. Thx for other response on ecn-encap - mañana.

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.
>
> it reads like a best current practice recommendation, so …
>
> *From:*Bob Briscoe <[email-masked]>
> *Sent:* Thursday, May 16, 2019 7:44 PM
> *To:* Black, David; [email-masked]
> *Subject:* Re: [tsvwg] David Black's WGLC review of 
>     *To:* [email-masked] <mailto:[email-masked]>
>     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 ---
>
> 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...
>
> 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.
>
> non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. 
> So the equipment would already be non-compliant with all these RFCs.
>
> 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.
>
> Bob Briscoehttp://bobbriscoe.net/

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 18 May 2019 08:57:37 +0100

David, An extra thought added to (d) below...

On 18/05/2019 00:27, Bob Briscoe wrote:
> d) Do you agree with my assessment that the MUST you quote below 
> doesn't make anything non-compliant that wasn't already non-compliant 
> with 2474. And anything that wants to claim support for anything to do 
> with ECN has to comply with the aspect of 2474 that split off the last 
> 2 bits from the ToS byte?
>

[BB] Would the following text change to S.4 of the shim draft also help?

CURRENT:

    the Diffserv field [RFC2474  <https://tools.ietf.org/html/rfc2474>], [RFC3260  <https://tools.ietf.org/html/rfc3260>].

SUGGESTED:

    There might be concern that the above "MUST" makes compliant
    equipment non-compliant at a stroke.  However, by definition it solely applies to
    equipment that provides Diffserv configuration. Any such Diffserv equipment that is
    configuring treatment of the former ToS octet (IPv4) or the former Traffic
    Class octet (IPv6) as a single 8-bit field must have always been non-compliant
    with the definition of the 6-bit Diffserv codepoint in [RFC2474  <https://tools.ietf.org/html/rfc2474>].

Bob

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 18 May 2019 09:14:11 +0100

Just one check below:

> 4 should likewise be moved to the ECN encapsulation draft.
I had to read this several times, and wasn't quite sure:

Was the intention that:

* the configuration SHOULD allow a sender to zero the ECN field in the 
outer header.

Gorry

> Bob Briscoehttp://bobbriscoe.net/  <http://bobbriscoe..net/>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 20 May 2019 11:26:02 +0100

> * the configuration SHOULD allow a sender to zero the ECN field in the 

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

---

From: "Black, David" <[email-masked]>
Date: Mon, 20 May 2019 14:37:27 +0000

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

Thanks, --David

> -----Original Message-----
> Sent: Monday, May 20, 2019 6:26 AM
> To: [email-masked]; Black, David
> Cc: [email-masked]
> >> it reads like a best current practice recommendation, so .
> >>
> >>     should be done, as the "right thing to do" appears to be in
> >>     potential conflict with deployed "running code".
> >>
> >>     --- Major ---
> >>

---

From: "Black, David" <[email-masked]>
Date: Mon, 20 May 2019 14:52:36 +0000

Inline ...  two action items:

  1.  idnits - update IKEv2 reference, and check whether pre-5378 boilerplate is required.
  2.  RFC 8085 on UDP Guidelines is a BCP, and should be updated directly for that reason (vs. indirectly via an update of RFC 6040).  No other RFC that cites RFC 6040 would be affected, unless it's also a BCP.

Thanks, --David

From: Bob Briscoe <[email-masked]>
Sent: Friday, May 17, 2019 6:55 PM
To: Black, David; [email-masked]
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

[EXTERNAL EMAIL]
David,

[David>]  Please check these, especially whether the pre-5378 boilerplate is required.

Thanks, --David

From: Black, David

--- Major ---

[snip]

--- Minor ---

[A] Updated RFCs.

Need to be explicit about what the updates are to each of the updated RFCs.
Each update to each RFC within S.5.1 says exactly what text in the original RFC is updated and exactly what it becomes. Surely it couldn't be more explicit?

The updates are scattered throughout the draft - a possible approach is to
add a section that summarizes the update(s) to each RFC and provides pointers
to the section(s) that contain the update(s).
The normative updates for each RFC are all in section 5.1. under the subsection for each protocol. That's the only place those interested in that RFC will look. So that's where it is safest to put each update.

All updates are extremely explicit, and all concentrated in one subsection, so I'm not sure how these criticisms have arisen.

[David>] Ok for now.

[B] Section 4

[David>] Ok.

[C] Section 4

That needs to be stated/explained.
You're right. Without context this text is dangerous. Thx. I've changed it to:

If a tunnel ingress does not have any ECN logic, 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.

Note, it didn't say it /will/ break; it just says it /risks/ breaking. The point is, if it doesn't have ECN logic, it cannot have checked the egress ECN capability. Indeed, if the ingress doesn't have ECN logic it's quite likely the egress doesn't either, assuming both ends of many tunnels are deployed at the same time.

[David>] I would add at the end "as it risks an ECN-unaware tunnel egress discarding ECN congestion indications as a consequence of discarding outer headers of packets whose inner header indicates ECN capability." to make the risk explicit to those who aren't as deeply involved in ECN as the two of us.

[D] Section 5

That's too clever/subtle - this draft should explicitly update RFC 8085.
Not happy about this. Followed to its logical conclusion, as well as updating RFC6040, this draft would then need to update every RFC that already normatively references RFC6040 (e.g. GUE, Geneve, etc).
[David>] No, RFC 8085 is different, as it's our primary UDP guidelines document for all protocol designers, not a specification of a specific protocol.  This is indicated by RFC 8085 being a BCP, whereas the protocol RFCs are not.

Wouldn't such an update get kicked out during IESG review, as a duplicate update? Certainly it might make the ID nits checker issue a high-pitched scream as it runs round a tight loop of "Updates" headers.
[David>] I think clarity wins over process here.  Update the BCP, please.

So, instead, how about stating the above para in the opposite order as follows:
   0b00, e.g. by configuration. Section 3.1.11 of RFC 8085 already explains

[David>] I think RFC 8085 needs to be explicitly updated, as we are definitely changing its BCP recommendations here.

[E] Have the L2TP changes been reviewed by L2TP experts?
Of course. Each protocol modification was done in collaboration with an expert on that protocol. I wouldn't have felt confident to modify all these protocols otherwise.

  *   L2TP update: Carlos was particularly helpful, but also Ignacio, and it was all properly discussed on the L2TPEXT list
  *   Similarly, CAPWAP in OPSAWG with Margaret Wasserman/Cullen, Benoit, Warren Kumari, Mahalingam Mani, Dorothy Gellert, Dorothy Stanley, Michael Montemurro. But once I dug into CAPWAP, it turned out not to require any changes.
  *   GRE was covered by INT-AREA, particularly Mohamed Boucadair. Early on INT-AREA and Alia Atlas did significant reviewing to find which protocols it should cover as well.
  *   See the ACKs section for the names of all the significant helpers.

Herding all these cats has involved a fair amount of work and cajoling, particularly 'cos it's unfamiliar territory for many people, and it's rarely their priority.

[David>] Thanks, just needed to double-check.  Once we get this draft revised, I'll send a note to the relevant protocol email lists for awareness.

--- Editorial ---

Abstract

separated by -> that use

Section 4

"Permanently" is not the right word..  Suggest rephrasing start of paragraph to

IANA Considerations

OLD
   IANA is requested to assign the following L2TP Control Message
   Attribute Value Pair:
NEW
   IANA is requested to assign the following L2TP Control Message
   Attribute Value Pair in the Layer Two Tunneling Protocol "L2TP"
   registry (https://www.iana.org/assignments/l2tp-parameters/l2tp-<https://www..iana.org/assignments/l2tp-parameters/l2tp->
   parameters.xhtml):
END

IANA will edit this text after performing the assignment and can
remove the link if appropriate.
I followed RFC5226 "Guidelines for Writing an IANA Considerations Section in RFCs" verbatim:

         When

         location:  http://www.iana.org/assignments/foobar-registry]

[David>] Ok, this is editorial-only, so no change is fine ...

Bob

Thanks, --David

--

---

From: "Black, David" <[email-masked]>
Date: Mon, 20 May 2019 15:15:40 +0000

I noticed that network operators are a primary target of the text involved, hence the interest in a BCP.  Let's set that aside for now, more inline ...

Thanks, --David

From: Bob Briscoe <[email-masked]>
Sent: Saturday, May 18, 2019 3:58 AM
To: Black, David; [email-masked]
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

[EXTERNAL EMAIL]

Three push backs and a question:
a) The MUST and SHOULD you quote below are surely not BCP, they are straight protocol implementation spec.
[David>] Indeed they are.

b) I believe it is important that this safety update to RFC6040 is formally flagged as an update, so it gets noticed and hopefully acted upon.
[David>] Agree.

c) Also, all the updates to specific protocols in the shim draft start with a section like the following example:
5.1.4.1<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-08#section-5.1.4.1>.  Safe Configuration of a 'Non-ECN' Ingress AMT Relay

   The following text is appended to Section 4.2.2 of [RFC7450]<https://tools.ietf.org/html/rfc7450#section-4.2.2> as an

      The operator of an AMT relay that does not support RFC 6040<https://tools.ietf.org/html/rfc6040> or one

      of its compatible predecessors (RFC 4301<https://tools.ietf.org/html/rfc4301> or the full functionality

      mode of RFC 3168<https://tools.ietf.org/html/rfc3168>) MUST follow the configuration requirements in

      Section 4<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-08#section-4> of RFCXXXX to ensure it clears the outer IP ECN field to

For implementers updating a particular protocol (e.g. AMT) it would be gratuitously weird to have moved Section 4 into a different RFC (especially one that did not have PS status).
[David>] Ok, and that 5.1.4.1 text (and analogs) is BCP-like text, but ok to use here.

d) Do you agree with my assessment that the MUST you quote below doesn't make anything non-compliant that wasn't already non-compliant with 2474. And anything that wants to claim support for anything to do with ECN has to comply with the aspect of 2474 that split off the last 2 bits from the ToS byte?
[David>] Maybe, let's see where this discussion goes:
> 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.
[David>] I agree that a tunnel implementation whose ingress blindly copies the inbound DSCP/ECN byte to the outer header and whose egress discards the outer header is not compliant with RFC 2474.  The S.4 text change suggested below helps:

If so, there's no longer a problem to solve. Let's move on. This has dragged on long enough.

CURRENT:

   the Diffserv field [RFC2474<https://tools.ietf.org/html/rfc2474>], [RFC3260<https://tools.ietf.org/html/rfc3260>].
SUGGESTED:

   with the definition of the 6-bit Diffserv codepoint in [RFC2474<https://tools.ietf.org/html/rfc2474>].

[David>] Here's the "MUST" requirement text that is referenced:

[David>]  That requirement text uses somewhat different language than the added explanation.

If we could rephrase that "MUST" to better align with the latter sentence in the suggested text, I would be happier, e.g.:

      *  it MUST NOT treat the former ToS octet (IPv4) or the former Traffic
          Class octet (IPv6) as a single 8-bit field, as the resulting linkage
          of ECN and Diffserv codepoint field propagation between inner and
          outer is not consistent with the definition of the 6-bit Diffserv
          codepoint field in [RFC2474];

[David>]  However, that feels like a change from the original text.  I suspect the immediately following "SHOULD" on the ability to zero the outer ECN field on tunnel ingress gets the rest of the necessary "clue" across to implementers, but I'm not confident that I haven't weakened the original "MUST" text  in a way that matters.  What's your view?

Bob

Bob

Thanks, --David

From: Bob Briscoe <[email-masked]><mailto:[email-masked]>
Sent: Thursday, May 16, 2019 7:44 PM
To: Black, David; [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

[EXTERNAL EMAIL]
David,

Thanks, --David

From: Black, David

--- Major ---

Section 3.1 says:

Bob

--

--

--

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 21 May 2019 10:39:50 +0100

David,

[I've added the UDP Guidelines authors to the distr. and digested the 
relevant parts of this otherwise long thread at the end for them.]

On 20/05/2019 15:52, Black, David wrote:

> 1.
>
>
>  2. RFC 8085 on UDP Guidelines is a BCP, and should be updated
>     directly for that reason (vs. indirectly via an update of RFC
>     6040).  No other RFC that cites RFC 6040 would be affected, unless
>     it’s also a BCP.
>
I've searched through RFC8085 and I do not think detailed discussion of 
this update to RFC6040 would be appropriate for the following reasons. 
Nonetheless, a pointer from RFC8085 to flag the tunnel configuration 
updates in this shim RFC could be appropriate.

UDP tunnels are a small part of RFC8085, tucked away at the bottom of 
Section 3.1 about congestion control; in Section 3.1.11 "UDP Tunnels" 
<https://tools.ietf.org/html/rfc8085#section-3.1.11>. Most of 3.1.11 is 
about congestion control, then there's a list of brief bullets with 
other considerations for UDP tunnels. There is no place where UDP tunnel 
management is mentioned, whether by config or auto-controlled set-up. 
For your convenience, I've repeated the ECN bullet and the sentence that 
opens the list below:

    Designing a tunneling mechanism requires significantly more expertise
    than needed for many other UDP applications, because tunnels are
    usually intended to be transparent to the endpoints transmitting over
    them, so they need to correctly emulate the behavior of an IP link
    [INT-TUNNELS  <https://tools.ietf.org/html/rfc8085#ref-INT-TUNNELS>], for example:

    o  Requirements for tunnels that carry or encapsulate using ECN code
       points [RFC6040  <https://tools.ietf.org/html/rfc6040>].
    o  ...

I propose to update that by replacing the bullet as follows:

    o Requirements for how tunnel endpoints propagate any ECN field
    within the UDP header to and from the outer IP header [RFC6040
    <https://tools.ietf.org/html/rfc6040>]. This includes the
    requirement for a tunnel ingress to zero the outer ECN field unless
    it is known that the tunnel egress implements ECN logic [RFCXXXX].
    {RFCXXXX refers to the present document so it will need to be
    inserted by the RFC Editor}

I've changed the existing bullet, because it is itself incorrect. It 
makes the common mistake of implying UDP tunnels can choose whether to 
use ECN codepoints. They can't. The UDP encapsulation will itself always 
be encapsulated by an IP header, which always "uses ECN codepoints" 
whether the tunnel designer likes it or not. That is the nub of the 
problem that this update to RFC6040 attempts to solve.

More specifically, in the shim draft I will remove the UDP paragraph 
from the opening text in section 5, and instead create a sub-section of 
5.1 for UDP tunnels, alongside all the other specific RFC updates. I'll 
also add RFC8085 to the updates header. Then in that new section I'll 
paste the UDP paragraph, but with the end altered as follows:

    Section 3.1.11
    <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-08#section-3.1.11>
    of the UDP usage guidelines [RFC8085
    <https://tools.ietf.org/html/rfc8085>] includes the following brief
    guidance about how a tunnel that encapsulated packets with a UDP/IP
    header handles the ECN field:
    "    o Requirements for tunnels that carry or encapsulate using ECN
    code points [RFC6040]."

    The following text replaces that bullet as an update to RFC 8085:
    "<the replacement bullet text I've already proposed above>"

Bob

>> **
>>> On 17/05/2019 23:54, Bob Briscoe wrote:
>>
>
[snip]
>> [DB] That's too clever/subtle - this draft should explicitly update 
>> RFC 8085.
> [BB] Not happy about this. Followed to its logical conclusion, as well 
> as updating RFC6040, this draft would then need to update every RFC 
> that already normatively references RFC6040 (e.g. GUE, Geneve, etc).
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 21 May 2019 10:42:19 +0100

David,

On 20/05/2019 15:52, Black, David wrote:
>
> Inline …  two action items:
>
>  1. idnits – update IKEv2 reference, and check whether pre-5378
>     boilerplate is required.
>
I've updated the IKEv2 ref and the boilerplate is not needed.

I've created a separate thread for the discussion on updating UDP 
Guidelines.

Bob

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 21 May 2019 11:16:25 +0100

I'm just looking at this and wondering whether we need to update RFC8085 
at all. The document primarily targets traditional use of UDP as an 
endpoint API to applications and upper layer protocols.

As I recall, the intention was to punt all discussion of tunnels away 
from this document, towards other documents, such as the INTAREA tunnels 
ID. That may have taken longer to complete than we first imagined, but 
to me it still remains the primary advice on what to do when 
designing/configuring tunnels. thjsi is part of a long list of items 
that refer the reader to other documents.

See below:

On 21/05/2019, 10:39, Bob Briscoe wrote:
>>     6040).  No other RFC that cites RFC 6040 would be affected,
>>     unless it’s also a BCP.
>>
> I've searched through RFC8085 and I do not think detailed discussion 
> of this update to RFC6040 would be appropriate for the following 
> reasons. Nonetheless, a pointer from RFC8085 to flag the tunnel 
> configuration updates in this shim RFC could be appropriate.
>
> <https://tools.ietf.org/html/rfc8085#section-3.1.11>. Most of 3.1.11 
> is about congestion control, then there's a list of brief bullets with 
> other considerations for UDP tunnels. There is no place where UDP 
> tunnel management is mentioned, whether by config or auto-controlled 
> set-up. For your convenience, I've repeated the ECN bullet and the 
> sentence that opens the list below:
>
>     requirement for a tunnel ingress to zero the outer ECN field
>     unless it is known that the tunnel egress implements ECN logic
>     [RFCXXXX]. {RFCXXXX refers to the present document so it will need
>     to be inserted by the RFC Editor}
>
> use ECN codepoints. They can't. The UDP encapsulation will itself 
> always be encapsulated by an IP header, which always "uses ECN 
> codepoints" whether the tunnel designer likes it or not. That is the 
> nub of the problem that this update to RFC6040 attempts to solve.
>
I am yet to be persauded that this needs any update to RFC8085, but will 
listen of course if people feel there is something wong in defering the 
topic to INT-TUNNELS 
<https://tools.ietf.org/html/rfc8085#ref-INT-TUNNELS> and RFC 6040 (and 
its updates).

> from the opening text in section 5, and instead create a sub-section 
> of 5.1 for UDP tunnels, alongside all the other specific RFC updates. 
> I'll also add RFC8085 to the updates header. Then in that new section 
> I'll paste the UDP paragraph, but with the end altered as follows:
>
>     Section 3.1.11
>     <https://tools.ietf.org/html/rfc8085>] includes the following
>     brief guidance about how a tunnel that encapsulated packets with a
>     UDP/IP header handles the ECN field:
>     "    o Requirements for tunnels that carry or encapsulate using
>     ECN code points [RFC6040]."
>
I don't think this needs to say more than something like:-

RFC 8085 refers to RFC 6040, and the present document updates the text 
provided in RFC 6040, specifically this includes the requirement for a 
UDP tunnel ingress to zero the outer ECN field unless it is known that 
the tunnel egress implements ECN logic.
Gorry

>> [BB] Not happy about this. Followed to its logical conclusion, as 
>> well as updating RFC6040, this draft would then need to update every 
>> RFC that already normatively references RFC6040 (e.g. GUE, Geneve, etc).
>>