Re: [tsvwg] ECN tunnel update to UDP Guidelines

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

Bob and Gorry,

> 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.
> This is part of a long list of items that refer the reader to other documents.

I generally concur - my goal is to have a visible "updates" relationship from RFC 8085 to the rfc6040update-shim RFC-to-be so that the uninitiated implementer puts this update on her checklist of RFCs to deal with based on RFC 8085.

Towards that end, Bob's proposed text is the sort of thing that I'd like to see (this is the text that the rfc6040update-shim draft would provide as its update to RFC 8085):

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

Although, "within the UDP header" is not the right phrasing - it may suffice to just drop those 4 words.

Thanks, --David

From: Bob Briscoe <[e-mail]>
Sent: Tuesday, May 21, 2019 6:53 AM
To: Gorry Fairhurst
Cc: Black, David; tsvwg IETF list; Eggert, Lars; Greg Shepherd; Bob Briscoe; Joe Touch
Subject: Re: ECN tunnel update to UDP Guidelines


[EXTERNAL EMAIL]
Gorry,

What you're suggesting is what I proposed to David earlier (see my suggested text right at the bottom of this thread). It highlights that this RFC /indirectly/ updates the UDP guidelines by updating RFC6040. I figured that this approach at least flags that the UDP guidelines have been altered, so a text search would find this out. However, it doesn't list RFC8085 explicitly in the Updates header.

I was happy to just go along with whatever David wanted, as doc shepherd. However, I wasn't aware of the general desire to keep the UDP guidelines primarily about e2e UDP. I can see that it will get unwieldy if every RFC about UDP tunnels ends up updating the UDP guidelines. So it would be better to rely mostly on the int-area tunnel I-D.

Indeed, since I replied to Joe's point about fragmentation & tunnels, I've realized that there were no normative requirements in RFC6040 about handling ECN during reassembly (other than a reference to ecn-encap-guidelines which are just guidelines), so I will be referring to the int-area tunnels I-D from this shim draft, and I suspect Joe might end up wanting to point his fragmentation discussion to the shim draft explicitly, not just RFC6040.


Bob

PS. I've switched to sending from my CableLabs address, cos Netapp's mail system doesn't trust the reputation of my ([e-mail]<mailto:[e-mail]>) mail provider. I should make it clear though that I have my independent hat on for this ECN-encap work, not my CableLabs hat.

On 21/05/2019 11:16, Gorry Fairhurst wrote:
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]<mailto:[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/