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

From: Liang GENG <[email-masked]>
Date: Tue, 11 Jun 2019 03:52:45 +0000

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

---

From: "qiangli (D)" <[email-masked]>
Date: Mon, 17 Jun 2019 08:10:44 +0000

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:[email-masked]]
Sent: Tuesday, June 11, 2019 11:53 AM
To: [email-masked]
Cc: Black, David <[email-masked]>; [email-masked]; [email-masked]; qiangli (D) <[email-masked]>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Dear all,

Comments are welcome!

Best regards,

---

From: "qiangli (D)" <[email-masked]>
Date: Wed, 26 Jun 2019 03:32:59 +0000

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:[email-masked]] On Behalf Of qiangli (D)
Sent: Monday, June 17, 2019 4:11 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Liang GENG <[email-masked]>
Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

From: Liang GENG [mailto:[email-masked]]
Sent: Tuesday, June 11, 2019 11:53 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Black, David <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; qiangli (D) <[email-masked]<mailto:[email-masked]>>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Dear all,

Comments are welcome!

Best regards,

---

From: Shunsuke Homma <[email-masked]>
Date: Wed, 26 Jun 2019 16:28:46 +0900

Hi,

I agree that these requirements are important, especially from operator's aspect.  Services and applications which are latency
sensitive will increase more, and it would be required that enough dynamicity and scalability for utilizing it in carrier-wide
networks.

Regarding req 7, "scalable" has wide meaning, for example implementation or management aspects, and I hope it is broken down to more
concrete requirements in the next revision.

Best regards,

Shunsuke

From: detnet [mailto:[email-masked]] On Behalf Of qiangli (D)
Sent: Wednesday, June 26, 2019 12:33 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Liang GENG
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

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. 7: Must be scalable

Best regards,

Cristina QIANG

From: Liang GENG [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Tuesday, June 11, 2019 11:53 AM
To:  <mailto:[email-masked]> [email-masked]
Cc: Black, David < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]; qiangli (D) < <mailto:[email-masked]>
[email-masked]>
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/>
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,

---

From: Janos Farkas <[email-masked]>
Date: Wed, 26 Jun 2019 08:27:40 +0000

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 <[email-masked]> On Behalf Of qiangli (D)
Sent: Wednesday, June 26, 2019 5:33 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Liang GENG <[email-masked]>
Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi all,

Best regards,

Cristina QIANG

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Liang GENG <[email-masked]<mailto:[email-masked]>>

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Cc: Black, David <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; qiangli (D) <[email-masked]<mailto:[email-masked]>>

Dear all,

Comments are welcome!

Best regards,

---

From: "qiangli (D)" <[email-masked]>
Date: Wed, 26 Jun 2019 09:29:11 +0000

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:[email-masked]]
Sent: Wednesday, June 26, 2019 4:28 PM
To: qiangli (D) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Liang GENG <[email-masked]>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi Cristina,

Best regards,
Janos

From: detnet <[email-masked]<mailto:[email-masked]>> On Behalf Of qiangli (D)

Hi all,

Best regards,

Cristina QIANG

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Dear all,

Comments are welcome!

Best regards,

---

From: Janos Farkas <[email-masked]>
Date: Wed, 26 Jun 2019 09:36:47 +0000

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) <[email-masked]>
Sent: Wednesday, June 26, 2019 11:29 AM
To: Janos Farkas <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Liang GENG <[email-masked]>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hello Janos,

Best regards,

Cristina QIANG

From: Janos Farkas [mailto:[email-masked]]
Sent: Wednesday, June 26, 2019 4:28 PM
To: qiangli (D) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Liang GENG <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi Cristina,

Best regards,
Janos

Hi all,

Best regards,

Cristina QIANG

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Dear all,

Comments are welcome!

Best regards,

---

From: "qiangli (D)" <[email-masked]>
Date: Wed, 26 Jun 2019 09:48:04 +0000

Hi Janos,

