Subject: [tsvwg] Fwd: Re: Moving forward on the ECN encapsulation drafts

From: Bob Briscoe <[email-masked]>
Date: Mon, 16 Nov 2020 10:17:43 +0000

tsvwg, David,

I just posted updates to ecn-encap 
<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines#section-4.6> 
and 6040update-shim 
<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim#section-5>
If you'd prefer to read the full text without the commentary below, just 
click those links - they go straight to the reframing section and the 
frag/reassembly section respectively.

Below I give explanation and summarized/paraphrased bullets of what's in 
the draft.
Pls don't sweat the text in this email. The text to sweat is in the drafts.

ecn-encap (intended for BCP)
=========
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-14#section-4.6

I believe the idea here is to say nothing about IP frag/reassembly, but 
still to say stuff about reframing.
IP frag & reassembly is not in scope for this draft anyway. So I've kept 
to purely L2 stuff.
I've made it suitably "sitting-on-the fence", by saying two things so 
that implementers can do either or both:
   * encapsulator or decapsulator SHOULD approximately preserve the 
proportion of PDUs with congestion indications arriving and leaving
* SHOULD ensure that any incoming congestion indication is propagated 
immediately

6040update-shim (intended for stds track)
==============
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-12#section-5

I've included the non-controversial pieces that were missing from 3168:
* On frag, MUST set all the same,
* On reassembly, MUST discard if mix of Not-ECT and other).

Then I've done what I think you asked, which is to refer to what RFC3168 
says, but not normatively.

    Section 5.3 of [RFC3168] defines the process that a tunnel egress
    follows to reassemble sets of outer fragments
    [I-D.ietf-intarea-tunnels] into packets.

Pls ignore the text in rev 11 (we're at-12).
Reason (if you care): I was tired, and I posted that without having 
clicked saved from my editor, so it contained some very old text I'd 
accidentally pasted in from a much earlier David Black email (Jul 2019)!

Bob

On 28/07/2020 15:03, Black, David wrote:
>
> > I wrote a detailed explanation of why my proposed solution satisfied 
> 3168, going through each point for Jonathan, blow by blow.
>
> > He responded by wiping the whole thing and repeating what he had 
> said without trying to understand what I had said at all,
>
> > even though I had written it specifically for how I thought he 
> understood the world.
> >
> > I would like the chairs to do a chairs job and ensure that the WG 
> participants are listening to each other, and respecting each other, 
> and the dialogue reaches a conclusion.
>
> From what I can see, that topic needs to be taken up in a separate 
> draft, to avoid having it hold up these drafts any further.
>
> Here’s the last message that I wrote on this topic, with which I think 
> you mostly agreed: 
> https://mailarchive.ietf.org/arch/msg/tsvwg/8nDK90Pva4SanKqk7VYxJVlBsH8/
>
> Can we start from there to try to craft some text that we can both 
> live with that doesn’t update RFC 3168 or imply that RFC 3168 will be 
> updated?  A goal would be to keep it short.
>
> I don’t think that requires a conclusion to the exchange with Jonathan 
> (or Rod) ... which is why I haven’t been trying to get to a conclusion ...
>
> Thanks, --David
>
> *From:* Bob Briscoe <[email-masked]>
> *Sent:* Tuesday, July 28, 2020 9:47 AM
> *To:* Black, David
> *Cc:* [email-masked]
> *Subject:* Re: Moving forward on the ECN encapsulation drafts
>
> [EXTERNAL EMAIL]
>
> David,
>
> Please do not do what you propose.
>
> The reason I have done nothing on these drafts, is because I am fed up 
> with the way the WG is being conducted on this point, not because I 
> don't have anything to contribute.
>
> I wrote a detailed explanation of why my proposed solution satisfied 
> 3168, going through each point for Jonathan, blow by blow. He 
> responded by wiping the whole thing and repeating what he had said 
> without trying to understand what I had said at all, even though I had 
> written it specifically for how I thought he understood the world.
>
> I would like the chairs to do a chairs job and ensure that the WG 
> participants are listening to each other, and respecting each other, 
> and the dialogue reaches a conclusion.
> It is not the chair's job to write the answer, especially not to 
> override people who have very carefully worked out views,
> And especially not if the chair concerned has not commented on the 
> details of what I have said either,nor stated why it is not acceptable.
>
> Sorry for the frankness, but this hits a raw nerve.
>
>
> Bob
>
> On 28/07/2020 14:30, Black, David wrote:
>
>     Hi Bob,
>
>     Sorry for the short notice (too much email, too many concalls),
>     but I thought I’d give you a heads-up on what I intend to say on
>     the two stuck ECN encapsulation drafts (ecn-encap-guidelines,
>     rfc6040update-shim).  We’ve both been diverted by other things
>     going on in TSVWG, and the drafts have expired in the interim.
>
>     The only outstanding issue on these drafts is the fragmentation
>     text - that text needs to adhere to RFC 3168’s procedures and
>     steer clear of trying to align the rate of CE marking of
>     reassembled packets to the rate of CE marking of fragments.  At
>     this point, I think we need text that just does that, much as it
>     might be desirable to describe how an implementation do better.
>
>     My suggestion for what to do (that I will make in the meeting that
>     starts shortly) is I write some text and send it to you with the
>     request that you hold your nose, insert the text and post the
>     resulting drafts.
>
>     Will that work for you?
>
>     Thanks, --David
>
>     ----------------------------------------------------------------
>
>     David L. Black, Senior Distinguished Engineer
>
>     Dell Technologies, Infrastructure Systems Group
>
>     176 South St., Hopkinton, MA  01748
>
>     +1 (774) 350-9323 <tel:+17743509323> Mobile: +1 (978) 394-7754
>     <tel:+19783947754>
>
>     [email-masked] <mailto:[email-masked]>
>
>     ----------------------------------------------------------------
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/