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

Donald Eastlake <d3e3e3@gmail.com> Thu, 31 January 2019 02:14 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFCB1271FF; Wed, 30 Jan 2019 18:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7QnLzMY5qzU; Wed, 30 Jan 2019 18:14:48 -0800 (PST)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA01130EBA; Wed, 30 Jan 2019 18:14:48 -0800 (PST)
Received: by mail-io1-xd36.google.com with SMTP id g8so1341038iok.4; Wed, 30 Jan 2019 18:14:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AP5lg2OstijlpZXB7tFSYnjcdv8geMxnEWV8TVMjmjQ=; b=WNsShMtVSZaLJhZ/alG3tJ+YdMWpEVMF5T8kGHhm0MVj5miqjTQTvpW26a53GOhu8n fy1aWIuei73MBRi9LcvONMQGx1qAsRkKQsXq+ZRHPXdhESpqDS0pZQ6YbOBvyE5YMHkO NCgTn4YBgu7p/9lV+us0NV/8LIG+rpoHEPOVAhKA0Gw4Gc7+3WPdXxV/ediTjWktKhuI xrMsHAm6fhSzkhQjTLJx9bvyOA6BRumzrIJ105P3PxwOrbKcvLoO+8RtBJYclVVR25E7 aJOcAsYyD3sfAs/Nv1JALFLk+s9EhQpWwJWQV1qducJO7ayUUCIuCet1gpMrz8EWsr7R jNuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AP5lg2OstijlpZXB7tFSYnjcdv8geMxnEWV8TVMjmjQ=; b=RnviQElGysO/XMtseIJ9/7pEb/fcCP0z3tTnAlynPuZt+e2nclKqvGVJZd7HUSjarA ZXnwb+ps/hkvcxefTybYyJ3MQUx0nhN0f/08mASrViuR07ZTYEmR/jXQBBeMeK0qD8Zi ybOr83e3PK/1TYzCcbKRM5PPl82qRdVfx8XY/TXIB1d15Qb1+AuJaC2c1Oa7+CSw7Vdk bh4HdVFljxnZtwsoCsTe8HXFSNJn7cvtvTQiBue1kgsbh27J6da1J2sR7oooxDcpizbN 8CB2qjEew55hwVGIgy4e+sS0W6X2ns5oVxcSq6LxIzP/RnkTufMrKrc5qZUn54yEC1vq fQhw==
X-Gm-Message-State: AHQUAuYrOZs6OyuoEUpgzAWnTK9I941WwNfvQATWCkTGK1Jbc/KGfPGo 30EnCv9cOT4+1S27exfFJ/EMonJv2hff5TVDR/g=
X-Google-Smtp-Source: AHgI3IaSIIqI/nFJWTgVEt1bWIeKSahAccWdsBV7DqQQdnjenWmGMoJgBCpTYcGPkbajdPSXZ1YsWfRnw6N6v1htH8M=
X-Received: by 2002:a6b:3945:: with SMTP id g66mr2580859ioa.131.1548900887344; Wed, 30 Jan 2019 18:14:47 -0800 (PST)
MIME-Version: 1.0
References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAA=duU2DOKXFH6GTDsVxN__OcfEUc5D-2tszGd2Z7QYBmyCv0w@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAA=duU1zNrdhnnmDmHpSpiCEOwU1ezzefQDwBq50GGtm1arJtA@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <e3eed468-86f3-6cd0-8f0f-71a0390b2f17@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7899163b-e90e-4fec-a523-a7c4f2e881df@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAF4+nEF0-F2WvBMyOhDuZXotX4VgKmWU0MZpUfXSHQJk7-1H0w@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA0E314@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0E314@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 30 Jan 2019 21:14:35 -0500
Message-ID: <CAF4+nEEwkNvoQPMec2VkCFVcWzei70YY_-D_T-8kywQ_CPaNtg@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, "draft-eastlake-sfc-nsh-ecn-support@ietf.org" <draft-eastlake-sfc-nsh-ecn-support@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/eCBzDj56GF0dnirkQyrJwvk6rk8>
Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption"
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2019 02:14:51 -0000

I guess that at this point it depends mostly on how often you think
the different circumstances will occur.

I don't think people will use outer DSCP marking that much in SFC
domains. While it is plausible for the egress SFF to change the DSCP,
I think it would only rarely depend on how an outer DSCP was
manipulated across the SFC domain. If I am correct then it is
significantly more effort to handle ECN between the outer and inner
IP.