Fully agree with you on this point.  So the statement "DetNet domain itself can be time synchronous or asynchronous, depending on the technology selection of different operators."  can be refined as "DetNet domain itself can be time synchronous or asynchronous, depending on actual deployment/application/use cases" for more accurate. Thank you.

Best regards,

Cristina QIANG

Sent: Wednesday, June 26, 2019 5:37 PM

Hi Cristina,

Best regards,
Janos

From: qiangli (D) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 26, 2019 11:29 AM
To: Janos Farkas <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Liang GENG <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hello Janos,

Best regards,

Cristina QIANG

Hi Cristina,

Best regards,
Janos

Hi all,

Best regards,

Cristina QIANG

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Dear all,

Comments are welcome!

Best regards,

---

From: <[email-masked]>
Date: Wed, 26 Jun 2019 10:20:28 +0000

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 <[email-masked]>
Sent: 26 June 2019 10:37
To: qiangli (D) <[email-masked]>
Cc: [email-masked]; [email-masked]; Willis,PJ,Peter,TUD1 R <[email-masked]>; Liang GENG <[email-masked]>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi Cristina,

Best regards,
Janos

Hello Janos,

Best regards,

Cristina QIANG

Hi Cristina,

Best regards,
Janos

Hi all,

Best regards,

Cristina QIANG

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Dear all,

Comments are welcome!

Best regards,

---

From: "qiangli (D)" <[email-masked]>
Date: Thu, 27 Jun 2019 08:47:38 +0000

Hi Shunsuke,

Thanks for your support. "Scalability" is indeed an important requirement, especially for operators when considering actual deployment. DetNet has considered this point, the DetNet architecture proposed to improve scalability through flow aggregation. Except for scale to a great amount of traffic flows,   current Req. 7 also mentions the number of network devices.  Do you recommend splitting Req.7 from these two aspects?

Best regards,

Cristina QIANG

From: Shunsuke Homma [mailto:[email-masked]]
Sent: Wednesday, June 26, 2019 3:29 PM
To: qiangli (D) <[email-masked]>; [email-masked]
Cc: [email-masked]; 'Liang GENG' <[email-masked]>
Subject: RE: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi,

I agree that these requirements are important, especially from operator's aspect.  Services and applications which are latency sensitive will increase more, and it would be required that enough dynamicity and scalability for utilizing it in carrier-wide networks.

Regarding req 7, "scalable" has wide meaning, for example implementation or management aspects, and I hope it is broken down to more concrete requirements in the next revision.

Best regards,

Shunsuke

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Liang GENG

Hi all,

Best regards,

Cristina QIANG

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Dear all,

Comments are welcome!

Best regards,

---

From: "qiangli (D)" <[email-masked]>
Date: Thu, 27 Jun 2019 09:25:32 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 26, 2019 6:20 PM
To: [email-masked]; qiangli (D) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Colleagues,

Best Regards,
Peter.

From: Janos Farkas <[email-masked]<mailto:[email-masked]>>
Sent: 26 June 2019 10:37
To: qiangli (D) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Willis,PJ,Peter,TUD1 R <[email-masked]<mailto:[email-masked]>>; Liang GENG <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi Cristina,

Best regards,
Janos

Hello Janos,

Best regards,

Cristina QIANG

Hi Cristina,

Best regards,
Janos

Hi all,

Best regards,

Cristina QIANG

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Dear all,

Comments are welcome!

Best regards,

---

From: Shunsuke Homma <[email-masked]>
Date: Thu, 27 Jun 2019 19:27:25 +0900

Hi Cristina,

>From operator's aspect, in addition to the number of network devices, the number of accommodated end devices and services would be
important. Also, the number of network devices may be broken down to some factors such as load of processes or unnecessity of
specific device/chip. There may other requirements on scalability.

Best regards,

Shunsuke

