[tsvwg] ECN tunnel update to UDP Guidelines (was: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08)

[Bob Briscoe <[e-mail]>]

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


> Thanks, --David
>
>

> On 09/05/2019 02:08, Black, David wrote:
>
>
>> **
>>> *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
>>>
>>> On 17/05/2019 23:54, Bob Briscoe wrote:
>>
>
[snip]
>
>> [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.
>>
>>
>> [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).
>
> 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]
>
>    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. Section 3.1.11 of RFC 8085 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. And the requirements in Section 4
>
>    update RFC 6040 so, by reference, they indirectly update RFC 8085.
>
>


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