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

["Joel M. Halpern" <[e-mail]>]

Okay.  With that, as chair I conclude that the working group has adopted 
this document.  Authors, please resubmit as draft-ietf-sfc-nsh-ecn-support.

Yours,
Joel

On 2/7/19 6:03 PM, Anoop Ghanwani wrote:
> Hi Joel,
> 
> OK, I can see a case for leaving it in.
> 
> Thanks,
> Anoop
> 
> On Thu, Feb 7, 2019 at 11:20 AM Joel M. Halpern <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     I had not understood that you meant specifically the tunnel congestion
>     feedback.  I see that there is already a normative reference to
>     https://tools.ietf.org/html/draft-ietf-tsvwg-tunnel-congestion-feedback-06
> 
>     While that normative reference may create problems for completing the
>     work, I do not see it as a problem for the working group adopting the
>     document?  If TSVWG ends up not advancing that document, then
>     presumably
>     the corresponding sections o fthis document would be removed?
> 
>     Yours,
>     Joel
> 
>     On 2/7/19 1:10 PM, Anoop Ghanwani wrote:
>      > 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
>     <[e-mail] <mailto:[e-mail]>
>      > <mailto:[e-mail] <mailto:[e-mail]>>> 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
>     <[e-mail] <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      > <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>> 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   [phone] (cell)
>      >      >       1424 Pro Shop Court, Davenport, FL 33896 USA
>      >      > [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >
>      >      >     On Mon, Jan 28, 2019 at 4:23 PM Anoop Ghanwani
>      >      >     <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>> 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
>      >      >      > <[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >     <mailto:[e-mail]
>     <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>>>
>      >      >     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
>      >      >     <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>> 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
>      >      >      > > >> [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >     <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >      > > >> https://www.ietf.org/mailman/listinfo/sfc
>      >      >      >
>      >      >      > _______________________________________________
>      >      >      > sfc mailing list
>      >      >      > [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >      >      > https://www.ietf.org/mailman/listinfo/sfc
>      >      >
>      >      >
>      >      > _______________________________________________
>      >      > sfc mailing list
>      >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      > https://www.ietf.org/mailman/listinfo/sfc
>      >      >
>      >
>