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

Hi Greg,

Many thanks for your review and feedback.
Proposal regarding your comments is as below.  I will check with the co-authors then update the draft.

Best regards,
Jiayi

发件人: detnet [mailto:detnet-bounces@ietf.org] 代表 Greg Mirsky
发送时间: 2021年2月13日 4:58 AM
收件人: Lou Berger <lberger@labn.net>
抄送: DetNet WG <detnet@ietf.org>
主题: Re: [Detnet] WG Last Call: draft-ietf-detnet-bounded-latency-02

Dear All,
I've read the current version of the draft and support progressing it to the publication as the Informational RFC.
I have several non-blocking comments and questions for the author's consideration:

  *   In Abstract and Introduction "server" and "central server" referenced. Could it be used to identify an SDN controller or orchestrator? If that is the case or close, perhaps a more direct terminology can be used.
<Jiayi>  Thank you for rising this question. The “server”, “central server” relates to the controller plane functions, that may receive registration of DetNet flows, do resource reservation,  and configure to DetNet nodes. If I understand right, theyalso refers to the function of SDN controller or orchestrator. Then, the term “controller” might be more direct. (Please let me know your idea, if you have suggestion in the terminology here)

  *   Perhaps s/un-provisioning/de-provisioning/?
<Jiayi> Next version will be updated with “de-provisioning” .

  *   It's been quite a long time since I've seen a network device being referenced as "bridge". If there's no difference modeling different types of networking devices in Section 3.2, perhaps "typically, bridges or routers" can be omitted.
<Jiayi> Thank you for this suggestion. Here bridge is mentioned because this draft refers to some layer-2 queuing or scheduling techniques defined in IEEE 802.1 TSN, where bridge is always referred. Since detnet focus on Layer-3, to omit "typically, bridges or routers" would be more clear to readers.

  *   And in the same sentence, a part of the reference model is described as "a wired link". Could that be some other media, e.g., wireless?
<Jiayi> Thank you for this suggestion. It is no need to limit the link as wired link, and in next paragraph it mentioned that link delay could be variable. I think to delete “wired” would be better.

  *   you may choose to use a single term from "DetNet unaware", "DetNet non-aware", and "non-DetNet"
<Jiayi> Thanks. We will use non-DetNet

  *   the statement in the second paragraph's  first sentence appears very assertive:
   In general, when passing through a non-DetNet island, the island
   causes delay variation in excess of what would be caused by DetNet
   nodes.
I agree that under some conditions such a domain might cause higher delay variation but I am not sure that is always the case.
<Jiayi> Yes, the delay variation caused by non-DetNet domain may “sometimes” happen. I propose to revise this paragraph to be less assertive, as: “In general → Sometimes”, “DetNet flow is lumpier → DetNet flow might be lumpier”, etc.

  *   Further in that paragraph, is stated that "... can still be calculated and met if and only if the following are true" though the second bullet appears as a conditional "An ingress conditioning function (Section 4.3) may be required ...". I am not sure it is clear when that second bullet is true - if the conditioning function is required or if it is not needed.
<Jiayi> The idea that latency upper-bound could be calculated relies on two parts:  traffic has TSpec (like maximum burst size and average rate, or examples in Sec 6), and service can be model. After a non-DetNet domain, where both traffic and service can hardly be modeled, the re-entered traffic can hardly be described. From this point of view, I think it would be necessary that conditioning the flow when it traverses a non-DetNet domain, in case these flows deteriorate the other existing DetNet flows, as well as the re-entered flow itself cannot be calculated with  delay bound because its lack of TSpec.
Regards,
Greg

On Fri, Feb 5, 2021 at 5:30 AM Lou Berger <lberger@labn.net<mailto:lberger@labn.net>> 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
detnet@ietf.org<mailto:detnet@ietf.org>
https://www.ietf.org/mailman/listinfo/detnet