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

Hi Joel,

I'm specifically referring to how the tunnel ingress should react to
congestion reports in terms of traffic engineering (selecting one tunnel
over another), which is the part that Donald is trying to retain in the
draft.

Is that what you're referring to?  If so, can you point to a specific
section in RFC 6040?  I took a quick look and I'm not able to find anything
about that.  All I see there is about propagation of ECN bits.

Thanks,
Anoop

On Thu, Feb 7, 2019 at 9:17 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> Isn't a lot of that general discussion already captured in RFC 6040?
>
> Yours,
> Joel
>
> On 2/7/19 11:54 AM, Anoop Ghanwani wrote:
> > Hi Donald,
> >
> > The functions are useful.  I just think they need more discussion before
> > it can be put in a WG document.  What is being suggested would be useful
> > for any tunneling technology, not just SFC.  And that's why it would
> > need wider discussion as to what information should be fed to the tunnel
> > ingress.
> >
> > A couple of issues for example:
> > - How does one treat ECT vs non-ECT sessions when making these decisions?
> > - How do we know the feedback is accurate if there are no ECT sessions?
> >
> > The document becomes a lot more straightforward if all it is dealing
> > with is propagation of ECN bits from inner to outer header and vice
> versa.
> >
> > Thanks,
> > Anoop
> >
> > On Tue, Feb 5, 2019 at 10:08 PM Donald Eastlake <d3e3e3@gmail.com
> > <mailto:d3e3e3@gmail.com>> wrote:
> >
> >     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 <mailto:d3e3e3@gmail.com>
> >
> >     On Mon, Jan 28, 2019 at 4:23 PM Anoop Ghanwani
> >     <anoop@alumni.duke.edu <mailto: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 <mailto: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 <mailto: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 <mailto:sfc@ietf.org>
> >      > > >> https://www.ietf.org/mailman/listinfo/sfc
> >      >
> >      > _______________________________________________
> >      > sfc mailing list
> >      > sfc@ietf.org <mailto:sfc@ietf.org>
> >      > https://www.ietf.org/mailman/listinfo/sfc
> >
> >
> > _______________________________________________
> > sfc mailing list
> > sfc@ietf.org
> > https://www.ietf.org/mailman/listinfo/sfc
> >
>