Re: [Detnet] draft-ietf-detnet-ip-02.txt - ECN changes
Lou Berger <lberger@labn.net> Wed, 23 October 2019 16:27 UTC
Return-Path: <lberger@labn.net>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F88120C67 for <detnet@ietfa.amsl.com>; Wed, 23 Oct 2019 09:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 RByzMECcV6x4 for <detnet@ietfa.amsl.com>; Wed, 23 Oct 2019 09:27:28 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 03C68120C2A for <detnet@ietf.org>; Wed, 23 Oct 2019 09:27:11 -0700 (PDT)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id F1C35176181 for <detnet@ietf.org>; Wed, 23 Oct 2019 10:27:08 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id NJTYiHOre94wVNJTYiZMua; Wed, 23 Oct 2019 10:27:08 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=eNA9ckh1 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=XobE76Q3jBoA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=iLNU1ar6AAAA:8 a=174xjjHKAAAA:20 a=VB46miiLAAAA:20 a=pGLkceISAAAA:8 a=G0_B3m8xAAAA:8 a=RpNjiQI2AAAA:8 a=n5vaJEIb7bv80mSXwIQA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=jpIH26JlB8aEU1M81S3jpgcb7nU=:19 a=J6XGpPsWV8Aqn0zP:21 a=Rha-q17Wnem4Sm3y:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=jM_x9b4JT8QA:10:demote_hacked_domain_1 a=TITxPsBxUocIRcqtJDQA:9 a=sku-By7NtNnoi0BI:21 a=qt-yuOwKI8MavIaO:21 a=tFfcCdPWGeg_C7iY:21 a=UiCQ7L4-1S4A:10:nop_mshtml_css_classes a=hTZeC7Yk6K0A:10:nop_msword_html a=_W_S_7VecoQA:10:nop_html a=frz4AuCg-hUA:10:nop_css_in_html a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=gBgTPrObzSPeouD7eQ2s:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=+fIY1QWWZFNdnDi9nKuFjWSYTBSDQVekGMGvDPhCIhg=; b=Ai5RiirCK3hhtxd88hIVK71fco sZCOcnoOesqs8gaeWVx9Iw7rc0r6yHnk9xP8Ts4fkB72qgcOoZNWobvAM9nCkZFS4S0D6zNMPb5Zn T9oxmZjlAvM8D30GAv982HHv0;
Received: from [127.0.0.1] (port=56435 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <lberger@labn.net>) id 1iNJTY-001b28-8L; Wed, 23 Oct 2019 10:27:08 -0600
To: "Black, David" <David.Black@dell.com>, "DetNet@ietf.org" <detnet@ietf.org>
Cc: "draft-ietf-detnet-ip@ietf.org" <draft-ietf-detnet-ip@ietf.org>
References: <CE03DB3D7B45C245BCA0D243277949363078BCE6@MX307CL04.corp.emc.com> <16df861f7a8.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <CE03DB3D7B45C245BCA0D243277949363078E2BC@MX307CL04.corp.emc.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <02b738e2-d2f7-fa39-4e03-83cbe3c5a0b7@labn.net>
Date: Wed, 23 Oct 2019 12:27:03 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949363078E2BC@MX307CL04.corp.emc.com>
Content-Type: multipart/alternative; boundary="------------9308C09FA555B59684B95BFD"
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 127.0.0.1
X-Source-L: Yes
X-Exim-ID: 1iNJTY-001b28-8L
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:56435
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/7KNJxPEETu159ytsxD8EvTukih8>
Subject: Re: [Detnet] draft-ietf-detnet-ip-02.txt - ECN changes
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2019 16:27:37 -0000
David, On 10/23/2019 11:38 AM, Black, David wrote: > > This seems to be mostly about which field appears in the 5.1.1.4 > section title and hence the table of contents. To retain that > section title, the following change would make it clear that only the > DSCP field is involved: > > OLD > > 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields > > These fields are used to support Differentiated Services [RFC2474]. > > Implementations of this document MUST support DetNet flow > > identification based on the IPv4 Type of Service field when > > processing IPv4 packets, and the IPv6 Traffic Class Field when > > processing IPv6 packets. Implementations MUST support list based > > matching of DSCP values, where the list is composed of possible field > > values that are to be considered when identifying a specific DetNet > > flow. Implementations SHOULD allow for this field to be ignored for > > a specific DetNet flow. > > NEW > > 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields > > The DSCP field in these fields is used to support Differentiated > Services [RFC2474][RFC2475]. > > Implementations of this document MUST support DetNet flow > > identification based on the DSCP field in the IPv4 Type of Service > field when > > processing IPv4 packets, and the DSCP field in the IPv6 Traffic Class > Field when > > processing IPv6 packets. Implementations MUST support list based > > matching of DSCP values, where the list is composed of possible field > > values that are to be considered when identifying a specific DetNet > > flow. Implementations SHOULD allow for this field to be ignored for > > a specific DetNet flow. > I pushed a version with the change, although I didn't include "The DSCP field in.." as it seemed quite redundant. Thanks! Lou > I also added a citation of RFC 2475 (DiffServ Architecture) in the new > text above, as that RFC is more useful than RFC 2474 for understanding > Diffserv in general. RFC 2475 would also need to be added to the list > of Informative References. > > Thanks, --David > > *From:*Lou Berger <lberger@labn.net> > *Sent:* Wednesday, October 23, 2019 7:31 AM > *To:* Black, David; DetNet@ietf.org > *Cc:* draft-ietf-detnet-ip@ietf.org > *Subject:* Re: [Detnet] draft-ietf-detnet-ip-02.txt - ECN changes > > [EXTERNAL EMAIL] > > Hi David, > > I agree that the changes you mentioned are really editorial and it > don't change anything from the implementation standpoint. But given > that rfc791 is still in force, albeit updated by rfc2474, and it > mentions the type of service field and we are saying that detnet > operates on the IP header - I personally think it appropriate to > continue to mentioned the field name defined in rfc 791. I think this > will be particularly helpful for those who learn about IP through DetNet. > > Lou > > ------------------------------------------------------------------------ > > On October 22, 2019 1:43:51 PM "Black, David" <David.Black@dell.com > <mailto:David.Black@dell.com>> wrote: > > Two more suggested edits to clean up the IPv4 and IPv6 header > field text to focus on the DSCP field: > > --- [1] Section 5.1.1.4 > > OLD > > 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields > > These fields are used to support Differentiated Services [RFC2474]. > > Implementations of this document MUST support DetNet flow > > identification based on the IPv4 Type of Service field when > > processing IPv4 packets, and the IPv6 Traffic Class Field when > > processing IPv6 packets. Implementations MUST support list based > > matching of DSCP values, where the list is composed of possible > field > > values that are to be considered when identifying a specific DetNet > > flow. Implementations SHOULD allow for this field to be > ignored for > > a specific DetNet flow. > > NEW > > 5.1.1.4. Differentiated Services Codepoint (DSCP) Field > > This field in the IPv4 Type of Service Field and the IPv6 Traffic > > Class Field is used to support Differentiated Services [RFC2474]. > > Implementations of this document MUST support DetNet flow > > identification based on the DSCP field of an IP packet. > > Implementations MUST support list based > > matching of DSCP values, where the list is composed of possible > field > > values that are to be considered when identifying a specific DetNet > > flow. Implementations SHOULD allow for this field to be > ignored for > > a specific DetNet flow. > > --- [2] Section 6 > > OLD > > o For the IPv4 Type of Service and IPv6 Traffic Class Fields: > > * If the DSCP field is to be used in flow identification. > > Ignoring the DSCP filed is optional. > > * When the DSCP field is used in flow identification, a list of > > field values that may be used by a specific flow. > > NEW > > o For the IPv4 and IPv6 DSCP field: > > * If the DSCP field is to be used in flow identification, > > ignoring the DSCP field is optional. > > * When the DSCP field is used in flow identification, a list of > > field values that may be used by a specific flow. > > Thanks, --David > > *From:*Lou Berger <lberger@labn.net <mailto:lberger@labn.net>> > *Sent:* Tuesday, October 22, 2019 9:00 AM > *To:* DetNet@ietf.org <mailto:DetNet@ietf.org> > *Cc:* Black, David; draft-ietf-detnet-ip@ietf.org > <mailto:draft-ietf-detnet-ip@ietf.org> > *Subject:* Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN > > [EXTERNAL EMAIL] > > Hi, > > Here are the proposed changes to support dropping references to ECN: > > Any objections? > > 1) deltas > > https://github.com/detnet-wg/data-plane-drafts/compare/working/lb/drop-ecn > > 2) formatted draft > > https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/detnet-wg/data-plane-drafts/working/lb/drop-ecn/ip/draft-ietf-detnet-ip.xml > > > 3) git diff format: > > diff --git a/ip/draft-ietf-detnet-ip.xml b/ip/draft-ietf-detnet-ip.xml > index 086fe6f..dcb022b 100644 > --- a/ip/draft-ietf-detnet-ip.xml > +++ b/ip/draft-ietf-detnet-ip.xml > @@ -163,7 +163,6 @@ > <t hangText="DN">DetNet.</t> > <t hangText="DiffServ">Differentiated Services</t> > <t hangText="DSCP">Differentiated Services Code Point</t> > - <t hangText="ECN">Explicit Congestion Notification.</t> > <t hangText="L2">Layer-2.</t> > <t hangText="L3">Layer-3.</t> > <t hangText="LSP">Label-switched path.</t> > @@ -237,9 +236,8 @@ > identification. > </t> > <t> > - The DetNet IP data plane also allows for optional > matching on two > - additional data fields. The optional fields are the ECN > Field, > - as in <xref target="RFC3168"/>, and the IPv6 flow label > field, > + The DetNet IP data plane also allows for optional matching on > + the IPv6 flow label field, > as defined in <xref target="RFC8200"/>. > </t> > <t> > @@ -542,9 +540,7 @@ DetNet |L2/SbN| |L2/SbN| > <t> > Class of Service (CoS) for DetNet flows carried in IPv6 > is provided using the standard > differentiated services code point (DSCP) field <xref > - target="RFC2474"/> and related mechanisms. The 2-bit > explicit > - congestion notification (ECN) <xref target="RFC3168"/> > field MAY > - also be used. > + target="RFC2474"/> and related mechanisms. > </t> > <t> > One additional consideration for DetNet nodes which > support CoS > @@ -565,7 +561,7 @@ DetNet |L2/SbN| |L2/SbN| > IP encapsulated DetNet flows are expected to be defined > in a future > document. From an encapsulation perspective, the > combination of the 6-tuple i.e., > the typical 5-tuple enhanced with the DSCP and previously > - mentioned two optional fields, uniquely identifies a DetNet > + mentioned optional field, uniquely identifies a DetNet > service flow. > </t> > <t> > @@ -594,8 +590,8 @@ DetNet |L2/SbN| |L2/SbN| > highlight the implications of DetNet IP flow > identification on > path selection and next hops. As mentioned above, the > DetNet > IP data plane identifies flows using "6-tuple" header > - information as well as two additional optional header > - fields. DetNet generally allows for both flow-specific > traffic > + information as well as the additional optional header > + field. DetNet generally allows for both flow-specific > traffic > treatment and flow-specific next-hops. > </t> > <t> > @@ -643,7 +639,7 @@ DetNet |L2/SbN| |L2/SbN| > impacts DetNet IP data plane flow identification and > resource > allocation. As discussed above, IP flow identification > uses > the IP "6-tuple" for flow identification. DetNet IP > flows can > - be aggregated using any of the 6-tuple, or two > additional optional fields defined in <xref > + be aggregated using any of the 6-tuple, and an > additional optional field defined in <xref > target="ip-flow-id"/>. The use of prefixes, wildcards, > lists, and value ranges allows a DetNet node to identify > aggregate DetNet flows. From a resource allocation > @@ -786,8 +782,7 @@ DetNet |L2/SbN| |L2/SbN| > <section title="IPv4 Type of Service and IPv6 Traffic > Class Fields"> > <t> > These fields are used to support Differentiated > Services > - <xref target="RFC2474"/> and Explicit Congestion > - Notification <xref target="RFC3168"/>. > Implementations of > + <xref target="RFC2474"/>. Implementations of > this document MUST support DetNet flow identification > based on the IPv4 Type of Service field when processing > IPv4 packets, and the IPv6 Traffic Class Field when > @@ -798,15 +793,6 @@ DetNet |L2/SbN| |L2/SbN| > SHOULD allow for this field to be ignored for a > specific > DetNet flow. > </t> > - <t> > - Implementations of this document MUST allow the ECN > field > - to be ignored as part of DetNet flow identification. > - Additionally, implementations SHOULD support > - identification of DetNet flows based on the value > carried > - in the ECN field. When this field is used to > identify a > - specific DetNet flow, implementations MUST support > a list > - of ECN values that match a specific slow. > - </t> > </section> > <section title="IPv6 Flow Label Field"> > <t> > @@ -945,10 +931,6 @@ DetNet |L2/SbN| |L2/SbN| > identification. Ignoring the DSCP filed is > optional.</t> > <t>When the DSCP field is used in flow > identification, a > list of field values that may be used by a > specific flow.</t> > - <t>If the ECN field is to be used in flow > - identification. Matching based on ECN filed > values is optional.</t> > - <t>When ECN field is used in flow identification, a > - list of field values that may be used by a > specific flow.</t> > </list></t> > <t>IPv6 flow label field. This field can be > optionally used > for matching. When used, can be exclusive of matching > @@ -957,7 +939,7 @@ DetNet |L2/SbN| |L2/SbN| > required. Port ranges can optionally be used.</t> > <t>TCP and UDP Destination Port. Exact and wildcard > matching is > required. Port ranges can optionally be used.</t> > - <t>IPsec Header SPI field. Exact > matching is > + <t>IPsec Header SPI field. Exact matching is > required. </t> > </list> > This information MUST be provisioned per DetNet flow via > @@ -1058,7 +1040,6 @@ DetNet |L2/SbN| |L2/SbN| > <?rfc include="reference.RFC.1812"?> > <?rfc include="reference.RFC.2119"?> > <?rfc include="reference.RFC.2474"?> > - <?rfc include="reference.RFC.3168"?> > <?rfc include="reference.RFC.3473"?> > <?rfc include="reference.RFC.4301"?> > <?rfc include="reference.RFC.4302"?> > > Lou > > On 10/22/2019 8:19 AM, Stewart Bryant wrote: > > > The main flow identifiers will be SA+DA+SP+DP (sure there is > type but there are only a couple of values used in practice) > > You would only really use the DSCP bits to select a subgroup > of the packets within a flow for special treatment. > > It seems unlikely that you would select more than a tiny > number of elements within the flow for special treatment on > the basis for the DSCP bits, where tiny is likely to be one. > > So it seems unlikely that there is any scaling impact. > > - Stewart > > On 22/10/2019 01:53, Grossman, Ethan A. wrote: > > Does losing control over those two bits (ECN) adversely > affect the upward scalability of the system in any > meaningful way? I mean, can one think of it like “this > reduces the number of flows that can be identified by a > factor of 4”? Does anyone working on “Large Scale DetNet” > have any thoughts on this? > > Thanks, > > Ethan. > > *From:* detnet <detnet-bounces@ietf.org> > <mailto:detnet-bounces@ietf.org> *On Behalf Of *Andrew G. > Malis > *Sent:* Monday, October 21, 2019 6:29 AM > *To:* Stewart Bryant <stewart.bryant@gmail.com> > <mailto:stewart.bryant@gmail.com> > *Cc:* DetNet@ietf.org <mailto:DetNet@ietf.org>; Lou Berger > <lberger@labn.net> <mailto:lberger@labn.net>; Black, David > <David.Black@dell.com> <mailto:David.Black@dell.com> > *Subject:* Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN > > I also don't have any objection to removing the ECN text. > > Cheers, > > Andy > > On Mon, Oct 21, 2019 at 8:59 AM Stewart Bryant > <stewart.bryant@gmail.com > <mailto:stewart.bryant@gmail.com>> wrote: > > > Yes, let's delete the references to ECN from the text. > > - Stewart > > On 18/10/2019 22:57, Lou Berger wrote: > > David, > > I'm personally okay with dropping all > references to the ECN field. But doing so is a > change from previous discussions so is a WG call. > > WG, > > Are there any objections to removing the language > related to the ECN field? > > The implication is that the detnet IP standard > will only cover the 6-bit DSCP field carried in > what was once referred to as the 8-bit IP TOS Field. > > Thanks, > > Lou > > (No hats) > > On 10/16/2019 11:08 PM, Black, David wrote: > > > While I understand you have concerns about a > node providing different traffic treatment > based on ECN markings on a local node, I > believe this happens today – > > just look at the related config options for > your favorite router vendor. Can you live > with SHOULD NOT vs MUST NOT? > > I can live with removal of all mention of ECN > from this draft. I would suggest this course > of action if the goal is to avoid “MUST NOT” > wording. > > Otherwise, I would need to be convinced that > what the draft proposes to do/allow wrt ECN is > consistent with RFC 3168. The current text is > not consistent with RFC 3168.. > > Thanks, --David > > *From:* Lou Berger <lberger@labn.net> > <mailto:lberger@labn.net> > *Sent:* Wednesday, October 16, 2019 10:02 PM > *To:* Black, David; DetNet@ietf.org > <mailto:DetNet@ietf.org> > *Subject:* Re: [Detnet] Fwd: > draft-ietf-detnet-ip-02.txt - ECN > > [EXTERNAL EMAIL] > > sigh -I thought we went over all language in > e-mail and over the phone. > > On 10/16/2019 4:43 PM, Black, David wrote: > > Forwarding to remove > internet-drafts@ietf.org > <mailto:internet-drafts@ietf.org> as a > recipient. Please respond to this email. > > Thanks, --David ... Sent from my Android > not-so-smartphone. > > -------- Original message -------- > > From: "Black, David" <david.black@emc.com> > <mailto:david.black@emc.com> > > Date: 10/16/19 3:13 PM (GMT-06:00) > > To: internet-drafts@ietf.org > <mailto:internet-drafts@ietf.org>, > detnet@ietf.org <mailto:detnet@ietf.org> > > Subject: draft-ietf-detnet-ip-02.txt - ECN > > The ECN material in this draft conflicts > with RFC 3168 (a long-standing Proposed > Standard). I apologize to anyone who may > have been under the impression that all > ECN-related concerns were resolved in that > call, as the text in this note did not > come up during that call. > > The TL;DR summary of my concerns is the > rationale for change [3] below: > > Rationale: Use of ECN field for > flow identification is not compatible with > RFC 3168. > > It was my understanding that your primary > concern was split paths and this is what we > covered in the language distributed on Monday. > > While I understand you have concerns about a > node providing different traffic treatment > based on ECN markings on a local node, I > believe this happens today -- just look at the > related config options for your favorite > router vendor. Can you live with SHOULD NOT > vs MUST NOT? > > Thanks, > > Lou > > > ------------------------------------------------- > > The following four changes will correct > this problem: > > [1] In Section 3. DetNet IP Data Plane > Overview > > OLD > The DetNet IP data plane also allows > for optional matching on two > additional data fields. The optional > fields are the ECN Field, as in > [RFC3168], and the IPv6 flow label > field, as defined in [RFC8200]. > NEW > The DetNet IP data plane also allows > for optional matching on one > additional data field, the IPv6 flow > label field, as defined in [RFC8200]. > > Rationale: ECN field MUST NOT be used to > subdivide a flow into sub-flows. See RFC > 3168. > > [2] In Section 4.3.1. Class of Service > > Remove this sentence: > > The 2-bit explicit congestion > notification (ECN) [RFC3168] field MAY > also be used. > > Rationale: The ECN mechanism is not a > Class of service mechanism. See RFC 3168. > > [3] In Section 5.1.1.4. IPv4 Type of > Service and IPv6 Traffic Class Fields > > Remove this text: > > Implementations of this document MUST > allow the ECN field to be > ignored as part of DetNet flow > identification. Additionally, > implementations SHOULD support > identification of DetNet flows based > on the value carried in the ECN field. > When this field is used to > identify a specific DetNet flow, > implementations MUST support a list > of ECN values that match a specific slow. > > If desired, replace it with: > > The ECN field MUST NOT be used as part > of DetNet flow identification. > > Rationale: Use of ECN field for flow > identification is not compatible with RFC > 3168. > > [4] In Section 6. Management and Control > Information Summary > > Remove these two bullets: > > * If the ECN field is to be used in > flow identification. > Matching based on ECN filed > values is optional. > > * When ECN field is used in flow > identification, a list of field > values that may be used by a > specific flow. > > Rationale: Same as [3]. > > Thanks, --David > > > -----Original Message----- > > From: I-D-Announce > <i-d-announce-bounces@ietf.org> > <mailto:i-d-announce-bounces@ietf.org> On > Behalf Of internet- > > drafts@ietf.org <mailto:drafts@ietf.org> > > Sent: Wednesday, October 16, 2019 3:49 PM > > To: i-d-announce@ietf.org > <mailto:i-d-announce@ietf.org> > > Cc: detnet@ietf.org <mailto:detnet@ietf.org> > > Subject: I-D Action: > draft-ietf-detnet-ip-02.txt > > > > > > [EXTERNAL EMAIL] > > > > > > A New Internet-Draft is available from > the on-line Internet-Drafts directories. > > This draft is a work item of the > Deterministic Networking WG of the IETF. > > > > Title : DetNet Data Plane: IP > > Authors : Balázs Varga > > János Farkas > > Lou Berger > > Don Fedyk > > Andrew G. Malis > > Stewart Bryant > > Jouni Korhonen > > Filename : > draft-ietf-detnet-ip-02.txt > > Pages : 23 > > Date : 2019-10-16 > > > > Abstract: > > This document specifies the > Deterministic Networking data plane when > > operating in an IP packet switched > network. > > > > > > The IETF datatracker status page for > this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddetnet-2Dip_&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=mzbAKXUleGS8Bz7ajbUbKTPPDXTF0sMHaR30Jz1vx3I&e=> > > > > There are also htmlized versions > available at: > > > https://tools.ietf.org/html/draft-ietf-detnet-ip-02 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddetnet-2Dip-2D02&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=U2KdtDL3CUVCsekPojtQVKIvgeP45L36pWIa_NTIOsA&e=> > > > https://datatracker.ietf.org/doc/html/draft-ietf-detnet-ip-02 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Ddetnet-2Dip-2D02&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=v_m7-Vya44Tpf38IPNTfLFKd9vOPrwEKJ1koUg0xB-s&e=> > > > > A diff from the previous version is > available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-ip-02 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Ddetnet-2Dip-2D02&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=9FVm_p_MTKAngR5wvgnJsDRVpBhRs1VBb-HiEc9AuFw&e=> > > > > > > Please note that it may take a couple of > minutes from the time of submission > > until the htmlized version and diff are > available at tools.ietf.org > <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=iQJB8fuxh1qkUEUNRcxmOvQFjWSriYN94CSHktRBwSw&e=>. > > > > Internet-Drafts are also available by > anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=4kQjX_H4U0HBUhyMvMm8v_ub2smEgNFOgcbS-JFjmCg&e=> > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > <mailto:I-D-Announce@ietf.org> > > > https://www.ietf.org/mailman/listinfo/i-d-announce > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=iESW3uqZs6fiih_VYgFB-F-rtwNyaGqHl757qWRjZ94&e=> > > Internet-Draft directories: > http://www.ietf.org/shadow.html > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=Gi367w04OysBMQsqQk4D_FlH9mrlETnu55sSZQwWo8M&e=> > > or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=YLkOGoZpigvSV1ZLn9IoiKXWyv2VoCYgoobywa8r3NE&e=> > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org <mailto:detnet@ietf.org> > > https://www.ietf.org/mailman/listinfo/detnet <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=ZKMFjjpaWmbkFYiW3V6Z8NzpzleGBZFDJT0yhKFMOyU&e=> > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org <mailto:detnet@ietf.org> > > https://www.ietf.org/mailman/listinfo/detnet <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=ZKMFjjpaWmbkFYiW3V6Z8NzpzleGBZFDJT0yhKFMOyU&e=> > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org <mailto:detnet@ietf.org> > > https://www.ietf.org/mailman/listinfo/detnet <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=ZKMFjjpaWmbkFYiW3V6Z8NzpzleGBZFDJT0yhKFMOyU&e=> > > _______________________________________________ > detnet mailing list > detnet@ietf.org <mailto:detnet@ietf.org> > https://www.ietf.org/mailman/listinfo/detnet > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=ZKMFjjpaWmbkFYiW3V6Z8NzpzleGBZFDJT0yhKFMOyU&e=> > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org <mailto:detnet%40ietf.org> > > https://www.ietf.org/mailman/listinfo/detnet >
- [Detnet] draft-ietf-detnet-ip-02.txt - ECN changes Black, David
- Re: [Detnet] draft-ietf-detnet-ip-02.txt - ECN ch… Lou Berger
- Re: [Detnet] draft-ietf-detnet-ip-02.txt - ECN ch… Black, David
- Re: [Detnet] draft-ietf-detnet-ip-02.txt - ECN ch… Lou Berger