Subject: Re: [Detnet] Genart last call review of draft-ietf-detnet-architecture-08

From: János Farkas <[email-masked]>
Date: Wed, 6 Feb 2019 23:17:45 +0100

Hi Joel,

Thank you very much again for your review!

The draft had multiple updates since v08 you reviewed. The latest 
revision is v 11: 
https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0

The updates address review comments, and comments and discussions on the 
DetNet WG list.

Please let us know if you have further comments.

Regards,
Janos

On 10/19/2018 9:17 PM, Joel M. Halpern wrote:
> Thank you Janos.  Two clarifications under retained text, with the 
> rest elided.
>
> Yours,
> Joel
>
> On 10/19/18 3:10 PM, János Farkas wrote:
> ...
>> On 9/22/2018 2:59 AM, Joel Halpern wrote:
> ...
>>> Minor issues:
>>>      Section 3.1 states that worst case delay for priority queueing is
>>>      unbounded.  That does not match my understanding.  I know that 
>>> DelayBound
>>>      DSCP behavior tightly (although, I think, not as tightly as 
>>> Detnet) limits
>>>      both the worst case delay and the delay variation.
>> Strict priority is not good enough for DetNet. A high priority packet 
>> may need to wait until the transmission of a lower priority packet is 
>> finished at an outbound port, which can cause too much uncertainties 
>> in the network.
>
> I understand that strict priority queueing is viewed as insufficient.  
> I wasn;t arguing about that.  I was arguing with the use of the word 
> "unbounded".  As far as I can tell, with suitable priority queueing 
> the worst case delay is bounded, simply not well enough bounded.
>
> ...
>>>      In section 4.1.2, I realized that the Detnet Transit node 
>>> terminology had
>>>      mildly confused me.  The text says "DetNet enabled nodes are 
>>> interconnected
>>>      via transit nodes (e.g., LSRs) which support DetNet, but are 
>>> not DetNet
>>>      service aware."  Reading this, and the definitions in section 
>>> 2.1, it
>>>      appears that a Detnet Transit node is a node that is providing 
>>> transport
>>>      behavior that detnet needs, but is not actually modified for 
>>> detnet.
>> Based on last call comments: 
>> https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, 
>> the phrase "DetNet enabled nodes" is removed from the document and it 
>> has been made clear what type of DetNet node is meant:
>> The text is updated to:
>>
>>     A "Deterministic Network" will be composed of DetNet enabled end
>>     systems, DetNet edge nodes, DetNet relay nodes and collectively
>>     deliver DetNet services.  DetNet relay and edge nodes are
>>     interconnected via DetNet transit nodes (e.g., LSRs) which support
>>     DetNet, but are not DetNet service aware.
>
> Any chance you could simply say "transit nodes" instead of "DetNet 
> transit nodes?  As far as I can tell, they are existing nodes that 
> were designed and implemented (and even configured) potentially before 
> DetNet was even defined?
>
> ...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 6 Feb 2019 17:54:52 -0500

Thanks Janos.  I will take a look at it promptly.
Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Feb 2019 09:19:27 -0500

Thank you Janos.  I have looked at the changes.  They address my 
concerns, and make a number of other useful and consistent changes that 
improve the document readability and clarity.

Yours,
Joel

---

From: János Farkas <[email-masked]>
Date: Thu, 7 Feb 2019 15:57:42 +0100

Thank you Joel!
Janos

On 2/7/2019 3:19 PM, Joel M. Halpern wrote:
> concerns, and make a number of other useful and consistent changes 
> that improve the document readability and clarity.
>
> Yours,
> Joel
>
>> The updates address review comments, and comments and discussions on 
>> the DetNet WG list.
>>
>>>>>      unbounded.  That does not match my understanding.  I know 
>>>>> that DelayBound
>>>> Strict priority is not good enough for DetNet. A high priority 
>>>> packet may need to wait until the transmission of a lower priority 
>>>> packet is finished at an outbound port, which can cause too much 
>>>> uncertainties in the network.
>>>
>>> I understand that strict priority queueing is viewed as 
>>> insufficient. I wasn;t arguing about that.  I was arguing with the 
>>> use of the word "unbounded".  As far as I can tell, with suitable 
>>> priority queueing the worst case delay is bounded, simply not well 
>>> enough bounded.
>>>
>>> ...
>>>>>      appears that a Detnet Transit node is a node that is 
>>>>> providing transport
>>>> the phrase "DetNet enabled nodes" is removed from the document and 
>>>> it has been made clear what type of DetNet node is meant:
>>>> The text is updated to:
>>>>
>>> were designed and implemented (and even configured) potentially 
>>> before DetNet was even defined?
>>>
>>> ...
>>
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet