Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments

["qiangli (D)" <[e-mail]>]

Thank you, Stewart. Will update draft according to this information.

Best regards,

Cristina QIANG


-----Original Message-----
From: Stewart Bryant [mailto:[e-mail]] 
Sent: Friday, June 28, 2019 6:21 PM
To: qiangli (D) <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments

If the ITU have specifications that cover our needs we should reference them. From an IETF perspective there is no procedural issue with referencing ITU specifications.

Characterizing oscillators is a complex and difficult task, and the ITU has a lot more expertise in that than IETF does, so we should use there work if possible.

- Stewart


On 27/06/2019 13:01, qiangli (D) wrote:
> Hi Peter,
> 
> Referencing ITU standards is acceptable IMHO. Let's see others' opinion.
> 
> Best regards,
> 
> Cristina QIANG
> 
> *From:*[e-mail] [mailto:[e-mail]]
> *Sent:* Thursday, June 27, 2019 6:59 PM
> *To:* qiangli (D) <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; [e-mail]; 
> [e-mail]
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 
> revised for comments
> 
> Cristina,
> 
> Personally I think it would be useful to reference such ITU standards 
> if it does not cause IETF procedure issues.
> 
> Best Regardsyyo
> 
> Peter.
> 
> *From:*qiangli (D) <[e-mail] <mailto:[e-mail]>>
> *Sent:* 27 June 2019 10:26
> *To:* Willis,PJ,Peter,TUD1 R <[e-mail] 
> <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 
> revised for comments
> 
> Hi Peter,
> 
> The relationship between clock jitter& wander and packet jitter is 
> very complicated, varies a lot depend on different mechanisms. I know 
> there are some time synch stands such as G.8273.2, G.8262. Is it 
> helpful to reference this stands?
> 
> Best regards,
> 
> Cristina QIANG
> 
> *From:*[e-mail]
> <mailto:[e-mail]>[mailto:[e-mail]]
> *Sent:* Wednesday, June 26, 2019 6:20 PM
> *To:* [e-mail] <mailto:[e-mail]>;
> qiangli (D) <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 
> revised for comments
> 
> Colleagues,
> 
>  From a network operator's point of view I do not want the extra cost 
> of highly accurate clocks in routers so prefer Detnet to work with the 
> current clocks I have in routers. For an exact specification we would 
> have to list the clock specifications in the typical routers that 
> network operators use (it's not information I have at my fingertips).
> 
> I also put this requirement in to test what assumptions we are making 
> about clock jitter & wander, and to check those assumptions are 
> reasonable in practice. If there is a correlation between clock jitter 
> & wander and packet jitter then that needs to be understood and stated.
> 
> Best Regards,
> 
> Peter.
> 
> *From:*Janos Farkas <[e-mail] 
> <mailto:[e-mail]>>
> *Sent:* 26 June 2019 10:37
> *To:* qiangli (D) <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; Willis,PJ,Peter,TUD1 R 
> <[e-mail] <mailto:[e-mail]>>; Liang GENG 
> <[e-mail] <mailto:[e-mail]>>
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 
> revised for comments
> 
> Hi Cristina,
> 
> Thank you for your quick response.
> 
> I'd like to have what others think.
> 
> Just one more note on my side: I think it depends a lot on the actual 
> deployment/application/use case. For instance, in some cases, 
> synchronization would be not needed at all; e.g., if the DetNet high 
> availability / high reliability feature is what is really needed for 
> the given case; or an asynchronous solution is used to achieve bounded 
> low latency.
> 
> Best regards,
> 
> Janos
> 
> *From:*qiangli (D) <[e-mail] <mailto:[e-mail]>>
> *Sent:* Wednesday, June 26, 2019 11:29 AM
> *To:* Janos Farkas <[e-mail] 
> <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; Liang GENG <[e-mail] 
> <mailto:[e-mail]>>
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 
> revised for comments
> 
> Hello Janos,
> 
> Thanks for your kindly remind and comment. I copied the Req. 2.2 text 
> as follows for easy check. The current version doesn't contain any 
> solution and details as you requested. The reason that why we want to 
> know what degree of clock jitter & wander DetNet can tolerate, is to 
> detail the current text. According to your reply, I understand that 
> DetNet just simply uses what is available.  So maybe we can simply 
> list some existing standards here, no need to further specify more 
> details. What do you think.
> 
> ==========================================================
> 
> 2.2.2.  Sub-requirement 2.2: Should tolerate clock jitter & wander
> 
>          within a clock synchronous domain
> 
>     DetNet domain itself can be time synchronous or asynchronous,
> 
>     depending on the technology selection of different operators.  
> Even
> 
>     within a time synchronous domain, the synchronized clocks may also
> 
>     experience jitter & wander, the mechanisms adopted by DetNet 
> should
> 
>     be able to tolerate a certain degree of clock jitter & wander.
> 
> ==========================================================
> 
> Best regards,
> 
> Cristina QIANG
> 
> *From:*Janos Farkas [mailto:[e-mail]]
> *Sent:* Wednesday, June 26, 2019 4:28 PM
> *To:* qiangli (D) <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; Liang GENG <[e-mail] 
> <mailto:[e-mail]>>
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 
> revised for comments
> 
> Hi Cristina,
> 
> My understanding of the consensus of the WG based on the Architecture 
> document is that synchronization is acknowledged to be important; 
> however, it is not the job of DetNet to specify the details, 
> solutions, etc.; DetNet just uses what is available, specified by other standards.
> 
> Best regards,
> 
> Janos
> 
> *From:*detnet <[e-mail] 
> <mailto:[e-mail]>> *On Behalf Of *qiangli (D)
> *Sent:* Wednesday, June 26, 2019 5:33 AM
> *To:* [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; Liang GENG <[e-mail] 
> <mailto:[e-mail]>>
> *Subject:* Re: [Detnet]
> draft-geng-detnet-requirements-bounded-latency-02 revised for comments
> 
> Hi all,
> 
> The Req. 2.2 discusses that DetNet should be able to tolerate a 
> certain degree of clock jitter & wander even within a time synchronous domain.
> We would like to know if you agree or disagree with this requirement. 
> If you think this requirement is necessary, then to what degree of 
> clock jitter & wander do you expect?
> 
> BTW, we are going to ask for WG adoption for this document in IETF 105 
> meeting. That's will be greatly appreciated if you can share your 
> comments to help us further improve this draft.
> 
> Best regards,
> 
> Cristina QIANG
> 
> *From:*detnet [mailto:[e-mail]] *On Behalf Of *qiangli 
> (D)
> *Sent:* Monday, June 17, 2019 4:11 PM
> *To:* [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; Liang GENG <[e-mail] 
> <mailto:[e-mail]>>
> *Subject:* Re: [Detnet]
> draft-geng-detnet-requirements-bounded-latency-02 revised for comments
> 
> Hi all,
> 
> This version has collected 7 requirements, and divided these 
> requirements into optional (SHOULD) and mandatory (MUST) two types as 
> following shows. We authors would like to know if this requirement 
> list is complete, and if the classification is appropriate or not.  
> Your review and comments are highly appropriated.
> 
> ==========================
> 
> Req. 1: Must support the dynamic creation, modification and deletion 
> of deterministic services
> 
> Req. 2.1: Should support asynchronous clocks across domains
> 
> Req. 2.2 : Should tolerate a certain of clock jitter & wander within a 
> clock synchronous domain
> 
> Req. 3: Must support Inter-Continental propagation delay
> 
> Req. 4: Should have self-monitoring capability
> 
> Req. 5: Should be robust against denial of service attacks
> 
> Req. 6: Must tolerate failures of links or nodes and topology changes
> 
> Req. 7: Must be scalable
> 
> ===========================
> 
> Best regards,
> 
> Cristina QIANG
> 
> *From:*Liang GENG [mailto:[e-mail]]
> *Sent:* Tuesday, June 11, 2019 11:53 AM
> *To:* [e-mail] <mailto:[e-mail]>
> *Cc:* Black, David <[e-mail] 
> <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; qiangli (D) 
> <[e-mail] <mailto:[e-mail]>>
> *Subject:* draft-geng-detnet-requirements-bounded-latency-02 revised 
> for comments
> 
> Dear all,
> 
> Since IETF 104, we have carefully revised
> draft-geng-detnet-requirements-bounded-latency-02 according to 
> received comments. The latest 02 version was uploaded and available 
> online https://datatracker.ietf.org/doc/draft-geng-detnet-requirements-bounded-latency/.
> 
> 
> This new version collects more technical, operational and management 
> requirements of deploying deterministic latency service on layer 3 
> networks from the perspective of various service providers.
> 
> Comments are welcome!
> 
> Best regards,
> 
> Liang Geng on behavior of co-authors
> 
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
>