From nobody Mon Jun 3 10:42:23 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9858A1206DE for ; Mon, 3 Jun 2019 10:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-1K0MYfoV_0 for ; Mon, 3 Jun 2019 10:42:19 -0700 (PDT) Received: from know-smtprelay-omc-9.server.virginmedia.net (know-smtprelay-omc-9.server.virginmedia.net [80.0.253.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCE61205E1 for ; Mon, 3 Jun 2019 10:42:03 -0700 (PDT) Received: from [192.168.1.34] ([79.72.6.207]) by cmsmtp with ESMTPA id Xqy8h47LkVaV8Xqy8hJxld; Mon, 03 Jun 2019 18:42:01 +0100 X-Originating-IP: [79.72.6.207] X-Authenticated-User: john.s.grant@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=PcnReBpd c=1 sm=1 tr=0 a=6eCWiWCKLHZwm2jqVNNtoA==:117 a=6eCWiWCKLHZwm2jqVNNtoA==:17 a=48vgC7mUAAAA:8 a=vC8qy13tVhA5W1vfpNwA:9 a=QEXdDO2ut3YA:10 a=On0Lc5ZqIP0A:10 a=-i-vOQe_oZb_B37zMdAA:9 a=pt9G7I5XmLUTiVRDx3fboKQV4P0=:19 a=w1C3t2QeGrPiZgrLijVG:22 a=Z5ABNNGmrOfJ6cZ5bIyy:22 a=QOGEsqRv6VhmHaoFNykA:22 MIME-version: 1.0 From: John Grant Message-ID: <2b989e9f-d7ba-6bcb-93a1-77e5548b5125@ninetiles.com> To: detnet@ietf.org Date: Mon, 03 Jun 2019 18:42:04 +0100 Content-type: multipart/mixed; boundary="Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)" X-CMAE-Envelope: MS4wfMwI7TL5xeleVloBADpjiBRi1BxkKEQ7VrHvmcVYx73mxJl5C1zhD/0zzrkSjZi42E+rlg4tRgJOtbTxFTMVwsaZAGhiJGa6GuyPM2hZlS02zDBzip41 j4ltFNb5nh9XXK2PKKvEfAFKS0h77/aNONCmNOJNCtt7GJ/j8KER+Lum Archived-At: Subject: [Detnet] Updated Event Invitation: DetNet Data Plane drafts progressing X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 17:42:22 -0000 --Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ) Content-type: multipart/alternative; boundary="Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)" --Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT DetNet Working Group has invited you to DetNet Data Plane drafts progressing --Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA) Content-type: text/calendar; method=REQUEST; charset=UTF-8 Content-transfer-encoding: 8BIT BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Amsterdam BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT LAST-MODIFIED:20190603T174204Z DTSTAMP:20190603T174204Z UID:df9ad342-1a1d-437f-8566-3c3fcd2cb430 SUMMARY:DetNet Data Plane drafts progressing PRIORITY:5 ORGANIZER;CN=DetNet Working Group:mailto:detnet-chairs@ietf.org ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:detne t@ietf.org RRULE:FREQ=WEEKLY;UNTIL=20190715;BYDAY=MO;WKST=SU DTSTART;TZID=Europe/Amsterdam:20190603T140000 DTEND;TZID=Europe/Amsterdam:20190603T150000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1559307959 DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php? MTID=m221008ce82e86a54d48a97711edd71a6\nMeeting number (access code): 646 379 614\nMeeting password: DataPlane\n\n\n\nJOIN BY PHONE\n1-650-479-3208 Call-in toll number (US/Canada)\nTap here to call (mobile phones only\, ho sts not supported): tel:%2B1-650-479-3208\,\,*01*646379614%23%23*01*\n\n\n \n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/W BX000029055\n\n\nIMPORTANT NOTICE: Please note that this Webex service all ows audio and other information sent during the session to be recorded\, w hich may be discoverable in a legal matter. By joining this session\, you automatically consent to such recordings. If you do not consent to being r ecorded\, discuss your concerns with the host or do not join the session.\ n X-ALT-DESC;FMTTYPE=text/html:\n\n\n\t\t Join Webex meeting\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t
\n\t\t\t\t\t\tMeeting number ( access code): 646 379 614\n\t\t\t\t\t
Meeting password:DataPlane
\n\t\t\n

\n \;
& nbsp\;
\n\n\n \;
Join by phone  \;
\n\n\n\t\t Join Webex meeting\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t
\n\t\t\t\t\t\tMeeting number ( access code): 646 379 614\n\t\t\t\t\t
Meeting password:DataPlane
\n\t\t\n

\n \;
& nbsp\;
\n\n\n \;
Join by phone  \;
Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BQ== Date: Tue, 11 Jun 2019 03:52:45 +0000 Message-ID: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:BEB4961CF8330E71D7AD3632D8E2CFA814EB8AC474D515AE5AA9A73C249C4572; UpperCasedChecksum:D4206DB9DCDEB76DD783CE6416169CE860DA5D6AF30486D9C39CF47243414099; SizeAsReceived:6765; Count:41 x-tmn: [rr09EeY/t54sMrNCMd2JZH5AUPtvS/X/] x-ms-publictraffictype: Email x-incomingheadercount: 41 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM02HT191; x-ms-traffictypediagnostic: SN1NAM02HT191: x-ms-exchange-purlcount: 1 x-microsoft-antispam-message-info: tLUswbktEYH6SmOeYnXvd0+88PikECokY+m8CRwyAVaKwPLuvqCxLGVxtmyyH4kZYSUf6XK+GgCovrIUIYqwSRddftDm87IRMy8l5usRihxqWS0YuL14mp9nbMwqQq3qK+qnPDwYybbTgYJlyVtalvVEUa5OqgvSRDBgD+7BwIZZ7vAJt7EX2ZlGkd7NZ7ms Content-Type: multipart/alternative; boundary="_000_BN6PR22MB0771D878C59904BC7E0E0ACC87ED0BN6PR22MB0771namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: dcf10dbe-e003-47e8-5b1d-08d6ee204384 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 03:52:45.8245 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT191 Archived-At: Subject: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 03:52:50 -0000 --_000_BN6PR22MB0771D878C59904BC7E0E0ACC87ED0BN6PR22MB0771namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_BN6PR22MB0771D878C59904BC7E0E0ACC87ED0BN6PR22MB0771namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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-lat= ency/. 


This new version collects more technical, operational and management requir= ements 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




--_000_BN6PR22MB0771D878C59904BC7E0E0ACC87ED0BN6PR22MB0771namp_-- From nobody Mon Jun 17 01:10:54 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BD61200BA for ; Mon, 17 Jun 2019 01:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFsQQgVlleDh for ; Mon, 17 Jun 2019 01:10:50 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25EE1200C3 for ; Mon, 17 Jun 2019 01:10:49 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7A542217871A5D7DB906; Mon, 17 Jun 2019 09:10:47 +0100 (IST) Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 17 Jun 2019 09:10:46 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 17 Jun 2019 16:10:44 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1591.008; Mon, 17 Jun 2019 16:10:44 +0800 From: "qiangli (D)" To: "detnet@ietf.org" CC: "peter.j.willis@bt.com" , "shunsuke.homma.fp@hco.ntt.co.jp" , "Liang GENG" Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUw Date: Mon, 17 Jun 2019 08:10:44 +0000 Message-ID: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: multipart/alternative; boundary="_000_8aea82da521a4faead2f6cb4652f7d4bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 08:10:53 -0000 --_000_8aea82da521a4faead2f6cb4652f7d4bhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David ; peter.j.willis@bt.com; shunsuke.ho= mma.fp@hco.ntt.co.jp; qiangli (D) Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_8aea82da521a4faead2f6cb4652f7d4bhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

This version has colle= cted 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 a= re highly appropriated.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Req. 1: Must support t= he dynamic creation, modification and deletion of deterministic services

 

Req. 2.1: Should suppo= rt asynchronous clocks across domains

Req. 2.2 : Should tole= rate a certain of clock jitter & wander within a clock synchronous doma= in

 

Req. 3: Must support I= nter-Continental propagation delay

 

Req. 4: Should have se= lf-monitoring capability

 

Req. 5: Should be robu= st against denial of service attacks

 

Req. 6: Must tolerate = failures of links or nodes and topology changes

 

Req. 7: Must be scalab= le

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

From: = Liang GENG [mailto:liang.geng@hotmail.com]
Sent: Tuesday, June 11, 2019 11:53 AM
To: detnet@ietf.org
Cc: Black, David <David.Black@dell.com>; peter.j.willis@bt.com= ; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@huawei.com><= br> Subject: draft-geng-detnet-requirements-bounded-latency-02 revised f= or comments

 

Dear all,

 

Since IETF 104, we have carefully revised draft-geng-detnet-r= equirements-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-lat= ency/. 

 

This new version collects more technical, operational and man= agement requirements of deploying deterministic latency service on layer 3 networks from the perspective of various servic= e providers.

 

Comments are welcome!

 

Best regards,

Liang Geng on behavior of co-authors

 

 

 