Maybe we need to make competing presentations and see which way the
room hums in Prague...

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 3:39 AM <mohamed.boucadair@orange.com> wrote:
>
> Hi Donald,
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Donald Eastlake [mailto:d3e3e3@gmail.com]
> > Envoyé : samedi 26 janvier 2019 06:36
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : Joel M. Halpern; 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"
> >
> > Hi Med,
> >
> > See below.
> >
> > On Thu, Jan 24, 2019 at 1:39 AM <mohamed.boucadair@orange.com> wrote:
> > >
> > > Joel,
> > >
> > > DSCP preservation is a trivial requirement for intra-domain SFC. Please
> > refer to https://tools.ietf.org/html/rfc2983:
> > >
> > >    When a tunnel is not end-to-end, there are
> > >    circumstances in which it may be desirable to propagate the DSCP
> > >    and/or some of the information that it contains to the outer IP
> > >    header on ingress and/or back to inner IP header on egress.
> >
> > So, I've read RFC 2983 and consulted with its author David Black. RFC
> > 2983 is not a standards track or BCP RFP. It's just Informational.
>
> [Med] Yes, but an interesting RFC as revealed by the wording used in some documents, e.g.,
>
> draft-ietf-intarea-gue:
>    "For instance, if an IP packet is being
>    encapsualated in GUE then diffserv interaction [RFC2983] and ECN
>    propagation for tunnels [RFC6040] SHOULD be followed."
>
> or RFC8085:
>    "Designing a tunneling mechanism requires significantly more expertise
>    than needed for many other UDP applications, because tunnels are
>    usually intended to be transparent to the endpoints transmitting over
>    them, so they need to correctly emulate the behavior of an IP link
>    [INT-TUNNELS], for example:
>
>    o  Requirements for tunnels that carry or encapsulate using ECN code
>       points [RFC6040].
>
>    o  Usage of the IP DSCP field by tunnel endpoints [RFC2983]."
>
>  It
> > focuses on two models, the "uniform" model you describe below and the
> > "pipe model".
> >
> > > One of the models discussed in 2983 assumes the following.
> > >
> > >    In this model, any packet has exactly one DS Field
> > >    that is used for traffic conditioning at any point, namely the DS
> > >    Field in the outermost IP header; any others are ignored.
> > >    Implementations of this model copy the DSCP value to the outer IP
> > >    header at encapsulation and copy the outer header's DSCP value to the
> > >    inner IP header at decapsulation.
> > >
> > > Because SFF is an encap/decpa function, it falls under the above
> > implementations.
> >
> > RFC 2983 doesn't say anything about which model should be used by SFC
> > nor does it say which model should necessarily be used by an
> > "encap/decap function".
>
> [Med] Agree. I cited the uniform model because this is what is recommended in some networks to preserve QoS policies, see for example RFC6908.
>
>  I continue to believe that the pipe model,
> > which does not require any modification to the inner IP DSCP based on
> > an outer IP DSCP, is more appropriate for SFC.
>
> [Med] This should be deployment-specific, IMO: the architecture should allow for both.
>
> If we focus on the pipe model, an SFF has to look into the inner header for diffserv matters. Then, if an SFF does that for DSCP, it can do it for ECN too without requiring duplicated functionality at the NSH level.
>
> >
> > The situation is quite different for ECN, as compared with DSCP. For
> > example, standards track RFC 6040 requires examination of both the
> > outer and inner ECN marking at egress and their combination (or
> > dropping the packet).
> >
> > Thanks,
> > Donald
> > ===============================
> >  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> >  1424 Pro Shop Court, Davenport, FL 33896 USA
> >  d3e3e3@gmail.com
> >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Joel M. Halpern [mailto:jmh@joelhalpern.com]
> > > > Envoyé : mercredi 23 janvier 2019 17:10
> > > > À : BOUCADAIR Mohamed TGI/OLN
> > > > Cc : 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"
> > > >
> > > > <no hat>
> > > > Maybe I am missing something important, but I would not expect SFF to
> > > > exhibit the behavior you describe relative to DSCPs.
> > > >
> > > > I do not know of any place where this is required for intra-domain
> > > > tunnels.  It is an interesting issue for inter-domain usage of SFC.  But
> > > > our scope is explicitly intra-domain.
> > > >
> > > > As far as I know, DSCPs are not re-marked within a domain.  They are
> > > > modified at entry / exit from a domain, but that is not an issue for an
> > SFF.
> > > >
> > > > Is there someplace where the behavior you are asking about is required
> > > > by existing documents?
> > > >
> > > > Yours,
> > > > Joel
> > > >
> > > > On 1/23/19 8:37 AM, mohamed.boucadair@orange.com wrote:
> > > > > Hi Joel,
> > > > >
> > > > > The point Joel is SFFs has to preserve whatever DSCP marking when
> > > > encapsulating/encapsulation (including cases where transport encap
> > changes).
> > > > >
> > > > > If you will, we can describe the scenario using your words:
> > > > >
> > > > > =======
> > > > > Consider an SFF that receives a packet with a transport DSCP marking
> > > > > and an NSH header.  That SFF removes the transport header.  It then
> > > > > (usually) sends the packet via some other means to an SF, and gets the
> > > > > packet back.  After which it sends it on to the next SFF with a new
> > > > > transport header carrying the NSH.
> > > > > Let us take as given that we want to support DSCP marking preservation.
> > > > > Then we need to somehow preserve the DSCP information that the SFF
> > > > > receives.
> > > > > ==========
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > >> -----Message d'origine-----
> > > > >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com]
> > > > >> Envoyé : mardi 22 janvier 2019 13:31
> > > > >> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis
> > > > >> Cc : 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"
> > > > >>
> > > > >> (again: speaking personally)
> > > > >> DSCP behavior is VERY different from ECN behavior in terms of
> > > > >> intermediate router modification.  DSCPs may get rewritten at certain
> > > > >> specific places, but not generally at interior routers.  So mapping
> > from
> > > > >> the interior packet DSCP to the exterior packet DSCP and IEEE marking
> > is
> > > > >> normal and safe.  there is no need to reverse the process.  ECN
> > marking
> > > > >> needs to reverse the process due to the fact that individual routers
> > are
> > > > >> expected to change the marking based on local conditions.
> > > > >>
> > > > >> At least thaat is how I understand it,
> > > > >> Joel
> > > > >>
> > > > >> On 1/22/19 1:25 AM, mohamed.boucadair@orange.com wrote:
> > > > >>> Hi Joel,
> > > > >>>
> > > > >>> What makes ECN specific in this regards compared to DSCP marking
> > > > >> preservation?
> > > > >>>
> > > > >>> Cheers,
> > > > >>> Med
> > > > >>>
> > > > >>>> -----Message d'origine-----
> > > > >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com]
> > > > >>>> Envoyé : vendredi 18 janvier 2019 15:55
> > > > >>>> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis
> > > > >>>> Cc : 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"
> > > > >>>>
> > > > >>>> <chair hat off>
> > > > >>>> Let me try as an individual to paraphrase what I understand the
> > document
> > > > >>>> to be offering.  That authors should feel free to comment further
> > > > >>>> including if necessary telling me that I am confused.
> > > > >>>>
> > > > >>>> Consider an SFF that receives a packet with a transport ECN
> > indication
> > > > >>>> and an NSH header.  That SFF removes the transport header.  It then
> > > > >>>> (usually) sends the packet via some other means to an SF, and gets
> > the
> > > > >>>> packet back.  After which it sends it on to the next SFF with a new
> > > > >>>> transport header carrying the NSH.
> > > > >>>> Let us take as given that we want to support effective ECN.
> > > > >>>> Then we need to somehow preserve the ECN information that the SFF
> > > > >> receives.
> > > > >>>>
> > > > >>>> One way would be to insist that the SFF, when it receives the ECN
> > > > >>>> information, has to rummage through to find the internal IP packet,
> > and
> > > > >>>> must update the internal ECN information therein.  Ugg.  IThat would
> > be
> > > > >>>> a pretty onerous requirement.
> > > > >>>>
> > > > >>>> Instead, the document suggests that the SFF transfer the marking to
> > the
> > > > >>>> NSH header, and then use that NSH marking when it generates the new
> > > > >>>> transport header.  This can then be used when the packet exits the
> > NSH
> > > > >>>> domain to propagate the information to the header (which is by
> > > > >>>> definition exposed when the NSH header is removed.)
> > > > >>>>
> > > > >>>> Med, if I understand you properly you are suggesting that the SFF
> > should
> > > > >>>> somehow keep the information from the transport header associated
> > with
> > > > >>>> the packet, but not in the NSH header.  In some SFF implementations,
> > and
> > > > >>>> with some ways of working with SFs, that is doable.  Requiring that
> > > > >>>> would limit the implementation and deployment choices.
> > > > >>>>
> > > > >>>> <chair hat somewhere>
> > > > >>>> Yours,
> > > > >>>> Joel
> > > > >>>>
> > > > >>>> On 1/18/19 4:15 AM, mohamed.boucadair@orange.com wrote:
> > > > >>>>> Hi Andy,
> > > > >>>>>
> > > > >>>>> Please see inline.
> > > > >>>>>
> > > > >>>>> Cheers,
> > > > >>>>>
> > > > >>>>> Med
> > > > >>>>>
> > > > >>>>> *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* Andrew G.
> > Malis
> > > > >>>>> *Envoyé :* jeudi 17 janvier 2019 16:33
> > > > >>>>> *À :* BOUCADAIR Mohamed TGI/OLN
> > > > >>>>> *Cc :* sfc-chairs@ietf.org; IETF Secretariat;
> > > > >>>>> 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,
> > > > >>>>>
> > > > >>>>> 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.
> > > > >>>>>
> > > > >>>>> [Med] I understood this was an example, but still this is IMHO
> > supposed
> > > > >>>>> to be handled among the spirit of the effort led by Bob in 6040 and
> > its
> > > > >>>>> current & futures updates.
> > > > >>>>>
> > > > >>>>> 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.
> > > > >>>>>
> > > > >>>>> [Med] I don’t understand your point about separate inputs/output
> > > > >>>>> interfaces and the change of encap schemes. Let’s put aside SFC for
> > a
> > > > >>>>> moment and consider the example of a LISP XTR which is supporting
> > ECN
> > > > >>>>> dissemination/handling. That xTR may not use the same in/out
> > > > interfaces,
> > > > >>>>> but still need to achieve some processing when doing its
> > encap/decap.
> > > > >>>>>
> > > > >>>>> It's difficult to depend on SFFs being able to preserve
> > > > >>>>> transport-header-dependent information without that becoming a
> > > > >>>>> requirement in the SFC architecture.
> > > > >>>>>
> > > > >>>>> [Med] I don’t think that we can tag congestion notification as
> > > > >>>>> “transport-header-dependent”. There are ways to pass that info even
> > > > when
> > > > >>>>> the transport encap changes.
> > > > >>>>>
> > > > >>>>> This is IMHO among things that the WG is supposed to cover under
> > this
> > > > >>>>> item in the charter (please note that those are clearing taged as
> > > > >>>>> transport issues):
> > > > >>>>>
> > > > >>>>> ==
> > > > >>>>>
> > > > >>>>> 4) Transport Considerations - This will capture the expectations
> > SFC
> > > > >>>>> places on transport behavior, including dealing with issues such as
> > > > >>>>> congestion indications and responses.
> > > > >>>>>
> > > > >>>>> ==
> > > > >>>>>
> > > > >>>>> Cheers,
> > > > >>>>>
> > > > >>>>> Andy
> > > > >>>>>
> > > > >>>>> On Thu, Jan 17, 2019 at 10:02 AM <mohamed.boucadair@orange.com
> > > > >>>>> <mailto:mohamed.boucadair@orange.com>> wrote:
> > > > >>>>>
> > > > >>>>>       Hi Andy,
> > > > >>>>>
> > > > >>>>>       Please see inline.
> > > > >>>>>
> > > > >>>>>       Cheers,
> > > > >>>>>
> > > > >>>>>       Med
> > > > >>>>>
> > > > >>>>>       *De :*Andrew G. Malis [mailto:agmalis@gmail.com
> > > > >>>>>       <mailto:agmalis@gmail.com>]
> > > > >>>>>       *Envoyé :* jeudi 17 janvier 2019 15:50
> > > > >>>>>       *À :* BOUCADAIR Mohamed TGI/OLN
> > > > >>>>>       *Cc :* IETF Secretariat; sfc-chairs@ietf.org
> > > > >>>>>       <mailto:sfc-chairs@ietf.org>;
> > > > >>>>>       draft-eastlake-sfc-nsh-ecn-support@ietf.org
> > > > >>>>>       <mailto:draft-eastlake-sfc-nsh-ecn-support@ietf.org>;
> > > > sfc@ietf.org
> > > > >>>>>       <mailto: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
> > > > >>>>>       <mailto: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
> > > > >>>>>           <mailto:sfc-bounces@ietf.org>] De la part de IETF
> > Secretariat
> > > > >>>>>            > Envoyé : jeudi 3 janvier 2019 06:11
> > > > >>>>>            > À : sfc-chairs@ietf.org <mailto:sfc-chairs@ietf.org>;
> > > > >>>>>           draft-eastlake-sfc-nsh-ecn-support@ietf.org
> > > > >>>>>           <mailto:draft-eastlake-sfc-nsh-ecn-support@ietf.org>;
> > > > >>>>>            > sfc@ietf.org <mailto: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 <mailto:sfc@ietf.org>
> > > > >>>>>            > https://www.ietf.org/mailman/listinfo/sfc
> > > > >>>>>