Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption"
"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 24 January 2019 13:39 UTC
Return-Path: <jmh@joelhalpern.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 D4E0E130E9D; Thu, 24 Jan 2019 05:39:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 O1Eyqr0pZVNh; Thu, 24 Jan 2019 05:39:54 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8041F130E99; Thu, 24 Jan 2019 05:39:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43ljvG2MJkzkZrQ; Thu, 24 Jan 2019 05:39:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1548337194; bh=npijM/MGmkqpiyur9k8Iy2bmV6doBU3k8xmL9M9aJ5A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eROUfJVMZjYbslIdOTBmPVi49qGkSBHTcqWehtLvJk2cL65uAPOZ2sXs7zH+weAwV 8boizcgaq6abw0AoeyxkwP7AQBU+PqS/8q5jonsbxiv8+swN+WLMmcIPMs3TrSiehv 9IaLU+/KxUybc5MFlAobOXgDScVoPFvK3+W6XToI=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43ljvF1CxpzkZrN; Thu, 24 Jan 2019 05:39:52 -0800 (PST)
To: mohamed.boucadair@orange.com
Cc: "draft-eastlake-sfc-nsh-ecn-support@ietf.org" <draft-eastlake-sfc-nsh-ecn-support@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <bc5f3798-ecf5-6b15-f3d9-d31b44f76f3e@joelhalpern.com>
Date: Thu, 24 Jan 2019 08:39:51 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/PEEDRJDHPsQjuG9akBl3Fnq_UTs>
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, 24 Jan 2019 13:39:57 -0000
<chair hat on> Thank you for the citation Med. I would like to hear from others in the working group as to whether they it. Yours, Joel On 1/24/19 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. > > 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. > > 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 >>>>>>>
- [sfc] The SFC WG has placed draft-eastlake-sfc-ns… IETF Secretariat
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Andrew G. Malis
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Tal Mizrahi
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Diego R. Lopez
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Donald Eastlake
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Mach Chen
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Bob Briscoe
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… mohamed.boucadair
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Andrew G. Malis
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… mohamed.boucadair
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Andrew G. Malis
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… mohamed.boucadair
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Joel M. Halpern
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Donald Eastlake
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Bob Briscoe
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… mohamed.boucadair
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Joel M. Halpern
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Tal Mizrahi
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… mohamed.boucadair
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Joel M. Halpern
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… mohamed.boucadair
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Joel M. Halpern
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Joel M. Halpern
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Donald Eastlake
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Loa Andersson
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… mohamed.boucadair
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Donald Eastlake
- Re: [sfc] The SFC WG has placed draft-eastlake-sf… Donald Eastlake