Re: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02

[Lou Berger <[e-mail]>]

Ehsan

Thanks for the quick turnaround!  The document has been submitted to the 
IESG.

Lou

On 5/17/2021 6:38 AM, Mohammadpour Ehsan wrote:
> Hello Lou,
>
> Thanks for the precise review; I updated the draft accordingly. You 
> can find the new version here: 
> https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-06 
> <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-06>.
>
>
> Best,
> Ehsan
>
>
>
> --
> Ehsan Mohammadpour
> PhD Candidate at Swiss Federal Institute of Technology (EPFL)
> EPFL EDIC PhD student representative
> IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
> https://people.epfl.ch/ehsan.mohammadpour 
> <https://people.epfl.ch/ehsan.mohammadpour>
>
>> On 15 May 2021, at 20:01, Lou Berger <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Hi Ehsan,
>>
>> Sorry about the delay.  I still see one problematic line in the new text:
>>
>>    Then,
>>    the input flows are identified using the information in (Section 5.1
>>    of [RFC8939]).  Then they are aggregated into eight macro flows based
>>    on their traffic classes.
>>
>> The term traffic classes still doesn't map well into RFC8939.  I 
>> think you mean
>>
>>    Then they are aggregated into eight macro flows based
>>    on their service requirements.
>>
>> It would be best to have this change made prior to submission for 
>> publication to the IESG. Please let me know what you think.
>>
>> Thanks,
>>
>> Lou
>>
>> On 5/10/2021 8:37 AM, Mohammadpour Ehsan wrote:
>>
>>> Dear WG chairs,
>>>
>>> Since the comments have been addressed, I was wondering if we can 
>>> proceed to the publication request.
>>>
>>>
>>> Best,
>>> Ehsan
>>>
>>>
>>>
>>>> On 19 Apr 2021, at 03:50, Mohammadpour Ehsan 
>>>> <[e-mail] 
>>>> <mailto:[e-mail]><mailto:[e-mail] 
>>>> <mailto:[e-mail]>>> wrote:
>>>>
>>>> Dear WG,
>>>>
>>>> A new version of Bounded Latency draft is uploaded 
>>>> (https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-05 
>>>> <https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-05><https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-05 
>>>> <https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-05>>). 
>>>> This version addresses all the raised comments, including the 
>>>> latest ones by Lou and Toerless.
>>>>
>>>>
>>>> Best,
>>>> Ehsan
>>>>
>>>>
>>>>
>>>> --
>>>> Ehsan Mohammadpour
>>>> PhD Candidate at Swiss Federal Institute of Technology (EPFL)
>>>> EPFL EDIC PhD student representative
>>>> IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
>>>> https://people.epfl.ch/ehsan.mohammadpour 
>>>> <https://people.epfl.ch/ehsan.mohammadpour><https://people.epfl.ch/ehsan.mohammadpour 
>>>> <https://people.epfl.ch/ehsan.mohammadpour>>
>>>>
>>>>> On 9 Apr 2021, at 14:19, Lou Berger <[e-mail] 
>>>>> <mailto:[e-mail]><mailto:[e-mail] 
>>>>> <mailto:[e-mail]>>> wrote:
>>>>>
>>>>> Eshan,
>>>>>
>>>>>     Please let the WG know when you have addressed all previous 
>>>>> raised (and discussed items) and have uploaded the new version. 
>>>>> This will unblock the publication request.
>>>>>
>>>>> Thank you!
>>>>>
>>>>> Lou
>>>>>
>>>>> On 4/7/2021 7:19 PM, Toerless Eckert wrote:
>>>>>> Ehsan, *:
>>>>>>
>>>>>> Thanks a lot for Section 7 in the latest draft version. Helps a 
>>>>>> lot to get
>>>>>> the linkage between this doc and the DetNet architecure an QoS 
>>>>>> options.
>>>>>>
>>>>>> Alas, i do not see the concerns i raised with the authors about 
>>>>>> section 6.5 solved
>>>>>> that i send before IEF 110 in email. If you can't find that 
>>>>>> email, i can post it
>>>>>> again. Its solely about the fact that the document uses "IntServ" 
>>>>>> where it
>>>>>> should say (IntServ) "Guaranteed Service", because the second 
>>>>>> "IntServ" Service,
>>>>>> "Controlled Load" does not provide any determinisic latency 
>>>>>> guarantees (only GS does),
>>>>>> and therefore the unconstrained use of "IntServ" and not 
>>>>>> mentioning of "Guaranteed Services"
>>>>>> will be confusing to anyone who digs deeper into the IETF 
>>>>>> terminology (the refernce to rfc2212 is correct though).
>>>>>>
>>>>>> I think also tha he formulas in rfc2211 are more complex than 
>>>>>> what you write in 6.5,
>>>>>> i do like he simplification of 6.5, but it might be worth noting 
>>>>>> explicitly
>>>>>> hat those are implifications. specifically there are a bunch more 
>>>>>> parameters in
>>>>>> TSPEC/RSPEC than whats written in 6.5, and those parameters have 
>>>>>> impact on the
>>>>>> bounded latency in GS.
>>>>>>
>>>>>> Cheers
>>>>>>     Toerless
>>>>>>
>>>>>> On Thu, Mar 25, 2021 at 07:56:01AM +0000, Mohammadpour Ehsan wrote:
>>>>>>> Hello Lou,
>>>>>>>
>>>>>>> Thanks for the comment, you???re right! I will use the following 
>>>>>>> sentence:
>>>>>>>
>>>>>>> "Then they are aggregated into eight macro flows based on their 
>>>>>>> DetNet flow aggregate."
>>>>>>>
>>>>>>> Best,
>>>>>>> Ehsan
>>>>>>>
>>>>>>>
>>>>>>> P.S. The intention of "Then, the input flows are identified 
>>>>>>> using the information in (Section 5.1 of [RFC8939])???, was to 
>>>>>>> say that we use Section 5.1 of RFC8939 to identify the 
>>>>>>> individual DetNet flows.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ehsan Mohammadpour
>>>>>>> PhD Candidate at Swiss Federal Institute of Technology (EPFL)
>>>>>>> IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
>>>>>>> https://people.epfl.ch/ehsan.mohammadpour<https://people.epfl.ch/ehsan.mohammadpour?lang=en> 
>>>>>>> <https://people.epfl.ch/ehsan.mohammadpour%3Chttps://people.epfl.ch/ehsan.mohammadpour?lang=en%3E><https://people.epfl.ch/ehsan.mohammadpour%3Chttps://people.epfl.ch/ehsan.mohammadpour?lang=en%3E 
>>>>>>> <https://people.epfl.ch/ehsan.mohammadpour%3Chttps://people.epfl.ch/ehsan.mohammadpour?lang=en%3E>>
>>>>>>>
>>>>>>> On 22 Mar 2021, at 16:56, Lou Berger <[e-mail] 
>>>>>>> <mailto:[e-mail]><mailto:[e-mail] 
>>>>>>> <mailto:[e-mail]>><mailto:[e-mail] 
>>>>>>> <mailto:[e-mail]><mailto:[e-mail] 
>>>>>>> <mailto:[e-mail]>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Ehsan
>>>>>>>
>>>>>>> Thank you for the update.  I did a quick skim and it looks much 
>>>>>>> improved.  I found one bit of new language confusing:
>>>>>>>
>>>>>>>    Section 6.4
>>>>>>>
>>>>>>>    In the considered queuing model, we considered the four traffic
>>>>>>>    classes (Definition 3.268 of [IEEE8021Q]): control-data traffic
>>>>>>>    (CDT), class A, class B, and best effort (BE) in decreasing 
>>>>>>> order of
>>>>>>>    priority.  Flows of classes A and B are together referred as AVB
>>>>>>>    flows.  This model is a subset of Time-Sensitive Networking as
>>>>>>>    described next.
>>>>>>>
>>>>>>>    ....
>>>>>>>
>>>>>>>    Then,
>>>>>>>    the input flows are identified using the information in 
>>>>>>> (Section 5.1
>>>>>>>    of [RFC8939]).  Then they are aggregated into eight macro 
>>>>>>> flows based
>>>>>>>    on their traffic classes.  We refer to each macro flow as a 
>>>>>>> class.
>>>>>>>
>>>>>>> So in the first paragraph, you say "traffic classes" is defined 
>>>>>>> by 802.1Q.  in the second, you say "their traffic classes" is 
>>>>>>> defined based on [RFC8939].  I believe these are inconsistent 
>>>>>>> definitions.  I think you are trying to say that
>>>>>>>
>>>>>>>     Then they are aggregated into eight macro flows based on 
>>>>>>> their *DetNet flow aggregate.*
>>>>>>>
>>>>>>> This is assuming that the node isn't doing some sort of 
>>>>>>> independent mapping of micro-flows to macro-flows.
>>>>>>>
>>>>>>> Please let me know if I'm missing something.
>>>>>>>
>>>>>>> Lou
>>>>>>>
>>>>>>> On 3/22/2021 11:33 AM, Mohammadpour Ehsan wrote:
>>>>>>>
>>>>>>> Dear WG,
>>>>>>>
>>>>>>> We submitted a new version of the Bounded Latency draft that 
>>>>>>> addresses the comments received in the list 
>>>>>>> (https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-04<https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-03> 
>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-04%3Chttps://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-03%3E><https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-04<https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-03> 
>>>>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-bounded-latency-04%3Chttps://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-03%3E>>); 
>>>>>>> it is now ready for submission to the IESG for publication.
>>>>>>>
>>>>>>> Thanks Lou for his comments. In the new version, we address the 
>>>>>>> comments as follows:
>>>>>>>
>>>>>>> - Abstract
>>>>>>> I think the abstract should to be updated to match the current 
>>>>>>> content of the document. I suggest just copying the 4th and 5th 
>>>>>>> paragraphs from the Introduction section.
>>>>>>>
>>>>>>>
>>>>>>> Thanks for the suggestion. The new version is updated accordingly.
>>>>>>>
>>>>>>> - general comment: classes of (DetNet) Service
>>>>>>>
>>>>>>> The document states that it uses terminology from RFC8655, it 
>>>>>>> also uses the terms "Classes of DetNet Service", " DetNet 
>>>>>>> Classes of Service"  and other similar forms of these terms. 
>>>>>>>  RFC8655 uses this term in one place " Class-of-Service schemes 
>>>>>>> (e.g., DiffServ)" and also mentions "classes of DetNet flows" 
>>>>>>>  in two places.  The data plane documents [RFC8964] and 
>>>>>>> [RFC8934] also describe Class of Service in the context of 
>>>>>>> DiffServ (and not DetNet).
>>>>>>>
>>>>>>> In reading the document it seems that it is not using CoS in the 
>>>>>>> typical way used in the IETF  or the other DetNet RFCs, and is 
>>>>>>> introducing a new definition for CoS.   II think having a 
>>>>>>> document specific definition of CoS probably isn't helpful. It 
>>>>>>> would be best to use existing DetNet terminology.  I suspect 
>>>>>>>  "flow aggregate" is the closest, but perhaps I'm missing something.
>>>>>>>
>>>>>>>
>>>>>>> Thanks for your comment. In the new version, we used the term 
>>>>>>> ???aggregate??? instead of class in section 3.1 and classes of 
>>>>>>> DetNet flows. Section 6.4 uses the term ???traffic class??? as 
>>>>>>> in IEEE802.1Q.
>>>>>>>
>>>>>>> - alignment with the Data Plane RFCs
>>>>>>>
>>>>>>> The lists in section 3.1 and in section 6.4 are not well aligned 
>>>>>>> with the Data plane documents.  These sections should be aligned 
>>>>>>> with the provisioning of IP flows, as summarized in Section  6 
>>>>>>> of RFC8939, and MPLS as summarized in Section 5 of RFC8964.
>>>>>>>
>>>>>>> Thanks for your comment. Section 3.1 is about flow admission 
>>>>>>> paradigm and not "flow creation???. The title is changed to 
>>>>>>> ???flow admission??? to avoid possible confusion. In fact, this 
>>>>>>> section is aligned with the DataPlane RFCs and in parallel with 
>>>>>>> provisioning of IP flows. We modified section 6.4 to follow the 
>>>>>>> Data plane documents.
>>>>>>>
>>>>>>>
>>>>>>> - minor comment service vs frame preemption
>>>>>>>
>>>>>>> Section 3.1 uses the term "un-provisioning", I read the text as 
>>>>>>> meaning "service preemption".
>>>>>>>
>>>>>>> In the rest of the document preemption refers to "frame 
>>>>>>> preemption" and this should be clarified.
>>>>>>>
>>>>>>> Thanks for the suggestion. In the new version, we use the term 
>>>>>>> ???service preemption??? and update the term ???preemption??? to 
>>>>>>> ???frame preemption???.
>>>>>>>
>>>>>>>
>>>>>>> - id nits, please ensure the document passes idnits without 
>>>>>>> errors, see
>>>>>>>
>>>>>>> https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-02.txt 
>>>>>>> <https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-02.txt><https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-02.txt 
>>>>>>> <https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-detnet-bounded-latency-02.txt>>
>>>>>>>
>>>>>>> Thanks for your comment about idnits. We added the missing 
>>>>>>> sections, i.e., ???security considerations??? and ???IANA 
>>>>>>> considerations??? to the draft. Also resolved other comments by 
>>>>>>> idnits.
>>>>>>>
>>>>>>> Best,
>>>>>>> Ehsan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ehsan Mohammadpour
>>>>>>> PhD Candidate at Swiss Federal Institute of Technology (EPFL)
>>>>>>> EPFL EDIC PhD student representative
>>>>>>> IC IINFCOM, LCA2, INF 011, Station 14, 1015 Lausanne, Switzerland
>>>>>>> https://people.epfl.ch/ehsan.mohammadpour<https://people.epfl.ch/ehsan.mohammadpour?lang=en> 
>>>>>>> <https://people.epfl.ch/ehsan.mohammadpour<https://people.epfl.ch/ehsan.mohammadpour?lang=en>>
>>>>>>>
>>>>>>>
>>>>>>> On 21 Feb 2021, at 23:15, Lou Berger 
>>>>>>> <[e-mail]<mailto:[e-mail]>> wrote:
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> The WG last call is complete.
>>>>>>>
>>>>>>> Authors,
>>>>>>>
>>>>>>> Please bring any resolutions to comments received to the list. 
>>>>>>> Once all comments are addressed please update the draft and let 
>>>>>>> the WG know that it is ready for submission to the IESG for 
>>>>>>> publications.
>>>>>>>
>>>>>>> Thank you!
>>>>>>>
>>>>>>> Lou
>>>>>>>
>>>>>>> On 2/5/2021 8:30 AM, Lou Berger wrote:
>>>>>>> All,
>>>>>>>
>>>>>>> This starts working group last call on 
>>>>>>> draft-ietf-detnet-bounded-latency-02
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-bounded-latency/
>>>>>>>
>>>>>>> The working group last call ends on February 19th.
>>>>>>> Please send your comments to the working group mailing list.
>>>>>>>
>>>>>>> Please note, there was an IPR disclosure against this document
>>>>>>> submitted on January 14, 2021, see 
>>>>>>> https://datatracker.ietf.org/ipr/4581/
>>>>>>> While this disclosure came very late in the document life cycle,
>>>>>>> it appears the filing was also relatively recent (2019-10-16) and
>>>>>>> after the pre adoption IP call:
>>>>>>> https://mailarchive.ietf.org/arch/msg/detnet/1mwYdadDzTLudcuH5T5O7R_KlDs
>>>>>>>
>>>>>>> Positive comments, e.g., "I've reviewed this document
>>>>>>> and believe it is ready for publication", are welcome!
>>>>>>> This is useful and important, even from authors.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Lou (DetNet Co-Chair & doc Shepherd)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> detnet mailing list
>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> detnet mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> detnet mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/detnet 
>>> <https://www.ietf.org/mailman/listinfo/detnet>
>