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

Hi Anoop,

I'm willing to consider removing a lot of this but I don't understand
what's wrong with Section 1.3, item (3). Say you are a provider of SFC
services to many clients and client session are relatively long lived
and the services required by a client session can be provided through
any one of multiple SFF paths. When a new client session starts,
wouldn't the classified want to have congestion information about the
SFF paths in use by existing client sessions when choosing the SFF
path to be used by the new session?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com

On Mon, Jan 28, 2019 at 4:23 PM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
>
> 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
>
> On Mon, Jan 28, 2019 at 1:20 PM Joel Halpern Direct
> <jmh.direct@joelhalpern.com> wrote:
> >
> > 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
> >
> > On 1/28/19 4:18 PM, Anoop Ghanwani wrote:
> > > 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
> > >
> > > On Wed, Jan 23, 2019 at 3:14 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
> > >>
> > >> 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
> > >>
> > >> _______________________________________________
> > >> sfc mailing list
> > >> sfc@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc