Subject: Re: [Detnet] charter update

From: <[email-masked]>
Date: Tue, 22 Mar 2022 17:27:44 +0800 (CST)

Hi  Janos and Lou,

Thanks for your work about the charter!

I agree with that the change from packet forwarding to packet treatment.

But you mentioned that treatment includes forwarding, service protection, and queuing. I suggest that scheduling may be better cause queuing can not cover traffic treatment and non-queuing behavior.

Moreover, I have two questions about the Enhanced DetNet Data Plane solution. 

First, as per RFC8655, the DetNet data plane can be divided into service sub-layer and forwarding sub-layer. If we should add a new sub-layer such as queuing sub-layer to the DetNet Data-Plane Protocol Stack? 

Second,as you listed in new charter, the WG may adopt  first Enhanced DetNet Data Plane solution document in Jul 2022.

I am not sure the Enhanced DetNet Data Plane solution you mentioned is the specific solution for queuing mechanisms or the overall enhancement for DetNet such as https://datatracker.ietf.org/doc/draft-xiong-detnet-large-scale-enhancements/ .

In my opinon, the  Enhanced DetNet Data Plane solution is not just solution for queuing. It may requires enhancement for forwarding and service.

What is your opinons?

Best Regards,

Quan

[Detnet] charter update
Janos Farkas <[email-masked]> Mon, 14 March 2022 11:40 UTCShow header

WG, As mentioned in past meetings, we have been looking into our charter to permit the definition of additional data plane mechanisms, such as new traffic treatment/queuing mechanisms. Based on our discussions with our AD, we propose the changes below. We expect to discuss these changes at IETF113 and the changes to be discussed by the IESG after our meeting. We have also taken this opportunity to revisit our milestones. The current charter can be found at https://datatracker.ietf.org/wg/detnet/about/For the Charter, we propose a fairly small change to the reference to forwarding in the Data Plane section to more generally refer to "treatment (including forwarding, service protection, and queuing)". Note that DetNet already defines mechanisms for forwarding and service protection. The proposed revision is as follows: OLD Data plane: This work will document how to use IP and/or MPLS, and related OAM, to support a data plane method of flow identification and packet forwarding over Layer 3. Other IETF defined data plane technologies may also be used. NEW Data plane: This work will document how to use IP and/or MPLS, and related OAM, to support a data plane method of flow identification and packet treatment (including forwarding, service protection, and queuing) over Layer 3. Other IETF defined data plane technologies may also be used. Again, our plan is to discuss this on the list, at IETF 113, and then submit to the IESG after IETF 113. For Milestones, we are proposing the following: March 2022 Submit DetNet first IP OAM document April 2023 Submit controller plane framework July 2022 Submit OAM framework for publication Apr 2022 Adopt Enhanced DetNet Data Plane Requirements document Jul 2022 Adopt first Enhanced DetNet Data Plane solution document Dec 2022 Submit Enhanced DetNet Data Plane Requirements document for publication June 2023 Submit first Enhanced DetNet Data Plane solution document for publication Here too, we'd like feedback on the list as well as at IETF 113. We will make the changes after our meeting. Thank you, Janos and Lou

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 22 Mar 2022 14:58:43 +0100

From my understanding, "scheduling" is more inclusive and technically better choice of word
for the charter.

But:

More importantly than only the charter text might be an agreement on what/how it is
permissible to write specs related to scheduling:

If i remember correctly, then back in the day when DiffServ was originally done (predating
TSVWG ? not quite sure), it was considered to be a NoNo to talk about queuing, because
that was just an internal implementation option, whereas the RFC should only describe the
externally observable (and hence interoperability impacting) externally visible
scheduling of packet sending time vs. arrival time, policies and competing traffic.