--_000_8aea82da521a4faead2f6cb4652f7d4bhuaweicom_-- From nobody Mon Jun 24 04:19:00 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0E120128 for ; Mon, 24 Jun 2019 04:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mTAcZ0AUWiz for ; Mon, 24 Jun 2019 04:18:57 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40085.outbound.protection.outlook.com [40.107.4.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77DF120048 for ; Mon, 24 Jun 2019 04:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DFaF4tF1ltCXV30RWRQcAjTzfP+DTzGjljoI9fAX+tU=; b=hGe94Pn6WKLXZ/rPa60maD1FKoH47WDKTDK1v5R/3YLUCa9EiZegbqBfvaHHiYIxsPJNBUJHR3eQpgmKzfQstjUM3cvEEcW96wXh2uPUBFtJxivHQCDGVv5NxG7r+qbFZR6Rp908KoQjZdMRs3b6V1/T7ZOm4SfkWKgTvbmUnjE= Received: from AM5PR0701MB2289.eurprd07.prod.outlook.com (10.169.152.148) by AM5PR0701MB2722.eurprd07.prod.outlook.com (10.173.92.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.13; Mon, 24 Jun 2019 11:18:54 +0000 Received: from AM5PR0701MB2289.eurprd07.prod.outlook.com ([fe80::d06:2c54:377:b9b5]) by AM5PR0701MB2289.eurprd07.prod.outlook.com ([fe80::d06:2c54:377:b9b5%3]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 11:18:54 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "detnet@ietf.org" Thread-Topic: Agenda - DetNet Data Plane drafts progressing Thread-Index: AdUqfhM+7y/PAPZLR9afv2Vq8N5O/g== Date: Mon, 24 Jun 2019 11:18:54 +0000 Message-ID: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-originating-ip: [178.164.138.151] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b65171a5-c4aa-47bd-6eea-08d6f895be2f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM5PR0701MB2722; x-ms-traffictypediagnostic: AM5PR0701MB2722: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2512; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(376002)(136003)(199004)(189003)(76116006)(5640700003)(1730700003)(2351001)(305945005)(7736002)(71190400001)(86362001)(99286004)(7696005)(25786009)(6116002)(316002)(6436002)(9686003)(2906002)(3846002)(55016002)(102836004)(558084003)(53936002)(2501003)(74316002)(66946007)(52536014)(26005)(45776006)(68736007)(6506007)(478600001)(256004)(186003)(66066001)(486006)(66446008)(5660300002)(8676002)(33656002)(64756008)(66476007)(6916009)(66556008)(81156014)(73956011)(81166006)(476003)(14454004)(8936002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2722; H:AM5PR0701MB2289.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: FDbLeTVg3pz6zkWWlrl3J+a+rhO86o+b3KHj92uSRrP0kP+O8Fzg8VFvPzCJ4X31snkzxSD2V21uJy8sBF4XWHxiVqMxzfAXKz/x7sTXCqR9zOpw+5K5Bw4uFvexyY6TYtX/88Y52CLsd9UjSehrbxoLVrTz+EJYir7j8xKZ4MzVDzvr+n69zg+GSO3AJIots8K3rAm4q45sWiv62Td0RDzs4hNB025hahGhun8xW7AElACXqePL4bAuDw0n4/JSYYCu9h4eIuL9iNWA82t/6tPAon+65rJuQFrYtrLSF2I/A2VQorXBO5rW/U5reB9dBuM13dOTbS5+2fOGNnPF1cOYkWNLrUglCzMrj/oAbM78zFEJiWg122pBpTXQFlQCle3Jlu1K3aj+YbkaM0dwhLBkEgJZW7vVg8IrSWbeK5M= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b65171a5-c4aa-47bd-6eea-08d6f895be2f X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 11:18:54.2979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: balazs.a.varga@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2722 Archived-At: Subject: [Detnet] Agenda - DetNet Data Plane drafts progressing X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 11:18:59 -0000 Hi, Preliminary agenda for the today's data plane call: - Framework - MPLS - MPLS over UDP/IP - IP over MPLS - Other ... Cheers Bala'zs From nobody Tue Jun 25 13:51:32 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DFF1202EB for ; Tue, 25 Jun 2019 13:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oagUw7sAPM7J for ; Tue, 25 Jun 2019 13:51:29 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712E012012A for ; Tue, 25 Jun 2019 13:51:29 -0700 (PDT) Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id DD7C51AC0E0 for ; Tue, 25 Jun 2019 14:31:28 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id fs6ChM3eMXFO5fs6Cho96c; Tue, 25 Jun 2019 14:31:28 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ibMwopXGEtvL9BcV9N2tPe01IQOhTCJ5KM67SPSMsg8=; b=dllRtlIvphF9gUjB6X9sSoF7IF 6rPfv3PZ6ltJRP5qvXegUQDbbIVnOsbt7uYVzsroiqWQErckEJ82qtta5NQiOclwaU3JfR4PoqRmE 54LxFwqEQ7gOPUxdXvtcNu9Aq; Received: from [127.0.0.1] (port=41923 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hfs6C-002gte-I2; Tue, 25 Jun 2019 14:31:28 -0600 To: Norman Finn , Le Boudec Jean-Yves , Mohammadpour Ehsan , zhangjiayi11@huawei.com, =?UTF-8?Q?Bal=c3=a1zs_Varga_A?= , =?UTF-8?Q?J=c3=a1nos_Farkas?= Cc: DetNet WG From: Lou Berger Message-ID: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> Date: Tue, 25 Jun 2019 16:31:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1hfs6C-002gte-I2 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:41923 X-Source-Auth: lberger@labn.net X-Email-Count: 12 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [Detnet] Regarding IPR on draft-finn-detnet-bounded-latency-04 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 20:51:32 -0000 Authors, Contributors, WG, As part of preparation for WG Adoption Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, DetNet WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Tue Jun 25 16:20:01 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2EC120123 for ; Tue, 25 Jun 2019 16:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nfinnconsulting.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAX5Kl2WUZUS for ; Tue, 25 Jun 2019 16:19:56 -0700 (PDT) Received: from us2-ob2-1.mailhostbox.com (us2-ob2-1.mailhostbox.com [162.210.70.55]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB79120086 for ; Tue, 25 Jun 2019 16:19:55 -0700 (PDT) Received: from [192.168.1.105] (ip72-220-192-145.sd.sd.cox.net [72.220.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nfinn@nfinnconsulting.com) by us2.outbound.mailhostbox.com (Postfix) with ESMTPSA id DA8A77826F5; Tue, 25 Jun 2019 23:19:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nfinnconsulting.com; s=20161121; t=1561504794; bh=k+T1jIFSqS09M9D4viNEYeV4vS9UJ7M8nqgh5j3Cr/o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=fdXw99ameTEHpGVZtDbzC86LpdpBxnAq764puUUj+P4bBYZjI40kRx3S5J+4wMGdY 9UFDzU9mXcjesWpaIDeSycnZd9rW/y6UWVYsDVxdQLxFpyStw07YKRWpWEtn9vChlV 3iP0weBcmH3Pa3g2e2bAvSPTIFmKbhOVYrQ85AnQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Norman Finn In-Reply-To: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> Date: Tue, 25 Jun 2019 16:19:51 -0700 Cc: Jean-Yves Le Boudec , Mohammadpour Ehsan , zhangjiayi11@huawei.com, =?utf-8?B?IkJhbMOhenMgQS4gVmFyZ2Ei?= , =?utf-8?Q?J=C3=A1nos_Farkas?= , DetNet WG Content-Transfer-Encoding: quoted-printable Message-Id: <64EEAC1E-0A90-4D09-8F54-D1440036FF7B@nfinnconsulting.com> References: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=epKv9shX c=1 sm=1 tr=0 a=dvCML1Ec+JVo0xWS3GsMJA==:117 a=dvCML1Ec+JVo0xWS3GsMJA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=c309fuS5OrV3TuQLdlEA:9 a=QEXdDO2ut3YA:10 a=Ig16_jW4bggA:10 Archived-At: Subject: Re: [Detnet] Regarding IPR on draft-finn-detnet-bounded-latency-04 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 23:20:00 -0000 No, I=E2=80=99m not aware of any IPR that applies to this draft. =E2=80=94 Norm > On Jun 25, 2019, at 13:31, Lou Berger wrote: >=20 > Authors, Contributors, WG, >=20 > As part of preparation for WG Adoption > Are you aware of any IPR that applies to drafts identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. >=20 > If you are on the WG email list or attend WG meetings but are not = listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed = above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > DetNet WG Chairs >=20 > PS Please include all listed in the headers of this message in your > response. >=20 >=20 >=20 From nobody Tue Jun 25 19:09:01 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD46F12013E; Tue, 25 Jun 2019 19:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVVLB0R-Eyun; Tue, 25 Jun 2019 19:08:59 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720132.outbound.protection.outlook.com [40.107.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D066B1200B3; Tue, 25 Jun 2019 19:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TKI2O41vnUKW0Zyj+idLTqOfjJ9LKMcWz/mCu0ayUFU=; b=LGsjdT2TIssbTOeDp795lcvvJxNVS3BdJ/aDUn3SZ5j1l4ZJUn/xUA4lrGImItR2v+DI0YfMynewSbelOu/bKqnIFNYMQZu2N3DlaIH4wMWyElm2D3jfs2Plz6/Cj6H3XktbrCqZ19LAYDcppaBqjAqhBtMoVTfI2A6qcJljaqA= Received: from BYAPR06MB4325.namprd06.prod.outlook.com (52.135.240.140) by BYAPR06MB4231.namprd06.prod.outlook.com (52.135.238.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Wed, 26 Jun 2019 02:08:57 +0000 Received: from BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::9566:ed8c:4256:a44d]) by BYAPR06MB4325.namprd06.prod.outlook.com ([fe80::9566:ed8c:4256:a44d%7]) with mapi id 15.20.2008.014; Wed, 26 Jun 2019 02:08:57 +0000 From: "Grossman, Ethan A." To: detnet WG CC: "detnet-chairs@ietf.org" Thread-Topic: IETF 105 Montreal - DetNet Meeting Slot Requests Thread-Index: AdUrwvzy6dH6Wk5tTwukWxF+i1QKPw== Date: Wed, 26 Jun 2019 02:08:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGVhZ3Jvc1xhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTU5YjFjY2U1LTk3YjctMTFlOS1hMjg3LWFjYmMzMjdhNTFjNlxhbWUtdGVzdFw1OWIxY2NlNi05N2I3LTExZTktYTI4Ny1hY2JjMzI3YTUxYzZib2R5Lmh0bWwiIHN6PSI1NjMyIiB0PSIxMzIwNTk4ODUzNjE2NDQ3ODQiIGg9InFmeExyUHVlR0RPT3p6TlRCaEpVZzFWWERVcz0iIGlkPSIiIGJsPSIwIiBibz0iMSIvPjwvbWV0YT4= authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6e018eda-3d24-49f5-7d99-08d6f9db3f50 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR06MB4231; x-ms-traffictypediagnostic: BYAPR06MB4231: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(136003)(39860400002)(346002)(376002)(199004)(189003)(54014002)(53754006)(7696005)(478600001)(236005)(9686003)(606006)(74316002)(102836004)(52536014)(68736007)(6436002)(8936002)(3846002)(790700001)(256004)(6306002)(55016002)(316002)(476003)(486006)(33656002)(5660300002)(71200400001)(14444005)(71190400001)(81166006)(66066001)(81156014)(99286004)(8676002)(6116002)(7736002)(86362001)(4326008)(26005)(4744005)(54896002)(966005)(14454004)(9326002)(6506007)(2906002)(73956011)(66946007)(66446008)(66476007)(66556008)(186003)(450100002)(25786009)(53936002)(6916009)(76116006)(64756008); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR06MB4231; H:BYAPR06MB4325.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: tzL4pjM5NvahU2bm27qMnyrwwQYEpbIzVeulLUYwHsyWy+Ih3iDMWb1uqe4Tpn+gaRlhVDOyoOkiMxvGxsRNuYU5aiCf9hIFxNGuXVHHzWHrYYGqkDTQNE/5d3Sxz8rdwAAjgu7j8/HYzS7JY48RhHct9jTSthgODR4R/b6wIJZj1r8ernrsJzFAZek5VQo9HcBlhBTCJSuUhVE04OMAiFv4aGERndBnbAwrosKQ+mQiwD9HUlDjoej3TvA9lYPnemcicgD4cp0RAs1osx/4c8K8HFVNobAPKU04Q456sRRGnBy4QVBBaf7JCH6ou8t3j8XnLpyNYMSG41usWlEJHFEuSjZE7SjBHLv207PmjmAGq1sfGUVop+bK5dXvCXxrlT6OcAP2vSkXwiXfUUG5slY9OSpvQZmm3NjucoQOjso= Content-Type: multipart/alternative; boundary="_000_BYAPR06MB43251380FB1BA91A28C9C00AC4E20BYAPR06MB4325namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6e018eda-3d24-49f5-7d99-08d6f9db3f50 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 02:08:57.3728 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eagros@dolby.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4231 Archived-At: Subject: [Detnet] IETF 105 Montreal - DetNet Meeting Slot Requests X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 02:09:01 -0000 --_000_BYAPR06MB43251380FB1BA91A28C9C00AC4E20BYAPR06MB4325namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, The IETF 105 Montreal agenda has been posted: https://datatracker.ietf.org/meeting/105/agenda/ We're scheduled to meet: Wednesday, July 24, 2019 (EDT) 13:30-15:30 Wednesday Afternoon session I And 15:50-16:50 Wednesday Afternoon session II In Centre Ville Please send any slot requests to the chairs email alias (see above) no late= r than Monday July 8, 5pm Pacific Daylight Time (-07). Please include draf= t names(s), presenter and desired slot length. Please keep in mind that pr= iority for presentation slots is given to WG drafts and other drafts/topics= discussed on the mailing list. The cutoff date for draft submissions is also Monday July 8, see https://da= tatracker.ietf.org/meeting/important-dates/ I can only attend remotely, so I'll miss seeing y'all in person. Ethan (as DetNet WG Secretary). --_000_BYAPR06MB43251380FB1BA91A28C9C00AC4E20BYAPR06MB4325namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

The IETF 105 Montreal agenda ha= s been posted:

 

https://datatracker.ietf.org/meeting/105/agenda/

 

We're scheduled to meet:

Wednesday, July 24, 2019 (EDT)<= o:p>

13:30-15:30 Wednesday Afternoon= session I

And

15:50-16:50 Wednesday Afternoon= session II

In Centre Ville

 

Please send any slot requests t= o the chairs email alias (see above) no later than Monday July 8, 5pm = Pacific Daylight Time (-07).  Please include draft names(s), presenter and desired slot length.  Please keep in min= d that priority for presentation slots is given to WG drafts and other= drafts/topics discussed on the mailing list.

 

The cutoff date for draft submi= ssions is also Monday July 8, see https://datatracker.ietf.org/m= eeting/important-dates/<= /o:p>

 

I can only attend remotely, so = I’ll miss seeing y’all in person.

Ethan (as DetNet WG Secretary).=

 

--_000_BYAPR06MB43251380FB1BA91A28C9C00AC4E20BYAPR06MB4325namp_-- From nobody Tue Jun 25 20:33:08 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2A812060E for ; Tue, 25 Jun 2019 20:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6e742ValQ8q for ; Tue, 25 Jun 2019 20:33:04 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476DD1204AE for ; Tue, 25 Jun 2019 20:33:04 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 95A9A155046560BBAE24; Wed, 26 Jun 2019 04:33:02 +0100 (IST) Received: from dggeme701-chm.china.huawei.com (10.1.199.97) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 26 Jun 2019 04:33:01 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme701-chm.china.huawei.com (10.1.199.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 26 Jun 2019 11:32:59 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1591.008; Wed, 26 Jun 2019 11:32:59 +0800 From: "qiangli (D)" To: "detnet@ietf.org" CC: "shunsuke.homma.fp@hco.ntt.co.jp" , "peter.j.willis@bt.com" , Liang GENG Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwAA= Date: Wed, 26 Jun 2019 03:32:59 +0000 Message-ID: References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> In-Reply-To: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: multipart/alternative; boundary="_000_cd7bbcc689ad4d1e80bb034fab603f65huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 03:33:06 -0000 --_000_cd7bbcc689ad4d1e80bb034fab603f65huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GENG Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= .j.willis@bt.com; shunsuke.homma.fp@hco.ntt.c= o.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_cd7bbcc689ad4d1e80bb034fab603f65huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The Req. 2.2 discusses= that DetNet should be able to tolerate a certain degree of clock jitter &a= mp; 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 &a= mp; wander do you expect?

 

BTW, we are going to a= sk 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:detnet-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Monday, June 17, 2019 4:11 PM
To: detnet@ietf.org
Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GE= NG <liang.geng@hotmail.com>
Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency= -02 revised for comments

 

Hi all,

 

This version has colle= cted 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 a= re highly appropriated.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Req. 1: Must support t= he dynamic creation, modification and deletion of deterministic services

 

Req. 2.1: Should suppo= rt asynchronous clocks across domains

Req. 2.2 : Should tole= rate a certain of clock jitter & wander within a clock synchronous doma= in

 

Req. 3: Must support I= nter-Continental propagation delay

 

Req. 4: Should have se= lf-monitoring capability

 

Req. 5: Should be robu= st against denial of service attacks

 

Req. 6: Must tolerate = failures of links or nodes and topology changes

 

Req. 7: Must be scalab= le

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

From: = Liang GENG [mailto:liang.geng@hotmail.com]
Sent: Tuesday, June 11, 2019 11:53 AM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: Black, David <David.Black@dell.com>; peter= .j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@huawei.com>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised f= or comments

 

Dear all,

 

Since IETF 104, we have carefully revised draft-geng-detnet-r= equirements-bounded-latency-02 according to received comments. The latest 02 version was uploaded and available online <= span lang=3D"EN-US">https://datatracker.ietf.org/doc/dra= ft-geng-detnet-requirements-bounded-latency/. 

 

This new version collects more technical, operational and man= agement requirements of deploying deterministic latency service on layer 3 networks from the perspective of various servic= e providers.

 

Comments are welcome!

 

Best regards,

Liang Geng on behavior of co-authors

 

 

 

--_000_cd7bbcc689ad4d1e80bb034fab603f65huaweicom_-- From nobody Tue Jun 25 23:24:02 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35C712016F for ; Tue, 25 Jun 2019 23:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7POjV3jMdIlA for ; Tue, 25 Jun 2019 23:23:57 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60080.outbound.protection.outlook.com [40.107.6.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5611200B4 for ; Tue, 25 Jun 2019 23:23:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=p9SoBOBsS2VC289b0OniFT/o92L3eMzt8TheAV4AFKKWJcTxO9YW2GFt8BsBotUpEDQEmmzsZ10gd4JD72YuArRNFYHf/WLuqQS0ASx8Z7cAndIbLMvrFWcLVy+OKiiqd82iXtqwStBp4/TiEKxbVWVWab4SEHELEXnEf27rEwE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D6+jl7xSIGa4INA2m7jLJ2b2SDK20dxES/kWHkoNnW4=; b=J3y28dn/RTJCZcJ8oa+NFHFAT5/OMzdZ3GGIs7gkX3XhQAPJ3cwnJn8J5ELybt6I7b2FPGOMp0xtDtDEpbAG3TLRb4aKWs4EAPRhgXHwRvCroJYWQ4G4bcFhSlrhkZW27hfb6BpNTjp40hXN2XACc2VKX6o7lE6Nv8FISmEq/1g= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D6+jl7xSIGa4INA2m7jLJ2b2SDK20dxES/kWHkoNnW4=; b=T7BDaL9soC8WgfCnfCXUdQLLaiKvkOuvxTt77efQZvDXkPS2H/fI/rrSoxrlB/fy13H02GDJJgVNGsMl4ZAbyxI1pM70p5LSxVO+wPcir+z2TQR6my7g3kcoI/dW0L9PlTuURJ1uxUYITteGGEuP1QyWW4v6fCaTbEKM3XVeOX4= Received: from AM5PR0701MB2289.eurprd07.prod.outlook.com (10.169.152.148) by AM5PR0701MB2514.eurprd07.prod.outlook.com (10.169.153.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.12; Wed, 26 Jun 2019 06:23:55 +0000 Received: from AM5PR0701MB2289.eurprd07.prod.outlook.com ([fe80::d06:2c54:377:b9b5]) by AM5PR0701MB2289.eurprd07.prod.outlook.com ([fe80::d06:2c54:377:b9b5%3]) with mapi id 15.20.2008.017; Wed, 26 Jun 2019 06:23:54 +0000 From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= To: Lou Berger , Norman Finn , Le Boudec Jean-Yves , Mohammadpour Ehsan , "zhangjiayi11@huawei.com" , Janos Farkas CC: DetNet WG Thread-Topic: Regarding IPR on draft-finn-detnet-bounded-latency-04 Thread-Index: AQHVK5Z8MLzoEFq/N0yRCYfCQ4iJG6ateCwA Date: Wed, 26 Jun 2019 06:23:54 +0000 Message-ID: References: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> In-Reply-To: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 39ac2797-6ca2-46aa-6ad9-08d6f9fedd57 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM5PR0701MB2514; x-ms-traffictypediagnostic: AM5PR0701MB2514: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(136003)(376002)(39860400002)(199004)(189003)(13464003)(33656002)(110136005)(7736002)(6246003)(25786009)(186003)(6636002)(256004)(486006)(305945005)(2906002)(8676002)(71200400001)(74316002)(85182001)(5660300002)(81166006)(81156014)(446003)(6436002)(4326008)(476003)(71190400001)(7696005)(52536014)(66476007)(966005)(66946007)(73956011)(76176011)(99286004)(76116006)(11346002)(14454004)(68736007)(66446008)(64756008)(66556008)(229853002)(85202003)(66066001)(2501003)(102836004)(86362001)(55016002)(6116002)(9686003)(6306002)(26005)(316002)(8936002)(53936002)(53546011)(6506007)(3846002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2514; H:AM5PR0701MB2289.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Htixp79bTcenlT3ASy6R4viT05ditrK4eYs6NO5mmBB4c98yjn9APb2feS6zEwGH5hgRU50XAhYM84duaTrcMU+zRjpN03A7OhDDQKIqOqearuDLV3uZMbYOqL0p+8HqO/5vp1sa9Xb1uPiA6WNOLJGGtGtrd+oZkfMOPLQz4uQeYHYJFsKB+yXTd4i2FWme5IoUNaZORzOx6sEFme+33OgsHH6UYuI0rSllfjO+v1FOsIkkRhB3/Y7zV91yL7K8QKFQbvN8NyU4/zwXzIG/cmbEb+GufUYp00V9RhRReRLPMddErfDz9xyo5XRFncy3LSGCtvY4uQF8qPm/rXG6yXPhYvh81HETM4K1PjheX+s1i6aMKKQyYcTnCiQEqHxR2oQQoZI4UAEIPOpk4u5iiQDpF4qhIOChAoBL2LRI724= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 39ac2797-6ca2-46aa-6ad9-08d6f9fedd57 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 06:23:54.8727 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: balazs.a.varga@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2514 Archived-At: Subject: Re: [Detnet] Regarding IPR on draft-finn-detnet-bounded-latency-04 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 06:24:01 -0000 Tm8sIEnigJltIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0 Lg0KDQpDaGVlcnMgQmFsYSd6cw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gDQpTZW50OiBUdWVzZGF5LCBKdW5lIDI1LCAy MDE5IDEwOjMxIFBNDQpUbzogTm9ybWFuIEZpbm4gPG5maW5uQG5maW5uY29uc3VsdGluZy5jb20+ OyBMZSBCb3VkZWMgSmVhbi1ZdmVzIDxqZWFuLXl2ZXMubGVib3VkZWNAZXBmbC5jaD47IE1vaGFt bWFkcG91ciBFaHNhbiA8ZWhzYW4ubW9oYW1tYWRwb3VyQGVwZmwuY2g+OyB6aGFuZ2ppYXlpMTFA aHVhd2VpLmNvbTsgQmFsw6F6cyBWYXJnYSBBIDxiYWxhenMuYS52YXJnYUBlcmljc3Nvbi5jb20+ OyBKYW5vcyBGYXJrYXMgPEphbm9zLkZhcmthc0Blcmljc3Nvbi5jb20+DQpDYzogRGV0TmV0IFdH IDxkZXRuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWZpbm4t ZGV0bmV0LWJvdW5kZWQtbGF0ZW5jeS0wNA0KDQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0K DQpBcyBwYXJ0IG9mIHByZXBhcmF0aW9uIGZvciBXRyBBZG9wdGlvbg0KQXJlIHlvdSBhd2FyZSBv ZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdHMgaWRlbnRpZmllZCBhYm92ZT8NCg0KUGxl YXNlIHN0YXRlIGVpdGhlcjoNCg0KIk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBh cHBsaWVzIHRvIHRoaXMgZHJhZnQiDQpvcg0KIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFw cGxpZXMgdG8gdGhpcyBkcmFmdCINCg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3Nl ZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4Nzks IDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/DQoNCklmIHllcyB0byB0aGUgYWJvdmUs IHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2Vk IGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCm9yDQoiTm8sIHRoZSBJUFIgaGFz IG5vdCBiZWVuIGRpc2Nsb3NlZCINCg0KSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUg YW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsgYXBwcm9wcmlhdGUuDQoNCklmIHlvdSBh cmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3 ZXIgdGhlIGFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdo ZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1 bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2Ug aGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9y LiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdF J1MgVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5k IFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0 b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVURiBJUFIg cnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUg YXdhcmUgb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVm cmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9u IHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBw bGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQgaHR0cDovL3RyYWMudG9vbHMuaWV0 Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQoNClRoYW5r IHlvdSwNCkRldE5ldCBXRyBDaGFpcnMNCg0KUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBp biB0aGUgaGVhZGVycyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91ciByZXNwb25zZS4NCg0KDQoNCg== From nobody Wed Jun 26 00:29:11 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3491200EC for ; Wed, 26 Jun 2019 00:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx_cGwAW9FSO for ; Wed, 26 Jun 2019 00:29:07 -0700 (PDT) Received: from dish-sg.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp [202.19.227.74]) by ietfa.amsl.com (Postfix) with ESMTP id C37A4120058 for ; Wed, 26 Jun 2019 00:29:06 -0700 (PDT) X-dD-Source: Outbound Received: from zssg-mailmd104.ddreams.local (zssg-mailmd900.ddreams.local [10.160.172.63]) by zssg-mailou104.ddreams.local (Postfix) with ESMTP id 00C801200FA; Wed, 26 Jun 2019 16:29:06 +0900 (JST) Received: from zssg-mailmf106.ddreams.local (zssg-mailmf900.ddreams.local [10.160.172.84]) by zssg-mailmd104.ddreams.local (dDREAMS) with ESMTP id <0PTP00Q9E3GHOF10@dDREAMS>; Wed, 26 Jun 2019 16:29:05 +0900 (JST) Received: from zssg-mailmf106.ddreams.local (unknown [127.0.0.1]) by zssg-mailmf106.ddreams.local (Postfix) with ESMTP id D23467E6032; Wed, 26 Jun 2019 16:29:05 +0900 (JST) Received: from zssg-mailmf106.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CFE968E6061; Wed, 26 Jun 2019 16:29:05 +0900 (JST) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id C485B8E6055; Wed, 26 Jun 2019 16:29:05 +0900 (JST) X-IMSS-HAND-OFF-DIRECTIVE: localhost:10026 Received: from zssg-mailmf106.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AEAF58E6055; Wed, 26 Jun 2019 16:29:04 +0900 (JST) Received: from zssg-mailua105.ddreams.local (unknown [10.160.172.62]) by zssg-mailmf106.ddreams.local (Postfix) with ESMTP; Wed, 26 Jun 2019 16:29:04 +0900 (JST) Received: from RDSVVDI0392 (unknown [10.171.80.137]) by zssg-mailua105.ddreams.local (dDREAMS) with ESMTPA id <0PTP001LT3FYZ2F0@dDREAMS>; Wed, 26 Jun 2019 16:28:56 +0900 (JST) From: Shunsuke Homma References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> In-reply-to: Date: Wed, 26 Jun 2019 16:28:46 +0900 Message-id: <005b01d52bf0$ca9e6020$5fdb2060$@hco.ntt.co.jp> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_005C_01D52C3C.3A887920" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQMnmUkp2H0Pi7SVpr3C7kb4R5YXsAHemyVbAl6tjtqj5sSDcA== Content-language: ja To: "'qiangli (D)'" , detnet@ietf.org Cc: peter.j.willis@bt.com, 'Liang GENG' X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 07:29:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005C_01D52C3C.3A887920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Wednesday, June 26, 2019 12:33 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; 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 From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GENG 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:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David < David.Black@dell.com>; peter..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) < qiangli3@huawei.com> 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 ------=_NextPart_000_005C_01D52C3C.3A887920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:detnet-bounces@ietf.org] On Behalf Of qiangli = (D)
Sent: Wednesday, June 26, 2019 12:33 PM
To: = detnet@ietf.org
Cc: shunsuke.homma.fp@hco.ntt.co.jp; = peter.j.willis@bt.com; 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

 

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of = qiangli (D)
Sent: Monday, June 17, 2019 4:11 = PM
To: detnet@ietf.org
Cc: = shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GENG = <liang.geng@hotmail.com>
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.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina = QIANG

 

From: Liang GENG [mailto:lian= g.geng@hotmail.com]
Sent: Tuesday, June 11, 2019 11:53 = AM
To: detnet@ietf= .org<= br>Cc: Black, David <David.Black= @dell.com>; peter..j.wi= llis@bt.com; shunsuke.ho= mma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@hu= awei.com>
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://dat= atracker.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

 

 

 

------=_NextPart_000_005C_01D52C3C.3A887920-- From nobody Wed Jun 26 00:46:09 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64411120179 for ; Wed, 26 Jun 2019 00:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyYSTXwed6wm for ; Wed, 26 Jun 2019 00:46:04 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50047.outbound.protection.outlook.com [40.107.5.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F210912011E for ; Wed, 26 Jun 2019 00:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NB1tp3yQ5TYkeJXsqbAq0Hby/vt9Otxd5i7YaHeC88E=; b=eqU0Nu80cyKl7s3Zdsbj74H0op73kVfG90upDGtjPXsJRSNBsASmqCwGzm6wmBsK4L6/Jl0QqJcUdFxM17BF6ywp+qt9Sc5HMJKscpziEqXJEBwU29h39rTKZOcSyrW2xUKCsEQ52giI1D7Y3IKPxmztsg4Cuv7uvTYHB1NXR1c= Received: from VI1PR07MB3440.eurprd07.prod.outlook.com (10.175.244.142) by VI1PR07MB4173.eurprd07.prod.outlook.com (20.176.6.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.12; Wed, 26 Jun 2019 07:46:01 +0000 Received: from VI1PR07MB3440.eurprd07.prod.outlook.com ([fe80::8d75:e94f:fb0b:9d5]) by VI1PR07MB3440.eurprd07.prod.outlook.com ([fe80::8d75:e94f:fb0b:9d5%7]) with mapi id 15.20.2032.012; Wed, 26 Jun 2019 07:46:01 +0000 From: Janos Farkas To: Lou Berger , Norman Finn , Le Boudec Jean-Yves , Mohammadpour Ehsan , "zhangjiayi11@huawei.com" , =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= CC: DetNet WG Thread-Topic: Regarding IPR on draft-finn-detnet-bounded-latency-04 Thread-Index: AQHVK5Z/dBpjn4CnbUyMv4SKJ3ATZ6atjxJA Date: Wed, 26 Jun 2019 07:46:01 +0000 Message-ID: References: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> In-Reply-To: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Janos.Farkas@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bbbb8b40-6303-402e-2ce4-08d6fa0a55ac x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1PR07MB4173; x-ms-traffictypediagnostic: VI1PR07MB4173: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(136003)(376002)(346002)(39860400002)(366004)(199004)(13464003)(189003)(6506007)(86362001)(76116006)(316002)(6636002)(53546011)(7696005)(305945005)(7736002)(6436002)(72206003)(26005)(478600001)(229853002)(9686003)(186003)(8936002)(6246003)(6306002)(68736007)(102836004)(76176011)(4326008)(74316002)(966005)(53936002)(81156014)(6116002)(476003)(14454004)(52536014)(81166006)(446003)(73956011)(71190400001)(8676002)(55016002)(66066001)(2501003)(71200400001)(2906002)(99286004)(5660300002)(486006)(25786009)(66476007)(33656002)(66946007)(256004)(110136005)(11346002)(66556008)(64756008)(66446008)(3846002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4173; H:VI1PR07MB3440.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MILoz11qY/htWzb8P4FrlKiYpbYpbiwuVn2JDTMDopMFBFDwT5hwyq9ea5uSA5hXAWI0sQAq+S41eAQMg2t4W+fb5FQWo0gWMf0IpT0yAYREaxqNveXi6qHzUZuqmCLoznvVvVvjH7C231kg4tUnO4yLq2BURkkWGFFEwwoGjeu3KZPwff6tjHTjIhTKxNgRzHq+jfL4+eB3jFVAPFBgS8EuiFQjheLwqid3hILAoHJ6e70LeeKhluy0omHoUqUGTlQW+yoZDK/gXECurtIvpdwxvXGKymjsltyihwXnqHkXsEVmI4Xq7hQc91QNFI17Xdmap+j9e1LaTyYlVFowyYZ+BhYRbO7CQz7sdy1SuJ1CKxcVkyRnLUBoVrbdC6U5FPJvkud0G4GkoLJeU2t4msdAEUG2eVTiL3MxO4M26lE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: bbbb8b40-6303-402e-2ce4-08d6fa0a55ac X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 07:46:01.2448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Janos.Farkas@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4173 Archived-At: Subject: Re: [Detnet] Regarding IPR on draft-finn-detnet-bounded-latency-04 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 07:46:07 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K UmVnYXJkcywNCkphbm9zDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3Ug QmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiANClNlbnQ6IFR1ZXNkYXksIEp1bmUgMjUsIDIwMTkg MTA6MzEgUE0NClRvOiBOb3JtYW4gRmlubiA8bmZpbm5AbmZpbm5jb25zdWx0aW5nLmNvbT47IExl IEJvdWRlYyBKZWFuLVl2ZXMgPGplYW4teXZlcy5sZWJvdWRlY0BlcGZsLmNoPjsgTW9oYW1tYWRw b3VyIEVoc2FuIDxlaHNhbi5tb2hhbW1hZHBvdXJAZXBmbC5jaD47IHpoYW5namlheWkxMUBodWF3 ZWkuY29tOyBCYWzDoXpzIFZhcmdhIEEgPGJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbT47IEph bm9zIEZhcmthcyA8SmFub3MuRmFya2FzQGVyaWNzc29uLmNvbT4NCkNjOiBEZXROZXQgV0cgPGRl dG5ldEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtZmlubi1kZXRu ZXQtYm91bmRlZC1sYXRlbmN5LTA0DQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csDQoNCkFz IHBhcnQgb2YgcHJlcGFyYXRpb24gZm9yIFdHIEFkb3B0aW9uDQpBcmUgeW91IGF3YXJlIG9mIGFu eSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0cyBpZGVudGlmaWVkIGFib3ZlPw0KDQpQbGVhc2Ug c3RhdGUgZWl0aGVyOg0KDQoiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxp ZXMgdG8gdGhpcyBkcmFmdCINCm9yDQoiWWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGll cyB0byB0aGlzIGRyYWZ0Ig0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGlu IGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2 OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxl YXNlIHN0YXRlIGVpdGhlcjoNCg0KIlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4g Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0Kb3INCiJObywgdGhlIElQUiBoYXMgbm90 IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkg YWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS4NCg0KSWYgeW91IGFyZSBs aXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0 aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhl ciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50 IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMg YmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQgY29udHJpYnV0b3IuIE5P VEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUyBU TyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cg bWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwg d2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxl cyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2Fy ZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWlu IGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVs YXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFz ZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCBodHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0KVGhhbmsgeW91 LA0KRGV0TmV0IFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRo ZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0KDQoNCg0K From nobody Wed Jun 26 00:57:29 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EE0120223 for ; Wed, 26 Jun 2019 00:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvPnlFEwkMiH for ; Wed, 26 Jun 2019 00:57:24 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9382312020A for ; Wed, 26 Jun 2019 00:57:24 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 59CD09881B4F7B014B5D; Wed, 26 Jun 2019 08:57:22 +0100 (IST) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 26 Jun 2019 08:57:20 +0100 Received: from DGGEMM505-MBX.china.huawei.com ([169.254.1.3]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Wed, 26 Jun 2019 15:57:16 +0800 From: "Zhangjiayi (Jiayi)" To: Lou Berger CC: DetNet WG , Norman Finn , "Le Boudec Jean-Yves" , Mohammadpour Ehsan , =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= , =?utf-8?B?SsOhbm9zIEZhcmthcw==?= Thread-Topic: Regarding IPR on draft-finn-detnet-bounded-latency-04 Thread-Index: AQHVK5fHP4ZykRUGO0ev0yp3szl/FqatkVNA Date: Wed, 26 Jun 2019 07:57:16 +0000 Message-ID: References: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> In-Reply-To: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.218.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] Regarding IPR on draft-finn-detnet-bounded-latency-04 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 07:57:27 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K DQpSZWdhcmRzLA0KSmlheWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExv dSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANClNlbnQ6IFdlZG5lc2RheSwgSnVu ZSAyNiwgMjAxOSA0OjMxIEFNDQpUbzogTm9ybWFuIEZpbm4gPG5maW5uQG5maW5uY29uc3VsdGlu Zy5jb20+OyBMZSBCb3VkZWMgSmVhbi1ZdmVzIDxqZWFuLXl2ZXMubGVib3VkZWNAZXBmbC5jaD47 IE1vaGFtbWFkcG91ciBFaHNhbiA8ZWhzYW4ubW9oYW1tYWRwb3VyQGVwZmwuY2g+OyBaaGFuZ2pp YXlpIChKaWF5aSkgPHpoYW5namlheWkxMUBodWF3ZWkuY29tPjsgQmFsw6F6cyBWYXJnYSBBIDxi YWxhenMuYS52YXJnYUBlcmljc3Nvbi5jb20+OyBKw6Fub3MgRmFya2FzIDxqYW5vcy5mYXJrYXNA ZXJpY3Nzb24uY29tPg0KQ2M6IERldE5ldCBXRyA8ZGV0bmV0QGlldGYub3JnPg0KU3ViamVjdDog UmVnYXJkaW5nIElQUiBvbiBkcmFmdC1maW5uLWRldG5ldC1ib3VuZGVkLWxhdGVuY3ktMDQNCg0K QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiBwcmVwYXJhdGlvbiBmb3Ig V0cgQWRvcHRpb24NCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJh ZnRzIGlkZW50aWZpZWQgYWJvdmU/DQoNClBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJObywgSSdt IG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0Kb3INCiJZ ZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNv LCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBS IHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFp bHMpPw0KDQpJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiWWVz LCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIg cnVsZXMiDQpvcg0KIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIHlv dSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRo aW5rIGFwcHJvcHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhv ciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRv IHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9m IGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUg bmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBh dXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBP RiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTIFRPIExJTkVTLg0KDQpJZiB5b3UgYXJlIG9u IHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0 ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2Js aWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRv IG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4g SUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFu eSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQg SVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJv dmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0lu dGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpEZXROZXQgV0cgQ2hhaXJzDQoNClBT IFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdl IGluIHlvdXIgcmVzcG9uc2UuDQoNCg0KDQo= From nobody Wed Jun 26 00:59:10 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E91512022B for ; Wed, 26 Jun 2019 00:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrB2piWNIqdI for ; Wed, 26 Jun 2019 00:59:05 -0700 (PDT) Received: from smtp5.epfl.ch (smtp5.epfl.ch [IPv6:2001:620:618:1e0:1:80b2:e034:1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E6A120194 for ; Wed, 26 Jun 2019 00:59:04 -0700 (PDT) Received: (qmail 3071 invoked by uid 107); 26 Jun 2019 07:59:01 -0000 Received: from ax-snat-224-187.epfl.ch (HELO ewa12.intranet.epfl.ch) (192.168.224.187) (TLS, AES256-GCM-SHA384 cipher) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPS; Wed, 26 Jun 2019 09:59:01 +0200 X-EPFL-Auth: O6o9kYXRWYl0IRXP5P5anWocxgRd472Nk36r2NJarivl6cV0ELw= Received: from ewa02.intranet.epfl.ch (128.178.224.159) by ewa12.intranet.epfl.ch (128.178.224.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 26 Jun 2019 09:59:01 +0200 Received: from ewa02.intranet.epfl.ch ([fe80::553e:eb20:777f:39ba]) by ewa02.intranet.epfl.ch ([fe80::553e:eb20:777f:39ba%5]) with mapi id 15.01.1713.004; Wed, 26 Jun 2019 09:59:01 +0200 From: Mohammadpour Ehsan To: Lou Berger CC: DetNet WG , Norman Finn , "Le boudec Jean-Yves" , =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= , =?utf-8?B?SsOhbm9zIEZhcmthcw==?= , "Zhangjiayi (Jiayi)" Thread-Topic: Regarding IPR on draft-finn-detnet-bounded-latency-04 Thread-Index: AQHVK/TLWGdRRuiV+EisF4r0fzyrnKatcJeA Date: Wed, 26 Jun 2019 07:59:01 +0000 Message-ID: <3B9E4778-58B6-4B51-AE4C-AFAE8B77C53C@epfl.ch> References: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> In-Reply-To: Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.179.197.232] Content-Type: multipart/alternative; boundary="_000_3B9E477858B64B51AE4CAFAE8B77C53Cepflch_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] Regarding IPR on draft-finn-detnet-bounded-latency-04 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 07:59:09 -0000 --_000_3B9E477858B64B51AE4CAFAE8B77C53Cepflch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIEnigJltIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0 Lg0KDQoNCkJlc3QsDQpFaHNhbg0KDQoNCg0KT24gMjYgSnVuIDIwMTksIGF0IDA5OjU3LCBaaGFu Z2ppYXlpIChKaWF5aSkgPHpoYW5namlheWkxMUBodWF3ZWkuY29tPG1haWx0bzp6aGFuZ2ppYXlp MTFAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRo YXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0DQoNClJlZ2FyZHMsDQpKaWF5aQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5u ZXRdDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjYsIDIwMTkgNDozMSBBTQ0KVG86IE5vcm1hbiBG aW5uIDxuZmlubkBuZmlubmNvbnN1bHRpbmcuY29tPG1haWx0bzpuZmlubkBuZmlubmNvbnN1bHRp bmcuY29tPj47IExlIEJvdWRlYyBKZWFuLVl2ZXMgPGplYW4teXZlcy5sZWJvdWRlY0BlcGZsLmNo PG1haWx0bzpqZWFuLXl2ZXMubGVib3VkZWNAZXBmbC5jaD4+OyBNb2hhbW1hZHBvdXIgRWhzYW4g PGVoc2FuLm1vaGFtbWFkcG91ckBlcGZsLmNoPG1haWx0bzplaHNhbi5tb2hhbW1hZHBvdXJAZXBm bC5jaD4+OyBaaGFuZ2ppYXlpIChKaWF5aSkgPHpoYW5namlheWkxMUBodWF3ZWkuY29tPG1haWx0 bzp6aGFuZ2ppYXlpMTFAaHVhd2VpLmNvbT4+OyBCYWzDoXpzIFZhcmdhIEEgPGJhbGF6cy5hLnZh cmdhQGVyaWNzc29uLmNvbTxtYWlsdG86YmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tPj47IErD oW5vcyBGYXJrYXMgPGphbm9zLmZhcmthc0Blcmljc3Nvbi5jb208bWFpbHRvOmphbm9zLmZhcmth c0Blcmljc3Nvbi5jb20+Pg0KQ2M6IERldE5ldCBXRyA8ZGV0bmV0QGlldGYub3JnPG1haWx0bzpk ZXRuZXRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1maW5uLWRl dG5ldC1ib3VuZGVkLWxhdGVuY3ktMDQNCg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0K QXMgcGFydCBvZiBwcmVwYXJhdGlvbiBmb3IgV0cgQWRvcHRpb24NCkFyZSB5b3UgYXdhcmUgb2Yg YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnRzIGlkZW50aWZpZWQgYWJvdmU/DQoNClBsZWFz ZSBzdGF0ZSBlaXRoZXI6DQoNCiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBw bGllcyB0byB0aGlzIGRyYWZ0Ig0Kb3INCiJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBs aWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQg aW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAz NjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KDQpJZiB5ZXMgdG8gdGhlIGFib3ZlLCBw bGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBp biBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQpvcg0KIk5vLCB0aGUgSVBSIGhhcyBu b3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFu eSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rIGFwcHJvcHJpYXRlLg0KDQpJZiB5b3UgYXJl IGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2Vy IHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0 aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1l bnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhh cyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci4g Tk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdT IFRPIExJTkVTLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBX RyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9y LCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1 bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3 YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJh aW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiBy ZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxl YXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYu b3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5 b3UsDQpEZXROZXQgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4g dGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgcmVzcG9uc2UuDQoNCg0KDQoNCg== --_000_3B9E477858B64B51AE4CAFAE8B77C53Cepflch_ Content-Type: text/html; charset="utf-8" Content-ID: <566885AFAD9F6F40B262220BB33EE6BD@intranet.epfl.ch> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCk5vLCBJ4oCZbSBub3QgYXdhcmUgb2YgYW55IElQ UiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQmVzdCw8YnIgY2xhc3M9 IiI+DQpFaHNhbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDI2IEp1biAyMDE5LCBhdCAwOTo1 NywgWmhhbmdqaWF5aSAoSmlheWkpICZsdDs8YSBocmVmPSJtYWlsdG86emhhbmdqaWF5aTExQGh1 YXdlaS5jb20iIGNsYXNzPSIiPnpoYW5namlheWkxMUBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFw cGxpZXMgdG8gdGhpcyBkcmFmdDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClJlZ2FyZHMs PGJyIGNsYXNzPSIiPg0KSmlheWk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IExvdSBCZXJnZXIgWzxhIGhy ZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0IiBjbGFzcz0iIj5tYWlsdG86bGJlcmdlckBsYWJu Lm5ldDwvYT5dDQo8YnIgY2xhc3M9IiI+DQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMjYsIDIwMTkg NDozMSBBTTxiciBjbGFzcz0iIj4NClRvOiBOb3JtYW4gRmlubiAmbHQ7PGEgaHJlZj0ibWFpbHRv Om5maW5uQG5maW5uY29uc3VsdGluZy5jb20iIGNsYXNzPSIiPm5maW5uQG5maW5uY29uc3VsdGlu Zy5jb208L2E+Jmd0OzsgTGUgQm91ZGVjIEplYW4tWXZlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpl YW4teXZlcy5sZWJvdWRlY0BlcGZsLmNoIiBjbGFzcz0iIj5qZWFuLXl2ZXMubGVib3VkZWNAZXBm bC5jaDwvYT4mZ3Q7OyBNb2hhbW1hZHBvdXIgRWhzYW4gJmx0OzxhIGhyZWY9Im1haWx0bzplaHNh bi5tb2hhbW1hZHBvdXJAZXBmbC5jaCIgY2xhc3M9IiI+ZWhzYW4ubW9oYW1tYWRwb3VyQGVwZmwu Y2g8L2E+Jmd0OzsNCiBaaGFuZ2ppYXlpIChKaWF5aSkgJmx0OzxhIGhyZWY9Im1haWx0bzp6aGFu Z2ppYXlpMTFAaHVhd2VpLmNvbSIgY2xhc3M9IiI+emhhbmdqaWF5aTExQGh1YXdlaS5jb208L2E+ Jmd0OzsgQmFsw6F6cyBWYXJnYSBBICZsdDs8YSBocmVmPSJtYWlsdG86YmFsYXpzLmEudmFyZ2FA ZXJpY3Nzb24uY29tIiBjbGFzcz0iIj5iYWxhenMuYS52YXJnYUBlcmljc3Nvbi5jb208L2E+Jmd0 OzsgSsOhbm9zIEZhcmthcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbm9zLmZhcmthc0Blcmljc3Nv bi5jb20iIGNsYXNzPSIiPmphbm9zLmZhcmthc0Blcmljc3Nvbi5jb208L2E+Jmd0OzxiciBjbGFz cz0iIj4NCkNjOiBEZXROZXQgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmci IGNsYXNzPSIiPmRldG5ldEBpZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KU3ViamVjdDog UmVnYXJkaW5nIElQUiBvbiBkcmFmdC1maW5uLWRldG5ldC1ib3VuZGVkLWxhdGVuY3ktMDQ8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLDxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIHBhcnQgb2YgcHJlcGFyYXRpb24gZm9yIFdHIEFk b3B0aW9uPGJyIGNsYXNzPSIiPg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGll cyB0byBkcmFmdHMgaWRlbnRpZmllZCBhYm92ZT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpQbGVhc2Ugc3RhdGUgZWl0aGVyOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZxdW90 O05vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQm cXVvdDs8YnIgY2xhc3M9IiI+DQpvcjxiciBjbGFzcz0iIj4NCiZxdW90O1llcywgSSdtIGF3YXJl IG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90OzxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxp YW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1 Mzc4IGZvciBtb3JlIGRldGFpbHMpPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklmIHll cyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KJnF1b3Q7WWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlh bmNlIHdpdGggSUVURiBJUFIgcnVsZXMmcXVvdDs8YnIgY2xhc3M9IiI+DQpvcjxiciBjbGFzcz0i Ij4NCiZxdW90O05vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQmcXVvdDs8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBh bnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBv ciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRo aXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFu eSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4 dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20NCiBlYWNoIGF1 dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9G IFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdFJ1MgVE8gTElORVMuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cg bWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwg d2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxl cyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2Fy ZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLA0KIG9yIHRvIHJlZnJh aW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiBy ZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxl YXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQo8YSBocmVmPSJodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eSIg Y2xhc3M9IiI+DQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lr aS9JbnRlbGxlY3R1YWxQcm9wZXJ0eTwvYT4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K VGhhbmsgeW91LDxiciBjbGFzcz0iIj4NCkRldE5ldCBXRyBDaGFpcnM8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJz IG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3B9E477858B64B51AE4CAFAE8B77C53Cepflch_-- From nobody Wed Jun 26 01:08:04 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86712024C for ; Wed, 26 Jun 2019 01:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkyXCAlJzCsR for ; Wed, 26 Jun 2019 01:08:00 -0700 (PDT) Received: from smtp4.epfl.ch (smtp4.epfl.ch [IPv6:2001:620:618:1e0:1:80b2:e059:1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DCD120248 for ; Wed, 26 Jun 2019 01:08:00 -0700 (PDT) Received: (qmail 21931 invoked by uid 107); 26 Jun 2019 08:07:57 -0000 Received: from tsf-484-wpa-1-200.epfl.ch (HELO [128.179.185.200]) (128.179.185.200) (TLS, ECDHE-RSA-AES256-GCM-SHA384 (X25519 curve) cipher) (authenticated) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTPSA; Wed, 26 Jun 2019 10:07:57 +0200 X-EPFL-Auth: VD13B0abPmjdjXvN5AY2dLKDXKBRfrCEC13CAZ7V8QE/Y5f1AUE= To: Norman Finn , Lou Berger Cc: Mohammadpour Ehsan , zhangjiayi11@huawei.com, =?UTF-8?Q?Bal=c3=a1zs_A=2e_Varga?= , =?UTF-8?Q?J=c3=a1nos_Farkas?= , DetNet WG References: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> <64EEAC1E-0A90-4D09-8F54-D1440036FF7B@nfinnconsulting.com> From: Jean-Yves Le Boudec Message-ID: <5f800360-5426-fde3-313c-124a5ad2b899@epfl.ch> Date: Wed, 26 Jun 2019 10:07:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <64EEAC1E-0A90-4D09-8F54-D1440036FF7B@nfinnconsulting.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Detnet] Regarding IPR on draft-finn-detnet-bounded-latency-04 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 08:08:03 -0000 No, I am not aware of any IPR that applies to this draft. JY On 2019-06-26 1:19 a.m., Norman Finn wrote: > No, I’m not aware of any IPR that applies to this draft. > > — Norm > >> On Jun 25, 2019, at 13:31, Lou Berger wrote: >> >> Authors, Contributors, WG, >> >> As part of preparation for WG Adoption >> Are you aware of any IPR that applies to drafts identified above? >> >> Please state either: >> >> "No, I'm not aware of any IPR that applies to this draft" >> or >> "Yes, I'm aware of IPR that applies to this draft" >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details)? >> >> If yes to the above, please state either: >> >> "Yes, the IPR has been disclosed in compliance with IETF IPR rules" >> or >> "No, the IPR has not been disclosed" >> >> If you answer no, please provide any additional details you think >> appropriate. >> >> If you are listed as a document author or contributor please answer the >> above by responding to this email regardless of whether or not you are >> aware of any relevant IPR. This document will not advance to the next >> stage until a response has been received from each author and listed >> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S >> TO LINES. >> >> If you are on the WG email list or attend WG meetings but are not listed >> as an author or contributor, we remind you of your obligations under >> the IETF IPR rules which encourages you to notify the IETF if you are >> aware of IPR of others on an IETF contribution, or to refrain from >> participating in any contribution or discussion related to your >> undisclosed IPR. For more information, please see the RFCs listed above >> and >> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >> >> Thank you, >> DetNet WG Chairs >> >> PS Please include all listed in the headers of this message in your >> response. >> >> >> From nobody Wed Jun 26 01:19:38 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2612023F for ; Wed, 26 Jun 2019 01:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYCBNrBUQiAa for ; Wed, 26 Jun 2019 01:19:34 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAEC31200B8 for ; Wed, 26 Jun 2019 01:19:33 -0700 (PDT) Received: from tpw09926dag18h.domain1.systemhost.net (10.9.212.42) by BWP09926081.bt.com (10.36.82.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 26 Jun 2019 09:19:22 +0100 Received: from tpw09926dag09f.domain1.systemhost.net (10.9.202.40) by tpw09926dag18h.domain1.systemhost.net (10.9.212.42) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Jun 2019 09:19:30 +0100 Received: from bwp09926080.bt.com (10.36.82.111) by tpw09926dag09f.domain1.systemhost.net (10.9.202.40) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 26 Jun 2019 09:19:30 +0100 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.52) by smtpe1.intersmtp.com (10.36.82.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 26 Jun 2019 09:18:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Coj1AlfzEJk3K8vvUXqedTKOS3CQF3YnrukMvg5H04=; b=WZs5ZcP0rO39BkOZBYJTdTfvn6QR8SWU09mQMvMnLKk2exxlTICbyB8pkGi2BsFNTfUCaq+fx7g+2DwO1Q/D50oMVrHskGuEufj9ukAvlzIVM7aFhIahC1rBPE+qK4ZeBKUuo3TFc0MbAct/Jrdhaz4Ol9zCuZvYlAeEwrboPmg= Received: from LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM (20.179.130.207) by LNXP123MB1753.GBRP123.PROD.OUTLOOK.COM (20.179.129.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Wed, 26 Jun 2019 08:19:02 +0000 Received: from LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM ([fe80::c833:389:1184:bc]) by LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM ([fe80::c833:389:1184:bc%7]) with mapi id 15.20.2008.014; Wed, 26 Jun 2019 08:19:02 +0000 From: To: , , , , , , CC: Thread-Topic: [Detnet] Regarding IPR on draft-finn-detnet-bounded-latency-04 Thread-Index: AQHVK5fJJE/9mvV8K02DSeUiz64fK6atmE7g Date: Wed, 26 Jun 2019 08:19:02 +0000 Message-ID: References: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> In-Reply-To: <48f3f477-d1c4-7542-def2-4c43682d8600@labn.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=peter.j.willis@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec0a23bd-4f65-4992-1fee-08d6fa0ef277 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB1753; x-ms-traffictypediagnostic: LNXP123MB1753: x-ms-exchange-purlcount: 2 x-antispam-2: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(376002)(136003)(39860400002)(13464003)(189003)(199004)(476003)(71200400001)(74316002)(486006)(316002)(4326008)(99286004)(3846002)(6116002)(110136005)(53936002)(7696005)(11346002)(68736007)(25786009)(6246003)(2501003)(76176011)(446003)(102836004)(2906002)(6506007)(53546011)(55016002)(64756008)(66556008)(66446008)(26005)(305945005)(66946007)(66066001)(66476007)(73956011)(9686003)(478600001)(76116006)(6436002)(14454004)(7736002)(5660300002)(81166006)(86362001)(229853002)(52536014)(81156014)(256004)(8936002)(33656002)(8676002)(966005)(186003)(6306002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB1753; H:LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DozUerpkNj8S6E99DJwbMJjdMQnU5uXybhgHUDPevgOpQWHIbZ7mgdH5iO23GfYHABfIY3PAcK14uUdedhMJSdlVoBzqe7iM3YZdnYwNmSHDDbWh7F8bm1N3jT6zNd3m5o3lcRJIrYE6xMp4pzXI5+xJ2bLHAuujLVbRRVS8ueOtspdupHj+R+T968wvyMVHoAMdzDQXakzCkemKcfrrnO/ouAbLnFUOBR5YHRMGy+GnePpGq6iWKxUDATGd8V/GYv0S7RV8cZ3pzUSVxX3WQoJ6MDVLY0DA0udj7qNT+joA1uYv8tcBkCcNYshNJeD+FJvY1zxtb1Uy0Ry87vIqKtzu2pCHDUE3fftUMohKl57eId08AE6X+0tgQqpOBwnWxhAIS5pchgUnTx624Gl2LfW+phniAxVXRjAaBvNUItk= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ec0a23bd-4f65-4992-1fee-08d6fa0ef277 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 08:19:02.2793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: peter.j.willis@bt.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB1753 X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Report: 3 Rules triggered * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6576 X-NAI-Spam-Version: 2.2.0.9309 : core <6576> : inlines <7110> : streams <1825592> : uri <2860474> X-OriginatorOrg: bt.com Archived-At: Subject: Re: [Detnet] Regarding IPR on draft-finn-detnet-bounded-latency-04 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 08:19:37 -0000 "No, I'm not aware of any IPR that applies to this draft" Best Regards, Peter Willis, Senior Manager Software Based Networks Research, Applied Research, BT Technology.=20 __________________________________ Tel: 01473 629943 Email: peter.j.willis@bt.com=20 -----Original Message----- From: detnet On Behalf Of Lou Berger Sent: 25 June 2019 21:31 To: Norman Finn ; Le Boudec Jean-Yves ; Mohammadpour Ehsan ; zhangj= iayi11@huawei.com; Bal=E1zs Varga A ; J=E1nos = Farkas Cc: DetNet WG Subject: [Detnet] Regarding IPR on draft-finn-detnet-bounded-latency-04 Authors, Contributors, WG, As part of preparation for WG Adoption Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropria= te. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until = a response has been received from each author and listed contributor. NOTE:= THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/grou= p/iesg/trac/wiki/IntellectualProperty. Thank you, DetNet WG Chairs PS Please include all listed in the headers of this message in your respons= e. _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet From nobody Wed Jun 26 01:27:48 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3991C1203DC for ; Wed, 26 Jun 2019 01:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHhwVPImT7A0 for ; Wed, 26 Jun 2019 01:27:44 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0614.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::614]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88690120219 for ; Wed, 26 Jun 2019 01:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xp4jUEAJG7kvc87ltReptP0QpKE5BIRD4+ZVQl+Kynk=; b=SMFpcZFQLwU4vRIMiUnV8wm+z7vV8frwQPzUxFuDyazOzvFOSLIx1rxT9RpcvW5tEjp/CDOzuyJhfzjAsy8AR62shdnbMxZsLIE51BdLYSTf3gbhbe0UDfFjKhSiEpRqf/+MATExkYJDImiK04D4X557jcwkeyrCpwzF+BOPxIA= Received: from VI1PR07MB3440.eurprd07.prod.outlook.com (10.175.244.142) by VI1SPR01MB0366.eurprd07.prod.outlook.com (20.178.120.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.12; Wed, 26 Jun 2019 08:27:41 +0000 Received: from VI1PR07MB3440.eurprd07.prod.outlook.com ([fe80::8d75:e94f:fb0b:9d5]) by VI1PR07MB3440.eurprd07.prod.outlook.com ([fe80::8d75:e94f:fb0b:9d5%7]) with mapi id 15.20.2032.012; Wed, 26 Jun 2019 08:27:41 +0000 From: Janos Farkas To: "qiangli (D)" CC: "detnet@ietf.org" , "shunsuke.homma.fp@hco.ntt.co.jp" , "peter.j.willis@bt.com" , Liang GENG Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwACAAF+FoA== Date: Wed, 26 Jun 2019 08:27:40 +0000 Message-ID: References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Janos.Farkas@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a8d635f1-7413-4f0d-6bf2-08d6fa1027a5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1SPR01MB0366; x-ms-traffictypediagnostic: VI1SPR01MB0366: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(39860400002)(396003)(346002)(53754006)(199004)(189003)(7696005)(64756008)(86362001)(71200400001)(76116006)(74316002)(81156014)(478600001)(68736007)(486006)(25786009)(9326002)(71190400001)(476003)(256004)(72206003)(186003)(102836004)(7736002)(4326008)(45080400002)(14444005)(26005)(966005)(6436002)(2906002)(73956011)(53546011)(8936002)(11346002)(606006)(236005)(53936002)(66476007)(81166006)(5660300002)(6916009)(9686003)(14454004)(52536014)(316002)(6506007)(6306002)(54906003)(66446008)(76176011)(55016002)(446003)(66066001)(54896002)(6116002)(229853002)(66556008)(790700001)(33656002)(3846002)(66946007)(6246003)(8676002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1SPR01MB0366; H:VI1PR07MB3440.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: idqO/DTb8PS0zXvWG9/oy/u36uxTZwRmbnfnGALRMwmNGBb1U7Lj/8oIDmGVwULIBoKxJ/oOxSk2KpVYwDMG5gmhrSTMs6UROQhp80bIlSPs4pR6JIkhAnPD9SspV7IYVGlD9sV3uhWhIfGZmnoQhaX5+caNjdtVC1utyuQAb0m/Wnti3hgGeNgmmH/ep1yIP4at/A5VAV2ZZybwM4w98C+J5IvQPd0bN1+w5KziVGBt3Umxdq6BJpSeFW/dJhbI6OhLXAcnPq35eXcUU5JBLyn+61KfhSeOWKv5wIVgstr+FgwdJ1WCJTATdYSKBv9WrRn5lU9WtnCzuclarFAL2mRj0KPJyrWB2EJO7swyfyudWF9THzCbnVPLm5mJX1zR5o+6oRYf7LyfTcLdazmvAWm96iehHsanFAjRb2sMfk8= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB3440B125F1D7696FFB71E961F2E20VI1PR07MB3440eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a8d635f1-7413-4f0d-6bf2-08d6fa1027a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 08:27:41.0157 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Janos.Farkas@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1SPR01MB0366 Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 08:27:46 -0000 --_000_VI1PR07MB3440B125F1D7696FFB71E961F2E20VI1PR07MB3440eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Cristina, My understanding of the consensus of the WG based on the Architecture docum= ent 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 On Behalf Of qiangli (D) Sent: Wednesday, June 26, 2019 5:33 AM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GENG Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.= co.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_VI1PR07MB3440B125F1D7696FFB71E961F2E20VI1PR07MB3440eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Cristina,

 

My understanding of the consensus of the WG based o= n the Architecture document is that synchronization is acknowledged to be i= mportant; however, it is not the job of DetNet to specify the details, solutions, etc.; DetNet just uses what is availabl= e, specified by other standards.

 

Best regards,

Janos

 

From: detnet <detnet-bounces@ietf= .org> On Behalf Of qiangli (D)
Sent: Wednesday, June 26, 2019 5:33 AM
To: detnet@ietf.org
Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GE= NG <liang.geng@hotmail.com>
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 clo= ck jitter & wander even within a time synchronous domain. We would like to know if you agree or disagree with this requireme= nt. If you think this requirement is necessary, then to what degree of cloc= k jitter & wander do you expect?

 = ;

BTW, we ar= e going to ask for WG adoption for this document in IETF 105 meeting. That&= #8217;s will be greatly appreciated if you can share your comments to help us further improve this draft.

 = ;

 = ;

Best regards,

 

Cristina QIANG

 = ;

&nbs= p;

Hi all,

 = ;

This versi= on has collected 7 requirements, and divided these requirements into option= al (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 revi= ew and comments are highly appropriated.

 = ;

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

Req. 1: Mu= st 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 sync= hronous domain

 = ;

Req. 3: Mu= st support Inter-Continental propagation delay

 = ;

Req. 4: Sh= ould have self-monitoring capability

 = ;

Req. 5: Sh= ould be robust against denial of service attacks

 = ;

Req. 6: Mu= st tolerate failures of links or nodes and topology changes

 = ;

Req. 7: Mu= st be scalable

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 = ;

Best regards,

 

Cristina QIANG

 = ;

From: Liang GENG [mailto:liang.geng@hot= mail.com]
Sent: Tuesday, June 11, 2019 11:53 AM
To: detnet@ietf.org
Cc: Black, David <David.Black@dell.com= >; peter..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@huawei.com>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised f= or comments

&nbs= p;

Dea= r all,

 

Sin= ce IETF 104, we have carefully revised draft-geng-detnet-requirements-bound= ed-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/<= span style=3D"font-size:10.5pt;font-family:"Calibri",sans-serif;c= olor:black;mso-fareast-language:ZH-CN">. 

 

Thi= s new version collects more technical, operational and management requireme= nts of deploying deterministic latency service on layer 3 networks from the perspective of various service providers.

 

Com= ments are welcome!

 

Bes= t regards,

Lia= ng Geng on behavior of co-authors

 

 

 

--_000_VI1PR07MB3440B125F1D7696FFB71E961F2E20VI1PR07MB3440eurp_-- From nobody Wed Jun 26 02:29:24 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BDB120255 for ; Wed, 26 Jun 2019 02:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2wb3TQCnfLF for ; Wed, 26 Jun 2019 02:29:17 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF82120254 for ; Wed, 26 Jun 2019 02:29:17 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 09B28CDFAC0CDA4E871F; Wed, 26 Jun 2019 10:29:15 +0100 (IST) Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 26 Jun 2019 10:29:14 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 26 Jun 2019 17:29:11 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1591.008; Wed, 26 Jun 2019 17:29:11 +0800 From: "qiangli (D)" To: Janos Farkas CC: "detnet@ietf.org" , "shunsuke.homma.fp@hco.ntt.co.jp" , "peter.j.willis@bt.com" , Liang GENG Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwACAAF+FoIAAExFw Date: Wed, 26 Jun 2019 09:29:11 +0000 Message-ID: <83dac230ca6d4035841b9d6a527ea16f@huawei.com> References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: multipart/alternative; boundary="_000_83dac230ca6d4035841b9d6a527ea16fhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 09:29:21 -0000 --_000_83dac230ca6d4035841b9d6a527ea16fhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Janos, Thanks for your kindly remind and comment. I copied the Req. 2.2 text as fo= llows 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 o= f 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 n= eed to further specify more details. What do you think. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Best regards, Cristina QIANG From: Janos Farkas [mailto:Janos.Farkas@ericsson.com] Sent: Wednesday, June 26, 2019 4:28 PM To: qiangli (D) Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com= ; Liang GENG 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 docum= ent 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 > On B= ehalf Of qiangli (D) Sent: Wednesday, June 26, 2019 5:33 AM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.= co.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_83dac230ca6d4035841b9d6a527ea16fhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 deg= ree of clock jitter & wander DetNet can t= olerate, is to detail the current text. According to your reply, I understa= nd 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.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

2.2.2.  Sub-requi= rement 2.2: Should tolerate clock jitter & wander

   &nbs= p;    within a clock synchronous domain

 

   DetNet do= main itself can be time synchronous or asynchronous,

   depending= on the technology selection of different operators.  Even<= /span>

   within a = time synchronous domain, the synchronized clocks may also=

   experienc= e jitter & wander, the mechanisms adopted by DetNet should

   be able t= o tolerate a certain degree of clock jitter & wander.=

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

Best regards,

 

Cristina QIANG

 

From: = Janos Farkas [mailto:Janos.Farkas@ericsson.com]
Sent: Wednesday, June 26, 2019 4:28 PM
To: qiangli (D) <qiangli3@huawei.com>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis= @bt.com; Liang GENG <liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Cristina,

 

My understanding of the consensus of= the WG based on the Architecture document is that synchronization is ackno= wledged to be important; however, it is not the job of DetNet to specify the details, solutions, etc.; DetNet just uses wh= at is available, specified by other standards.

 

Best regards,

Janos

 

 

Hi all,

 

The Req. 2.2 discusses= that DetNet should be able to tolerate a certain degree of clock jitter &a= mp; 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 &a= mp; wander do you expect?

 

BTW, we are going to a= sk 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 colle= cted 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 a= re highly appropriated.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Req. 1: Must support t= he dynamic creation, modification and deletion of deterministic services

 

Req. 2.1: Should suppo= rt asynchronous clocks across domains

Req. 2.2 : Should tole= rate a certain of clock jitter & wander within a clock synchronous doma= in

 

Req. 3: Must support I= nter-Continental propagation delay

 

Req. 4: Should have se= lf-monitoring capability

 

Req. 5: Should be robu= st against denial of service attacks

 

Req. 6: Must tolerate = failures of links or nodes and topology changes

 

Req. 7: Must be scalab= le

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

From: = Liang GENG [mailto:liang.geng@hotmail.com]
Sent: Tuesday, June 11, 2019 11:53 AM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: Black, David <David.Black@dell.com>; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@huawei.com>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised f= or comments

 

Dear all,

 

Since IETF 104, we have carefully revised draft-geng-detnet-r= equirements-bounded-latency-02 according to received comments. The latest 02 version was uploaded and available online <= span lang=3D"EN-US">https://datatracker.ietf.org/doc/dra= ft-geng-detnet-requirements-bounded-latency/. 

 

This new version collects more technical, operational and man= agement requirements of deploying deterministic latency service on layer 3 networks from the perspective of various servic= e providers.

 

Comments are welcome!

 

Best regards,

Liang Geng on behavior of co-authors

 

 

 

--_000_83dac230ca6d4035841b9d6a527ea16fhuaweicom_-- From nobody Wed Jun 26 02:36:56 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D229120146 for ; Wed, 26 Jun 2019 02:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubHW1IY38V6B for ; Wed, 26 Jun 2019 02:36:50 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150053.outbound.protection.outlook.com [40.107.15.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6ED120058 for ; Wed, 26 Jun 2019 02:36:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=DW9sT53ciU/2HHfvOsM0naFxxEVyTFyB+WCe833oYM59CAfh30Hc/auYgL9ZC5jx/PlRMBW8y9sBuoxJfJzVnpX8NgMmmKVEc9kHf6zmEMq7wtJFaoMy4Inb/aHuiEdfGRk89JpPAg8ItEyRVYPxhGylaPhiXZq0aicDbNWYupY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sUrdVVWs2gL4xhYjCqpflLP4ZcpY7lfIqM3Dw5en424=; b=nIMnFq5UauUHsxwhy+1k5p/3ElMNQyyN4BvjQ7TKcSD8XTUBCS/NFoLkJpr8LxNbhWGroemsmETHFJ5FHsDih+E+qR/+jDEQWNkyjHoqzkXx68YFXphl07S7snKslMloNmDqOpXyuUdap3imeaPasF0Suu3pjyHOwrkY43rFsb0= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sUrdVVWs2gL4xhYjCqpflLP4ZcpY7lfIqM3Dw5en424=; b=XuNCuNBHLcdBrAl0q3bMBXGwhWZKwQD8IcFyqZui8WI7ckWSg03hLKrecc94YJPpfWiJSfRhSYrlQhAVV+rdsg8hWZmPMyaZKtL6Y9q0scvqO7llK1eKcf8sd8VBtvi8SRe7exa8LBAR36D5w7B4KeqyFzpjkGpG9Et7n5NZqPo= Received: from VI1PR07MB3440.eurprd07.prod.outlook.com (10.175.244.142) by VI1PR07MB5709.eurprd07.prod.outlook.com (20.178.121.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.11; Wed, 26 Jun 2019 09:36:47 +0000 Received: from VI1PR07MB3440.eurprd07.prod.outlook.com ([fe80::8d75:e94f:fb0b:9d5]) by VI1PR07MB3440.eurprd07.prod.outlook.com ([fe80::8d75:e94f:fb0b:9d5%7]) with mapi id 15.20.2032.012; Wed, 26 Jun 2019 09:36:47 +0000 From: Janos Farkas To: "qiangli (D)" CC: "detnet@ietf.org" , "shunsuke.homma.fp@hco.ntt.co.jp" , "peter.j.willis@bt.com" , Liang GENG Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwACAAF+FoIAAExFwgAAGYnA= Date: Wed, 26 Jun 2019 09:36:47 +0000 Message-ID: References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <83dac230ca6d4035841b9d6a527ea16f@huawei.com> In-Reply-To: <83dac230ca6d4035841b9d6a527ea16f@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Janos.Farkas@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b8791b41-bcf4-4843-d33b-08d6fa19cf01 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1PR07MB5709; x-ms-traffictypediagnostic: VI1PR07MB5709: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(396003)(346002)(136003)(366004)(199004)(189003)(53754006)(74316002)(52536014)(6916009)(606006)(5660300002)(54906003)(316002)(86362001)(2906002)(186003)(7736002)(9686003)(236005)(55016002)(99286004)(6306002)(54896002)(6436002)(8676002)(229853002)(3846002)(33656002)(9326002)(6116002)(25786009)(81166006)(81156014)(53546011)(11346002)(476003)(6246003)(4326008)(45080400002)(478600001)(446003)(66066001)(68736007)(6506007)(102836004)(53936002)(76176011)(790700001)(7696005)(486006)(14454004)(26005)(71200400001)(71190400001)(14444005)(256004)(64756008)(66446008)(66476007)(66556008)(73956011)(76116006)(966005)(72206003)(66946007)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5709; H:VI1PR07MB3440.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: q8u3zirWVnxy876FH+WNTXiaGvz6+z5imd76H6r0nNYtcTrZLi9DkrV+Be1e5qVBW5yEbwiYfhqpMVjHezPhBWzdcPC4eNx7udo/lxJFqQq5RuN7rNTI6ZdpygE0osV6ZUL4kc2SL1otpzsgb+sa/+XZs43J+wKDdbocgMCE8mY6TmlTU0+L1x8ymD/1+ZAEbSGoDXBMRpPZ97DDKizrAjNtHEmthd9VLvA8l36lzIjo5v8urtrkfhlPdE7EZfB0wC2DB4ZmXlkbQEwwnICyXOV36Wboj9CHOW1zvkPAxcLpghRYqd6MNtqtuW2coS16Vxxurn0XFqXm9sXAkyFj0coHGu97EDnewZIOr6COtiZCbaUn2ITpvN2/0bGRbk1Vs0FDwdAVetM930PRm6o55YeteQiHeKX1DZyMbGXxpkg= Content-Type: multipart/alternative; boundary="_000_VI1PR07MB34407B283639D6414ABD8D02F2E20VI1PR07MB3440eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8791b41-bcf4-4843-d33b-08d6fa19cf01 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 09:36:47.2863 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Janos.Farkas@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5709 Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 09:36:54 -0000 --_000_VI1PR07MB34407B283639D6414ABD8D02F2E20VI1PR07MB3440eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 deplo= yment/application/use case. For instance, in some cases, synchronization wo= uld be not needed at all; e.g., if the DetNet high availability / high reli= ability feature is what is really needed for the given case; or an asynchro= nous solution is used to achieve bounded low latency. Best regards, Janos From: qiangli (D) Sent: Wednesday, June 26, 2019 11:29 AM To: Janos Farkas Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com= ; Liang GENG 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 fo= llows 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 o= f 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 n= eed to further specify more details. What do you think. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Best regards, Cristina QIANG From: Janos Farkas [mailto:Janos.Farkas@ericsson.com] Sent: Wednesday, June 26, 2019 4:28 PM To: qiangli (D) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 docum= ent 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 > On B= ehalf Of qiangli (D) Sent: Wednesday, June 26, 2019 5:33 AM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.= co.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_VI1PR07MB34407B283639D6414ABD8D02F2E20VI1PR07MB3440eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 c= ases, synchronization would be not needed at all; e.g., if the DetNet high availability / high reliability feature is what i= s really needed for the given case; or an asynchronous solution is used to = achieve bounded low latency.

 

Best regards,

Janos

 

From: qiangli (D) <qiangli3@huawe= i.com>
Sent: Wednesday, June 26, 2019 11:29 AM
To: Janos Farkas <Janos.Farkas@ericsson.com>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis= @bt.com; Liang GENG <liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hello Jano= s,

 = ;

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 de= tail the current text. According to your reply, I understand that DetNet ju= st 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.

 = ;

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

2.2.2.&nbs= p; Sub-requirement 2.2: Should tolerate clock jitter & wander

 &nbs= p;      within a clock synchronous domain

 = ;

 &nbs= p; DetNet domain itself can be time synchronous or asynchronous,=

 &nbs= p; depending on the technology selection of different operators.  Even=

 &nbs= p; within a time synchronous domain, the synchronized clocks may also<= /o:p>

 &nbs= p; experience jitter & wander, the mechanisms adopted by DetNet should<= o:p>

 &nbs= p; be able to tolerate a certain degree of clock jitter & wander.<= /o:p>

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 = ;

Best regards,

 

Cristina QIANG

 = ;

From: Janos Farkas [mailto:Janos.Farkas@ericsson.com]
Sent: Wednesday, June 26, 2019 4:28 PM
To: qiangli (D) <qiangli3@= huawei.com>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GENG <liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

&nbs= p;

Hi Cristina,<= /span>

 =

My understanding of the = consensus of the WG based on the Architecture document is that synchronizat= ion is acknowledged to be important; however, it is not the job of DetNet to specify the details, solutions, etc.; DetNe= t just uses what is available, specified by other standards.

 =

Best regards,=

Janos<= /p>

 =

&nbs= p;

Hi all,

 = ;

The Req. 2= .2 discusses that DetNet should be able to tolerate a certain degree of clo= ck jitter & wander even within a time synchronous domain. We would like to know if you agree or disagree with this requireme= nt. If you think this requirement is necessary, then to what degree of cloc= k jitter & wander do you expect?

 = ;

BTW, we ar= e going to ask for WG adoption for this document in IETF 105 meeting. That&= #8217;s will be greatly appreciated if you can share your comments to help us further improve this draft.

 = ;

 = ;

Best regards,

 

Cristina QIANG

 = ;

&nbs= p;

Hi all,

 = ;

This versi= on has collected 7 requirements, and divided these requirements into option= al (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 revi= ew and comments are highly appropriated.

 = ;

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

Req. 1: Mu= st 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 sync= hronous domain

 = ;

Req. 3: Mu= st support Inter-Continental propagation delay

 = ;

Req. 4: Sh= ould have self-monitoring capability

 = ;

Req. 5: Sh= ould be robust against denial of service attacks

 = ;

Req. 6: Mu= st tolerate failures of links or nodes and topology changes

 = ;

Req. 7: Mu= st be scalable

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 = ;

Best regards,

 

Cristina QIANG

 = ;

From: Liang GENG [mailto:liang.geng@hot= mail.com]
Sent: Tuesday, June 11, 2019 11:53 AM
To: detnet@ietf.org
Cc: Black, David <David.Black@dell.com= >; peter..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@huawei.com>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised f= or comments

&nbs= p;

Dea= r all,

 

Sin= ce IETF 104, we have carefully revised draft-geng-detnet-requirements-bound= ed-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/<= span style=3D"font-size:10.5pt;font-family:"Calibri",sans-serif;c= olor:black;mso-fareast-language:ZH-CN">. 

 

Thi= s new version collects more technical, operational and management requireme= nts of deploying deterministic latency service on layer 3 networks from the perspective of various service providers.

 

Com= ments are welcome!

 

Bes= t regards,

Lia= ng Geng on behavior of co-authors

 

 

 

--_000_VI1PR07MB34407B283639D6414ABD8D02F2E20VI1PR07MB3440eurp_-- From nobody Wed Jun 26 02:48:16 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71863120265 for ; Wed, 26 Jun 2019 02:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-G9AY62Wc_W for ; Wed, 26 Jun 2019 02:48:10 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E25912010E for ; Wed, 26 Jun 2019 02:48:10 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0A79B1EBEC27185E149C; Wed, 26 Jun 2019 10:48:08 +0100 (IST) Received: from dggeme704-chm.china.huawei.com (10.1.199.100) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 26 Jun 2019 10:48:07 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme704-chm.china.huawei.com (10.1.199.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 26 Jun 2019 17:48:05 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1591.008; Wed, 26 Jun 2019 17:48:04 +0800 From: "qiangli (D)" To: Janos Farkas CC: "detnet@ietf.org" , "shunsuke.homma.fp@hco.ntt.co.jp" , "peter.j.willis@bt.com" , Liang GENG Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwACAAF+FoIAAExFwgAAGYnCAAAGF4A== Date: Wed, 26 Jun 2019 09:48:04 +0000 Message-ID: References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <83dac230ca6d4035841b9d6a527ea16f@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: multipart/alternative; boundary="_000_ceace26fc55b4a74abed1b95d4cc4363huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 09:48:14 -0000 --_000_ceace26fc55b4a74abed1b95d4cc4363huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 selec= tion of different operators." can be refined as "DetNet domain itself can = be time synchronous or asynchronous, depending on actual deployment/applica= tion/use cases" for more accurate. Thank you. Best regards, Cristina QIANG From: Janos Farkas [mailto:Janos.Farkas@ericsson.com] Sent: Wednesday, June 26, 2019 5:37 PM To: qiangli (D) Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com= ; Liang GENG 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 deplo= yment/application/use case. For instance, in some cases, synchronization wo= uld be not needed at all; e.g., if the DetNet high availability / high reli= ability feature is what is really needed for the given case; or an asynchro= nous solution is used to achieve bounded low latency. Best regards, Janos From: qiangli (D) > Sent: Wednesday, June 26, 2019 11:29 AM To: Janos Farkas > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 fo= llows 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 o= f 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 n= eed to further specify more details. What do you think. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Best regards, Cristina QIANG From: Janos Farkas [mailto:Janos.Farkas@ericsson.com] Sent: Wednesday, June 26, 2019 4:28 PM To: qiangli (D) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 docum= ent 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 > On B= ehalf Of qiangli (D) Sent: Wednesday, June 26, 2019 5:33 AM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.= co.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_ceace26fc55b4a74abed1b95d4cc4363huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Janos,

 

Fully agree with you o= n this point.  So the statement “DetNet d= omain itself can be time synchronous or asynchronous, depending on the tech= nology selection of different operators.”  can be refined as “DetNet domain itself can be time synchronous or asynchronous, de= pending on actual deployment/application/use cases” for more accurate= . Thank you.

 

Best regards,

 

Cristina QIANG

 

From: = Janos Farkas [mailto:Janos.Farkas@ericsson.com]
Sent: Wednesday, June 26, 2019 5:37 PM
To: qiangli (D) <qiangli3@huawei.com>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis= @bt.com; Liang GENG <liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Cristina,

 

Thank you for your quick response.

 

I’d like to have what others t= hink.

 

Just one more note on my side: I thi= nk it depends a lot on the actual deployment/application/use case. For inst= ance, in some cases, synchronization would be not needed at all; e.g., if the DetNet high availability / high reliability fe= ature is what is really needed for the given case; or an asynchronous solut= ion is used to achieve bounded low latency.

 

Best regards,

Janos

 

 

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 deg= ree of clock jitter & wander DetNet can tolerate, is to detail the curr= ent text. According to your reply, I understand that DetNet just simply use= s what is available.  So maybe we can simply list some existing standards here, no need to further specify more = details. What do you think.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

2.2.2.  Sub-requi= rement 2.2: Should tolerate clock jitter & wander

   &nbs= p;    within a clock synchronous domain

 

   DetNet do= main itself can be time synchronous or asynchronous,

   depending= on the technology selection of different operators.  Even<= /span>

   within a = time synchronous domain, the synchronized clocks may also=

   experienc= e jitter & wander, the mechanisms adopted by DetNet should

   be able t= o tolerate a certain degree of clock jitter & wander.=

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

Best regards,

 

Cristina QIANG

 

From: = Janos Farkas [mailto:Janos.Far= kas@ericsson.com]
Sent: Wednesday, June 26, 2019 4:28 PM
To: qiangli (D) <qiangli3@= huawei.com>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GENG <liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Cristina,

 

My understanding of the consensus of= the WG based on the Architecture document is that synchronization is ackno= wledged to be important; however, it is not the job of DetNet to specify the details, solutions, etc.; DetNet just uses wh= at is available, specified by other standards.

 

Best regards,

Janos

 

 

Hi all,

 

The Req. 2.2 discusses= that DetNet should be able to tolerate a certain degree of clock jitter &a= mp; 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 &a= mp; wander do you expect?

 

BTW, we are going to a= sk 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 colle= cted 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 a= re highly appropriated.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Req. 1: Must support t= he dynamic creation, modification and deletion of deterministic services

 

Req. 2.1: Should suppo= rt asynchronous clocks across domains

Req. 2.2 : Should tole= rate a certain of clock jitter & wander within a clock synchronous doma= in

 

Req. 3: Must support I= nter-Continental propagation delay

 

Req. 4: Should have se= lf-monitoring capability

 

Req. 5: Should be robu= st against denial of service attacks

 

Req. 6: Must tolerate = failures of links or nodes and topology changes

 

Req. 7: Must be scalab= le

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

From: = Liang GENG [mailto:liang.geng@hotmail.com]
Sent: Tuesday, June 11, 2019 11:53 AM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: Black, David <David.Black@dell.com>; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@huawei.com>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised f= or comments

 

Dear all,

 

Since IETF 104, we have carefully revised draft-geng-detnet-r= equirements-bounded-latency-02 according to received comments. The latest 02 version was uploaded and available online <= span lang=3D"EN-US">https://datatracker.ietf.org/doc/dra= ft-geng-detnet-requirements-bounded-latency/. 

 

This new version collects more technical, operational and man= agement requirements of deploying deterministic latency service on layer 3 networks from the perspective of various servic= e providers.

 

Comments are welcome!

 

Best regards,

Liang Geng on behavior of co-authors

 

 

 

--_000_ceace26fc55b4a74abed1b95d4cc4363huaweicom_-- From nobody Wed Jun 26 03:20:42 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67B3120278 for ; Wed, 26 Jun 2019 03:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnU85N5yaf7a for ; Wed, 26 Jun 2019 03:20:36 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A35120077 for ; Wed, 26 Jun 2019 03:20:35 -0700 (PDT) Received: from tpw09926dag08g.domain1.systemhost.net (10.9.202.43) by BWP09926081.bt.com (10.36.82.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 26 Jun 2019 11:20:24 +0100 Received: from tpw09926dag05h.domain1.systemhost.net (10.9.202.32) by tpw09926dag08g.domain1.systemhost.net (10.9.202.43) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Jun 2019 11:20:33 +0100 Received: from bwp09926080.bt.com (10.36.82.111) by tpw09926dag05h.domain1.systemhost.net (10.9.202.32) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 26 Jun 2019 11:20:33 +0100 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.55) by smtpe1.intersmtp.com (10.36.82.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Wed, 26 Jun 2019 11:20:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+a264sJUkVIk3FRz+hpK+C7gh59OysjRIQ3gDb/GKG8=; b=T01N/KnyeRg9zIsRBpmheAUv8Kw6Cidp3E9ypX8/doD9suTy5/3D9KQm6aSxJ07LuwJe1dV0K3ODwERxJZibmLfguaVSxYZEFJYR4tRUIqIC50RsmEsytNrlpdyUqd6dE+13DksjxreYs95HpwCRBkqsoP+zfpqgO/WOXX7eR8k= Received: from LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM (20.179.130.207) by LNXP123MB2201.GBRP123.PROD.OUTLOOK.COM (20.179.129.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Wed, 26 Jun 2019 10:20:28 +0000 Received: from LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM ([fe80::c833:389:1184:bc]) by LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM ([fe80::c833:389:1184:bc%7]) with mapi id 15.20.2008.014; Wed, 26 Jun 2019 10:20:28 +0000 From: To: , CC: , , Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwACAAF+FoIAAExFwgAAGYnCAAAsdwA== Date: Wed, 26 Jun 2019 10:20:28 +0000 Message-ID: References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <83dac230ca6d4035841b9d6a527ea16f@huawei.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=peter.j.willis@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74df94aa-3dc1-4e26-8e44-08d6fa1fe987 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB2201; x-ms-traffictypediagnostic: LNXP123MB2201: x-ms-exchange-purlcount: 1 x-antispam-2: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(136003)(346002)(39860400002)(53754006)(199004)(189003)(54896002)(966005)(76116006)(74316002)(71190400001)(73956011)(9686003)(66556008)(6306002)(33656002)(6436002)(14454004)(6506007)(186003)(71200400001)(66476007)(64756008)(55016002)(66446008)(66946007)(316002)(76176011)(68736007)(5660300002)(53546011)(229853002)(236005)(53936002)(606006)(66066001)(6246003)(54906003)(52536014)(7696005)(6116002)(14444005)(256004)(790700001)(26005)(8936002)(102836004)(478600001)(86362001)(4326008)(45080400002)(7736002)(2906002)(110136005)(81166006)(81156014)(446003)(476003)(25786009)(8676002)(3846002)(486006)(11346002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB2201; H:LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OAwrORzTJYP/+eucLxI38SuizghzVKWAbyenqXdXYudBH/ZELD/PxuaHBM3DAlSeJhT08JCz1fcspYN+geTwPoPC6aWhbw3UB6LzBVHobILb6hZnjo7eb/Mv+7W0KQ6C2nXQvQ9/NSejcToSIkLBcnGnsuThZ/qoHpRLtX4enke+Tyvjj+FCmAhuayM664grvhKY/NAOBn1LEE9R5sHLaiBV/bPO+E7Q3qonG5lQFQDEXiK5UZSzsf5URtJ85XIda26MKzV5sbxg1LsK8CcXx+sUnmspkWB6Da6gjf14Zll8hXqGuxPZDI+kXC/NH6q4wyvyucA1Qftugi3YO2eQSxH5cjnrMfI3yPdAb6ok1rLLfzf1DUwu/gs3i0w9GiM3WYrvldS3oI8zbg7qDYCzH8uT5DznzGPBxuIG80GQBJA= Content-Type: multipart/alternative; boundary="_000_LNXP123MB24119F86D5174F411A02DF3CBBE20LNXP123MB2411GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 74df94aa-3dc1-4e26-8e44-08d6fa1fe987 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 10:20:28.7389 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: peter.j.willis@bt.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2201 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Report: 4 Rules triggered * 0.1 -- JSDHEY_JHDEYU * 0 -- EDT_SDHA_ADR_FRG * 0 -- EDT_SDHA_DMN_FRG * 0 -- RV6576 X-NAI-Spam-Version: 2.2.0.9309 : core <6576> : inlines <7110> : streams <1825600> : uri <2860504> X-OriginatorOrg: bt.com Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 10:20:41 -0000 --_000_LNXP123MB24119F86D5174F411A02DF3CBBE20LNXP123MB2411GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues, >From a network operator's point of view I do not want the extra cost of hig= hly accurate clocks in routers so prefer Detnet to work with the current cl= ocks I have in routers. For an exact specification we would have to list th= e clock specifications in the typical routers that network operators use (i= t'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 pr= actice. 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 Sent: 26 June 2019 10:37 To: qiangli (D) Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; Willis,PJ,Peter,TUD1 = R ; Liang GENG 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 deplo= yment/application/use case. For instance, in some cases, synchronization wo= uld be not needed at all; e.g., if the DetNet high availability / high reli= ability feature is what is really needed for the given case; or an asynchro= nous solution is used to achieve bounded low latency. Best regards, Janos From: qiangli (D) > Sent: Wednesday, June 26, 2019 11:29 AM To: Janos Farkas > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 fo= llows 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 o= f 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 n= eed to further specify more details. What do you think. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Best regards, Cristina QIANG From: Janos Farkas [mailto:Janos.Farkas@ericsson.com] Sent: Wednesday, June 26, 2019 4:28 PM To: qiangli (D) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 docum= ent 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 > On B= ehalf Of qiangli (D) Sent: Wednesday, June 26, 2019 5:33 AM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.= co.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_LNXP123MB24119F86D5174F411A02DF3CBBE20LNXP123MB2411GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Colleagues,

 =

From a network operator&= #8217;s point of view I do not want the extra cost of highly accurate clock= s 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 requirem= ent in to test what assumptions we are making about clock jitter & wand= er, and to check those assumptions are reasonable in practice. If there is a correlation between clock jitter & wander a= nd packet jitter then that needs to be understood and stated.

 =

Best Regards,=

Peter.=

 =

From: = Janos Farkas <Janos.Farkas@ericsson.com>
Sent: 26 June 2019 10:37
To: qiangli (D) <qiangli3@huawei.com>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; Willis,PJ,Pete= r,TUD1 R <peter.j.willis@bt.com>; Liang GENG <liang.geng@hotmail.c= om>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Cristina,

 

Thank you for your quick response.

 

I’d like to have what others t= hink.

 

Just one more note on my side: I thi= nk it depends a lot on the actual deployment/application/use case. For inst= ance, in some cases, synchronization would be not needed at all; e.g., if the DetNet high availability / high reliability fe= ature is what is really needed for the given case; or an asynchronous solut= ion is used to achieve bounded low latency.

 

Best regards,

Janos

 

 

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 D= etNet 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.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

2.2.2.  Sub-requirement 2.2: Should tolerate clock jitter & w= ander

        within a clock synchronous = domain

 

   DetNet domain itself can be time synchronous or asynchron= ous,

   depending on the technology selection of different operat= ors.  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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

From:<= /span> Janos Farkas [mailto:Janos.Farkas@ericsson= .com]
Sent: Wednesday, June 26, 2019 4:28 PM
To: qiangli (D) <qiangli3@= huawei.com>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GENG <liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Cristi= na,

&nbs= p;

My unders= tanding of the consensus of the WG based on the Architecture document is th= at synchronization is acknowledged to be important; however, it is not the job of DetNet to specify the details, solutions, et= c.; DetNet just uses what is available, specified by other standards.<= /o:p>

&nbs= p;

Best rega= rds,

Janos

&nbs= p;

 

Hi all,

 

The Req. 2.2 discusses that DetNet should be able to tolerate a certai= n degree of clock jitter & wander even within a time synchronous domain. We would like to know if you agree or disagree wi= th this requirement. If you think this requirement is necessary, then to wh= at 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 requireme= nts into optional (SHOULD) and mandatory (MUST) two types as following shows. We authors would like to know if this requir= ement list is complete, and if the classification is appropriate or not. &n= bsp;Your review and comments are highly appropriated.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Req. 1: Must support the dynamic creation, modification and deletion o= f deterministic services

 

Req. 2.1: Should support asynchronous clocks across domains=

Req. 2.2 : Should tolerate a certain of clock jitter & wander with= in 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<= /span>

 

Req. 6: Must tolerate failures of links or nodes and topology changes<= o:p>

 

Req. 7: Must be scalable

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

 

Dear all,

 

Since IETF 104, we have careful= ly revised draft-geng-detnet-requirements-bounded-latency-02 according to r= eceived comments. The latest 02 version was uploaded and available online https://datatracker.ietf.org/doc/draft-geng-detnet-requirements-bounded-la= tency/. 

 

This new version collects more = technical, operational and management requirements of deploying determinist= ic latency service on layer 3 networks from the perspective of various service providers.

 

Comments are welcome!

 

Best regards,=

Liang Geng on behavior of co-au= thors

 

 

 

--_000_LNXP123MB24119F86D5174F411A02DF3CBBE20LNXP123MB2411GBRP_-- From nobody Thu Jun 27 01:33:37 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9824120153 for ; Thu, 27 Jun 2019 01:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM2-ipp4ON4U for ; Thu, 27 Jun 2019 01:33:35 -0700 (PDT) Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC6D120110 for ; Thu, 27 Jun 2019 01:33:34 -0700 (PDT) Received: from unknown (HELO smtpeg.etri.re.kr) (129.254.27.142) by 129.254.9.16 with ESMTP; 27 Jun 2019 17:33:29 +0900 X-Original-SENDERIP: 129.254.27.142 X-Original-MAILFROM: ryoo@etri.re.kr X-Original-RCPTTO: detnet@ietf.org Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 27 Jun 2019 17:33:31 +0900 Received: from SMTP2.etri.info ([169.254.2.225]) by SMTP3.etri.info ([169.254.4.24]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 17:33:28 +0900 From: "Ryoo, Jeong-dong " To: "detnet@ietf.org" Thread-Topic: A new version of ID, draft-jiang-detnet-ring-04.txt is available Thread-Index: AdUswv4yX0k81CYfQHeQdP85lWNpFw== Date: Thu, 27 Jun 2019 08:33:28 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A8710FED1@SMTP2.etri.info> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZyA= x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A8710FED1SMTP2etriinfo_" MIME-Version: 1.0 Archived-At: Subject: [Detnet] A new version of ID, draft-jiang-detnet-ring-04.txt is available X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 08:33:37 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A8710FED1SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSUQsIGRyYWZ0LWppYW5nLWRldG5ldC1yaW5n LTA0LnR4dCBpcyBhdmFpbGFibGUgYXQNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWppYW5nLWRldG5ldC1yaW5nLTA0LnR4dA0KDQoNCg0KVGhpcyBkcmFmdCBk ZXNjcmliZXMgaG93IERldE5ldCBjYW4gYmUgdXNlZCBpbiByaW5nIHRvcG9sb2dpZXMgdG8gc3Vw cG9ydCBib3RoIFBvaW50LXRvLVBvaW50IChQMlApIGFuZCBQb2ludC10by1NdWx0aXBvaW50IChQ Mk1QKSBzZXJ2aWNlcy4gQ29uc2lkZXJpbmcgdGhlIGZhY3QgdGhhdCBwaHlzaWNhbCByaW5nIG5l dHdvcmtzIGFyZSB3aWRlbHkgdXNlZCwgaXQgd291bGQgYmUgYmVuZWZpY2lhbCB0byBoYXZlIGEg ZG9jdW1lbnQgZm9yIHJpbmdzIHRvIHN1cHBvcnQgbm90IG9ubHkgUDJQIGJ1dCBhbHNvIFAyTVAg c2VydmljZXMuDQoNCg0KDQpZb3VyIHF1ZXN0aW9ucywgY29tbWVudHMgYW5kIGZlZWRiYWNrcyBh cmUgd2VsY29tZS4NCg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KDQoNCkplb25nLWRvbmcgKG9uIGJl aGFsZiBvZiBjby1hdXRob3JzKQ0KDQoNCg0KDQoNCg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A8710FED1SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBpZD0iZXpG b3JtUHJvY19kaXYiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDqtbTrprwi Pg0KPGRpdiBpZD0ibXNnYm9keSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1 cHQiPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48Zm9u dCBzaXplPSIzIj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTjogMHB4IDBjbSI+PHNwYW4g bGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUiPkhpIEFsbCw8L2ZvbnQ+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBweCAwY20iPjxzcGFuIGxhbmc9IkVOLVVTIj48 Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj48YnI+DQo8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1UT1A6IDBweCI+PGZvbnQgc2l6ZT0iMyI+ PC9mb250PjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBweCAwY20iPjxzcGFuIGxhbmc9IkVOLVVT Ij48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5BIG5ldyB2ZXJzaW9uIG9mIElELCBkcmFmdC1q aWFuZy1kZXRuZXQtcmluZy0wNC50eHQgaXMgYXZhaWxhYmxlIGF0PC9mb250Pjwvc3Bhbj48L3A+ DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxmb250IHNp emU9IjMiPjwvZm9udD48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwcHggMGNtIj48c3BhbiBsYW5n PSJFTi1VUyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qaWFuZy1kZXRuZXQtcmluZy0wNC50eHQiPjxmb250IGNv bG9yPSIjMDU2M2MxIiBmYWNlPSLrp5HsnYAg6rOg65SVIj5odHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtamlhbmctZGV0bmV0LXJpbmctMDQudHh0PC9mb250PjwvYT48 L3NwYW4+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1U T1A6IDBweCI+PGZvbnQgc2l6ZT0iMyI+PC9mb250PjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46IDBw eCAwY20iPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj4mbmJz cDs8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJ Ti1UT1A6IDBweCI+PGZvbnQgc2l6ZT0iMyI+PC9mb250PjwvcD4NCjxwIHN0eWxlPSJNQVJHSU46 IDBweCAwY20iPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSLrp5HsnYAg6rOg65SVIj5U aGlzIGRyYWZ0IGRlc2NyaWJlcyBob3cgRGV0TmV0IGNhbiBiZSB1c2VkIGluIHJpbmcgdG9wb2xv Z2llcyB0byBzdXBwb3J0IGJvdGggUG9pbnQtdG8tUG9pbnQgKFAyUCkgYW5kIFBvaW50LXRvLU11 bHRpcG9pbnQgKFAyTVApIHNlcnZpY2VzLiBDb25zaWRlcmluZyB0aGUgZmFjdCB0aGF0IHBoeXNp Y2FsIHJpbmcgbmV0d29ya3MgYXJlDQogd2lkZWx5IHVzZWQsIGl0IHdvdWxkIGJlIGJlbmVmaWNp YWwgdG8gaGF2ZSBhIGRvY3VtZW50IGZvciByaW5ncyB0byBzdXBwb3J0IG5vdCBvbmx5IFAyUCBi dXQgYWxzbyBQMk1QIHNlcnZpY2VzLg0KPC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFS R0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxmb250IHNpemU9IjMiPjwvZm9udD48 L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwcHggMGNtIj48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQg ZmFjZT0i66eR7J2AIOqzoOuUlSI+Jm5ic3A7PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i TUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPjxmb250IHNpemU9IjMiPjwvZm9u dD48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwcHggMGNtIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mb250LWtlcm5pbmc6IDBwdCI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+WW91 ciBxdWVzdGlvbnMsIGNvbW1lbnRzIGFuZCBmZWVkYmFja3MgYXJlIHdlbGNvbWUuPC9mb250Pjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgi Pjxmb250IHNpemU9IjMiPjwvZm9udD48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwcHggMGNtIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+Jm5ic3A7PC9mb250 Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAw cHgiPjxmb250IHNpemU9IjMiPjwvZm9udD48L3A+DQo8cCBzdHlsZT0iTUFSR0lOOiAwcHggMGNt Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0i66eR7J2AIOqzoOuUlSI+QmVzdCByZWdh cmRzLDwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFS R0lOLVRPUDogMHB4Ij48Zm9udCBzaXplPSIzIj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJ TjogMHB4IDBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6DrlJUi PiZuYnNwOzwvZm9udD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsg TUFSR0lOLVRPUDogMHB4Ij48Zm9udCBzaXplPSIzIj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Ik1B UkdJTjogMHB4IDBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IuunkeydgCDqs6Dr lJUiPkplb25nLWRvbmcgKG9uIGJlaGFsZiBvZiBjby1hdXRob3JzKTwvZm9udD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4Ij48Zm9udCBz aXplPSIzIj4mbmJzcDs8L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDBweDsg TUFSR0lOLVRPUDogMHB4Ij4mbmJzcDs8L3A+DQo8ZGl2IGlkPSJNYWlsU2lnblNlbnQiPg0KPGRp diBpZD0ia2Fvbmlfc2lnbjIiPg0KPGRpdj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHls ZT0iTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9QOiAwcHgiPiZuYnNwOzwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A8710FED1SMTP2etriinfo_-- From nobody Thu Jun 27 01:47:48 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B011200CD for ; Thu, 27 Jun 2019 01:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0JaMXaixGOc for ; Thu, 27 Jun 2019 01:47:43 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA8612000F for ; Thu, 27 Jun 2019 01:47:43 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CA0C1C684568DDD65EC9; Thu, 27 Jun 2019 09:47:41 +0100 (IST) Received: from dggeme751-chm.china.huawei.com (10.3.19.97) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 09:47:41 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme751-chm.china.huawei.com (10.3.19.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 27 Jun 2019 16:47:39 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1591.008; Thu, 27 Jun 2019 16:47:38 +0800 From: "qiangli (D)" To: Shunsuke Homma , "detnet@ietf.org" CC: "peter.j.willis@bt.com" , 'Liang GENG' Thread-Topic: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwAD//9AhAIACH2xg Date: Thu, 27 Jun 2019 08:47:38 +0000 Message-ID: <92dc836a882543cfb4c79b25fc5124f8@huawei.com> References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <005b01d52bf0$ca9e6020$5fdb2060$@hco.ntt.co.jp> In-Reply-To: <005b01d52bf0$ca9e6020$5fdb2060$@hco.ntt.co.jp> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: multipart/alternative; boundary="_000_92dc836a882543cfb4c79b25fc5124f8huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 08:47:47 -0000 --_000_92dc836a882543cfb4c79b25fc5124f8huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shunsuke, Thanks for your support. "Scalability" is indeed an important requirement, = especially for operators when considering actual deployment. DetNet has con= sidered this point, the DetNet architecture proposed to improve scalability= through flow aggregation. Except for scale to a great amount of traffic fl= ows, 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:shunsuke.homma.fp@hco.ntt.co.jp] Sent: Wednesday, June 26, 2019 3:29 PM To: qiangli (D) ; detnet@ietf.org Cc: peter.j.willis@bt.com; 'Liang GENG' Subject: RE: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi, I agree that these requirements are important, especially from operator's a= spect. 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 requirem= ents in the next revision. Best regards, Shunsuke From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Wednesday, June 26, 2019 12:33 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.= co.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_92dc836a882543cfb4c79b25fc5124f8huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shunsuke,

 

Thanks for your suppor= t. “Scalability” is indeed an important requirement, especially= for operators when considering actual deployment. DetNet has considered this point, the DetNet architecture proposed to improve scalabi= lity through flow aggregation. Except for scale to a great amount of traffi= c flows,   current Req. 7 also mentions the number of network dev= ices.  Do you recommend splitting Req.7 from these two aspects?

 

 

Best regards,

 

Cristina QIANG

 

From: = Shunsuke Homma [mailto:shunsuke.homma.fp@hco.ntt.co.jp]
Sent: Wednesday, June 26, 2019 3:29 PM
To: qiangli (D) <qiangli3@huawei.com>; detnet@ietf.org
Cc: peter.j.willis@bt.com; 'Liang GENG' <liang.geng@hotmail.com&g= t;
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 a= spect.  Services and applications which are latency sensitive will increase more, and it would be required that enough dynamic= ity and scalability for utilizing it in carrier-wide networks.

=  

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

=  

= Best regards,

=  

= Shunsuke

=  

 

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Wednesday, June 26, 2019 12:33 PM
To: detnet@ietf.org
Cc: shunsuke.homm= a.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang G= ENG
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 &a= mp; 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 &a= mp; wander do you expect?

 

BTW, we are going to a= sk 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 colle= cted 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 a= re highly appropriated.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Req. 1: Must support t= he dynamic creation, modification and deletion of deterministic services

 

Req. 2.1: Should suppo= rt asynchronous clocks across domains

Req. 2.2 : Should tole= rate a certain of clock jitter & wander within a clock synchronous doma= in

 

Req. 3: Must support I= nter-Continental propagation delay

 

Req. 4: Should have se= lf-monitoring capability

 

Req. 5: Should be robu= st against denial of service attacks

 

Req. 6: Must tolerate = failures of links or nodes and topology changes

 

Req. 7: Must be scalab= le

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

From: = Liang GENG [mailto:liang.geng@hotmail.com]
Sent: Tuesday, June 11, 2019 11:53 AM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: Black, David <David.Black@dell.com>; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@huawei.com>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised f= or comments

 

Dear all,

 

Since IETF 104, we have carefully revised draft-geng-detnet-r= equirements-bounded-latency-02 according to received comments. The latest 02 version was uploaded and available online <= span lang=3D"EN-US">https://datatracker.ietf.org/doc/dra= ft-geng-detnet-requirements-bounded-latency/. 

 

This new version collects more technical, operational and man= agement requirements of deploying deterministic latency service on layer 3 networks from the perspective of various servic= e providers.

 

Comments are welcome!

 

Best regards,

Liang Geng on behavior of co-authors

 

 

 

--_000_92dc836a882543cfb4c79b25fc5124f8huaweicom_-- From nobody Thu Jun 27 02:25:42 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382661200DB for ; Thu, 27 Jun 2019 02:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWHAAry7uEvN for ; Thu, 27 Jun 2019 02:25:37 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A90812004A for ; Thu, 27 Jun 2019 02:25:36 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id F3174EF07FF1407241A1; Thu, 27 Jun 2019 10:25:34 +0100 (IST) Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 10:25:34 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 27 Jun 2019 17:25:32 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1591.008; Thu, 27 Jun 2019 17:25:32 +0800 From: "qiangli (D)" To: "peter.j.willis@bt.com" , "Janos.Farkas@ericsson.com" CC: "detnet@ietf.org" , "shunsuke.homma.fp@hco.ntt.co.jp" , "liang.geng@hotmail.com" Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwACAAF+FoIAAExFwgAAGYnCAAAsdwIABevmg Date: Thu, 27 Jun 2019 09:25:32 +0000 Message-ID: <37358fdaf8464d1295cfaadf0975fe44@huawei.com> References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <83dac230ca6d4035841b9d6a527ea16f@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: multipart/alternative; boundary="_000_37358fdaf8464d1295cfaadf0975fe44huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 09:25:40 -0000 --_000_37358fdaf8464d1295cfaadf0975fe44huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, The relationship between clock jitter& wander and packet jitter is very com= plicated, varies a lot depend on different mechanisms. I know there are som= e time synch stands such as G.8273.2, G.8262. Is it helpful to reference th= is stands? Best regards, Cristina QIANG From: peter.j.willis@bt.com [mailto:peter.j.willis@bt.com] Sent: Wednesday, June 26, 2019 6:20 PM To: Janos.Farkas@ericsson.com; qiangli (D) Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; liang.geng@hotmail.co= m 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 hig= hly accurate clocks in routers so prefer Detnet to work with the current cl= ocks I have in routers. For an exact specification we would have to list th= e clock specifications in the typical routers that network operators use (i= t'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 pr= actice. 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 > Sent: 26 June 2019 10:37 To: qiangli (D) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; Willis,PJ,Peter,TUD1 R >; Liang GENG > 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 deplo= yment/application/use case. For instance, in some cases, synchronization wo= uld be not needed at all; e.g., if the DetNet high availability / high reli= ability feature is what is really needed for the given case; or an asynchro= nous solution is used to achieve bounded low latency. Best regards, Janos From: qiangli (D) > Sent: Wednesday, June 26, 2019 11:29 AM To: Janos Farkas > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 fo= llows 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 o= f 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 n= eed to further specify more details. What do you think. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Best regards, Cristina QIANG From: Janos Farkas [mailto:Janos.Farkas@ericsson.com] Sent: Wednesday, June 26, 2019 4:28 PM To: qiangli (D) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 docum= ent 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 > On B= ehalf Of qiangli (D) Sent: Wednesday, June 26, 2019 5:33 AM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.= co.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_37358fdaf8464d1295cfaadf0975fe44huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

The relationship betwe= en 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 referenc= e this stands?

 

 

Best regards,

 

Cristina QIANG

 

From: = peter.j.willis@bt.com [mailto:peter.j.willis@bt.com]
Sent: Wednesday, June 26, 2019 6:20 PM
To: Janos.Farkas@ericsson.com; qiangli (D) <qiangli3@huawei.com&g= t;
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; liang.geng@hot= mail.com
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Colleague= s,

&nbs= p;

From a ne= twork 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 o= perators use (it’s not information I have at my fingertips).

&nbs= p;

I also pu= t this requirement in to test what assumptions we are making about clock ji= tter & wander, and to check those assumptions are reasonable in practice. If there is a correlation between clock jitter &am= p; wander and packet jitter then that needs to be understood and stated.

&nbs= p;

Best Rega= rds,

Peter.

&nbs= p;

From: = Janos Farkas <Janos.Farkas@ericsson.com= >
Sent: 26 June 2019 10:37
To: qiangli (D) <qiangli3@huawei.com&g= t;
Cc: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; Willis,PJ,Peter,TUD1 R <peter.j.willis@bt.com>; Liang GENG <liang.geng@hotmail.com> Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Cristina,

 

Thank you for your quick response.

 

I’d like to have what others t= hink.

 

Just one more note on my side: I thi= nk it depends a lot on the actual deployment/application/use case. For inst= ance, in some cases, synchronization would be not needed at all; e.g., if the DetNet high availability / high reliability fe= ature is what is really needed for the given case; or an asynchronous solut= ion is used to achieve bounded low latency.

 

Best regards,

Janos

 

From: = qiangli (D) <qiangli3@huawei.com>
Sent: Wednesday, June 26, 2019 11:29 AM
To: Janos Farkas <Janos.Farkas@ericsson.com>
Cc: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter= .j.willis@bt.com; Liang GENG <= liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed 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 deg= ree of clock jitter & wander DetNet can tolerate, is to detail the curr= ent text. According to your reply, I understand that DetNet just simply use= s what is available.  So maybe we can simply list some existing standards here, no need to further specify more = details. What do you think.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

2.2.2.  Sub-requi= rement 2.2: Should tolerate clock jitter & wander

   &nbs= p;    within a clock synchronous domain

 

   DetNet do= main itself can be time synchronous or asynchronous,

   depending= on the technology selection of different operators.  Even<= /span>

   within a = time synchronous domain, the synchronized clocks may also=

   experienc= e jitter & wander, the mechanisms adopted by DetNet should

   be able t= o tolerate a certain degree of clock jitter & wander.=

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

Best regards,

 

Cristina QIANG

 

From: = Janos Farkas [mailto:Janos.Farkas@ericsson.com]
Sent: Wednesday, June 26, 2019 4:28 PM
To: qiangli (D) <qiangli3@huawei.com&g= t;
Cc: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter= .j.willis@bt.com; Liang GENG <= liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Cristina,

 

My understanding of the consensus of= the WG based on the Architecture document is that synchronization is ackno= wledged to be important; however, it is not the job of DetNet to specify the details, solutions, etc.; DetNet just uses wh= at is available, specified by other standards.

 

Best regards,

Janos

 

From: = detnet <detnet-bounces@ietf.org> On Behalf Of qiangli (D)
Sent: Wednesday, June 26, 2019 5:33 AM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter= .j.willis@bt.com; Liang GENG <= liang.geng@hotmail.com>
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 &a= mp; 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 &a= mp; wander do you expect?

 

BTW, we are going to a= sk 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:detnet-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Monday, June 17, 2019 4:11 PM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter= .j.willis@bt.com; Liang GENG <= liang.geng@hotmail.com>
Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency= -02 revised for comments

 

Hi all,

 

This version has colle= cted 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 a= re highly appropriated.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Req. 1: Must support t= he dynamic creation, modification and deletion of deterministic services

 

Req. 2.1: Should suppo= rt asynchronous clocks across domains

Req. 2.2 : Should tole= rate a certain of clock jitter & wander within a clock synchronous doma= in

 

Req. 3: Must support I= nter-Continental propagation delay

 

Req. 4: Should have se= lf-monitoring capability

 

Req. 5: Should be robu= st against denial of service attacks

 

Req. 6: Must tolerate = failures of links or nodes and topology changes

 

Req. 7: Must be scalab= le

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

From: = Liang GENG [mailto:liang.geng@hotmail.com]
Sent: Tuesday, June 11, 2019 11:53 AM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: Black, David <David.Black@dell.com>; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@huawei.com>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised f= or comments

 

Dear all,

 

Since IETF 104, we have caref= ully 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/dra= ft-geng-detnet-requirements-bounded-latency/. 

 

This new version collects mor= e technical, operational and management requirements of deploying determini= stic 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

 

 

 

--_000_37358fdaf8464d1295cfaadf0975fe44huaweicom_-- From nobody Thu Jun 27 03:27:47 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BD8120152 for ; Thu, 27 Jun 2019 03:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS9ntD3cQk6N for ; Thu, 27 Jun 2019 03:27:43 -0700 (PDT) Received: from dish-sg.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp [202.19.227.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB36120058 for ; Thu, 27 Jun 2019 03:27:43 -0700 (PDT) X-dD-Source: Outbound Received: from zssg-mailmd104.ddreams.local (zssg-mailmd900.ddreams.local [10.160.172.63]) by zssg-mailou104.ddreams.local (Postfix) with ESMTP id B6C0812011D; Thu, 27 Jun 2019 19:27:42 +0900 (JST) Received: from zssg-mailmf102.ddreams.local (zssg-mailmf900.ddreams.local [10.160.172.84]) by zssg-mailmd104.ddreams.local (dDREAMS) with ESMTP id <0PTR00UKM6E6WW50@dDREAMS>; Thu, 27 Jun 2019 19:27:42 +0900 (JST) Received: from zssg-mailmf102.ddreams.local (unknown [127.0.0.1]) by zssg-mailmf102.ddreams.local (Postfix) with ESMTP id 8B2BB7E6032; Thu, 27 Jun 2019 19:27:42 +0900 (JST) Received: from zssg-mailmf102.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8A01C8E6054; Thu, 27 Jun 2019 19:27:42 +0900 (JST) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 7F1218E6052; Thu, 27 Jun 2019 19:27:42 +0900 (JST) X-IMSS-HAND-OFF-DIRECTIVE: localhost:10026 Received: from zssg-mailmf102.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EB4128E6042; Thu, 27 Jun 2019 19:27:41 +0900 (JST) Received: from zssg-mailua105.ddreams.local (unknown [10.160.172.62]) by zssg-mailmf102.ddreams.local (Postfix) with ESMTP; Thu, 27 Jun 2019 19:27:41 +0900 (JST) Received: from RDSVVDI0392 (unknown [10.171.80.137]) by zssg-mailua105.ddreams.local (dDREAMS) with ESMTPA id <0PTR014Z26DPCDB0@dDREAMS>; Thu, 27 Jun 2019 19:27:41 +0900 (JST) From: Shunsuke Homma References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <005b01d52bf0$ca9e6020$5fdb2060$@hco.ntt.co.jp> <92dc836a882543cfb4c79b25fc5124f8@huawei.com> In-reply-to: <92dc836a882543cfb4c79b25fc5124f8@huawei.com> Date: Thu, 27 Jun 2019 19:27:25 +0900 Message-id: <01a901d52cd2$e9a42260$bcec6720$@hco.ntt.co.jp> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_01AA_01D52D1E.598E3B60" X-Mailer: Microsoft Outlook 14.0 Content-language: ja Thread-index: AQMnmUkp2H0Pi7SVpr3C7kb4R5YXsAHemyVbAl6tjtoBWeluNwHR+enGo88pgHA= To: "'qiangli (D)'" , detnet@ietf.org Cc: peter.j.willis@bt.com, 'Liang GENG' X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 10:27:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AA_01D52D1E.598E3B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:qiangli3@huawei.com] Sent: Thursday, June 27, 2019 5:48 PM To: Shunsuke Homma; detnet@ietf.org Cc: peter.j.willis@bt.com; '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 From: Shunsuke Homma [mailto:shunsuke.homma.fp@hco.ntt.co.jp] Sent: Wednesday, June 26, 2019 3:29 PM To: qiangli (D) ; detnet@ietf.org Cc: peter.j.willis@bt.com; 'Liang GENG' 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 From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Wednesday, June 26, 2019 12:33 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; 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 From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GENG 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:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David < David.Black@dell.com>; peter..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) < qiangli3@huawei.com> 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 ------=_NextPart_000_01AA_01D52D1E.598E3B60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:qiangli3@huawei.com]
Sent: Thursday, June 27, = 2019 5:48 PM
To: Shunsuke Homma; detnet@ietf.org
Cc: = peter.j.willis@bt.com; '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

 

From: Shunsuke Homma [mailto:shunsuke.homma.fp@hco.ntt.co.jp] =
Sent: Wednesday, June 26, 2019 3:29 PM
To: qiangli = (D) <qiangli3@huawei.com>; detnet@ietf.org
Cc: = peter.j.willis@bt.com; 'Liang GENG' = <liang.geng@hotmail.com>
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

 

 

From:= detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Wednesday, June 26, = 2019 12:33 PM
To: detnet@ietf.org
Cc: shunsuke.homma.fp@hco.ntt= .co.jp; peter.j.willis@bt.com; 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

 

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Monday, June 17, 2019 = 4:11 PM
To: detnet@ietf.org
Cc: shunsuke.homma.fp@hco.ntt= .co.jp; peter.j.willis@bt.com; Liang = GENG <liang.geng@hotmail.com>
= 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.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina = QIANG

 

From: Liang GENG [mailto:lian= g.geng@hotmail.com]
Sent: Tuesday, June 11, 2019 11:53 = AM
To: detnet@ietf= .org<= br>Cc: Black, David <David.Black= @dell.com>; peter..j.wi= llis@bt.com; shunsuke.ho= mma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@hu= awei.com>
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://dat= atracker.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

 

 

 

------=_NextPart_000_01AA_01D52D1E.598E3B60-- From nobody Thu Jun 27 03:59:40 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7801200EB for ; Thu, 27 Jun 2019 03:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNOk84jEE2Dp for ; Thu, 27 Jun 2019 03:59:34 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B4B12009E for ; Thu, 27 Jun 2019 03:59:33 -0700 (PDT) Received: from tpw09926dag06g.domain1.systemhost.net (10.9.202.29) by BWP09926079.bt.com (10.36.82.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Thu, 27 Jun 2019 11:59:29 +0100 Received: from tpw09926dag14h.domain1.systemhost.net (10.9.212.38) by tpw09926dag06g.domain1.systemhost.net (10.9.202.29) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Jun 2019 11:59:31 +0100 Received: from RDW083A012ED68.bt.com (10.187.98.38) by tpw09926dag14h.domain1.systemhost.net (10.9.212.38) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 27 Jun 2019 11:59:31 +0100 Received: from GBR01-LO2-obe.outbound.protection.outlook.com (104.47.21.51) by smtpe1.intersmtp.com (62.239.224.234) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 27 Jun 2019 11:59:12 +0100 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=rWxyDJjjMrkQs5vIEuVEkjlszrKz4xWPewLr8mKtwnv6lqha/nMyaWaJcbxtw5VSJH11w8xlZhTifWg+tGgLWPvFCssiJA5oe2g2ffKTNnoFgr/5ayInvwpL/dbORZCMnywkFEkcRlS9TdiW41kNmPr27Ef1tRAN8EwVum5MY4M= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UUghIXcDb+gq+jA0dHzC0+6jvYI58Rwv/Ia5mFdlcKs=; b=jCWHpKa99+EkjQdaVWaEr8wq/Q6cqKEoXLC6AnT8k5Jy0TO/ccosTN8TyhBh77EmBRzoJOQgKQ/vU3wrzitESI6HIkupNHXwltz8bM3meCaPDELEMmFW5ulEnDIMxDtjTrrBcjBn5QhEYWm8ZDD+PYnWbdZRRFZgxvAcDyFIOug= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UUghIXcDb+gq+jA0dHzC0+6jvYI58Rwv/Ia5mFdlcKs=; b=mZUe6DI56oru3Rq1UDU0dTPEcAIj9xksLexdHdRDdVLvCwRiqSHzBNTGjiUwT/cZmcd20EkXqcbx2E7V2ZML8tomQ6HTNayd6PqpraBYyexqoeIIMGfTfC1e3yy5UVOJRsuAmKIS0U2yXYJTt2hIzKsRywiAOS2+yZSexG4m9jg= Received: from LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM (20.179.130.207) by LNXP123MB1948.GBRP123.PROD.OUTLOOK.COM (20.179.131.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Thu, 27 Jun 2019 10:59:29 +0000 Received: from LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM ([fe80::c833:389:1184:bc]) by LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM ([fe80::c833:389:1184:bc%7]) with mapi id 15.20.2008.014; Thu, 27 Jun 2019 10:59:29 +0000 From: To: , CC: , , Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwACAAF+FoIAAExFwgAAGYnCAAAsdwIABevmggAAipsA= Date: Thu, 27 Jun 2019 10:59:29 +0000 Message-ID: References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <83dac230ca6d4035841b9d6a527ea16f@huawei.com> <37358fdaf8464d1295cfaadf0975fe44@huawei.com> In-Reply-To: <37358fdaf8464d1295cfaadf0975fe44@huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=peter.j.willis@bt.com; x-originating-ip: [193.113.37.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f182c7ac-bdcc-4126-8f41-08d6faee871b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LNXP123MB1948; x-ms-traffictypediagnostic: LNXP123MB1948: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(136003)(366004)(376002)(199004)(53754006)(189003)(99286004)(6506007)(6436002)(76176011)(71200400001)(53546011)(8676002)(64756008)(86362001)(606006)(3846002)(790700001)(66066001)(66446008)(186003)(54896002)(14454004)(966005)(2906002)(7696005)(66476007)(5660300002)(73956011)(74316002)(446003)(68736007)(476003)(52536014)(81166006)(102836004)(486006)(71190400001)(11346002)(53946003)(33656002)(76116006)(229853002)(66556008)(45080400002)(6116002)(66946007)(26005)(110136005)(81156014)(6246003)(8936002)(256004)(14444005)(2501003)(55016002)(7736002)(4326008)(478600001)(54906003)(6306002)(236005)(53936002)(316002)(9686003)(25786009)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:LNXP123MB1948; H:LNXP123MB2411.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mKlvDA5jYIRVzrPGCotODj/ToOFLfkRDdRy0WEDtK4NQmvq56ASprbhQ0Vtba9tON61hq0H2A++oVUdbf8YKQotndXiIoaDwefGL6izbTEEHbX/bd1icJnLeozTDEioiJ0BKwbD1RXhiq/RAMgo0BSNhA6UuexQvvPZCD6Eg8bY6Ap0g8eBB5YUOotfhhQ2OAN3FRl1yOrSW9L39TvZuIsnO0hW/ZZkzQ507mFtaKsDo/OVUfE69eyvorDvKsbfwp0B5RV7ZIIcUtvWtyAeXKqanfE/U7F0pPG7r7CELUWSGxAdIYv1hbx5o1YCx/6zIpiLqUPEIZ5rYJ8QaMHJwPBRU/gPUec60LILzoCr8CzfYsZImZwvQXAdZwECO7AX/J9jLAwJIDRZXjl52zTRndF4n4fmL79AUKlapC1Ljupk= Content-Type: multipart/alternative; boundary="_000_LNXP123MB24111037D9266CF73C940D28BBFD0LNXP123MB2411GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f182c7ac-bdcc-4126-8f41-08d6faee871b X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 10:59:29.4305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: peter.j.willis@bt.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB1948 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 10:59:39 -0000 --_000_LNXP123MB24111037D9266CF73C940D28BBFD0LNXP123MB2411GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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) Sent: 27 June 2019 10:26 To: Willis,PJ,Peter,TUD1 R ; Janos.Farkas@ericsson.c= om Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; liang.geng@hotmail.co= m 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 com= plicated, varies a lot depend on different mechanisms. I know there are som= e time synch stands such as G.8273.2, G.8262. Is it helpful to reference th= is stands? Best regards, Cristina QIANG From: peter.j.willis@bt.com [mailto:peter.j.w= illis@bt.com] Sent: Wednesday, June 26, 2019 6:20 PM To: Janos.Farkas@ericsson.com; qiangli (D= ) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; liang.geng@hotmail.com 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 hig= hly accurate clocks in routers so prefer Detnet to work with the current cl= ocks I have in routers. For an exact specification we would have to list th= e clock specifications in the typical routers that network operators use (i= t'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 pr= actice. 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 > Sent: 26 June 2019 10:37 To: qiangli (D) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; Willis,PJ,Peter,TUD1 R >; Liang GENG > 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 deplo= yment/application/use case. For instance, in some cases, synchronization wo= uld be not needed at all; e.g., if the DetNet high availability / high reli= ability feature is what is really needed for the given case; or an asynchro= nous solution is used to achieve bounded low latency. Best regards, Janos From: qiangli (D) > Sent: Wednesday, June 26, 2019 11:29 AM To: Janos Farkas > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 fo= llows 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 o= f 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 n= eed to further specify more details. What do you think. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Best regards, Cristina QIANG From: Janos Farkas [mailto:Janos.Farkas@ericsson.com] Sent: Wednesday, June 26, 2019 4:28 PM To: qiangli (D) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 docum= ent 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 > On B= ehalf Of qiangli (D) Sent: Wednesday, June 26, 2019 5:33 AM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.= co.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_LNXP123MB24111037D9266CF73C940D28BBFD0LNXP123MB2411GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cristina,

 =

Personally I think it wo= uld be useful to reference such ITU standards if it does not cause IETF pro= cedure issues.

 =

Best Regards,=

Peter.=

 =

From: = qiangli (D) <qiangli3@huawei.com>
Sent: 27 June 2019 10:26
To: Willis,PJ,Peter,TUD1 R <peter.j.willis@bt.com>; Janos.Fark= as@ericsson.com
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; liang.geng@hot= mail.com
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed 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.82= 62. Is it helpful to reference this stands?

 

 

Best regards,

 

Cristina QIANG

 

From:<= /span> peter.j.willis@bt.com [mailto:peter.j.willis@bt.com]
Sent: Wednesday, June 26, 2019 6:20 PM
To: Janos.Farkas@ericss= on.com; qiangli (D) <qiangli3= @huawei.com>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; liang.geng@hotmail.com
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Colleagues,

 =

From a network operator&= #8217;s point of view I do not want the extra cost of highly accurate clock= s 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 requirem= ent in to test what assumptions we are making about clock jitter & wand= er, and to check those assumptions are reasonable in practice. If there is a correlation between clock jitter & wander a= nd packet jitter then that needs to be understood and stated.

 =

Best Regards,=

Peter.=

 =

From:<= /span> Janos Farkas <Janos.Farkas@ericsson.com>
Sent: 26 June 2019 10:37
To: qiangli (D) <qiangli3@huawei.co= m>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; Willis,PJ,Peter,TUD1 R <peter.j.willis@= bt.com>; Liang GENG <liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

&nbs= p;

Hi Cristi= na,

&nbs= p;

Thank you= for your quick response.

&nbs= p;

I’d= like to have what others think.

&nbs= p;

Just one = more note on my side: I think it depends a lot on the actual deployment/app= lication/use case. For instance, in some cases, synchronization would be not needed at all; e.g., if the DetNet high avail= ability / high reliability feature is what is really needed for the given c= ase; or an asynchronous solution is used to achieve bounded low latency.

&nbs= p;

Best rega= rds,

Janos

&nbs= p;

From:<= /span> qiangli (D) <<= a href=3D"mailto:qiangli3@huawei.com">qiangli3@huawei.com>
Sent: Wednesday, June 26, 2019 11:29 AM
To: Janos Farkas <Janos.Fark= as@ericsson.com>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GENG <liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed 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 D= etNet 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.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

2.2.2.  Sub-requirement 2.2: Should tolerate clock jitter & w= ander

        within a clock synchronous = domain

 

   DetNet domain itself can be time synchronous or asynchron= ous,

   depending on the technology selection of different operat= ors.  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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

From:<= /span> Janos Farkas [mailto:Janos.Farkas@ericsson.com]
Sent: Wednesday, June 26, 2019 4:28 PM
To: qiangli (D) <qiangli3@huawei.co= m>
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang GENG <liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Cristi= na,

&nbs= p;

My unders= tanding of the consensus of the WG based on the Architecture document is th= at synchronization is acknowledged to be important; however, it is not the job of DetNet to specify the details, solutions, et= c.; DetNet just uses what is available, specified by other standards.<= /o:p>

&nbs= p;

Best rega= rds,

Janos

&nbs= p;

From:<= /span> detnet <detnet-bounces@ietf.org> On Behalf Of qiangli (D)
Sent: Wednesday, June 26, 2019 5:33 AM
To: detnet@ietf.org
Cc: shunsuke.homma.fp@hco.= ntt.co.jp; peter.j.willis@bt.com; Liang GENG <liang.geng@hotmail.com>
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 certai= n degree of clock jitter & wander even within a time synchronous domain. We would like to know if you agree or disagree wi= th this requirement. If you think this requirement is necessary, then to wh= at 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:<= /span> detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Monday, June 17, 2019 4:11 PM
To: detnet@ietf.org
Cc: shunsuke.homma.fp@hco.= ntt.co.jp; peter.j.willis@bt.com; Liang GENG <liang.geng@hotmail.com>
Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency= -02 revised for comments

 

Hi all,

 

This version has collected 7 requirements, and divided these requireme= nts into optional (SHOULD) and mandatory (MUST) two types as following shows. We authors would like to know if this requir= ement list is complete, and if the classification is appropriate or not. &n= bsp;Your review and comments are highly appropriated.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Req. 1: Must support the dynamic creation, modification and deletion o= f deterministic services

 

Req. 2.1: Should support asynchronous clocks across domains=

Req. 2.2 : Should tolerate a certain of clock jitter & wander with= in 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<= /span>

 

Req. 6: Must tolerate failures of links or nodes and topology changes<= o:p>

 

Req. 7: Must be scalable

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

 

Dear all,

 

Since IETF 104, we have careful= ly revised draft-geng-detnet-requirements-bounded-latency-02 according to r= eceived comments. The latest 02 version was uploaded and available online https://datatracker.ietf.org/doc/draft-geng-detnet-requirements-bounded-la= tency/. 

 

This new version collects more = technical, operational and management requirements of deploying determinist= ic latency service on layer 3 networks from the perspective of various service providers.

 

Comments are welcome!

 

Best regards,=

Liang Geng on behavior of co-au= thors

 

 

 

--_000_LNXP123MB24111037D9266CF73C940D28BBFD0LNXP123MB2411GBRP_-- From nobody Thu Jun 27 05:01:20 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00219120170 for ; Thu, 27 Jun 2019 05:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eURUmaXOXsc9 for ; Thu, 27 Jun 2019 05:01:15 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA72212004A for ; Thu, 27 Jun 2019 05:01:14 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 7BFCFDE79B8FEF154B09; Thu, 27 Jun 2019 13:01:13 +0100 (IST) Received: from dggeme701-chm.china.huawei.com (10.1.199.97) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 13:01:13 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme701-chm.china.huawei.com (10.1.199.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 27 Jun 2019 20:01:10 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1591.008; Thu, 27 Jun 2019 20:01:10 +0800 From: "qiangli (D)" To: "peter.j.willis@bt.com" , "Janos.Farkas@ericsson.com" CC: "detnet@ietf.org" , "shunsuke.homma.fp@hco.ntt.co.jp" , "liang.geng@hotmail.com" Thread-Topic: draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwACAAF+FoIAAExFwgAAGYnCAAAsdwIABevmggAAipsCAAAQewA== Date: Thu, 27 Jun 2019 12:01:10 +0000 Message-ID: References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <83dac230ca6d4035841b9d6a527ea16f@huawei.com> <37358fdaf8464d1295cfaadf0975fe44@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: multipart/alternative; boundary="_000_d0064d37fb15475888c8aec068df687bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 12:01:19 -0000 --_000_d0064d37fb15475888c8aec068df687bhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, Referencing ITU standards is acceptable IMHO. Let's see others' opinion. Best regards, Cristina QIANG From: peter.j.willis@bt.com [mailto:peter.j.willis@bt.com] Sent: Thursday, June 27, 2019 6:59 PM To: qiangli (D) ; Janos.Farkas@ericsson.com Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; liang.geng@hotmail.co= m 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) > Sent: 27 June 2019 10:26 To: Willis,PJ,Peter,TUD1 R >; Janos.Farkas@ericsson.com Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; liang.geng@hotmail.com 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 com= plicated, varies a lot depend on different mechanisms. I know there are som= e time synch stands such as G.8273.2, G.8262. Is it helpful to reference th= is stands? Best regards, Cristina QIANG From: peter.j.willis@bt.com [mailto:peter.j.w= illis@bt.com] Sent: Wednesday, June 26, 2019 6:20 PM To: Janos.Farkas@ericsson.com; qiangli (D= ) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; liang.geng@hotmail.com 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 hig= hly accurate clocks in routers so prefer Detnet to work with the current cl= ocks I have in routers. For an exact specification we would have to list th= e clock specifications in the typical routers that network operators use (i= t'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 pr= actice. 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 > Sent: 26 June 2019 10:37 To: qiangli (D) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; Willis,PJ,Peter,TUD1 R >; Liang GENG > 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 deplo= yment/application/use case. For instance, in some cases, synchronization wo= uld be not needed at all; e.g., if the DetNet high availability / high reli= ability feature is what is really needed for the given case; or an asynchro= nous solution is used to achieve bounded low latency. Best regards, Janos From: qiangli (D) > Sent: Wednesday, June 26, 2019 11:29 AM To: Janos Farkas > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 fo= llows 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 o= f 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 n= eed to further specify more details. What do you think. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Best regards, Cristina QIANG From: Janos Farkas [mailto:Janos.Farkas@ericsson.com] Sent: Wednesday, June 26, 2019 4:28 PM To: qiangli (D) > Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.j= p; peter.j.willis@bt.com; Liang GENG > 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 docum= ent 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 > On B= ehalf Of qiangli (D) Sent: Wednesday, June 26, 2019 5:33 AM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.= co.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_d0064d37fb15475888c8aec068df687bhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

Referencing ITU standa= rds is acceptable IMHO. Let's see others’ opinion.<= /p>

 

Best regards,

 

Cristina QIANG

 

From: = peter.j.willis@bt.com [mailto:peter.j.willis@bt.com]
Sent: Thursday, June 27, 2019 6:59 PM
To: qiangli (D) <qiangli3@huawei.com>; Janos.Farkas@ericsson.c= om
Cc: detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; liang.geng@hot= mail.com
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Cristina,=

&nbs= p;

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

&nbs= p;

Best Rega= rdsyyo

Peter.

&nbs= p;

From: = qiangli (D) <qiangli3@huawei.com>
Sent: 27 June 2019 10:26
To: Willis,PJ,Peter,TUD1 R <peter.j.willis@bt.com<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,sans-serif">>; J= anos.Farkas@ericsson.com
Cc: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; lian= g.geng@hotmail.com
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Peter,

 

The relationship betwe= en 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 referenc= e this stands?

 

 

Best regards,

 

Cristina QIANG

 

From: peter= .j.willis@bt.com [mailto:peter.j.willis@bt.com= ]
Sent: Wednesday, June 26, 2019 6:20 PM
To: Janos.Farkas@ericsson.com; qiangli (D) <qiangli3@huawei.com>
Cc: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; lian= g.geng@hotmail.com
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Colleague= s,

&nbs= p;

From a ne= twork 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 o= perators use (it’s not information I have at my fingertips).

&nbs= p;

I also pu= t this requirement in to test what assumptions we are making about clock ji= tter & wander, and to check those assumptions are reasonable in practice. If there is a correlation between clock jitter &am= p; wander and packet jitter then that needs to be understood and stated.

&nbs= p;

Best Rega= rds,

Peter.

&nbs= p;

From: = Janos Farkas <Janos.Farkas@ericsson.com= >
Sent: 26 June 2019 10:37
To: qiangli (D) <qiangli3@huawei.com&g= t;
Cc: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; Willis,PJ,Peter,TUD1 R <peter.j.willis@bt.com>; Liang GENG <liang.geng@hotmail.com> Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Cristina,

 

Thank you for your quick response.

 

I’d like to have what others t= hink.

 

Just one more note on my side: I thi= nk it depends a lot on the actual deployment/application/use case. For inst= ance, in some cases, synchronization would be not needed at all; e.g., if the DetNet high availability / high reliability fe= ature is what is really needed for the given case; or an asynchronous solut= ion is used to achieve bounded low latency.

 

Best regards,

Janos

 

From: = qiangli (D) <qiangli3@huawei.com>
Sent: Wednesday, June 26, 2019 11:29 AM
To: Janos Farkas <Janos.Farkas@ericsson.com>
Cc: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter= .j.willis@bt.com; Liang GENG <= liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed 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 deg= ree of clock jitter & wander DetNet can tolerate, is to detail the curr= ent text. According to your reply, I understand that DetNet just simply use= s what is available.  So maybe we can simply list some existing standards here, no need to further specify more = details. What do you think.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

2.2.2.  Sub-requi= rement 2.2: Should tolerate clock jitter & wander

   &nbs= p;    within a clock synchronous domain

 

   DetNet do= main itself can be time synchronous or asynchronous,

   depending= on the technology selection of different operators.  Even<= /span>

   within a = time synchronous domain, the synchronized clocks may also=

   experienc= e jitter & wander, the mechanisms adopted by DetNet should

   be able t= o tolerate a certain degree of clock jitter & wander.=

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

Best regards,

 

Cristina QIANG

 

From: = Janos Farkas [mailto:Janos.Farkas@ericsson.com]
Sent: Wednesday, June 26, 2019 4:28 PM
To: qiangli (D) <qiangli3@huawei.com&g= t;
Cc: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; peter= .j.willis@bt.com; Liang GENG <= liang.geng@hotmail.com>
Subject: RE: draft-geng-detnet-requirements-bounded-latency-02 revis= ed for comments

 

Hi Cristina,

 

My understanding of the consensus of= the WG based on the Architecture document is that synchronization is ackno= wledged to be important; however, it is not the job of DetNet to specify the details, solutions, etc.; DetNet just uses wh= at is available, specified by other standards.

 

Best regards,

Janos

 

From: = detnet <detnet-bounces@ietf.org> On Behalf Of qiangli (D)
Sent: Wednesday, June 26, 2019 5:33 AM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter= .j.willis@bt.com; Liang GENG <= liang.geng@hotmail.com>
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 &a= mp; 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 &a= mp; wander do you expect?

 

BTW, we are going to a= sk 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:detnet-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Monday, June 17, 2019 4:11 PM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: shunsuke.homma.fp@hco.ntt.co.jp; peter= .j.willis@bt.com; Liang GENG <= liang.geng@hotmail.com>
Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency= -02 revised for comments

 

Hi all,

 

This version has colle= cted 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 a= re highly appropriated.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Req. 1: Must support t= he dynamic creation, modification and deletion of deterministic services

 

Req. 2.1: Should suppo= rt asynchronous clocks across domains

Req. 2.2 : Should tole= rate a certain of clock jitter & wander within a clock synchronous doma= in

 

Req. 3: Must support I= nter-Continental propagation delay

 

Req. 4: Should have se= lf-monitoring capability

 

Req. 5: Should be robu= st against denial of service attacks

 

Req. 6: Must tolerate = failures of links or nodes and topology changes

 

Req. 7: Must be scalab= le

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

From: = Liang GENG [mailto:liang.geng@hotmail.com]
Sent: Tuesday, June 11, 2019 11:53 AM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: Black, David <David.Black@dell.com>; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@huawei.com>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised f= or comments

 

Dear all,

 

Since IETF 104, we have caref= ully 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/dra= ft-geng-detnet-requirements-bounded-latency/. 

 

This new version collects mor= e technical, operational and management requirements of deploying determini= stic 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

 

 

 

--_000_d0064d37fb15475888c8aec068df687bhuaweicom_-- From nobody Thu Jun 27 06:24:01 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C2012013C for ; Thu, 27 Jun 2019 06:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-gRX1m8JKKw for ; Thu, 27 Jun 2019 06:23:55 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BB1120043 for ; Thu, 27 Jun 2019 06:23:55 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 647D586DF04A69C8021E; Thu, 27 Jun 2019 14:23:53 +0100 (IST) Received: from dggeme702-chm.china.huawei.com (10.1.199.98) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 14:23:52 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme702-chm.china.huawei.com (10.1.199.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 27 Jun 2019 21:23:50 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1591.008; Thu, 27 Jun 2019 21:23:50 +0800 From: "qiangli (D)" To: Shunsuke Homma , "detnet@ietf.org" CC: "peter.j.willis@bt.com" , 'Liang GENG' Thread-Topic: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwAD//9AhAIACH2xg//+k04CAAKQYEA== Date: Thu, 27 Jun 2019 13:23:50 +0000 Message-ID: <8c420ab49d47466288fab3e2a00de3f9@huawei.com> References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <005b01d52bf0$ca9e6020$5fdb2060$@hco.ntt.co.jp> <92dc836a882543cfb4c79b25fc5124f8@huawei.com> <01a901d52cd2$e9a42260$bcec6720$@hco.ntt.co.jp> In-Reply-To: <01a901d52cd2$e9a42260$bcec6720$@hco.ntt.co.jp> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: multipart/alternative; boundary="_000_8c420ab49d47466288fab3e2a00de3f9huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 13:23:58 -0000 --_000_8c420ab49d47466288fab3e2a00de3f9huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Shunsuke, Thank you for your comments. We will try to analyze "scalability" in detai= l next version. But I'm afraid we couldn't go so deep as you suggested, sin= ce like the load of process, the chips are OS/hardware related, is not in I= ETF's scope. Best regards, Cristina QIANG From: Shunsuke Homma [mailto:shunsuke.homma.fp@hco.ntt.co.jp] Sent: Thursday, June 27, 2019 6:27 PM To: qiangli (D) ; detnet@ietf.org Cc: peter.j.willis@bt.com; 'Liang GENG' Subject: RE: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi Cristina, >From operator's aspect, in addition to the number of network devices, the n= umber of accommodated end devices and services would be important. Also, th= e 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 requi= rements on scalability. Best regards, Shunsuke From: qiangli (D) [mailto:qiangli3@huawei.com] Sent: Thursday, June 27, 2019 5:48 PM To: Shunsuke Homma; detnet@ietf.org Cc: peter.j.willis@bt.com; 'Liang GENG' Subject: RE: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi Shunsuke, Thanks for your support. "Scalability" is indeed an important requirement, = especially for operators when considering actual deployment. DetNet has con= sidered this point, the DetNet architecture proposed to improve scalability= through flow aggregation. Except for scale to a great amount of traffic fl= ows, 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:shunsuke.homma.fp@hco.ntt.co.jp] Sent: Wednesday, June 26, 2019 3:29 PM To: qiangli (D) >; detnet@i= etf.org Cc: peter.j.willis@bt.com; 'Liang GENG' > Subject: RE: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi, I agree that these requirements are important, especially from operator's a= spect. 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 requirem= ents in the next revision. Best regards, Shunsuke From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Wednesday, June 26, 2019 12:33 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, The Req. 2.2 discusses that DetNet should be able to tolerate a certain deg= ree of clock jitter & wander even within a time synchronous domain. We woul= d 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 & wande= r do you expect? BTW, we are going to ask for WG adoption for this document in IETF 105 meet= ing. That's will be greatly appreciated if you can share your comments to h= elp us further improve this draft. Best regards, Cristina QIANG From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D) Sent: Monday, June 17, 2019 4:11 PM To: detnet@ietf.org Cc: shunsuke.homma.fp@hco.ntt.co.jp= ; peter.j.willis@bt.com; Liang GENG > Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments Hi all, This version has collected 7 requirements, and divided these requirements i= nto optional (SHOULD) and mandatory (MUST) two types as following shows. We= authors would like to know if this requirement list is complete, and if th= e classification is appropriate or not. Your review and comments are highl= y appropriated. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Req. 1: Must support the dynamic creation, modification and deletion of det= erministic services Req. 2.1: Should support asynchronous clocks across domains Req. 2.2 : Should tolerate a certain of clock jitter & wander within a cloc= k 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Best regards, Cristina QIANG From: Liang GENG [mailto:liang.geng@hotmail.com] Sent: Tuesday, June 11, 2019 11:53 AM To: detnet@ietf.org Cc: Black, David >; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.= co.jp; qiangli (D) > Subject: draft-geng-detnet-requirements-bounded-latency-02 revised for comm= ents Dear all, Since IETF 104, we have carefully revised draft-geng-detnet-requirements-bo= unded-latency-02 according to received comments. The latest 02 version was = uploaded and available online https://datatracker.ietf.org/doc/draft-geng-d= etnet-requirements-bounded-latency/. This new version collects more technical, operational and management requir= ements 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 --_000_8c420ab49d47466288fab3e2a00de3f9huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Shunsuke,

 

Thank you for your com= ments. We will try to analyze  “scalability” in detail nex= t version. But I’m afraid we couldn’t go so deep as you suggest= ed, since like the load of process, the chips are OS/hardware related, is not = in IETF’s scope.  

 

Best regards,

 

Cristina QIANG

 

From: = Shunsuke Homma [mailto:shunsuke.homma.fp@hco.ntt.co.jp]
Sent: Thursday, June 27, 2019 6:27 PM
To: qiangli (D) <qiangli3@huawei.com>; detnet@ietf.org
Cc: peter.j.willis@bt.com; 'Liang GENG' <liang.geng@hotmail.com&g= t;
Subject: RE: [Detnet] draft-geng-detnet-requirements-bounded-latency= -02 revised for comments

 

= Hi Cristina,

=  

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

=  

= Best regards,

=  

= Shunsuke

 

 

Hi Shunsuke,

 

Thanks for your suppor= t. “Scalability” is indeed an important requirement, especially= for operators when considering actual deployment. DetNet has considered this point, the DetNet architecture proposed to improve scalabi= lity through flow aggregation. Except for scale to a great amount of traffi= c flows,   current Req. 7 also mentions the number of network dev= ices.  Do you recommend splitting Req.7 from these two aspects?

 

 

Best regards,

 

Cristina QIANG

 

From: = Shunsuke Homma [mailto:s= hunsuke.homma.fp@hco.ntt.co.jp]
Sent: Wednesday, June 26, 2019 3:29 PM
To: qiangli (D) <qiangli3@= huawei.com>; detnet@ietf.org
Cc: peter.j.willis@bt.com; 'Liang GENG' <liang.geng@h= otmail.com>
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 a= spect.  Services and applications which are latency sensitive will increase more, and it would be required that enough dynamic= ity and scalability for utilizing it in carrier-wide networks.

=  

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

=  

= Best regards,

=  

= Shunsuke

=  

=  

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of qiangli (D)
Sent: Wednesday, June 26, 2019 12:33 PM
To: detnet@ietf.org
Cc: shunsuke.homm= a.fp@hco.ntt.co.jp; peter.j.willis@bt.com; Liang G= ENG
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 &a= mp; 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 &a= mp; wander do you expect?

 

BTW, we are going to a= sk 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 colle= cted 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 a= re highly appropriated.

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Req. 1: Must support t= he dynamic creation, modification and deletion of deterministic services

 

Req. 2.1: Should suppo= rt asynchronous clocks across domains

Req. 2.2 : Should tole= rate a certain of clock jitter & wander within a clock synchronous doma= in

 

Req. 3: Must support I= nter-Continental propagation delay

 

Req. 4: Should have se= lf-monitoring capability

 

Req. 5: Should be robu= st against denial of service attacks

 

Req. 6: Must tolerate = failures of links or nodes and topology changes

 

Req. 7: Must be scalab= le

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Best regards,

 

Cristina QIANG

 

From: = Liang GENG [mailto:liang.geng@hotmail.com]
Sent: Tuesday, June 11, 2019 11:53 AM
To: <= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= detnet@ietf.org
Cc: Black, David <David.Black@dell.com>; peter= ..j.willis@bt.com; shunsuke.homma.fp@hco.ntt.co.jp; qiangli (D) <qiangli3@huawei.com>
Subject: draft-geng-detnet-requirements-bounded-latency-02 revised f= or comments

 

Dear all,

 

Since IETF 104, we have carefully revised draft-geng-detnet-r= equirements-bounded-latency-02 according to received comments. The latest 02 version was uploaded and available online <= span lang=3D"EN-US">https://datatracker.ietf.org/doc/dra= ft-geng-detnet-requirements-bounded-latency/. 

 

This new version collects more technical, operational and man= agement requirements of deploying deterministic latency service on layer 3 networks from the perspective of various servic= e providers.

 

Comments are welcome!

 

Best regards,

Liang Geng on behavior of co-authors

 

 

 

--_000_8c420ab49d47466288fab3e2a00de3f9huaweicom_-- From nobody Fri Jun 28 03:15:48 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE53A120224 for ; Fri, 28 Jun 2019 03:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60PhuSfxXFNC for ; Fri, 28 Jun 2019 03:15:46 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3591201EA for ; Fri, 28 Jun 2019 03:15:46 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id 207so8532555wma.1 for ; Fri, 28 Jun 2019 03:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Ld6hXxLH9Vtd14kjKpsgxTeXTB8Q0uqFiLy0y01pzvc=; b=uSHDrUbf5eTM5InfUo8VBTnRmLYyPaCmcrd+DgOXmJPlwzcZS310a0oZsnv6y3KZ5q kZB45JK9d0uPBN/Gouo4oveCGy0iKthYeIRMvDDAUQCR/V8Y6nUwKLXeVjje3wx2cGNO 2QT29exy80zeIL88ozEwgCADQvA/WvWbvmNVxbmJ6617V9soYyJoHLb3Pw+ynOU4kDzV HGjSzeKIs6uM3VfeqvSScBfEdH//BI8zhenVnRA6nrglGa/Rqfu9XKlg6HoW55t7azYw A9weuTED5dVOc8QU8Ze8g5kqje2+McO08w+/wlaSQ+Wo+brV/Jwh78QGFaHKK7KJg37z sD/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ld6hXxLH9Vtd14kjKpsgxTeXTB8Q0uqFiLy0y01pzvc=; b=FSPE8+0AGlwhitKgIBXZg5CvX9uvXR/8iU9qMsvfRIXF+ksn5B6yb9i6c/rYhpZEwh 8EmJF5ltWvTOnSnfRJtgjaHp72Dcfu6IKeBJqR4AbHG/vmSx/CmdSHzw2dqTRxPE4hDd vZF3+BPfnPyEl6uvq+QPLi0SaDHSmlLY4x/9VkcF4r8P0c72zLmN7f+gG1ZUxO/eiH7J BfLGtWcKXNHLewpZq7MjmYqeWaPyTr47Y0id1uKVjzIvVfORalII9kfGKMzoMpRIiEnb E/b0XqSiDUnsj7t1S6GGt5IWeGDPR0eusU+dvAq1zM13E6/6/qrZ4yrJWjR5ScVjsm5a FUzg== X-Gm-Message-State: APjAAAXEzg8AHzsVOHa0ny/IRMQikUrVhETwS3AvSeIiX/FPr6xMzWqi /Km1FnpChDdG8y9X7Ppgg6UJd0lDfiw= X-Google-Smtp-Source: APXvYqy9a5QV4i2hteMhW1eMsSR36LjwoeTapsuaCky3uNolFIvsmvCSpDctQS5v1ylY2VSKuMVZFQ== X-Received: by 2002:a7b:c74a:: with SMTP id w10mr6300563wmk.99.1561716944224; Fri, 28 Jun 2019 03:15:44 -0700 (PDT) Received: from [192.168.178.22] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id v204sm1749878wma.20.2019.06.28.03.15.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2019 03:15:43 -0700 (PDT) To: detnet@ietf.org References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <83dac230ca6d4035841b9d6a527ea16f@huawei.com> From: Stewart Bryant Message-ID: <10ec2c20-3ef2-befb-888e-721e41354060@gmail.com> Date: Fri, 28 Jun 2019 11:15:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 10:15:48 -0000 On 26/06/2019 11:20, peter.j.willis@bt.com 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 nobody Fri Jun 28 03:21:06 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB27A120130 for ; Fri, 28 Jun 2019 03:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BKBHOg3lawC for ; Fri, 28 Jun 2019 03:21:02 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8401200CE for ; Fri, 28 Jun 2019 03:21:01 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id h19so9030447wme.0 for ; Fri, 28 Jun 2019 03:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GNOHzocvRxVi81/eN94IC1NvPv7rW8w5ET+1nPx4V2E=; b=OkDeNEfFqA69bPUDwZTU8QUHRPItCJQF71Bnk8yx9HWBon0CYv3641isV40uB3Im1o V+o7aTWQLFVCWCU6LA6UhguZse4hRS7VwnlOSRu1GqJRy8Z+buaTooWnNdIEkR86XJOS YomMLneOYJePoaGA5T1MNTBNXdB0S32ZjoSPiaJcBIpc4tONGI+du6Qkn4CTYcqREWsV 892QcvYYc5JlX1q1i6c2bXCoQUoI8RilxooLGonL92nLS+DAyltBDpdM6ZI8UBJXNPV9 GQDK+VwSJIwnu/gro0phyKLcG3zszj7qYT3hGRWvraBdExSfasDZhURL7xbIllTOpc7D SjBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GNOHzocvRxVi81/eN94IC1NvPv7rW8w5ET+1nPx4V2E=; b=FZ1bdOk6pHJHZqOa9k7vAebFLvtW5buzTbCqHgA2hy0QlQWO5gcVjzjAqebW6BhW5a aBevHAAbeOXv/Xvl65GiaelC3l1M4i+TKlod4g0Y/GDJOMdiUYI/EyiMWesB9DAn28C1 s8eQ2ZMHAjoeBKoT5xQi1icpgQTEo6hAooRH3jq1YjbyprhS0ETMlierb+lU2BtWI3uF qOK6w46Q5ZjhZqVv4FJk9BIYdRw4wEjmf1Z/x6TPIMb7GUG22QX3Mo50fneXfCXGLJ7F sjYxC9vBnY9Xspu4rd345SKHbsfJequ8KCpAA3Qk7AlEeQ8DUSNAjx5Dinz2Up0ODMWJ CwGw== X-Gm-Message-State: APjAAAUSjBbs3B6yXszlJGZ5uDo3N2L4aJ7AKu0S9sn/fcn/zpF2Hfbf yeqrb7SfRwRGaKnM9WogcA8= X-Google-Smtp-Source: APXvYqwC1z0PLf1YK2alzhsAlq1tOGB5XcWY/Ni01EcXHPwCr6vctBXvJo+YKQhB1PgjfKr8fQSKEg== X-Received: by 2002:a1c:be0a:: with SMTP id o10mr6695128wmf.91.1561717260303; Fri, 28 Jun 2019 03:21:00 -0700 (PDT) Received: from [192.168.178.22] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id g19sm1700521wmg.10.2019.06.28.03.20.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2019 03:20:59 -0700 (PDT) To: "qiangli (D)" , "peter.j.willis@bt.com" , "Janos.Farkas@ericsson.com" Cc: "shunsuke.homma.fp@hco.ntt.co.jp" , "detnet@ietf.org" , "liang.geng@hotmail.com" References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <83dac230ca6d4035841b9d6a527ea16f@huawei.com> <37358fdaf8464d1295cfaadf0975fe44@huawei.com> From: Stewart Bryant Message-ID: <4a7a2848-0f82-8fed-d599-dbda21177dd9@gmail.com> Date: Fri, 28 Jun 2019 11:20:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 10:21:05 -0000 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:*peter.j.willis@bt.com [mailto:peter.j.willis@bt.com] > *Sent:* Thursday, June 27, 2019 6:59 PM > *To:* qiangli (D) ; Janos.Farkas@ericsson.com > *Cc:* detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp; > liang.geng@hotmail.com > *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) > > *Sent:* 27 June 2019 10:26 > *To:* Willis,PJ,Peter,TUD1 R >; Janos.Farkas@ericsson.com > > *Cc:* detnet@ietf.org ; > shunsuke.homma.fp@hco.ntt.co.jp > ; liang.geng@hotmail.com > > *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:*peter..j.willis@bt.com > [mailto:peter.j.willis@bt.com] > *Sent:* Wednesday, June 26, 2019 6:20 PM > *To:* Janos.Farkas@ericsson.com ; > qiangli (D) > > *Cc:* detnet@ietf.org ; > shunsuke.homma.fp@hco.ntt.co.jp > ; liang.geng@hotmail.com > > *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 > > *Sent:* 26 June 2019 10:37 > *To:* qiangli (D) > > *Cc:* detnet@ietf.org ; > shunsuke.homma.fp@hco.ntt.co.jp > ; Willis,PJ,Peter,TUD1 R > >; Liang GENG > > > *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) > > *Sent:* Wednesday, June 26, 2019 11:29 AM > *To:* Janos Farkas > > *Cc:* detnet@ietf.org ; > shunsuke.homma.fp@hco.ntt.co.jp > ; peter..j.willis@bt.com > ; Liang GENG > > *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:Janos.Farkas@ericsson.com] > *Sent:* Wednesday, June 26, 2019 4:28 PM > *To:* qiangli (D) > > *Cc:* detnet@ietf.org ; > shunsuke.homma.fp@hco.ntt.co.jp > ; peter..j.willis@bt.com > ; Liang GENG > > *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 > > *On Behalf Of *qiangli (D) > *Sent:* Wednesday, June 26, 2019 5:33 AM > *To:* detnet@ietf.org > *Cc:* shunsuke.homma.fp@hco.ntt.co.jp > ; peter..j.willis@bt.com > ; 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 > > *From:*detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *qiangli (D) > *Sent:* Monday, June 17, 2019 4:11 PM > *To:* detnet@ietf.org > *Cc:* shunsuke.homma.fp@hco.ntt.co.jp > ; peter..j.willis@bt.com > ; Liang GENG > > *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:liang.geng@hotmail.com] > *Sent:* Tuesday, June 11, 2019 11:53 AM > *To:* detnet@ietf.org > *Cc:* Black, David >; > peter...j.willis@bt.com ; > shunsuke.homma.fp@hco.ntt.co.jp > ; qiangli (D) > > > *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 > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Fri Jun 28 16:08:34 2019 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C61B91209E8; Fri, 28 Jun 2019 15:58:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: detnet@ietf.org, db3546@att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176268979.11015.8896031919854044429.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:58:09 -0700 Archived-At: Subject: [Detnet] detnet - Requested sessions have been scheduled for IETF 105 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 23:07:24 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. detnet Session 1 (1:30 requested) Wednesday, 24 July 2019, Afternoon Session I 1330-1530 Room Name: Centre Ville size: 200 --------------------------------------------- detnet Session 2 (1:00 requested) Wednesday, 24 July 2019, Afternoon Session II 1550-1650 Room Name: Centre Ville size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/detnet.ics Request Information: --------------------------------------------------------- Working Group Name: Deterministic Networking Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: pce teas netmod mpls Second Priority: ccamp tsvwg lsr bess pals rtgwg sfc Third Priority: nvo3 People who must be present: Lou Berger David L. Black Deborah Brungard Janos Farkas Ethan Grossman Resources Requested: Special Requests: One 2.5 hour session please... --------------------------------------------------------- From nobody Fri Jun 28 23:10:00 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65658120024 for ; Fri, 28 Jun 2019 23:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmqvPFvJBq2P for ; Fri, 28 Jun 2019 23:09:54 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5361200E6 for ; Fri, 28 Jun 2019 23:09:54 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 087A095436734684D62D; Sat, 29 Jun 2019 07:09:52 +0100 (IST) Received: from dggeme704-chm.china.huawei.com (10.1.199.100) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 29 Jun 2019 07:09:51 +0100 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggeme704-chm.china.huawei.com (10.1.199.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Sat, 29 Jun 2019 14:09:49 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1591.008; Sat, 29 Jun 2019 14:09:48 +0800 From: "qiangli (D)" To: Stewart Bryant , "peter.j.willis@bt.com" , "Janos.Farkas@ericsson.com" CC: "shunsuke.homma.fp@hco.ntt.co.jp" , "detnet@ietf.org" , "liang.geng@hotmail.com" Thread-Topic: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments Thread-Index: AQHVIAiMvlIW7RTI2kKwIvaJSqO8BaafgoUwgA3IwACAAF+FoIAAExFwgAAGYnCAAAsdwIABevmggAAipsCAAAQewIAA/xMAgAHR0jA= Date: Sat, 29 Jun 2019 06:09:48 +0000 Message-ID: <31b820f12c7b4d61b03ff6a92bf517df@huawei.com> References: <8aea82da521a4faead2f6cb4652f7d4b@huawei.com> <83dac230ca6d4035841b9d6a527ea16f@huawei.com> <37358fdaf8464d1295cfaadf0975fe44@huawei.com> <4a7a2848-0f82-8fed-d599-dbda21177dd9@gmail.com> In-Reply-To: <4a7a2848-0f82-8fed-d599-dbda21177dd9@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 revised for comments X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 06:09:59 -0000 Thank you, Stewart. Will update draft according to this information. Best regards, Cristina QIANG -----Original Message----- From: Stewart Bryant [mailto:stewart.bryant@gmail.com]=20 Sent: Friday, June 28, 2019 6:21 PM To: qiangli (D) ; peter.j.willis@bt.com; Janos.Farkas@= ericsson.com Cc: shunsuke.homma.fp@hco.ntt.co.jp; detnet@ietf.org; liang.geng@hotmail.co= m Subject: Re: [Detnet] draft-geng-detnet-requirements-bounded-latency-02 rev= ised for comments If the ITU have specifications that cover our needs we should reference the= m. From an IETF perspective there is no procedural issue with referencing I= TU 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 i= f possible. - Stewart On 27/06/2019 13:01, qiangli (D) wrote: > Hi Peter, >=20 > Referencing ITU standards is acceptable IMHO. Let's see others' opinion. >=20 > Best regards, >=20 > Cristina QIANG >=20 > *From:*peter.j.willis@bt.com [mailto:peter.j.willis@bt.com] > *Sent:* Thursday, June 27, 2019 6:59 PM > *To:* qiangli (D) ; Janos.Farkas@ericsson.com > *Cc:* detnet@ietf.org; shunsuke.homma.fp@hco.ntt.co.jp;=20 > liang.geng@hotmail.com > *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02=20 > revised for comments >=20 > Cristina, >=20 > Personally I think it would be useful to reference such ITU standards=20 > if it does not cause IETF procedure issues. >=20 > Best Regardsyyo >=20 > Peter. >=20 > *From:*qiangli (D) > > *Sent:* 27 June 2019 10:26 > *To:* Willis,PJ,Peter,TUD1 R >; Janos.Farkas@ericsson.com=20 > > *Cc:* detnet@ietf.org ;=20 > shunsuke.homma.fp@hco.ntt.co.jp=20 > ; liang.geng@hotmail.com=20 > > *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02=20 > revised for comments >=20 > Hi Peter, >=20 > The relationship between clock jitter& wander and packet jitter is=20 > very complicated, varies a lot depend on different mechanisms. I know=20 > there are some time synch stands such as G.8273.2, G.8262. Is it=20 > helpful to reference this stands? >=20 > Best regards, >=20 > Cristina QIANG >=20 > *From:*peter..j.willis@bt.com > [mailto:peter.j.willis@bt.com] > *Sent:* Wednesday, June 26, 2019 6:20 PM > *To:* Janos.Farkas@ericsson.com ; > qiangli (D) > > *Cc:* detnet@ietf.org ;=20 > shunsuke.homma.fp@hco.ntt.co.jp=20 > ; liang.geng@hotmail.com=20 > > *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02=20 > revised for comments >=20 > Colleagues, >=20 > From a network operator's point of view I do not want the extra cost=20 > of highly accurate clocks in routers so prefer Detnet to work with the=20 > current clocks I have in routers. For an exact specification we would=20 > have to list the clock specifications in the typical routers that=20 > network operators use (it's not information I have at my fingertips). >=20 > I also put this requirement in to test what assumptions we are making=20 > about clock jitter & wander, and to check those assumptions are=20 > reasonable in practice. If there is a correlation between clock jitter=20 > & wander and packet jitter then that needs to be understood and stated. >=20 > Best Regards, >=20 > Peter. >=20 > *From:*Janos Farkas > > *Sent:* 26 June 2019 10:37 > *To:* qiangli (D) > > *Cc:* detnet@ietf.org ;=20 > shunsuke.homma.fp@hco.ntt.co.jp=20 > ; Willis,PJ,Peter,TUD1 R=20 > >; Liang GENG=20 > > > *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02=20 > revised for comments >=20 > Hi Cristina, >=20 > Thank you for your quick response. >=20 > I'd like to have what others think. >=20 > Just one more note on my side: I think it depends a lot on the actual=20 > deployment/application/use case. For instance, in some cases,=20 > synchronization would be not needed at all; e.g., if the DetNet high=20 > availability / high reliability feature is what is really needed for=20 > the given case; or an asynchronous solution is used to achieve bounded=20 > low latency. >=20 > Best regards, >=20 > Janos >=20 > *From:*qiangli (D) > > *Sent:* Wednesday, June 26, 2019 11:29 AM > *To:* Janos Farkas > > *Cc:* detnet@ietf.org ;=20 > shunsuke.homma.fp@hco.ntt.co.jp=20 > ; peter..j.willis@bt.com=20 > ; Liang GENG > > *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02=20 > revised for comments >=20 > Hello Janos, >=20 > Thanks for your kindly remind and comment. I copied the Req. 2.2 text=20 > as follows for easy check. The current version doesn't contain any=20 > solution and details as you requested. The reason that why we want to=20 > know what degree of clock jitter & wander DetNet can tolerate, is to=20 > detail the current text. According to your reply, I understand that=20 > DetNet just simply uses what is available. =A0So maybe we can simply=20 > list some existing standards here, no need to further specify more=20 > details. What do you think. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 2.2.2.=A0 Sub-requirement 2.2: Should tolerate clock jitter & wander >=20 > =A0=A0=A0=A0=A0=A0=A0 within a clock synchronous domain >=20 > =A0=A0 DetNet domain itself can be time synchronous or asynchronous, >=20 > =A0=A0 depending on the technology selection of different operators.=A0= =20 > Even >=20 > =A0=A0 within a time synchronous domain, the synchronized clocks may als= o >=20 > =A0=A0 experience jitter & wander, the mechanisms adopted by DetNet=20 > should >=20 > =A0=A0 be able to tolerate a certain degree of clock jitter & wander. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Best regards, >=20 > Cristina QIANG >=20 > *From:*Janos Farkas [mailto:Janos.Farkas@ericsson.com] > *Sent:* Wednesday, June 26, 2019 4:28 PM > *To:* qiangli (D) > > *Cc:* detnet@ietf.org ;=20 > shunsuke.homma.fp@hco.ntt.co.jp=20 > ; peter..j.willis@bt.com=20 > ; Liang GENG > > *Subject:* RE: draft-geng-detnet-requirements-bounded-latency-02=20 > revised for comments >=20 > Hi Cristina, >=20 > My understanding of the consensus of the WG based on the Architecture=20 > document is that synchronization is acknowledged to be important;=20 > however, it is not the job of DetNet to specify the details,=20 > solutions, etc.; DetNet just uses what is available, specified by other s= tandards. >=20 > Best regards, >=20 > Janos >=20 > *From:*detnet > *On Behalf Of *qiangli (D) > *Sent:* Wednesday, June 26, 2019 5:33 AM > *To:* detnet@ietf.org > *Cc:* shunsuke.homma.fp@hco.ntt.co.jp=20 > ; peter..j.willis@bt.com=20 > ; Liang GENG > > *Subject:* Re: [Detnet] > draft-geng-detnet-requirements-bounded-latency-02 revised for comments >=20 > Hi all, >=20 > The Req. 2.2 discusses that DetNet should be able to tolerate a=20 > certain degree of clock jitter & wander even within a time synchronous do= main. > We would like to know if you agree or disagree with this requirement.=20 > If you think this requirement is necessary, then to what degree of=20 > clock jitter & wander do you expect? >=20 > BTW, we are going to ask for WG adoption for this document in IETF 105=20 > meeting. That's will be greatly appreciated if you can share your=20 > comments to help us further improve this draft. >=20 > Best regards, >=20 > Cristina QIANG >=20 > *From:*detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *qiangli=20 > (D) > *Sent:* Monday, June 17, 2019 4:11 PM > *To:* detnet@ietf.org > *Cc:* shunsuke.homma.fp@hco.ntt.co.jp=20 > ; peter..j.willis@bt.com=20 > ; Liang GENG > > *Subject:* Re: [Detnet] > draft-geng-detnet-requirements-bounded-latency-02 revised for comments >=20 > Hi all, >=20 > This version has collected 7 requirements, and divided these=20 > requirements into optional (SHOULD) and mandatory (MUST) two types as=20 > following shows. We authors would like to know if this requirement=20 > list is complete, and if the classification is appropriate or not. =A0 > Your review and comments are highly appropriated. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > Req. 1: Must support the dynamic creation, modification and deletion=20 > of deterministic services >=20 > Req. 2.1: Should support asynchronous clocks across domains >=20 > Req. 2.2 : Should tolerate a certain of clock jitter & wander within a=20 > clock synchronous domain >=20 > Req. 3: Must support Inter-Continental propagation delay >=20 > Req. 4: Should have self-monitoring capability >=20 > Req. 5: Should be robust against denial of service attacks >=20 > Req. 6: Must tolerate failures of links or nodes and topology changes >=20 > Req. 7: Must be scalable >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Best regards, >=20 > Cristina QIANG >=20 > *From:*Liang GENG [mailto:liang.geng@hotmail.com] > *Sent:* Tuesday, June 11, 2019 11:53 AM > *To:* detnet@ietf.org > *Cc:* Black, David >; peter...j.willis@bt.com=20 > ; shunsuke.homma.fp@hco.ntt.co.jp=20 > ; qiangli (D)=20 > > > *Subject:* draft-geng-detnet-requirements-bounded-latency-02 revised=20 > for comments >=20 > Dear all, >=20 > Since IETF 104, we have carefully revised > draft-geng-detnet-requirements-bounded-latency-02 according to=20 > received comments. The latest 02 version was uploaded and available=20 > online https://datatracker.ietf.org/doc/draft-geng-detnet-requirements-bo= unded-latency/. >=20 >=20 > This new version collects more technical, operational and management=20 > requirements of deploying deterministic latency service on layer 3=20 > networks from the perspective of various service providers. >=20 > Comments are welcome! >=20 > Best regards, >=20 > Liang Geng on behavior of co-authors >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet >=20 From nobody Sun Jun 30 08:21:52 2019 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA55120131 for ; Sun, 30 Jun 2019 08:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_i9F9oL4u-Q for ; Sun, 30 Jun 2019 08:21:48 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53376120129 for ; Sun, 30 Jun 2019 08:21:48 -0700 (PDT) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id ACEC31412A8 for ; Sun, 30 Jun 2019 09:13:41 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id hbWPhiwtvmds9hbWPhsYH2; Sun, 30 Jun 2019 09:13:41 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=K4Py/ssLgcjAcmZE3dx0It1QVuabY++wz2WtZpA+dQM=; b=L6ypRrFW5gT4q54zxePbBMrFAd XkdbmgDxz1QhUWLhOekfxOrMntnOD6USln7cmcKKHmacJ0diSI/rd5TZ2nUA1/xt02IulBLEYPRE6 U7E1bdr2Asr8sZibz+C19ZPN9; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:53233 helo=[11.5.0.30]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hhbWP-00020J-3C; Sun, 30 Jun 2019 09:13:41 -0600 From: Lou Berger To: "Gengxuesong (Geng Xuesong)" , CC: =?UTF-8?B?7Jyg7Jew7LKg?= , Mach Chen Date: Sun, 30 Jun 2019 11:13:37 -0400 Message-ID: <16ba8f2dce8.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <1be0f2c21bc04ffcb5934f36c1ff14b7@huawei.com> References: <155353240678.28988.18080552674175846436@ietfa.amsl.com> <1be0f2c21bc04ffcb5934f36c1ff14b7@huawei.com> User-Agent: AquaMail/1.20.0-1458 (build: 102100001) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------16ba8f2e06f23d927ce36dd44e" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1hhbWP-00020J-3C X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([11.5.0.30]) [72.66.11.201]:53233 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2019 15:21:51 -0000 This is a multi-part message in MIME format. ------------16ba8f2e06f23d927ce36dd44e Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi, I was hoping others would comment on this first, but I guess I'll jump in. I think our yang modeling should follow the architecture, the flow information model and the data plane solution documents. I think this means that are four basic elements are (App flow) Service sub-layer Forwarding sub-layer (Sub-network) The two sublayers are part of detnet and should be fully described in the models. The said the data plane solutions allows for different technologies to realize each sub-layer and we are currently defining two different technologies. I think this means that the Subway or is need a general structure that covers detnet abstract elements, but also allows for technology specifics. I suggest ensuring that the structure covers both the current IP and mpls data plane definitions, and the elements identified in those documents that require configuration. The same concepts largely apply for the app flow subnetwork portions, i.e., there should be a general structure that allows for technology specifics. Hereto, I suggested that the structure covers both the current IP over mpls and mpls over UDP definitions, and the elements identified in those documents that require configuration. See below for more specific comments. ---------- On May 27, 2019 2:36:31 AM "Gengxuesong (Geng Xuesong)" wrote: > Dear WG, > > > > After several discussions with other authors and chairs, we decided to > update the YANG Model, which aligns with the new serious of Data Plane > drafts, as follows: > > [cid:image001.png@01D51499.6EF5EC20]1. There are four configuration > instances, including "DetNet Proxy Instance", "Service Sub-layer Instance", > "Forwarding Sub-layer Instance", "TSN Sub-network Instance". When the > device is configured, these instances are used following the order of the > layer stack defined in the architecture: > > [cid:image003.png@01D51499.6EF5EC20] I don't really understand how proxy fits in the middle of a detnet. I'd say the four elements and the overall model match what we have in the architecture, and what I have listed above: app flow, service and forwarding sublayers, and (technology agnostic) sub-layer. > 2. There are four elements in every configuration instance: operations, > in-segment, out-segment, as discussed in IETF 104. > > The overall structure is like: > > [cid:image006.png@01D51499.6EF5EC20] > > If the WG agrees with the structure, we will work on update the draft and > publish 03 version as soon as possible. > > The different node rolls identified in the architecture, need to covered in the overall model, but need not be explicitly identified. For example some nodes, will be service aware while others only support the forwarding sub layer. I'd like to see the update resulting from my comment above before making more detail comments though. Lou (As contributor) > > Any comments or suggests are welcome. > > > > Best Regards > Xuesong > > > >>-----Original Message----- > >>From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of > >>internet-drafts@ietf.org > >>Sent: Tuesday, March 26, 2019 12:47 AM > >>To: i-d-announce@ietf.org > >>Cc: detnet@ietf.org > >>Subject: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt > >> > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts directories. > >>This draft is a work item of the Deterministic Networking WG of the IETF. > >> > >> Title : Deterministic Networking (DetNet) Configuration > >>YANG Model > >> Authors : Xuesong Geng > >> Mach(Guoyi) Chen > >> Zhenqiang Li > >> Reshad Rahman > >> Filename : draft-ietf-detnet-yang-02.txt > >> Pages : 46 > >> Date : 2019-03-25 > >> > >>Abstract: > >> This document contains the specification for Deterministic Networking > >> flow configuration YANG Model. The model allows for provisioning of > >> end-to-end DetNet service along the path without dependency on any > >> signaling protocol. > >> > >> The YANG module defined in this document conforms to the Network > >> Management Datastore Architecture (NMDA). > >> > >> > >> > >>The IETF datatracker status page for this draft is: > >>https://datatracker.ietf.org/doc/draft-ietf-detnet-yang/ > >> > >>There are also htmlized versions available at: > >>https://tools.ietf.org/html/draft-ietf-detnet-yang-02 > >>https://datatracker.ietf.org/doc/html/draft-ietf-detnet-yang-02 > >> > >>A diff from the previous version is available at: > >>https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-yang-02 > >> > >> > >>Please note that it may take a couple of minutes from the time of submission > >>until the htmlized version and diff are available at tools.ietf.org. > >> > >>Internet-Drafts are also available by anonymous FTP at: > >>ftp://ftp.ietf.org/internet-drafts/ > >> > >>_______________________________________________ > >>detnet mailing list > >>detnet@ietf.org > >>https://www.ietf.org/mailman/listinfo/detnet > > > ---------- > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > ------------16ba8f2e06f23d927ce36dd44e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

I was hoping others would com= ment on this first, but I guess I'll jump in.

I think our yang modeling sho= uld follow the architecture, the flow information model and the data plane = solution documents.

I think this means that are f= our basic elements are

(App flow)
Service sub-layer
Forwarding sub-layer
(Sub-network)

The two sublayers are part of= detnet and should be fully described in the models. The said the data plan= e solutions allows for different technologies to realize each sub-layer and= we are currently defining two different technologies.  I think this m= eans that the Subway or is need a general structure that covers detnet abst= ract elements, but also allows for technology specifics. I suggest ensuring= that the structure covers both the current IP and mpls data plane definiti= ons, and the elements identified in those documents that require configurat= ion.

The same concepts largely app= ly for the app flow subnetwork portions, i.e., there should be a general st= ructure that allows for technology specifics. Hereto, I suggested  tha= t the structure covers both the current IP over mpls and mpls over UDP defi= nitions, and the elements identified in those documents that require config= uration.

See below for more specific c= omments.

----= ------
On May 27, 2019 2:36:31 AM "Gengxuesong (Geng Xuesong)" <gengxuesong@hua= wei.com> wrote:

>= Dear WG,
>
>
>
> After several discussions with other authors and chairs, we decided to= update the YANG Model, which aligns with the new serious of Data Plane dra= fts, as follows:
>
> [cid:image001.png@01D51499.6EF5EC20]1. There are four configuration in= stances, including "DetNet Proxy Instance", "Service Sub-layer Instance", "= Forwarding Sub-layer Instance", "TSN Sub-network Instance". When the device= is configured, these instances are used following the order of the layer s= tack defined in the architecture:
>
> [cid:image003.png@01D51499.6EF5EC20]

I don't really understand how= proxy fits in the middle of a detnet.

I'd say the four elements and= the overall model match what we have in the architecture, and what I have = listed above: app flow, service and forwarding sublayers, and (technology a= gnostic) sub-layer.


> 2. There are four elements in every configuration instance: operations= , in-segment, out-segment, as discussed in IETF 104.
>
> The overall structure is like:
>
> [cid:image006.png@01D51499.6EF5EC20]
>
> If the WG agrees with the structure, we will work on update the draft = and publish 03 version as soon as possible.
>
>

The different node rolls iden= tified in the architecture, need to covered in the overall model, but need = not be explicitly identified. For example some nodes, will be service aware= while others only support the forwarding sub layer. I'd like to see the up= date resulting from my comment above before making more detail comments tho= ugh.

Lou
(As contributor)


>
> Any comments or suggests are welcome.
>
>
>
> Best Regards
> Xuesong
>
>
>
>>-----Original Message-----
>
>>From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of
>
>>internet-drafts@ietf.org
>
>>Sent: Tuesday, March 26, 2019 12:47 AM
>
>>To: i-d-announce@ietf.org
>
>>Cc: detnet@ietf.org
>
>>Subject: [Detnet] I-D Action: draft-ietf-detnet-yang-02.txt
>
>>
>
>>
>
>>A New Internet-Draft is available from the on-line Internet-Drafts = directories.
>
>>This draft is a work item of the Deterministic Networking WG of the= IETF.
>
>>
>
>>        Title   &= nbsp;       : Deterministic Networking (DetNe= t) Configuration
>
>>YANG Model
>
>>        Authors   = ;      : Xuesong Geng
>
>>           &= nbsp;           &nbs= p;  Mach(Guoyi) Chen
>
>>           &= nbsp;           &nbs= p;  Zhenqiang Li
>
>>           &= nbsp;           &nbs= p;  Reshad Rahman
>
>>       Filename   &nbs= p;    : draft-ietf-detnet-yang-02.txt
>
>>       Pages    &= nbsp;      : 46
>
>>       Date    &n= bsp;       : 2019-03-25
>
>>
>
>>Abstract:
>
>>   This document contains the specification for Determini= stic Networking
>
>>   flow configuration YANG Model.  The model allows = for provisioning of
>
>>   end-to-end DetNet service along the path without depen= dency on any
>
>>   signaling protocol.
>
>>
>
>>   The YANG module defined in this document conforms to t= he Network
>
>>   Management Datastore Architecture (NMDA).
>
>>
>
>>
>
>>
>
>>The IETF datatracker status page for this draft is:
>
>>https://datatracker.ietf.org/doc/draft-ietf-detnet-yang/
>
>>
>
>>There are also htmlized versions available at:
>
>>h= ttps://tools.ietf.org/html/draft-ietf-detnet-yang-02
>
>>https://datatracker.ietf.org/doc/html/draft-ietf-detnet-yang-02
>
>>
>
>>A diff from the previous version is available at:
>
>>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-detnet-yang-02 >
>>
>
>>
>
>>Please note that it may take a couple of minutes from the time of s= ubmission
>
>>until the htmlized version and diff are available at tools.ietf.org= .
>
>>
>
>>Internet-Drafts are also available by anonymous FTP at:
>
>>ftp://ftp.ietf.org/= internet-drafts/
>
>>
>
>>_______________________________________________
>
>>detnet mailing list
>
>>detnet@ietf.org
>
>>https://ww= w.ietf.org/mailman/listinfo/detnet
>
>
> ----------
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.i= etf.org/mailman/listinfo/detnet
>

------------16ba8f2e06f23d927ce36dd44e--