Subject: [Detnet] draft-ietf-detnet-ip-02.txt - ECN

From: "Black, David" <[email-masked]>
Date: Wed, 16 Oct 2019 20:13:06 +0000

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.

-------------------------------------------------

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 <[email-masked]> On Behalf Of internet-
> [email-masked]
> Sent: Wednesday, October 16, 2019 3:49 PM
> To: [email-masked]
> Cc: [email-masked]
> 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/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-detnet-ip-02
> https://datatracker.ietf.org/doc/html/draft-ietf-detnet-ip-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-ip-02
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Black, David" <[email-masked]>
Date: Wed, 16 Oct 2019 20:43:27 +0000

Forwarding to remove [email-masked] as a recipient.  Please respond to this email.

Thanks, --David ... Sent from my Android not-so-smartphone.

-------- Original message --------
From: "Black, David" <[email-masked]>
Date: 10/16/19 3:13 PM (GMT-06:00)
To: [email-masked], [email-masked]
Subject: draft-ietf-detnet-ip-02.txt - ECN

OLD

Remove this sentence:

Remove this text:

Rationale: Same as [3].

Thanks, --David

---

From: Lou Berger <[email-masked]>
Date: Wed, 16 Oct 2019 22:01:53 -0400

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:
> 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.
>

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

> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: "Black, David" <[email-masked]>
Date: Thu, 17 Oct 2019 03:08:53 +0000

> 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 <[email-masked]>
Sent: Wednesday, October 16, 2019 10:02 PM
To: Black, David; [email-masked]
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 [email-masked]<mailto:[email-masked]> as a recipient.  Please respond to this email.

-------- Original message --------
From: "Black, David" <[email-masked]><mailto:[email-masked]>
Date: 10/16/19 3:13 PM (GMT-06:00)
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-detnet-ip-02.txt - ECN

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

OLD

Remove this sentence:

Remove this text:

Rationale: Same as [3].

Thanks, --David