So, avoiding to use the term "queuing" is a nice writing requirement, but i would have we
do not make it mandatory, because i think that if the WG agrees, then its perfectly fine
to describe external behavior to a good reference implementation model, such as one using
queuing. Of course, we always want to make sure that our specs do not unnecessarily
constrain implementation options beyond what we want interoperability upon. That always
has to be kept in mind when writing/reviewing these type of details. 

Cheers
    Toerless

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

-- 
---
[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Mar 2022 10:04:00 -0400

Quan,

Thank you for the comments, please see below.

On 3/22/2022 5:27 AM, [email-masked] wrote:
> But you mentioned that treatment includes forwarding, service 
> protection, and queuing. I suggest that scheduling may be better cause 
> queuing can not cover traffic treatment and non-queuing behavior.
>
We suggest that we add the words "for example" to the list to cover this 
and other similar comment. We can discuss this in oour session that is 
coming up shortly.

> First, as per RFC8655, the DetNet data plane can be divided into 
> service sub-layer and forwarding sub-layer. If we should add a new 
> sub-layer such as queuing sub-layer to the DetNet Data-Plane Protocol 
> Stack?
>
I suggest that this is a fine discussion for today. Personally (as 
contributor) I don't see the need for this architectural level 
addition/change.

> Second,as you listed in new charter, the WG may adopt  first Enhanced 
> DetNet Data Plane solution document in Jul 2022.
>
> I am not sure the Enhanced DetNet Data Plane solution you mentioned is 
> the specific solution for queuing mechanisms or the overall 
> enhancement for DetNet such as 
> https://datatracker.ietf.org/doc/draft-xiong-detnet-large-scale-enhancements/ .
>
> In my opinon, the Enhanced DetNet Data Plane solution is not just 
> solution for queuing. It may requires enhancement for forwarding and 
> service.
>
 From a procedural perspective, this covers any document on the topic 
that the WG identifies and agrees to.  This can be queuing specific or 
something  different.  Of course, we are contribution driven so need 
specific proposals to be discussed and considered.

Thank you for your comments and questions.

See you (virtually) shortly,

Lou

> <https://mailarchive.ietf.org/arch/msg/detnet/FK4f16lwYaJH6z7Swkd6KL82Ves/#>
>
> WG,  As mentioned in past meetings, we have been looking into our charter to permit the definition of additional data plane mechanisms, such as new traffic treatment/queuing mechanisms. Based on our discussions with our AD, we propose the changes below.  We expect to discuss these changes at IETF113 and the changes to be discussed by the IESG after our meeting. We have also taken this opportunity to revisit our milestones.  The current charter can be found athttps://datatracker.ietf.org/wg/detnet/about/For the Charter, we propose a fairly small change to the reference to forwarding in the Data Plane section to more generally refer to "treatment (including forwarding, service protection, and queuing)".  Note that DetNet already defines mechanisms for forwarding and service protection.  The proposed revision is as follows:  OLD  Data plane: This work will document how to use IP and/or MPLS, and related OAM, to support a data plane method of flow identification and packet forwarding over Layer 3. Other IETF defined data plane technologies may also be used.  NEW  Data plane: This work will document how to use IP and/or MPLS, and related OAM, to support a data plane method of flow identification and packet treatment (including forwarding, service protection, and queuing) over Layer 3. Other IETF defined data plane technologies may also be used.  Again, our plan is to discuss this on the list, at IETF 113, and then submit to the IESG after IETF 113.    For Milestones, we are proposing the following:  March 2022    Submit DetNet first IP OAM document April 2023    Submit controller plane framework July 2022    Submit OAM framework  for publication Apr 2022     Adopt Enhanced DetNet Data Plane Requirements  document Jul 2022     Adopt  first Enhanced DetNet Data Plane solution document Dec 2022     Submit Enhanced DetNet Data Plane Requirements document for publication June 2023     Submit first Enhanced DetNet Data Plane solution document for publication  Here too, we'd like feedback on the list as well as at IETF 113.  We will make the changes after our meeting.  Thank you, Janos and Lou
>
>
>