From: qiangli (D) [mailto:[email-masked]] 
Sent: Thursday, June 27, 2019 5:48 PM
To: Shunsuke Homma; [email-masked]
Cc: [email-masked]; 'Liang GENG'
Subject: RE: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi Shunsuke,

Thanks for your support. "Scalability" is indeed an important requirement, especially for operators when considering actual
deployment. DetNet has considered this point, the DetNet architecture proposed to improve scalability through flow aggregation.
Except for scale to a great amount of traffic flows,   current Req. 7 also mentions the number of network devices.  Do you recommend
splitting Req.7 from these two aspects?

Best regards,

Cristina QIANG

Hi,

Best regards,

Shunsuke

Hi all,

 

Best regards,

Cristina QIANG

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Dear all,

Comments are welcome!

Best regards,

---

From: <[email-masked]>
Date: Thu, 27 Jun 2019 10:59:29 +0000

Cristina,

Personally I think it would be useful to reference such ITU standards if it does not cause IETF procedure issues.

Best Regards,
Peter.

From: qiangli (D) <[email-masked]>
Sent: 27 June 2019 10:26
To: Willis,PJ,Peter,TUD1 R <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi Peter,

Best regards,

Cristina QIANG

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, June 26, 2019 6:20 PM
To: [email-masked]<mailto:[email-masked]>; qiangli (D) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Colleagues,

Best Regards,
Peter.

Hi Cristina,

Best regards,
Janos

Hello Janos,

Best regards,

Cristina QIANG

Hi Cristina,

Best regards,
Janos

Hi all,

Best regards,

Cristina QIANG

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Dear all,

Comments are welcome!

Best regards,

---

From: "qiangli (D)" <[email-masked]>
Date: Thu, 27 Jun 2019 12:01:10 +0000

Hi Peter,

Referencing ITU standards is acceptable IMHO. Let's see others' opinion.

Best regards,

Cristina QIANG

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 27, 2019 6:59 PM
To: qiangli (D) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Cristina,

Best Regardsyyo
Peter.

From: qiangli (D) <[email-masked]<mailto:[email-masked]>>
Sent: 27 June 2019 10:26
To: Willis,PJ,Peter,TUD1 R <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi Peter,

Best regards,

Cristina QIANG

Colleagues,

Best Regards,
Peter.

Hi Cristina,

Best regards,
Janos

Hello Janos,

Best regards,

Cristina QIANG

Hi Cristina,

Best regards,
Janos

Hi all,

Best regards,

Cristina QIANG

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Dear all,

Comments are welcome!

Best regards,

---

From: "qiangli (D)" <[email-masked]>
Date: Thu, 27 Jun 2019 13:23:50 +0000

Hi Shunsuke,

Thank you for your comments. We will try to analyze  "scalability" in detail next version. But I'm afraid we couldn't go so deep as you suggested, since like the load of process, the chips are OS/hardware related, is not in IETF's scope.

Best regards,

Cristina QIANG

Sent: Thursday, June 27, 2019 6:27 PM

Hi Cristina,

>From operator's aspect, in addition to the number of network devices, the number of accommodated end devices and services would be important. Also, the number of network devices may be broken down to some factors such as load of processes or unnecessity of specific device/chip. There may other requirements on scalability.

Best regards,

Shunsuke

From: qiangli (D) [mailto:[email-masked]]
Sent: Thursday, June 27, 2019 5:48 PM
To: Shunsuke Homma; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Liang GENG'
Subject: RE: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi Shunsuke,

Best regards,

Cristina QIANG

From: Shunsuke Homma [mailto:[email-masked]]
Sent: Wednesday, June 26, 2019 3:29 PM
To: qiangli (D) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Liang GENG' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments

Hi,

Best regards,

Shunsuke

Hi all,

Best regards,

Cristina QIANG

Hi all,

Req. 7: Must be scalable

Best regards,

Cristina QIANG

Dear all,

Comments are welcome!

Best regards,

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 28 Jun 2019 11:15:40 +0100

On 26/06/2019 11:20, [email-masked] wrote:
> 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).
> 