> From: I-D-Announce <[email-masked]><mailto:[email-masked]> On Behalf Of internet-
> [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

detnet mailing list

[email-masked]<mailto:[email-masked]>

---

From: Lou Berger <[email-masked]>
Date: Fri, 18 Oct 2019 16:57:16 -0400

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 <[email-masked]>
> *Sent:* Wednesday, October 16, 2019 10:02 PM
> *To:* Black, David; [email-masked]
> *Subject:* Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN
>
> [EXTERNAL EMAIL]
>
>     Forwarding to remove [email-masked]
>     <mailto:[email-masked]> as a recipient.  Please respond
>     to this email.
>
>     <mailto:[email-masked]>
>
>     To: [email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>
>
>     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.
>
> traffic treatment based on ECN markings on a local node, I believe 
> this happens today -- just look at the related config options for your 
>     > From: I-D-Announce <[email-masked]>
>     <mailto:[email-masked]> On Behalf Of internet-
>     > [email-masked] <mailto:[email-masked]>
>     > To: [email-masked] <mailto:[email-masked]>
>     > Cc: [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 21 Oct 2019 13:59:07 +0100

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,
>
> 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)
>
>> would suggest this course of action if the goal is to avoid “MUST 
>> NOT” wording.
>>
>> 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
>>
>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 21 Oct 2019 09:28:32 -0400

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 <[email-masked]>
wrote:

> happens today –
> 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 <[email-masked]> <[email-masked]>
> From: "Black, David" <[email-masked]> <[email-masked]>
>
> 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.
>
> It was my understanding that your primary concern was split paths and this
> is what we covered in the language distributed on Monday.
>
> 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
>
>
>
>
> <[email-masked]> On Behalf Of internet-
> > [email-masked]
> detnet mailing [email-masked]://www.ietf.org/mailman/listinfo/detnet
>
>
> detnet mailing [email-masked]://www.ietf.org/mailman/listinfo/detnet
>
>

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 22 Oct 2019 00:53:16 +0000

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 <[email-masked]> On Behalf Of Andrew G. Malis
Sent: Monday, October 21, 2019 6:29 AM
To: Stewart Bryant <[email-masked]>
Cc: [email-masked]; Lou Berger <[email-masked]>; Black, David <[email-masked]>
Subject: Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN

Cheers,
Andy

On Mon, Oct 21, 2019 at 8:59 AM Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

- Stewart

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,

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 –
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 <[email-masked]><mailto:[email-masked]>
Sent: Wednesday, October 16, 2019 10:02 PM
To: Black, David; [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN

[EXTERNAL EMAIL]

-------- Original message --------
From: "Black, David" <[email-masked]><mailto:[email-masked]>
Date: 10/16/19 3:13 PM (GMT-06:00)
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-detnet-ip-02.txt - ECN

Thanks,

Lou

OLD

Remove this sentence:

Remove this text:

Rationale: Same as [3].

Thanks, --David

> 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=>
>
> 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=>
>
> 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=>
>
>
> 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=>.
>
> 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=>
>
> 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

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

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

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
[email-masked]<mailto:[email-masked]>
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=>

---

From: Lou Berger <[email-masked]>
Date: Mon, 21 Oct 2019 21:25:05 -0400

Ethan,

Yes, but I think it's a tolerable compromise to move the work forward - and 
there are other bits available in the header...

Lou

----------
On October 21, 2019 8:54:00 PM "Grossman, Ethan A." <[email-masked]> 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.
>
> On Mon, Oct 21, 2019 at 8:59 AM Stewart Bryant 
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>     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,
>
>> just look at the related config options for your favorite router vendor.  
>> Can you live with SHOULD NOT vs MUST NOT?
> Forwarding to remove 
> [email-masked]<mailto:[email-masked]> as a recipient.  
> Please respond to this email.
>
>> From: I-D-Announce 
>> <[email-masked]><mailto:[email-masked]> On 
>> Behalf Of internet-
>> 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-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=>
>
>
> ----------

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 22 Oct 2019 03:50:09 +0000

Just so I understand, by "other bits in the header" do you mean the 6-tuple bits, or are there others that can also be used for flow ID?

________________________________
From: Lou Berger <[email-masked]>
Sent: Monday, October 21, 2019 6:25:05 PM
To: Grossman, Ethan A. <[email-masked]>; [email-masked] <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Andrew G. Malis <[email-masked]>; Black, David <[email-masked]>
Subject: Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN

Ethan,

Yes, but I think it's a tolerable compromise to move the work forward - and there are other bits available in the header...

Lou

________________________________

Cheers,
Andy

- Stewart

David,

WG,

Thanks,

Lou

(No hats)

Thanks, --David

[EXTERNAL EMAIL]

-------- Original message --------
From: "Black, David" <[email-masked]><mailto:[email-masked]>
Date: 10/16/19 3:13 PM (GMT-06:00)
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-detnet-ip-02.txt - ECN

Thanks,

Lou

OLD

Remove this sentence:

Remove this text:

Rationale: Same as [3].

Thanks, --David

detnet mailing list

detnet mailing list

detnet mailing list

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:detnet%40ietf.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=GKNVqAPtpa8uZ40gFa5S2b4cmkGUlcUqPaMIYaykBg0&s=NyiNEuJHbNv1U35XZu0V43ZJnNGmQDS5-LMVkQosZZM&e=>

---

From: Janos Farkas <[email-masked]>
Date: Tue, 22 Oct 2019 11:24:52 +0000

Hi,

No objections from my side either on deleting the text on the ECN field.

Regards,
Janos

Sent: Monday, October 21, 2019 3:29 PM

Cheers,
Andy

- Stewart

David,

WG,

Thanks,

Lou

(No hats)

Thanks, --David

[EXTERNAL EMAIL]

-------- Original message --------
From: "Black, David" <[email-masked]><mailto:[email-masked]>
Date: 10/16/19 3:13 PM (GMT-06:00)
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-detnet-ip-02.txt - ECN

Thanks,

Lou

OLD

Remove this sentence:

Remove this text:

Rationale: Same as [3].

Thanks, --David

> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>

detnet mailing list

detnet mailing list

detnet mailing list

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 22 Oct 2019 13:19:48 +0100

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 <[email-masked]> *On Behalf Of *Andrew G. Malis
> *Sent:* Monday, October 21, 2019 6:29 AM
> *To:* Stewart Bryant <[email-masked]>
> *Cc:* [email-masked]; Lou Berger <[email-masked]>; Black, David 
> <[email-masked]>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>             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,
>
>         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)
>
>             > 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
>             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 <[email-masked]>
>             <mailto:[email-masked]>
>             *To:* Black, David; [email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked]> as a recipient. 
>                 To: [email-masked]
>                 <mailto:[email-masked]>, [email-masked]
>                 <mailto:[email-masked]>
>
>                 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.
>
>                         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
>                 <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=>
>                 >
>                 <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://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=>
>                 >
>                 <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=>
>                 >
>                 >
>                 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=>.
>                 >
>                 <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=>
>                 >
>                 <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=>
>                 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=>
>                 <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=>
>
>                 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=>
>
>             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=>
>
>         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=>
>
>     <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=>
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Oct 2019 08:59:42 -0400

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:
> elements within the flow for special treatment on the basis for the 
> DSCP bits, where tiny is likely to be one.
>
>>         ECN field.  But doing so is a change from previous
>>         discussions so is a WG call.
>>
>>         WG,
>>
>>         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)
>>
>>                 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.
>>
>>                 <mailto:[email-masked]>
>>                 > until the htmlized version and diff are available
>>                 at tools.ietf.org

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 22 Oct 2019 18:00:05 +0000

Understood, thanks.
Ethan.

From: Stewart Bryant <[email-masked]>
Sent: Tuesday, October 22, 2019 5:20 AM
To: Grossman, Ethan A. <[email-masked]>; [email-masked]
Cc: Lou Berger <[email-masked]>; Andrew G. Malis <[email-masked]>; Black, David <[email-masked]>
Subject: Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN

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.

- Stewart

From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Andrew G. Malis
Sent: Monday, October 21, 2019 6:29 AM
To: Stewart Bryant <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Lou Berger <[email-masked]><mailto:[email-masked]>; Black, David <[email-masked]><mailto:[email-masked]>
Subject: Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN

Cheers,
Andy

- Stewart

David,

WG,

Thanks,

Lou

(No hats)

Thanks, --David

[EXTERNAL EMAIL]

-------- Original message --------
From: "Black, David" <[email-masked]><mailto:[email-masked]>
Date: 10/16/19 3:13 PM (GMT-06:00)
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-detnet-ip-02.txt - ECN

Thanks,

Lou

OLD

Remove this sentence:

Remove this text:

Rationale: Same as [3].

Thanks, --David

detnet mailing list

detnet mailing list

detnet mailing list

---

From: Lou Berger <[email-masked]>
Date: Thu, 24 Oct 2019 07:36:57 -0400

Hi Ethan,

     I was referring to the rest of the 5 tuple.

Lou

On 10/21/2019 11:50 PM, Grossman, Ethan A. wrote:
> Just so I understand, by "other bits in the header" do you mean the 
> 6-tuple bits, or are there others that can also be used for flow ID?
>
> ------------------------------------------------------------------------
> *Sent:* Monday, October 21, 2019 6:25:05 PM
> *To:* Grossman, Ethan A. <[email-masked]>; [email-masked] 
> <[email-masked]>
> *Cc:* Stewart Bryant <[email-masked]>; Andrew G. Malis 
> <[email-masked]>; Black, David <[email-masked]>
> Yes, but I think it's a tolerable compromise to move the work forward 
> - and there are other bits available in the header...
>
> Lou
>
> ------------------------------------------------------------------------
>
>> [email-masked] <mailto:detnet%40ietf.org>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=GKNVqAPtpa8uZ40gFa5S2b4cmkGUlcUqPaMIYaykBg0&s=NyiNEuJHbNv1U35XZu0V43ZJnNGmQDS5-LMVkQosZZM&e=>
>>

---

From: "Black, David" <[email-masked]>
Date: Thu, 24 Oct 2019 13:22:16 +0000

In addition, for IPv6, the 20-bit flow label field in the IPv6 header is available - see RFC 6437 for usage requirements and guidance.

Thanks, --David

From: Lou Berger <[email-masked]>
Sent: Thursday, October 24, 2019 7:37 AM
To: Grossman, Ethan A.; [email-masked]
Cc: Stewart Bryant; Andrew G. Malis; Black, David
Subject: Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN

[EXTERNAL EMAIL]

Hi Ethan,

Lou

________________________________
From: Lou Berger <[email-masked]><mailto:[email-masked]>
Sent: Monday, October 21, 2019 6:25:05 PM
To: Grossman, Ethan A. <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Cc: Stewart Bryant <[email-masked]><mailto:[email-masked]>; Andrew G. Malis <[email-masked]><mailto:[email-masked]>; Black, David <[email-masked]><mailto:[email-masked]>
Subject: Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN

Ethan,

Lou

On October 21, 2019 8:54:00 PM "Grossman, Ethan A." <[email-masked]><mailto:[email-masked]> 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.

Cheers,
Andy

- Stewart

David,

WG,

Thanks,

Lou

(No hats)

Thanks, --David

[EXTERNAL EMAIL]

-------- Original message --------
From: "Black, David" <[email-masked]><mailto:[email-masked]>
Date: 10/16/19 3:13 PM (GMT-06:00)
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: draft-ietf-detnet-ip-02.txt - ECN

Thanks,

Lou

OLD

Remove this sentence:

Remove this text:

Rationale: Same as [3].

Thanks, --David

detnet mailing list

detnet mailing list

detnet mailing list

---

From: Lou Berger <[email-masked]>
Date: Fri, 25 Oct 2019 07:27:33 -0400

excellent point -- and already covered in the doc!

On 10/24/2019 9:22 AM, Black, David wrote:
>
> In addition, for IPv6, the 20-bit flow label field in the IPv6 header 
> is available – see RFC 6437 for usage requirements and guidance.
>
> Thanks, --David
>
> *Sent:* Thursday, October 24, 2019 7:37 AM
> *To:* Grossman, Ethan A.; [email-masked]
> *Cc:* Stewart Bryant; Andrew G. Malis; Black, David
>     Just so I understand, by "other bits in the header" do you mean
>     the 6-tuple bits, or are there others that can also be used for
>     flow ID?
>
>     *From:* Lou Berger <[email-masked]> <mailto:[email-masked]>
>     *To:* Grossman, Ethan A. <[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>     *Cc:* Stewart Bryant <[email-masked]>
>     <mailto:[email-masked]>; Andrew G. Malis
>     <[email-masked]> <mailto:[email-masked]>; Black, David
>     <[email-masked]> <mailto:[email-masked]>
>     Yes, but I think it's a tolerable compromise to move the work
>     forward - and there are other bits available in the header...
>
>     Lou
>
>     On October 21, 2019 8:54:00 PM "Grossman, Ethan A."
>     <[email-masked]> <mailto:[email-masked]> 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 <[email-masked]>
>         <mailto:[email-masked]> *On Behalf Of *Andrew G. Malis
>         <mailto:[email-masked]>
>         *Cc:* [email-masked] <mailto:[email-masked]>; Lou Berger
>         <[email-masked]> <mailto:[email-masked]>; Black, David
>         <[email-masked]> <mailto:[email-masked]>
>                     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,
>
>                 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)
>
>                     > 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 –
>                     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
>                     <mailto:[email-masked]>
>                         <mailto:[email-masked]> as a
>                         recipient.  Please respond to this email.
>
>                         <mailto:[email-masked]>,
>                         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.
>
>                     It was my understanding that your primary concern
>                     was split paths and this is what we covered in the
>                     language distributed on Monday.
>
>                     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
>
>
>                         Rationale: ECN field MUST NOT be used to
>                         subdivide a flow into sub-flows.  See RFC 3168.
>
>                         <[email-masked]>
>                         > until the htmlized version and diff are
>                         available at tools.ietf.org
>                         <mailto:[email-masked]>
>                         >
>                         <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=>
>