Subject: [sfc] Regarding draft-eastlake-sfc-nsh-ecn-support adoption call

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 23 Jan 2019 18:14:10 -0500

While the time for the call has completed, I would like to see the 
current discussion resolve before judging the adoption as chair (with Jim).
As a corollary, if anyone who has not spoken up has an opinion about the 
adoption, it is still VERY helpful if you speak up.  Please provide 
motivation for your response.

If things do not resolve clearly on their own, the chairs will (as is 
required) reach a determination anyway, but WG clarity is preferred.

Thank you,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 28 Jan 2019 11:57:47 +0800

Hi,
the problem presented in this draft is real, the document is well-written,
and thus I support the adoption. I also concur with the proposal Loa have
made on the other thread related to WG AP for this draft - summarize the
discussion, comments received during the WG AP as To-Do list for the WG.

Regards,
Greg

On Thu, Jan 24, 2019 at 7:14 AM Joel M. Halpern <[email-masked]> wrote:

> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 28 Jan 2019 13:18:02 -0800

I read the draft and had a clarification question about Section 1.3
and Section 4.

Is the draft suggestion an alternate congestion control mechanism
between tunnel ingress and tunnel egress which is working separately
from end-to-end congestion control that requires ECN?

If it's just about propagation of bits for the original feedback loop
(i.e. before the tunnel header is added), I support the draft.  If
it's attempting to define a new congestion feedback loop and
mechanism, I think it may need more discussion.

Thanks,
Anoop

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 28 Jan 2019 16:20:06 -0500

I am pretty sure that what is intended is exactly what you say you 
support, namely simple propagation of the information for the ECN 
control loop, not a new loop.

Can you suggest additional or modified owrding for the document to help 
make this clear to readers?

Thank you,
Joel

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 28 Jan 2019 13:23:00 -0800

Hi Joel,

If that is truly the case, then I think Sections 1.3 and 4 should be removed.

Otherwise, I myself am not clear what 1.3 and 4 are trying to
accomplish and therefore would need clarification on that from the
authors.

Thanks,
Anoop