Peter,

Ethernet is spec'd at 100ppm and that is what most cheap crystals do, so 
I think that is all you get if you fall back to basics.

However cell sites need 50ppb, and this resulted in so-called syncE at 
that specification. In the mobile backhaul there will also be precision 
time - 1.2us for minimum operation of 5G and circa 200ns for optimum 
operation.

So I think "the clocks I have in routers" is a statement that very much 
depends on where in the network you are, and what the primary 
application of that network domain is.

However, if 5G becomes the dominate network use, as some predict, the 
trend is surely to the pervasive availability of accurate clocks in 
network fragments that need them.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 28 Jun 2019 11:20:56 +0100

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:[email-masked] [mailto:[email-masked]]
> *Sent:* Thursday, June 27, 2019 6:59 PM
> *To:* qiangli (D) <[email-masked]>; [email-masked]
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 revised 
> for comments
> 
> Cristina,
> 
> *From:*qiangli (D) <[email-masked] <mailto:[email-masked]>>
> *Sent:* 27 June 2019 10:26
> *To:* Willis,PJ,Peter,TUD1 R <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *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:[email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked]]
> *Sent:* Wednesday, June 26, 2019 6:20 PM
> *To:* [email-masked] <mailto:[email-masked]>; 
> qiangli (D) <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 revised 
> for comments
> 
> Colleagues,
> 
> 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 <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* 26 June 2019 10:37
> *To:* qiangli (D) <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; Willis,PJ,Peter,TUD1 R 
> <[email-masked] <mailto:[email-masked]>>; Liang GENG 
> <[email-masked] <mailto:[email-masked]>>
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 revised 
> for comments
> 
> Hi Cristina,
> 
> 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) <[email-masked] <mailto:[email-masked]>>
> *Sent:* Wednesday, June 26, 2019 11:29 AM
> *To:* Janos Farkas <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Liang GENG <[email-masked] 
> <mailto:[email-masked]>>
> *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.
> 
> *From:*Janos Farkas [mailto:[email-masked]]
> *Sent:* Wednesday, June 26, 2019 4:28 PM
> *To:* qiangli (D) <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Liang GENG <[email-masked] 
> <mailto:[email-masked]>>
> *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 <[email-masked] <mailto:[email-masked]>> 
> *On Behalf Of *qiangli (D)
> *Sent:* Wednesday, June 26, 2019 5:33 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Liang GENG <[email-masked] 
> <mailto:[email-masked]>>
> *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:[email-masked]] *On Behalf Of *qiangli (D)
> *Sent:* Monday, June 17, 2019 4:11 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Liang GENG <[email-masked] 
> <mailto:[email-masked]>>
> *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.
> 
> *From:*Liang GENG [mailto:[email-masked]]
> *Sent:* Tuesday, June 11, 2019 11:53 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* Black, David <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>; qiangli (D) 
> <[email-masked] <mailto:[email-masked]>>
> *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 
> 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,
> 
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: "qiangli (D)" <[email-masked]>
Date: Sat, 29 Jun 2019 06:09:48 +0000

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

Best regards,

Cristina QIANG

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Friday, June 28, 2019 6:21 PM
To: qiangli (D) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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:
> *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.
> 
> *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
> 
> *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 
> network operators use (it's not information I have at my fingertips).
> 
> 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.
> 
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 
> revised for comments
> 
> Hi Cristina,
> 
> 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
> 
> *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.
> 
> *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02 
> revised for comments
> 
> Hi Cristina,
> 
> 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 <[email-masked] 
> <mailto:[email-masked]>> *On Behalf Of *qiangli (D)
> 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?
> 
> meeting. That's will be greatly appreciated if you can share your 
> 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.
> 
> *Cc:* Black, David <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> *Subject:* draft-geng-detnet-requirements-bounded-latency-02 revised 
> for comments
> 
> Dear all,
> 
> 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/.
> 
>