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
[email protected]
https://www.ietf.org/mailman/listinfo/detnet
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
