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

[János Farkas <[e-mail]>]

Thank you Joel!
Janos

On 2/7/2019 3:19 PM, Joel M. Halpern wrote:
> 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
>
> On 2/6/19 5:17 PM, János Farkas wrote:
>> 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?
>>>
>>> ...
>>
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet