Re: [tsvwg] ECN tunnel update to UDP Guidelines

[Gorry Fairhurst <[e-mail]>]

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

>
> 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>"
>
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.
> Bob
>
>
Gorry

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