Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption"

Med,

Your point about RFC 5129 is correct, but I'm not personally aware of any
implementations. And I was just using MPLS as an example, there may be
others in the future as well.

Your point about the SFF preserving ECN is implementation dependent, for
example the SFF could have separate input and output interfaces without
shared memory, or the transport encapsulation could change in different
regions of the SFC domain. It's difficult to depend on SFFs being able to
preserve transport-header-dependent information without that becoming a
requirement in the SFC architecture.

Cheers,
Andy

On Thu, Jan 17, 2019 at 10:02 AM <mohamed.boucadair@orange.com> wrote:

> Hi Andy,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Andrew G. Malis [mailto:agmalis@gmail.com]
> *Envoyé :* jeudi 17 janvier 2019 15:50
> *À :* BOUCADAIR Mohamed TGI/OLN
> *Cc :* IETF Secretariat; sfc-chairs@ietf.org;
> draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org
> *Objet :* Re: [sfc] The SFC WG has placed
> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption"
>
>
>
> Med,
>
>
>
> Not all transports support ECN marking, for example NSH over MPLS.
>
> [Med] Isn’t this covered by RFC5129?
>
>
>
> And even where the transport supports ECN marking, note the example in
> Figure 1 in the draft where the outer encapsulation can be stripped during
> SFF processing. In that case, the scope of the ECN marking is limited to
> individual SFF-SFF links. rather than end-to-end.
>
>
>
> [Med] Why couldn’t SFF preserve ECN when doing its transport decap/encap?
>
>
>
>
>
> Cheers,
>
> Andy
>
>
>
>
>
> On Thu, Jan 17, 2019 at 9:12 AM <mohamed.boucadair@orange.com> wrote:
>
> Hi all,
>
> I do think that ECN is naturally better handled at the transport
> encapsulation instead of the NSH itself.
>
> Requiring the functionality to be handled at the transport encap
> (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redundant, IMO.
>
> I like the approach we set in the SFC architecture in which we separated
> service matters from transport ones. I'd vote for maintaining that
> separation cleaner as it was set in the arch RFC.
>
> Thank you.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : sfc [mailto:sfc-bounces@ietf.org] De la part de IETF Secretariat
> > Envoyé : jeudi 3 janvier 2019 06:11
> > À : sfc-chairs@ietf.org; draft-eastlake-sfc-nsh-ecn-support@ietf.org;
> > sfc@ietf.org
> > Objet : [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in
> > state "Candidate for WG Adoption"
> >
> >
> > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state
> > Candidate for WG Adoption (entered by Joel Halpern)
> >
> > The document is available at
> > https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/
> >
> > Comment:
> > This starts the WG call for adoption of this draft.
> > Please respond to the list, indicating support for this as a work item
> of the
> > working group with this document as the basis for the work, or objection
> to
> > the working group adopting this item as a working group draft.
> >
> > The authors should confirm to the chairs and WG secretary that all IPR
> known
> > to them relevant to this draft has been disclosed.
> >
> > The working group adoption call will last 2 weeks, ending at the end of
> the
> > day on Thursday, January 17 2019 COB somewhere.
> >
> > Thank you,
> > Joel
> >
> > _______________________________________________
> > sfc mailing list
> > sfc@ietf.org
> > https://www.ietf.org/mailman/listinfo/sfc
>
>