From nobody Wed May 4 16:16:28 2016 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 1DFF912D940 for ; Wed, 4 May 2016 16:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QJVpDH6e9ctK for ; Wed, 4 May 2016 16:16:25 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 495ED12D649 for ; Wed, 4 May 2016 16:16:25 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u44NGO50013502; Wed, 4 May 2016 16:16:24 -0700 Received: from dlb-xchpw04.dolby.net (124.187.216.67.in-addr.arpa [67.216.187.124] (may be forged)) by mx0a-000fd501.pphosted.com with ESMTP id 22mty6fg79-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 May 2016 16:16:24 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 4 May 2016 16:16:22 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1076.000; Wed, 4 May 2016 16:16:22 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" , "Pascal Thubert (pthubert) (pthubert@cisco.com)" Thread-Topic: DetNet Use Case Statements - 6TiSCH - Path set/get protocol, must be direct to PCE Thread-Index: AdGmVYq7fkowWwZHRLOQ86gR19L0rQ== Date: Wed, 4 May 2016 23:16:22 +0000 Message-ID: <3f4bbb01500c4c8799b387b84dd2517d@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: multipart/alternative; boundary="_000_3f4bbb01500c4c8799b387b84dd2517dDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-04_09:, , signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements - 6TiSCH - Path set/get protocol, must be direct to PCE X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 23:16:27 -0000 --_000_3f4bbb01500c4c8799b387b84dd2517dDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: 6TiSCH use case: Path set/get protocol, must be direct to PCE Discussion: There has been discussion about whether path configuration is pushed to an = endpoint directly from the PCE, or whether the path is configured from devi= ce to device starting with the talker endpoint device, as it is in an AVB n= etwork. Because devices that use 6TiSCH usually have constrained resources,= the assumption here is that this configuration would always be direct from= the PCE, thus removing the peer-to-peer protocol requirement from the devi= ce. Similar logic applies to getting device capability information from the= device to the PCE - making this a direct query from the PCE to the device = means that the device would not have to support being an intermediary for c= ollecting or forwarding capabilities of neighbor devices to the PCE. Here = is an example of relevant text from the Use Cases draft, however part of th= is conversation was offline and was not directly covered in the draft. "a tiny IoT device may have just enough buffers to store one or a f= ew IPv6 packets, and will have limited bandwidth between peers such that i= t can maintain only a small amount of peer information, and will not be ab= le to store many packets waiting to be forwarded. It is advantageous then = for it to only be required to carry out the specific behavior assigned to i= t by the PCE/NME" As a counter example, I could imagine that for a larger DetNet network with= many and powerful devices, perhaps device querying and configuration might= better be done in a hierarchical or tree'd manner; that is, limiting confi= guration to direct communication from the PCE to every individual device ma= y be inefficient or limiting. So the question as I understand it is "will the DetNet architecture support= direct PCE-to-device interrogation and configuration?" It would not have t= o be to the exclusion of e.g. a hierarchical model, but the point is not to= assume a hierarchical model that would disenfranchise such small IoT devic= es. --_000_3f4bbb01500c4c8799b387b84dd2517dDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Statement:
6TiSCH use case: Path set/get protocol, must be direct to PCE
Discussion:
There has been discussion about whether path configuration is pushed t= o an endpoint directly from the PCE, or whether the path is configured from= device to device starting with the talker endpoint device, as it is in an = AVB network. Because devices that use 6TiSCH usually have constrained resources, the assumption here is that = this configuration would always be direct from the PCE, thus removing the p= eer-to-peer protocol requirement from the device. Similar logic applies to = getting device capability information from the device to the PCE – making this a direct query from the PCE = to the device means that the device would not have to support being an inte= rmediary for collecting or forwarding capabilities of neighbor devices to t= he PCE.  Here is an example of relevant text from the Use Cases draft, however part of this conversation was offlin= e and was not directly covered in the draft.
 
”a tiny IoT device may have just e= nough buffers to  store one or a few IPv6 packets, and will have limit= ed bandwidth between  peers such that it can maintain only a small amo= unt of peer information, and  will not be able to store many packets waiting to be forwarded. It is  advantageous then f= or it to only be required to carry out the specific behavior assigned to it= by the PCE/NME”
 
As a counter example, I could imagine that for a larger DetNet network= with many and powerful devices, perhaps device querying and configuration = might better be done in a hierarchical or tree’d manner; that is, lim= iting configuration to direct communication from the PCE to every individual device may be inefficient or limiting.
 
So the question as I understand it is “will the DetNet architect= ure support direct PCE-to-device interrogation and configuration?” It= would not have to be to the exclusion of e.g. a hierarchical model, but th= e point is not to assume a hierarchical model that would disenfranchise such small IoT devices.
 
 --_000_3f4bbb01500c4c8799b387b84dd2517dDLBXCHPW03dolbynet_-- From nobody Wed May 4 16:26:49 2016 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 146B312D1A3 for ; Wed, 4 May 2016 16:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 tBbmNTvUprBy for ; Wed, 4 May 2016 16:26:46 -0700 (PDT) Received: from mx0b-000fd501.pphosted.com (mx0b-000fd501.pphosted.com [67.231.152.235]) (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 6495A12D608 for ; Wed, 4 May 2016 16:26:35 -0700 (PDT) Received: from pps.filterd (m0000695.ppops.net [127.0.0.1]) by mx0b-000fd501.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u44NORRO003002; Wed, 4 May 2016 16:26:32 -0700 Received: from dlb-xchpw03.dolby.net (124.187.216.67.in-addr.arpa [67.216.187.124] (may be forged)) by mx0b-000fd501.pphosted.com with ESMTP id 22mtg7v8ey-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 May 2016 16:26:32 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 4 May 2016 16:26:28 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1076.000; Wed, 4 May 2016 16:26:28 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" , "Pascal Thubert (pthubert) (pthubert@cisco.com)" Thread-Topic: DetNet Use Case Statements - 6TiSCH - Push neighbor info to PCE over CoAP Thread-Index: AdGmWxlaF2Txaq8zS/yjG+frPIhtKw== Date: Wed, 4 May 2016 23:26:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: multipart/alternative; boundary="_000_da7d33025dbd41ea80cc564fe2e7b197DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-04_09:, , signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements - 6TiSCH - Push neighbor info to PCE over CoAP X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 23:26:48 -0000 --_000_da7d33025dbd41ea80cc564fe2e7b197DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: 6TiCH use case: Push neighbor info to PCE over CoAP? (CoAP: Constrained App= lication Protocol [RFC 7252]) Discussion: The relevant text in the draft is: "6TiSCH expects that the PCE commands will be issued directly as CoAP= requests or be mapped back and forth into CoAP by a gateway function at th= e edge of the 6TiSCH network. For instance, it is possible that a mapping e= ntity on the backbone transforms a non-CoAP protocol such as PCEP into the = RESTful interfaces that the 6TiSCH devices support. This architecture will = be refined to comply with [I-D.finn-detnet-architecture] when the work is formalized." This reads like a requirement, however since an alternative is given to usi= ng CoAP (i.e. using a gateway) perhaps this statement just gets removed fro= m the use case? Is there any sense to having DetNet specify CoAP or even re= ference it at all? --_000_da7d33025dbd41ea80cc564fe2e7b197DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Statement:
6TiCH use case: Push neighbor info to PCE over CoAP? (CoAP: Constraine= d Application Protocol [RFC 7252])
Discussion:
The relevant text in the draft is:
 
“6TiSCH expects that the PCE comman= ds will be issued directly as CoAP requests or be mapped back and forth int= o CoAP by a gateway function at the edge of the 6TiSCH network. For instanc= e, it is possible that a mapping entity on the backbone transforms a non-CoAP protocol such as PCEP into the RESTfu= l interfaces that the 6TiSCH devices support. This architecture will be ref= ined to comply with [I-D.finn-detnet-architecture] when the work is
formalized.”
 
This reads like a requirement, however since an alternative is given t= o using CoAP (i.e. using a gateway) perhaps this statement just gets remove= d from the use case? Is there any sense to having DetNet specify CoAP or ev= en reference it at all?
 
 
 
 --_000_da7d33025dbd41ea80cc564fe2e7b197DLBXCHPW03dolbynet_-- From nobody Wed May 4 16:50:39 2016 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 3A29A12D18C for ; Wed, 4 May 2016 16:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 otmJaQESeHYn for ; Wed, 4 May 2016 16:50:36 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 99D5F12D0A3 for ; Wed, 4 May 2016 16:50:36 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u44NkwCj021310; Wed, 4 May 2016 16:50:34 -0700 Received: from dlb-xchpw04.dolby.net (124.187.216.67.in-addr.arpa [67.216.187.124] (may be forged)) by mx0a-000fd501.pphosted.com with ESMTP id 22qqf50bs1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 May 2016 16:50:34 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 4 May 2016 16:50:32 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1076.000; Wed, 4 May 2016 16:50:32 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" , "Pascal Thubert (pthubert) (pthubert@cisco.com)" Thread-Topic: DetNet Use Case Statements - 6TiSCH - Multiple metrics same as RPL Ops (RFC6551) Thread-Index: AdGmXPRV8yLqLT8CQKuImAleGKb/cQ== Date: Wed, 4 May 2016 23:50:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: multipart/alternative; boundary="_000_decd9b3d2bec440b9039d5e221981b93DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-04_09:, , signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements - 6TiSCH - Multiple metrics same as RPL Ops (RFC6551) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 23:50:38 -0000 --_000_decd9b3d2bec440b9039d5e221981b93DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: 6TiSCH use case - Multiple metrics same as RPL Ops (RFC6551) Discussion: The relevant text in the draft is: "6TiSCH devices can discover their neighbors over the radio using a mechani= sm such as beacons, but even though the neighbor information is available i= n the 6TiSCH interface data model, 6TiSCH does not describe a protocol to p= roactively push the neighborhood information to a PCE. DetNet should define= this protocol, and it should operate over CoAP. The protocol should be abl= e to carry multiple metrics, in particular the same metrics as used for RPL= operations (RFC6551). " So I phrase the question(s) here to be "Will DetNet define a protocol to pr= oactively push neighbor device information to a PCE? If so, will it use CoA= P? If so, will it be able to carry multiple metrics, including RPL operatio= ns (RFC6551)?" --_000_decd9b3d2bec440b9039d5e221981b93DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Statement:

6TiSCH use case - Multiple metrics same= as RPL Ops (RFC6551)

Discussion:

The relevant text in the draft is:

 <= /o:p>

“6TiSC= H devices can discover their neighbors over the radio using a mechanism suc= h as beacons, but even though the neighbor information is available in the 6TiSCH interface data model, 6TiSCH does not describe a protocol to= proactively push the neighborhood information to a PCE. DetNet should defi= ne this protocol, and it should operate over CoAP. The protocol should be a= ble to carry multiple metrics, in particular the same metrics as used for RPL operations (RFC6551). “<= o:p>

 <= /o:p>

So I phrase the question(s) here to be = “Will DetNet define a protocol to proactively push neighbor device in= formation to a PCE? If so, will it use CoAP? If so, will it be able to carry multiple metrics, including RPL operations (RFC6551)?”=

 

 

 

 

--_000_decd9b3d2bec440b9039d5e221981b93DLBXCHPW03dolbynet_-- From nobody Wed May 4 17:30:15 2016 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 208AE12D584 for ; Wed, 4 May 2016 17:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ocVOBFuNgRE3 for ; Wed, 4 May 2016 17:30:12 -0700 (PDT) Received: from mx0b-000fd501.pphosted.com (mx0b-000fd501.pphosted.com [67.231.152.235]) (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 6400712D0A9 for ; Wed, 4 May 2016 17:30:12 -0700 (PDT) Received: from pps.filterd (m0000695.ppops.net [127.0.0.1]) by mx0b-000fd501.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u450TfsB006328; Wed, 4 May 2016 17:30:10 -0700 Received: from dlb-xchpw04.dolby.net (124.187.216.67.in-addr.arpa [67.216.187.124] (may be forged)) by mx0b-000fd501.pphosted.com with ESMTP id 22mtg7vddq-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 May 2016 17:30:10 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 4 May 2016 17:30:05 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1076.000; Wed, 4 May 2016 17:30:05 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" , "Pascal Thubert (pthubert) (pthubert@cisco.com)" Thread-Topic: DetNet Use Case Statements - 6TiSCH - One-Shot vs Update of paths Thread-Index: AdGmX9P3Z6z1degqRm6Mm+Z0orNKhg== Date: Thu, 5 May 2016 00:30:04 +0000 Message-ID: <779547efb8434639a70027ed19071dbc@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: multipart/alternative; boundary="_000_779547efb8434639a70027ed19071dbcDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-04_09:, , signatures=0 Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements - 6TiSCH - One-Shot vs Update of paths X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 00:30:14 -0000 --_000_779547efb8434639a70027ed19071dbcDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: 6TiCH use case: One-Shot vs Update of paths Discussion: The relevant text in the draft is as follows, but some of the material was = discussed offline. "If it appears that a path through the network does not perform as expected= , a protocol may be used to update the state in the devices, but in 6TiSCH = that flow was not designed and no protocol was selected and it is expected = that DetNet will determine the appropriate end-to-end protocols to be used = in that case." So there is a distinction between a protocol that can propagate all path in= formation to the network at once ("one-shot") and one that is also capable = of subsequently propagating individual path updates, for example to work ar= ound a malfunctioning path or device. It would seem to me that this would b= e a necessity - am I missing anything or is this clearly within scope for D= etNet? --_000_779547efb8434639a70027ed19071dbcDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Statement:

6TiCH use case: One-Shot vs Update of p= aths

Discussion:

The relevant text in the draft is as fo= llows, but some of the material was discussed offline.

 

“If it= appears that a path through the network does not perform as expected, a pr= otocol may be used to update the state in the devices, but in 6TiSCH that flow was not designed and no protocol was selected and it is expected= that DetNet will determine the appropriate end-to-end protocols to be used= in that case.”

 

So there is a distinction between a pro= tocol that can propagate all path information to the network at once (̶= 0;one-shot”) and one that is also capable of subsequently propagating individual path updates, for example to work around a malfunctioning path = or device. It would seem to me that this would be a necessity – am I = missing anything or is this clearly within scope for DetNet?

--_000_779547efb8434639a70027ed19071dbcDLBXCHPW03dolbynet_-- From nobody Thu May 5 08:04:44 2016 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 091B312DA56 for ; Thu, 5 May 2016 08:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Qi9HRJvnnQ7v for ; Thu, 5 May 2016 08:04:41 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EE712D64E for ; Thu, 5 May 2016 07:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8422; q=dns/txt; s=iport; t=1462460156; x=1463669756; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=s/43wc7dd+cK0TpYzLWRJGxULFcEN8Qk1+y4dGsx7Lc=; b=JHdiU5cjAh3DFwkcRlw2swJKlVaNirRnoK/OovWyneQ4PgTZDtHCRQBX pnJSzvKeXnx3vfJYgcPoAJfAiHZA7oSmnA45aUuay3N0zm+0J/7BYDJeO 0mzZq6KOqKoaftMFua/upkD9aXFx1lXOd9CQdMTbrdhVgTVGEbg9f0nM3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbBgBTXitX/4kNJK1dgmxMgVC0IIUBg?= =?us-ascii?q?XaGEAIcgRg5EwEBAQEBAQFlJ4RCAQEEIwpMEAIBCD8DAgICMBQRAQEEDgWIKq5?= =?us-ascii?q?KkH8BAQEBAQEBAQEBAQEBAQEBAQEBAQEVgh+EAYF2glaHPyuCLgWTJYR1AY4Yg?= =?us-ascii?q?WiNK4YmiQ0BIgE/g2tsiFoBAQE?= X-IronPort-AV: E=Sophos;i="5.24,582,1454976000"; d="scan'208,217";a="269190328" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2016 14:55:56 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u45EtuCl029797 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 May 2016 14:55:56 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 May 2016 09:55:55 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Thu, 5 May 2016 09:55:55 -0500 From: "Pascal Thubert (pthubert)" To: "Grossman, Ethan A." Thread-Topic: DetNet Use Case Statements - 6TiSCH - One-Shot vs Update of paths Thread-Index: AdGmX9P3Z6z1degqRm6Mm+Z0orNKhgAkM3+A Date: Thu, 5 May 2016 14:55:55 +0000 Message-ID: References: <779547efb8434639a70027ed19071dbc@DLB-XCHPW03.dolby.net> In-Reply-To: <779547efb8434639a70027ed19071dbc@DLB-XCHPW03.dolby.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_D4615B2F435A486CA90DF5EEFE3B0F61ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements - 6TiSCH - One-Shot vs Update of paths X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 05 May 2016 15:04:43 -0000 --_000_D4615B2F435A486CA90DF5EEFE3B0F61ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRXRoYW46DQoNCkkgZG8gYmVsaWV2ZSBpdCBiZWxvbmdzLg0KDQpJIG4gYSBURE0gLyB0 aW1lLXRyaWdnZXJlZCBkb21haW4sIGlmIGFsbCBmbG93cyBhcmUga25vd24gaW4gYWR2YW5jZSwg aXQgaXMgcG9zc2libGUgdG8gcHJvZ3JhbSB0aGUgZGV2aWNlIGluIHRlcm1zIG9mIHNjaGVkdWxl LCBhcyBhY3Rpb25zIGluZGV4ZWQgYnkgdGltZS4gVGhlIG5vdGlvbiBvZiB0cmFjayBpcyBzZWNv bmRhcnkuDQoNCklmIGZsb3dzIGFyZSBhZGRlZCBhbmQgcmVtb3ZlZCBpbmRpdmlkdWFsbHkgdGhl biB0aGV5IG5lZWQgdG8gYmUgYSBwcmltYXJ5IGtleSBhbmQgd2UgZGVzaWduIGEgZGlmZmVyZW50 IGRhdGEgbW9kZWwuDQoNCg0KUmVnYXJkcywNCg0KUGFzY2FsDQoNCkxlIDUgbWFpIDIwMTYgw6Ag MDI6MzAsIEdyb3NzbWFuLCBFdGhhbiBBLiA8ZWFncm9zQGRvbGJ5LmNvbTxtYWlsdG86ZWFncm9z QGRvbGJ5LmNvbT4+IGEgw6ljcml0IDoNCg0KU3RhdGVtZW50Og0KNlRpQ0ggdXNlIGNhc2U6IE9u ZS1TaG90IHZzIFVwZGF0ZSBvZiBwYXRocw0KRGlzY3Vzc2lvbjoNClRoZSByZWxldmFudCB0ZXh0 IGluIHRoZSBkcmFmdCBpcyBhcyBmb2xsb3dzLCBidXQgc29tZSBvZiB0aGUgbWF0ZXJpYWwgd2Fz IGRpc2N1c3NlZCBvZmZsaW5lLg0KDQrigJxJZiBpdCBhcHBlYXJzIHRoYXQgYSBwYXRoIHRocm91 Z2ggdGhlIG5ldHdvcmsgZG9lcyBub3QgcGVyZm9ybSBhcyBleHBlY3RlZCwgYSBwcm90b2NvbCBt YXkgYmUgdXNlZCB0byB1cGRhdGUgdGhlIHN0YXRlIGluIHRoZSBkZXZpY2VzLCBidXQgaW4gNlRp U0NIIHRoYXQgZmxvdyB3YXMgbm90IGRlc2lnbmVkIGFuZCBubyBwcm90b2NvbCB3YXMgc2VsZWN0 ZWQgYW5kIGl0IGlzIGV4cGVjdGVkIHRoYXQgRGV0TmV0IHdpbGwgZGV0ZXJtaW5lIHRoZSBhcHBy b3ByaWF0ZSBlbmQtdG8tZW5kIHByb3RvY29scyB0byBiZSB1c2VkIGluIHRoYXQgY2FzZS7igJ0N Cg0KU28gdGhlcmUgaXMgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGEgcHJvdG9jb2wgdGhhdCBjYW4g cHJvcGFnYXRlIGFsbCBwYXRoIGluZm9ybWF0aW9uIHRvIHRoZSBuZXR3b3JrIGF0IG9uY2UgKOKA nG9uZS1zaG904oCdKSBhbmQgb25lIHRoYXQgaXMgYWxzbyBjYXBhYmxlIG9mIHN1YnNlcXVlbnRs eSBwcm9wYWdhdGluZyBpbmRpdmlkdWFsIHBhdGggdXBkYXRlcywgZm9yIGV4YW1wbGUgdG8gd29y ayBhcm91bmQgYSBtYWxmdW5jdGlvbmluZyBwYXRoIG9yIGRldmljZS4gSXQgd291bGQgc2VlbSB0 byBtZSB0aGF0IHRoaXMgd291bGQgYmUgYSBuZWNlc3NpdHkg4oCTIGFtIEkgbWlzc2luZyBhbnl0 aGluZyBvciBpcyB0aGlzIGNsZWFybHkgd2l0aGluIHNjb3BlIGZvciBEZXROZXQ/DQo= --_000_D4615B2F435A486CA90DF5EEFE3B0F61ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0936170FCDD8EA41A716BADC9C9FF7DA@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkhlbGxvIEV0aGFuOjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+ DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+SSBkbyBiZWxpZXZlIGl0IGJl bG9uZ3MuPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj4NCjwvZGl2Pg0K PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5JIG4gYSBURE0gLyB0aW1lLXRyaWdnZXJlZCBk b21haW4sIGlmIGFsbCBmbG93cyBhcmUga25vd24gaW4gYWR2YW5jZSwgaXQgaXMgcG9zc2libGUg dG8gcHJvZ3JhbSB0aGUgZGV2aWNlIGluIHRlcm1zIG9mIHNjaGVkdWxlLCBhcyBhY3Rpb25zIGlu ZGV4ZWQgYnkgdGltZS4gVGhlIG5vdGlvbiBvZiB0cmFjayBpcyBzZWNvbmRhcnkuPC9kaXY+DQo8 ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVN YWlsU2lnbmF0dXJlIj5JZiBmbG93cyBhcmUgYWRkZWQgYW5kIHJlbW92ZWQgaW5kaXZpZHVhbGx5 IHRoZW4gdGhleSBuZWVkIHRvIGJlIGEgcHJpbWFyeSBrZXkgYW5kIHdlIGRlc2lnbiBhIGRpZmZl cmVudCBkYXRhIG1vZGVsLjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+ DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KUmVnYXJkcywNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBhc2NhbDwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCkxlIDUgbWFpIDIwMTYgw6AgMDI6MzAsIEdyb3NzbWFuLCBFdGhhbiBBLiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmVhZ3Jvc0Bkb2xieS5jb20iPmVhZ3Jvc0Bkb2xieS5jb208L2E+ Jmd0OyBhIMOpY3JpdCZuYnNwOzo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0 IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5p dGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5lbWFpbHF1b3RlLCBsaS5lbWFpbHF1b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28tc3R5bGUt bmFtZTplbWFpbHF1b3RlOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7 DQoJYm9yZGVyOm5vbmU7DQoJcGFkZGluZzowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5TdGF0ZW1lbnQ6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij42VGlDSCB1 c2UgY2FzZTogT25lLVNob3QgdnMgVXBkYXRlIG9mIHBhdGhzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5EaXNjdXNzaW9uOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5U aGUgcmVsZXZhbnQgdGV4dCBpbiB0aGUgZHJhZnQgaXMgYXMgZm9sbG93cywgYnV0IHNvbWUgb2Yg dGhlIG1hdGVyaWFsIHdhcyBkaXNjdXNzZWQgb2ZmbGluZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+4oCcSWYgaXQgYXBwZWFycyB0aGF0IGEgcGF0aCB0aHJvdWdoIHRoZSBuZXR3b3JrIGRvZXMg bm90IHBlcmZvcm0gYXMgZXhwZWN0ZWQsIGEgcHJvdG9jb2wgbWF5IGJlIHVzZWQgdG8gdXBkYXRl IHRoZSBzdGF0ZSBpbiB0aGUgZGV2aWNlcywgYnV0IGluIDZUaVNDSA0KIHRoYXQgZmxvdyB3YXMg bm90IGRlc2lnbmVkIGFuZCBubyBwcm90b2NvbCB3YXMgc2VsZWN0ZWQgYW5kIGl0IGlzIGV4cGVj dGVkIHRoYXQgRGV0TmV0IHdpbGwgZGV0ZXJtaW5lIHRoZSBhcHByb3ByaWF0ZSBlbmQtdG8tZW5k IHByb3RvY29scyB0byBiZSB1c2VkIGluIHRoYXQgY2FzZS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U28gdGhl cmUgaXMgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGEgcHJvdG9jb2wgdGhhdCBjYW4gcHJvcGFnYXRl IGFsbCBwYXRoIGluZm9ybWF0aW9uIHRvIHRoZSBuZXR3b3JrIGF0IG9uY2UgKOKAnG9uZS1zaG90 4oCdKSBhbmQgb25lIHRoYXQgaXMgYWxzbyBjYXBhYmxlIG9mIHN1YnNlcXVlbnRseSBwcm9wYWdh dGluZw0KIGluZGl2aWR1YWwgcGF0aCB1cGRhdGVzLCBmb3IgZXhhbXBsZSB0byB3b3JrIGFyb3Vu ZCBhIG1hbGZ1bmN0aW9uaW5nIHBhdGggb3IgZGV2aWNlLiBJdCB3b3VsZCBzZWVtIHRvIG1lIHRo YXQgdGhpcyB3b3VsZCBiZSBhIG5lY2Vzc2l0eSDigJMgYW0gSSBtaXNzaW5nIGFueXRoaW5nIG9y IGlzIHRoaXMgY2xlYXJseSB3aXRoaW4gc2NvcGUgZm9yIERldE5ldD8NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_D4615B2F435A486CA90DF5EEFE3B0F61ciscocom_-- From nobody Fri May 6 10:52:11 2016 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 81F7712D529 for ; Fri, 6 May 2016 10:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4rgCWUZibOKq for ; Fri, 6 May 2016 10:52:08 -0700 (PDT) Received: from mx0b-000fd501.pphosted.com (mx0b-000fd501.pphosted.com [67.231.152.235]) (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 EDC4612B009 for ; Fri, 6 May 2016 10:52:07 -0700 (PDT) Received: from pps.filterd (m0000695.ppops.net [127.0.0.1]) by mx0b-000fd501.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u46Hnpq8026464; Fri, 6 May 2016 10:52:02 -0700 Received: from dlb-xchpw04.dolby.net (124.187.216.67.in-addr.arpa [67.216.187.124] (may be forged)) by mx0b-000fd501.pphosted.com with ESMTP id 22rf7jayrv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 06 May 2016 10:52:02 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 6 May 2016 10:52:01 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1076.000; Fri, 6 May 2016 10:52:01 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" , "Pascal Thubert (pthubert) (pthubert@cisco.com)" Thread-Topic: DetNet Use Case Statements - 6TiSCH - Read energy data from devices Thread-Index: AdGnNalY+4dxl2z4TLCmDUEggF8Dag== Date: Fri, 6 May 2016 17:52:00 +0000 Message-ID: <4197b8a06d57402caa48812b443d9d2f@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.233.7.60] Content-Type: multipart/alternative; boundary="_000_4197b8a06d57402caa48812b443d9d2fDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-06_08:, , signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements - 6TiSCH - Read energy data from devices X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 06 May 2016 17:52:09 -0000 --_000_4197b8a06d57402caa48812b443d9d2fDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: 6TiCH use case: Read energy data from devices (app layer?) - Extensible pro= tocol - vendor specific? Discussion: The relevant text in the draft is as follows: The PCE should be able to read energy data from devices, and compute paths = that will implement policies on how energy in devices is consumed, for inst= ance to ensure that the spent energy does not exceeded the available energy= over a period of time. Please excuse my naivete with respect to PCE's but to me this sounds like t= he PCE (which is nominally an application) is expected to support a vendor-= extensible protocol to enable arbitrary information to be queried from/push= ed to devices, and also some kind of vendor-supplied "plug-in" to the "path= computation" algorithm so that such information can be incorporated into t= he resulting path computation. Is this within scope of DetNet? Perhaps a "D= etNet 2.0" feature or is it critical to build this into the initial design,= or account for it in any way? --_000_4197b8a06d57402caa48812b443d9d2fDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Statement:

6TiCH use case: Read energy data from devices (app layer?) - Extensible = protocol – vendor specific?

Discussion:

The relevant text in the draft is as fo= llows:

 

The PCE shou= ld be able to read energy data from devices, and compute paths that will im= plement policies on how energy in devices is consumed, for instance to ensure that the spent energy does not exceeded the available e= nergy over a period of time.

 

Please excuse my naivete with respect to= PCE’s but to me this sounds like the PCE (which is nominally an appl= ication) is expected to support a vendor-extensible protocol to enable arbitrary information to be queried from/pushed to devices, and als= o some kind of vendor-supplied “plug-in” to the “path com= putation” algorithm so that such information can be incorporated into= the resulting path computation. Is this within scope of DetNet? Perhaps a “DetNet 2.0” feature or is it critical to bu= ild this into the initial design, or account for it in any way?

 

 

--_000_4197b8a06d57402caa48812b443d9d2fDLBXCHPW03dolbynet_-- From nobody Fri May 6 11:33:34 2016 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 7B5B312D0A2 for ; Fri, 6 May 2016 11:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 z6gwX_Wvv555 for ; Fri, 6 May 2016 11:33:31 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 32D6C12B05D for ; Fri, 6 May 2016 11:33:31 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u46IW602001299; Fri, 6 May 2016 11:33:30 -0700 Received: from dlb-xchpw04.dolby.net (124.187.216.67.in-addr.arpa [67.216.187.124] (may be forged)) by mx0a-000fd501.pphosted.com with ESMTP id 22mty6m13d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 06 May 2016 11:33:30 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 6 May 2016 11:33:25 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1076.000; Fri, 6 May 2016 11:33:25 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" , "Pascal Thubert (pthubert) (pthubert@cisco.com)" Thread-Topic: DetNet Use Case Statements - 6TiSCH - ARQ protocol (auto retry, specific to wireless) Thread-Index: AdGnwrOMLGlO6jzeTrqjZYD3WkNn7w== Date: Fri, 6 May 2016 18:33:24 +0000 Message-ID: <1bd015e612c64537bfde670f1993695f@DLB-XCHPW03.dolby.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.233.7.60] Content-Type: multipart/alternative; boundary="_000_1bd015e612c64537bfde670f1993695fDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-06_08:, , signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements - 6TiSCH - ARQ protocol (auto retry, specific to wireless) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 06 May 2016 18:33:33 -0000 --_000_1bd015e612c64537bfde670f1993695fDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: 6TiCH use case: ARQ protocol (auto retry, specific to wireless) Discussion: The relevant text from the draft is shown below. The actionable statement i= s "this may be a technique that would be appropriate for DetNet and so aspe= cts of the enabling protocol could be co-developed [between DetNet and 6TiS= CH]". So the first question is "Will DetNEt use this ARQ (or ARQ-like) technique?= " If so, how does it affect the DetNet architecture, control or data plane= specification? 6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism to provide higher reliability of packet delivery. = ARQ is related to packet replication and elimination because there are t= wo independent paths for packets to arrive at the destination, and if an= expected packed does not arrive on one path then it checks for the packe= t on the second path. Although to date this mechanism is only used by wi= reless networks, this may be a technique that would be appropriate fo= r DetNet and so aspects of the enabling protocol could be co-developed. For example, in , a Trac= k is laid out from a field device in a 6TiSCH network to an IoT gate= way that is located on a IEEE802.1 TSN backbone. The Replication function in the field device sends= a copy of each packet over two different branches, and the PCE schedu= les each hop of both branches so that the two copies arrive in due t= ime at the gateway. In case of a loss on one branch, hopefully the oth= er copy of the packet still arrives within the allocated time. If two= copies make it to the IoT gateway, the Elimination function in the ga= teway ignores the extra packet and presents only one copy to upper laye= rs. At each 6TiSCH hop along the Track, the PCE may sc= hedule more than one timeSlot for a packet, so as to support Layer-2= retries (ARQ). In current deployments, a TSCH Track does not nece= ssarily support PRE but is systematically multi-path. This means th= at a Track is scheduled so as to ensure that each hop has at least two = forwarding solutions, and the forwarding decision is to try the preferred= one and use the other in case of Layer-2 transmission failure as detecte= d by ARQ. -------------------------------------------------------- --_000_1bd015e612c64537bfde670f1993695fDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Statement:

6TiCH use case: ARQ protocol (auto retry, specific to wireless)

Discussion:

 

The relevant text from the draft is sho= wn below. The actionable statement is “this may be= a technique that would be appropriate for DetNet and so aspects of the enabling protoc= ol could be co-developed [between DetNet and 6TiSCH]”.

 

So the first question is “Will Det= NEt use this ARQ (or ARQ-like) technique?”  If so, how does it a= ffect the DetNet architecture, control or data plane specification?<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">

 

6TiSCH uses the IEEE802.15.4 Automatic Repeat-reQuest (ARQ) mechanism t= o

      &nbs= p;            &= nbsp;        provide higher reliability = of packet delivery. ARQ is related to packet

      &nbs= p;            &= nbsp;        replication and elimination= because there are two independent paths for

      &nbs= p;            &= nbsp;        packets to arrive at the de= stination, and if an expected packed does not

      &nbs= p;            &= nbsp;        arrive on one path then it = checks for the packet on the second path.

      &nbs= p;            &= nbsp;     Although to date this mechanism is only = used by wireless networks, this

      &nbs= p;            &= nbsp;        may be a technique that wou= ld be appropriate for DetNet and so aspects

      &nbs= p;            &= nbsp;        of the enabling protocol co= uld be co-developed.

      &nbs= p;            &= nbsp;     For example, in <xref target=3D"= wi_fig3"/>, a Track is laid out from a

      &nbs= p;            &= nbsp;        field device in a 6TiSCH ne= twork to an IoT gateway that is located on a

      &nbs= p;            &= nbsp;        IEEE802.1 TSN backbone.

      &nbs= p;            &= nbsp;     The Replication function in the field de= vice sends a copy of each packet

      &nbs= p;            &= nbsp;        over two different branches= , and the PCE schedules each hop of both

      &nbs= p;            &= nbsp;        branches so that the two co= pies arrive in due time at the gateway. In

      &nbs= p;            &= nbsp;        case of a loss on one branc= h, hopefully the other copy of the packet

      &nbs= p;            &= nbsp;        still arrives within the al= located time. If two copies make it to the

      &nbs= p;            &= nbsp;        IoT gateway, the Eliminatio= n function in the gateway ignores the extra

      &nbs= p;            &= nbsp;        packet and presents only on= e copy to upper layers.

      &nbs= p;            &= nbsp;     At each 6TiSCH hop along the Track, the = PCE may schedule more than one

      &nbs= p;            &= nbsp;        timeSlot for a packet, so a= s to support Layer-2 retries (ARQ).

      &nbs= p;            &= nbsp;     In current deployments, a TSCH Track doe= s not necessarily support PRE

      &nbs= p;            &= nbsp;        but is systematically multi= -path. This means that a Track is scheduled

      &nbs= p;            &= nbsp;        so as to ensure that each h= op has at least two forwarding solutions, and

      &nbs= p;            &= nbsp;        the forwarding decision is = to try the preferred one and use the other in

      &nbs= p;            &= nbsp;        case of Layer-2 transmissio= n failure as detected by ARQ.

-------------------------= -------------------------------

 

--_000_1bd015e612c64537bfde670f1993695fDLBXCHPW03dolbynet_-- From nobody Mon May 9 00:43:00 2016 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 6D4CA12D10E for ; Mon, 9 May 2016 00:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.895 X-Spam-Level: X-Spam-Status: No, score=-7.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 deSwWFmOlbVD for ; Mon, 9 May 2016 00:42:47 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD57712B067 for ; Mon, 9 May 2016 00:42:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,600,1454972400"; d="scan'208,217";a="217344009" Received: from mail-lf0-f54.google.com ([209.85.215.54]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 09 May 2016 09:42:45 +0200 Received: by mail-lf0-f54.google.com with SMTP id y84so191191840lfc.0 for ; Mon, 09 May 2016 00:42:45 -0700 (PDT) X-Gm-Message-State: AOPr4FUdYwBOSu6JHUhWZxfWbABLDtm9X9IGgc4rOXz2dIyd0DNWFUdfNU/V9anDavDnFXwARi57ALPRKPJUEA== X-Received: by 10.25.86.137 with SMTP id k131mr14585889lfb.97.1462779764775; Mon, 09 May 2016 00:42:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.149.195 with HTTP; Mon, 9 May 2016 00:42:24 -0700 (PDT) In-Reply-To: <3f4bbb01500c4c8799b387b84dd2517d@DLB-XCHPW03.dolby.net> References: <3f4bbb01500c4c8799b387b84dd2517d@DLB-XCHPW03.dolby.net> From: Thomas Watteyne Date: Mon, 9 May 2016 09:42:24 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "Grossman, Ethan A." Content-Type: multipart/alternative; boundary=001a1147375843a30f053263f454 Archived-At: Cc: "Pascal Thubert \(pthubert\) \(pthubert@cisco.com\)" , "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements - 6TiSCH - Path set/get protocol, must be direct to PCE X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 07:42:59 -0000 --001a1147375843a30f053263f454 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ethan, [I'm going through the set of e-mails you just sent to the ML, assuming you created these to kickstart different threads of execution. Please correct me if I'm wrong.] My 2c on this issue: - small IoT devices (class 1 devices per RFC7228) are powerful enough to run a state machine of a simple protocol such as 6P (draft-ietf-6tisch-6top-protocol-00) - network bandwidth is severely constrained, and having two neighbor node discuss locally (e.g. as part of the 6P protocol) is more feasible than globally with the PCE for each transaction. - given this, I wouldn't dismiss having some distributed intelligence, with possibly the PCE/NME giving high-level commands On Thu, May 5, 2016 at 1:16 AM, Grossman, Ethan A. wrote= : > Statement: > 6TiSCH use case: Path set/get protocol, must be direct to PCE > Discussion: > There has been discussion about whether path configuration is pushed to a= n > endpoint directly from the PCE, or whether the path is configured from > device to device starting with the talker endpoint device, as it is in an > AVB network. Because devices that use 6TiSCH usually have constrained > resources, the assumption here is that this configuration would always be > direct from the PCE, thus removing the peer-to-peer protocol requirement > from the device. Similar logic applies to getting device capability > information from the device to the PCE =E2=80=93 making this a direct que= ry from > the PCE to the device means that the device would not have to support bei= ng > an intermediary for collecting or forwarding capabilities of neighbor > devices to the PCE. Here is an example of relevant text from the Use Cas= es > draft, however part of this conversation was offline and was not directly > covered in the draft. > > =E2=80=9Da tiny IoT device may have just enough buffers to store one or = a few > IPv6 packets, and will have limited bandwidth between peers such that it > can maintain only a small amount of peer information, and will not be ab= le > to store many packets waiting to be forwarded. It is advantageous then f= or > it to only be required to carry out the specific behavior assigned to it = by > the PCE/NME=E2=80=9D > > As a counter example, I could imagine that for a larger DetNet network > with many and powerful devices, perhaps device querying and configuration > might better be done in a hierarchical or tree=E2=80=99d manner; that is,= limiting > configuration to direct communication from the PCE to every individual > device may be inefficient or limiting. > > So the question as I understand it is =E2=80=9Cwill the DetNet architectu= re > support direct PCE-to-device interrogation and configuration?=E2=80=9D It= would not > have to be to the exclusion of e.g. a hierarchical model, but the point i= s > not to assume a hierarchical model that would disenfranchise such small I= oT > devices. > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > --=20 _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a1147375843a30f053263f454 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ethan,

[I'm going through the set o= f e-mails you just sent to the ML, assuming you created these to kickstart = different threads of execution. Please correct me if I'm wrong.]
<= div>
My 2c on this issue:
- small IoT devices (clas= s 1 devices per RFC7228) are powerful enough to run a state machine of a si= mple protocol such as 6P (draft-ietf-6tisch-6top-protocol-00)
- n= etwork bandwidth is severely constrained, and having two neighbor node disc= uss locally (e.g. as part of the 6P protocol) is more feasible than globall= y with the PCE for each transaction.
- given this, I wouldn't= dismiss having some distributed intelligence, with possibly the PCE/NME gi= ving high-level commands



=


On Thu, May 5, 2016 at 1:16 AM, Grossman, Ethan A. &l= t;eagros@dolby.com> wrote:
Statement:
6TiSCH use case: Path set/get protocol, must be direct to PCE
Discussion:
There has been discussion about whether path configuration is pushed t= o an endpoint directly from the PCE, or whether the path is configured from= device to device starting with the talker endpoint device, as it is in an = AVB network. Because devices that use 6TiSCH usually have constrained resources, the assumption here is that = this configuration would always be direct from the PCE, thus removing the p= eer-to-peer protocol requirement from the device. Similar logic applies to = getting device capability information from the device to the PCE =E2=80=93 making this a direct query from the PC= E to the device means that the device would not have to support being an in= termediary for collecting or forwarding capabilities of neighbor devices to= the PCE.=C2=A0 Here is an example of relevant text from the Use Cases draft, however part of this conversation was offlin= e and was not directly covered in the draft.
=C2=A0
=E2=80=9Da tiny IoT device may have just = enough buffers to=C2=A0 store one or a few IPv6 packets, and will have limi= ted bandwidth between=C2=A0 peers such that it can maintain only a small am= ount of peer information, and=C2=A0 will not be able to store many packets waiting to be forwarded. It is=C2=A0 advantageous then f= or it to only be required to carry out the specific behavior assigned to it= by the PCE/NME=E2=80=9D
=C2=A0
As a counter example, I could imagine that for a larger DetNet network= with many and powerful devices, perhaps device querying and configuration = might better be done in a hierarchical or tree=E2=80=99d manner; that is, l= imiting configuration to direct communication from the PCE to every individual device may be inefficient or limiting.
=C2=A0
So the question as I understand it is =E2=80=9Cwill the DetNet archite= cture support direct PCE-to-device interrogation and configuration?=E2=80= =9D It would not have to be to the exclusion of e.g. a hierarchical model, = but the point is not to assume a hierarchical model that would disenfranchise such small IoT devices.
=C2=A0

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet




--
_______________= ________________________

Thomas Watteyne, PhD
Research Sci= entist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH
<= br>
_______________________________________
--001a1147375843a30f053263f454-- From nobody Mon May 9 09:31:45 2016 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 DEE8912D156 for ; Mon, 9 May 2016 09:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 6nRXHgfAOSwx for ; Mon, 9 May 2016 09:31:41 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (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 3E38712D155 for ; Mon, 9 May 2016 09:31:41 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u49GV9bo015417; Mon, 9 May 2016 09:31:41 -0700 Received: from dlb-xchpw03.dolby.net (124.187.216.67.in-addr.arpa [67.216.187.124] (may be forged)) by mx0a-000fd501.pphosted.com with ESMTP id 22sem7arxq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 May 2016 09:31:40 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 9 May 2016 09:31:29 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1076.000; Mon, 9 May 2016 09:31:29 -0700 From: "Grossman, Ethan A." To: Thomas Watteyne Thread-Topic: [Detnet] DetNet Use Case Statements - 6TiSCH - Path set/get protocol, must be direct to PCE Thread-Index: AdGmVYq7fkowWwZHRLOQ86gR19L0rQDq3UkAAAOnHkg= Date: Mon, 9 May 2016 16:31:29 +0000 Message-ID: <1462811479718.19891@dolby.com> References: <3f4bbb01500c4c8799b387b84dd2517d@DLB-XCHPW03.dolby.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.233.7.60] Content-Type: multipart/alternative; boundary="_000_146281147971819891dolbycom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-09_07:, , signatures=0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements - 6TiSCH - Path set/get protocol, must be direct to PCE X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 16:31:44 -0000 --_000_146281147971819891dolbycom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas, Yes you are correct about my intent, and thank you for contributing. I have= not yet finished sending out all of this batch of emails (about 6 remain) = but once I do I will start harassing the group about replying to them :- ) My intent is to collate the results of replies to these "question statement= s" into "answer statements", then have the group "approve" the updated stat= ements, then update the Use Cases text accordingly. Ethan. ________________________________ From: Thomas Watteyne Sent: Monday, May 9, 2016 12:42 AM To: Grossman, Ethan A. Cc: detnet@ietf.org; Pascal Thubert (pthubert) (pthubert@cisco.com) Subject: Re: [Detnet] DetNet Use Case Statements - 6TiSCH - Path set/get pr= otocol, must be direct to PCE Ethan, [I'm going through the set of e-mails you just sent to the ML, assuming you= created these to kickstart different threads of execution. Please correct = me if I'm wrong.] My 2c on this issue: - small IoT devices (class 1 devices per RFC7228) are powerful enough to ru= n a state machine of a simple protocol such as 6P (draft-ietf-6tisch-6top-p= rotocol-00) - network bandwidth is severely constrained, and having two neighbor node d= iscuss locally (e.g. as part of the 6P protocol) is more feasible than glob= ally with the PCE for each transaction. - given this, I wouldn't dismiss having some distributed intelligence, with= possibly the PCE/NME giving high-level commands On Thu, May 5, 2016 at 1:16 AM, Grossman, Ethan A. > wrote: Statement: 6TiSCH use case: Path set/get protocol, must be direct to PCE Discussion: There has been discussion about whether path configuration is pushed to an = endpoint directly from the PCE, or whether the path is configured from devi= ce to device starting with the talker endpoint device, as it is in an AVB n= etwork. Because devices that use 6TiSCH usually have constrained resources,= the assumption here is that this configuration would always be direct from= the PCE, thus removing the peer-to-peer protocol requirement from the devi= ce. Similar logic applies to getting device capability information from the= device to the PCE - making this a direct query from the PCE to the device = means that the device would not have to support being an intermediary for c= ollecting or forwarding capabilities of neighbor devices to the PCE. Here = is an example of relevant text from the Use Cases draft, however part of th= is conversation was offline and was not directly covered in the draft. "a tiny IoT device may have just enough buffers to store one or a few IPv6= packets, and will have limited bandwidth between peers such that it can m= aintain only a small amount of peer information, and will not be able to s= tore many packets waiting to be forwarded. It is advantageous then for it = to only be required to carry out the specific behavior assigned to it by th= e PCE/NME" As a counter example, I could imagine that for a larger DetNet network with= many and powerful devices, perhaps device querying and configuration might= better be done in a hierarchical or tree'd manner; that is, limiting confi= guration to direct communication from the PCE to every individual device ma= y be inefficient or limiting. So the question as I understand it is "will the DetNet architecture support= direct PCE-to-device interrogation and configuration?" It would not have t= o be to the exclusion of e.g. a hierarchical model, but the point is not to= assume a hierarchical model that would disenfranchise such small IoT devic= es. _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --_000_146281147971819891dolbycom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Thomas,

Yes you are correct about my intent, and thank you for contributing. I h= ave not yet finished sending out all of this batch of emails (abo= ut 6 remain) but once I do I will start harassing the group about replying = to them :- ) 

My intent is to collate the results of replies to these "quest= ion statements" into "answer statements", then have the grou= p "approve" the updated statements, then update the Use Cases text accordingly. <= br>

Ethan.

From: Thomas Watteyne <t= homas.watteyne@inria.fr>
Sent: Monday, May 9, 2016 12:42 AM
To: Grossman, Ethan A.
Cc: detnet@ietf.org; Pascal Thubert (pthubert) (pthubert@cisco.com)<= br> Subject: Re: [Detnet] DetNet Use Case Statements - 6TiSCH - Path set= /get protocol, must be direct to PCE
 
Ethan,

[I'm going through the set of e-mails you just sent to the ML, assumin= g you created these to kickstart different threads of execution. Please cor= rect me if I'm wrong.]

My 2c on this issue:
- small IoT devices (class 1 devices per RFC7228) are powerful enough = to run a state machine of a simple protocol such as 6P (draft-ietf-6tisch-6= top-protocol-00)
- network bandwidth is severely constrained, and having two neighbor n= ode discuss locally (e.g. as part of the 6P protocol) is more feasible than= globally with the PCE for each transaction.
- given this, I wouldn't dismiss having some distributed intelligence,= with possibly the PCE/NME giving high-level commands





On Thu, May 5, 2016 at 1:16 AM, Grossman, Ethan = A. <eagros@dolby.com<= /a>> wrote:
Statement:
6TiSCH use case: Path set/get protocol, must be direct to PCE
Discussion:
There has been discussion about whether path configuration is pushed t= o an endpoint directly from the PCE, or whether the path is configured from= device to device starting with the talker endpoint device, as it is in an = AVB network. Because devices that use 6TiSCH usually have constrained resources, the assumption here is that= this configuration would always be direct from the PCE, thus removing the = peer-to-peer protocol requirement from the device. Similar logic applies to= getting device capability information from the device to the PCE – making this a direct query from the PCE= to the device means that the device would not have to support being an int= ermediary for collecting or forwarding capabilities of neighbor devices to = the PCE.  Here is an example of relevant text from the Use Cases draft, however part of this conversation was offli= ne and was not directly covered in the draft.
 
”a tiny IoT device may have just eno= ugh buffers to  store one or a few IPv6 packets, and will have limited= bandwidth between  peers such that it can maintain only a small amoun= t of peer information, and  will not be able to store many packets waiting to be forwarded. It is  advantageous then for it= to only be required to carry out the specific behavior assigned to it by t= he PCE/NME”
 
As a counter example, I could imagine that for a larger DetNet network= with many and powerful devices, perhaps device querying and configuration = might better be done in a hierarchical or tree’d manner; that is, lim= iting configuration to direct communication from the PCE to every individual device may be inefficient or limiting.
 
So the question as I understand it is “will the DetNet architect= ure support direct PCE-to-device interrogation and configuration?” It= would not have to be to the exclusion of e.g. a hierarchical model, but th= e point is not to assume a hierarchical model that would disenfranchise such small IoT devices.
 

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet=




--
________= _______________________________

Thomas W= atteyne, PhD
Research= Scientist & Innovator, Inria
Sr Netwo= rking Design Eng, Linear Tech
Founder = & co-lead, UC Berkeley OpenWSN
Co-chair= , IETF 6TiSCH

________= _______________________________
--_000_146281147971819891dolbycom_-- From nobody Mon May 9 10:39:04 2016 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 38C1112D167 for ; Mon, 9 May 2016 10:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cJy7o3Xn7cJK for ; Mon, 9 May 2016 10:39:01 -0700 (PDT) Received: from mx0b-000fd501.pphosted.com (mx0b-000fd501.pphosted.com [67.231.152.235]) (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 B157B12D585 for ; Mon, 9 May 2016 10:39:01 -0700 (PDT) Received: from pps.filterd (m0000695.ppops.net [127.0.0.1]) by mx0b-000fd501.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u49HZH3Q003006; Mon, 9 May 2016 10:38:52 -0700 Received: from dlb-xchpw03.dolby.net (124.187.216.67.in-addr.arpa [67.216.187.124] (may be forged)) by mx0b-000fd501.pphosted.com with ESMTP id 22se56mwk8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 May 2016 10:38:52 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 9 May 2016 10:38:41 -0700 Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1076.000; Mon, 9 May 2016 10:38:41 -0700 From: "Grossman, Ethan A." To: Lou Berger , Pat Thaler Thread-Topic: Use Cases preso at IETF 96 - Ethan can't make it Thread-Index: AQHRqhEIV5AzPq4SlEC4IJZqptN3FA== Date: Mon, 9 May 2016 17:38:41 +0000 Message-ID: <1462815511403.31467@dolby.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.207.133.62] Content-Type: multipart/alternative; boundary="_000_146281551140331467dolbycom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-09_07:, , signatures=0 Archived-At: Cc: "jouni.korhonen@broadcom.com" , "detnet@ietf.org" , =?iso-8859-1?Q?Bal=E1zs_Varga_A?= Subject: [Detnet] Use Cases preso at IETF 96 - Ethan can't make it X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 17:39:03 -0000 --_000_146281551140331467dolbycom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lou and Pat, I can't attend IETF 96 in Berlin (though I intend to attend the DetNet sess= ion remotely). I can put together a PPT preso summarizing the current state= of the use cases, i.e. what I would do if I were going to be there to pres= ent it, but I need someone else to present it (and contribute if they wish)= . Perhaps Bala'zs might agree to present? I could attempt the preso remotely but the results lately seem to be mixed = (though I am open to trying it with a human as a fallback). Opinions on th= is? Regarding my attendance at future IETF DetNet sessions I have requested fro= m my management to continue in-person participation, but I don't have a con= crete agreement in place yet - TBD. Ethan. --_000_146281551140331467dolbycom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Lou and Pat,


I can't attend IETF 96 in Berlin (though I intend to attend the DetNet session remotely). I= can put together a PPT preso summarizing the current state of the use cases, i.e. what I would do if I were going to be= there to present it, but I need someone else to present it (and contr= ibute if they wish). Perhaps Bala’zs might agree to present? 


I could attempt the preso remotely but the results lately= seem to be mixed (though I am open to trying it with a= human as a fallback).  Opinions on this? 


Regarding my attendance at future IETF DetNet sessions I have = requested from my management to continue in-person participation,= but I don't have a concrete agreement in place yet - TBD. 


Ethan. 

--_000_146281551140331467dolbycom_-- From nobody Mon May 9 13:02:02 2016 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 854D712D605 for ; Mon, 9 May 2016 13:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 fCi5yVwAXYn3 for ; Mon, 9 May 2016 13:01:47 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921FD12D5EF for ; Mon, 9 May 2016 13:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5563; q=dns/txt; s=iport; t=1462824106; x=1464033706; h=from:to:cc:subject:date:message-id:mime-version; bh=1kUZNsyxnS0lSI/bPRm1p1KKYQENNlEsx3AtlKGEE4I=; b=jDcmeEXGUTJ0dasCuCNQCoA4h7u+87UcXz2nKVaeYuJ8MRSyguPRiw6K qSKOxNXRVkNoPNHGxpbPZig1Qp2a4WpQjirl9JImvkvtQDXFxOn6ixQIS SPSJD+FGNqctqmBN/oXFHjI6U5x7KWqCSqdksZj2of7/44AWYLwCFGr2Q Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AgBV7DBX/4cNJK1dgmxMgVIGtByCZ?= =?us-ascii?q?YIPAQ2BdoYQgTs4FAEBAQEBAQFlJ4RBAQEBBHkSAQgRAwECKDkUCQoEAQ0FiCu?= =?us-ascii?q?/OAEBAQEBAQEDAQEBAQEBAQEBF4YghEyEX4U5BYthgjWFFoR2AY4bjxePOgEeA?= =?us-ascii?q?QFCg2tuAYgGfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,601,1454976000"; d="scan'208,217";a="100706505" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2016 20:01:21 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u49K1LC3026300 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 May 2016 20:01:21 GMT Received: from xch-rtp-014.cisco.com (64.101.220.154) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 May 2016 16:01:20 -0400 Received: from xch-rtp-014.cisco.com ([64.101.220.154]) by XCH-RTP-014.cisco.com ([64.101.220.154]) with mapi id 15.00.1104.009; Mon, 9 May 2016 16:01:20 -0400 From: "Patrick Wetterwald (pwetterw)" To: "Grossman, Ethan A." , Lou Berger , Pat Thaler Thread-Topic: [Detnet] Use Cases preso at IETF 96 - Ethan can't make it Thread-Index: AQHRqi2ObxfMFV18LEOn4/Y+J4gdNw== Date: Mon, 9 May 2016 20:01:20 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.149.184] Content-Type: multipart/alternative; boundary="_000_D356B8EF6AC99pwetterwciscocom_" MIME-Version: 1.0 Archived-At: Cc: "jouni.korhonen@broadcom.com" , "detnet@ietf.org" , =?iso-8859-1?Q?Bal=E1zs_Varga_A?= Subject: Re: [Detnet] Use Cases preso at IETF 96 - Ethan can't make it X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 20:02:00 -0000 --_000_D356B8EF6AC99pwetterwciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ethan, If needed, I can present on your behalf. Thanks, Patrick From: detnet > on b= ehalf of "Grossman, Ethan A." > Date: Monday 9 May 2016 at 19:38 To: Lou Berger >, Pat Thaler > Cc: "jouni.korhonen@broadcom.com" >, "detnet@ietf.= org" >, Bal= =E1zs Varga A > Subject: [Detnet] Use Cases preso at IETF 96 - Ethan can't make it Hi Lou and Pat, I can't attend IETF 96 in Berlin (though I intend to attend the DetNet sess= ion remotely). I can put together a PPT preso summarizing the current state= of the use cases, i.e. what I would do if I were going to be there to pres= ent it, but I need someone else to present it (and contribute if they wish)= . Perhaps Bala'zs might agree to present? I could attempt the preso remotely but the results lately seem to be mixed = (though I am open to trying it with a human as a fallback). Opinions on th= is? Regarding my attendance at future IETF DetNet sessions I have requested fro= m my management to continue in-person participation, but I don't have a con= crete agreement in place yet - TBD. Ethan. --_000_D356B8EF6AC99pwetterwciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <742CD7B3A1F1A441B480C89B23A65232@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Ethan,

If needed, I can present on your behalf.

Thanks,

Patrick

From: detnet <detnet-bounces@ietf.org> on behalf of "= ;Grossman, Ethan A." <eagros@do= lby.com>
Date: Monday 9 May 2016 at 19:38 To: Lou Berger <lberger@labn.net>, Pat Thaler <pthaler@broadcom.com>
Cc: "jouni.korhonen@broadcom.com" <jouni.korhonen@broadcom.com>, &q= uot;detnet@ietf.org" <detnet@ietf.org>, Bal=E1zs Varga A <balazs= .a.varga@ericsson.com>
Subject: [Detnet] Use Cases preso a= t IETF 96 - Ethan can't make it

Hi Lou and Pat,


I can't attend IETF 96 in Berlin (though I intend to attend the DetNet session remotely). I= can put together a PPT preso summarizing the current state of the use cases, i.e. what I would do if I were going to be= there to present it, but I need someone else to present it (and contr= ibute if they wish). Perhaps Bala’zs might agree to present? 


I could attempt the preso remotely but the results lately= seem to be mixed (though I am open to trying it with a= human as a fallback).  Opinions on this? 


Regarding my attendance at future IETF DetNet sessions I have = requested from my management to continue in-person participation,= but I don't have a concrete agreement in place yet - TBD. 


Ethan. 

 --_000_D356B8EF6AC99pwetterwciscocom_-- From nobody Mon May 9 22:15:07 2016 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 34D5A12D0CC for ; Mon, 9 May 2016 22:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 nTzykOBVdwu7 for ; Mon, 9 May 2016 22:15:02 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2114212D0F6 for ; Mon, 9 May 2016 22:14:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,603,1454972400"; d="scan'208,217";a="217496626" Received: from mail-lf0-f54.google.com ([209.85.215.54]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 10 May 2016 07:14:58 +0200 Received: by mail-lf0-f54.google.com with SMTP id j8so2012994lfd.2 for ; Mon, 09 May 2016 22:14:58 -0700 (PDT) X-Gm-Message-State: AOPr4FVN9827IlULcqG7vT9zSuY77bEpQ68b6ClE3qmA2qkNlHfUb2KHbXnNUnF9RBdK0NVdvKdnwK80P7OSCg== X-Received: by 10.112.12.1 with SMTP id u1mr6994342lbb.98.1462857298004; Mon, 09 May 2016 22:14:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.149.195 with HTTP; Mon, 9 May 2016 22:14:38 -0700 (PDT) In-Reply-To: <1462811479718.19891@dolby.com> References: <3f4bbb01500c4c8799b387b84dd2517d@DLB-XCHPW03.dolby.net> <1462811479718.19891@dolby.com> From: Thomas Watteyne Date: Tue, 10 May 2016 07:14:38 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "Grossman, Ethan A." Content-Type: multipart/alternative; boundary=001a11c3f4de9ad6760532760101 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements - 6TiSCH - Path set/get protocol, must be direct to PCE X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 05:15:05 -0000 --001a11c3f4de9ad6760532760101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ethan, Great, thanks! Thomas On Mon, May 9, 2016 at 6:31 PM, Grossman, Ethan A. wrote= : > Hi Thomas, > > Yes you are correct about my intent, and thank you for contributing. I > have not yet finished sending out all of this batch of emails (about 6 > remain) but once I do I will start harassing the group about replying to > them :- ) > > My intent is to collate the results of replies to > these "question statements" into "answer statements", then have the group > "approve" the updated statements, then update the Use Cases text > accordingly. > > Ethan. > ------------------------------ > *From:* Thomas Watteyne > *Sent:* Monday, May 9, 2016 12:42 AM > *To:* Grossman, Ethan A. > *Cc:* detnet@ietf.org; Pascal Thubert (pthubert) (pthubert@cisco.com) > *Subject:* Re: [Detnet] DetNet Use Case Statements - 6TiSCH - Path > set/get protocol, must be direct to PCE > > Ethan, > > [I'm going through the set of e-mails you just sent to the ML, assuming > you created these to kickstart different threads of execution. Please > correct me if I'm wrong.] > > My 2c on this issue: > - small IoT devices (class 1 devices per RFC7228) are powerful enough to > run a state machine of a simple protocol such as 6P > (draft-ietf-6tisch-6top-protocol-00) > - network bandwidth is severely constrained, and having two neighbor node > discuss locally (e.g. as part of the 6P protocol) is more feasible than > globally with the PCE for each transaction. > - given this, I wouldn't dismiss having some distributed intelligence, > with possibly the PCE/NME giving high-level commands > > > > > > On Thu, May 5, 2016 at 1:16 AM, Grossman, Ethan A. > wrote: > >> Statement: >> 6TiSCH use case: Path set/get protocol, must be direct to PCE >> Discussion: >> There has been discussion about whether path configuration is pushed to >> an endpoint directly from the PCE, or whether the path is configured fro= m >> device to device starting with the talker endpoint device, as it is in a= n >> AVB network. Because devices that use 6TiSCH usually have constrained >> resources, the assumption here is that this configuration would always b= e >> direct from the PCE, thus removing the peer-to-peer protocol requirement >> from the device. Similar logic applies to getting device capability >> information from the device to the PCE =E2=80=93 making this a direct qu= ery from >> the PCE to the device means that the device would not have to support be= ing >> an intermediary for collecting or forwarding capabilities of neighbor >> devices to the PCE. Here is an example of relevant text from the Use Ca= ses >> draft, however part of this conversation was offline and was not directl= y >> covered in the draft. >> >> =E2=80=9Da tiny IoT device may have just enough buffers to store one or= a few >> IPv6 packets, and will have limited bandwidth between peers such that i= t >> can maintain only a small amount of peer information, and will not be a= ble >> to store many packets waiting to be forwarded. It is advantageous then = for >> it to only be required to carry out the specific behavior assigned to it= by >> the PCE/NME=E2=80=9D >> >> As a counter example, I could imagine that for a larger DetNet network >> with many and powerful devices, perhaps device querying and configuratio= n >> might better be done in a hierarchical or tree=E2=80=99d manner; that is= , limiting >> configuration to direct communication from the PCE to every individual >> device may be inefficient or limiting. >> >> So the question as I understand it is =E2=80=9Cwill the DetNet architect= ure >> support direct PCE-to-device interrogation and configuration?=E2=80=9D I= t would not >> have to be to the exclusion of e.g. a hierarchical model, but the point = is >> not to assume a hierarchical model that would disenfranchise such small = IoT >> devices. >> >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >> >> >> > > > -- > _______________________________________ > > Thomas Watteyne, PhD > Research Scientist & Innovator, Inria > Sr Networking Design Eng, Linear Tech > Founder & co-lead, UC Berkeley OpenWSN > Co-chair, IETF 6TiSCH > > www.thomaswatteyne.com > > _______________________________________ > --=20 _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a11c3f4de9ad6760532760101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ethan,
Great, thanks!
Thomas

On Mon, May 9, 2016 a= t 6:31 PM, Grossman, Ethan A. <eagros@dolby.com> wrote:

Hi Thomas,

Yes you are correct about my intent, and thank you for contributing. I h= ave not yet finished sending out all=C2=A0of this batch of=C2=A0emails (abo= ut 6 remain) but once I do I will start harassing the group about replying = to them :- )=C2=A0

My intent is to collate the results of replies to these=C2=A0"quest= ion=C2=A0statements"=C2=A0into &q= uot;answer statements",=C2=A0then=C2=A0have the group "app= rove" the updated statements, then update the Use Cases text accordingly.=C2=A0<= br>

Ethan.

From: Thomas Watteyne <thomas.watteyne@inria.fr> Sent: Monday, May 9, 2016 12:42 AM
To: Grossman, Ethan A.
Cc: detnet@ietf= .org; Pascal Thubert (pthubert) (pthubert@cisco.com)
Subject: Re: [Detnet] DetNet Use Case Statements - 6TiSCH - Path set= /get protocol, must be direct to PCE
=C2=A0
Ethan,

[I'm going through the set of e-mails you just sent to the ML, ass= uming you created these to kickstart different threads of execution. Please= correct me if I'm wrong.]

My 2c on this issue:
- small IoT devices (class 1 devices per RFC7228) are powerful enough = to run a state machine of a simple protocol such as 6P (draft-ietf-6tisch-6= top-protocol-00)
- network bandwidth is severely constrained, and having two neighbor n= ode discuss locally (e.g. as part of the 6P protocol) is more feasible than= globally with the PCE for each transaction.
- given this, I wouldn't dismiss having some distributed intellige= nce, with possibly the PCE/NME giving high-level commands





On Thu, May 5, 2016 at 1:16 AM, Grossman, Ethan = A. <eagros@dolby.com<= /a>> wrote:
Statement:
6TiSCH use case: Path set/get protocol, must be direct to PCE
Discussion:
There has been discussion about whether path configuration is pushed t= o an endpoint directly from the PCE, or whether the path is configured from= device to device starting with the talker endpoint device, as it is in an = AVB network. Because devices that use 6TiSCH usually have constrained resources, the assumption here is that= this configuration would always be direct from the PCE, thus removing the = peer-to-peer protocol requirement from the device. Similar logic applies to= getting device capability information from the device to the PCE =E2=80=93 making this a direct query from the P= CE to the device means that the device would not have to support being an i= ntermediary for collecting or forwarding capabilities of neighbor devices t= o the PCE.=C2=A0 Here is an example of relevant text from the Use Cases draft, however part of this conversation was offli= ne and was not directly covered in the draft.
=C2=A0
=E2=80=9Da tiny IoT device may have just e= nough buffers to=C2=A0 store one or a few IPv6 packets, and will have limit= ed bandwidth between=C2=A0 peers such that it can maintain only a small amo= unt of peer information, and=C2=A0 will not be able to store many packets waiting to be forwarded. It is=C2=A0 advantageous then for it= to only be required to carry out the specific behavior assigned to it by t= he PCE/NME=E2=80=9D
=C2=A0
As a counter example, I could imagine that for a larger DetNet network= with many and powerful devices, perhaps device querying and configuration = might better be done in a hierarchical or tree=E2=80=99d manner; that is, l= imiting configuration to direct communication from the PCE to every individual device may be inefficient or limiting.
=C2=A0
So the question as I understand it is =E2=80=9Cwill the DetNet archite= cture support direct PCE-to-device interrogation and configuration?=E2=80= =9D It would not have to be to the exclusion of e.g. a hierarchical model, = but the point is not to assume a hierarchical model that would disenfranchise such small IoT devices.
=C2=A0

_______________________________________________
detnet mailing list
detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet=




--
________= _______________________________

Thomas W= atteyne, PhD
Research= Scientist & Innovator, Inria
Sr Netwo= rking Design Eng, Linear Tech
Founder = & co-lead, UC Berkeley OpenWSN
Co-chair= , IETF 6TiSCH

________= _______________________________



--
_______________________= ________________

Thomas Watteyne, PhD
Research Scientist= & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Found= er & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswat= teyne.com
_______________________________________
--001a11c3f4de9ad6760532760101-- From nobody Tue May 10 07:39:44 2016 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 BC7CD12B030 for ; Tue, 10 May 2016 07:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 l_vmxwJEo2o4 for ; Tue, 10 May 2016 07:39:40 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3F312B068 for ; Tue, 10 May 2016 07:39:39 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-d3-5731f2a9c0bb Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E1.A6.27088.9A2F1375; Tue, 10 May 2016 16:39:37 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.234]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Tue, 10 May 2016 16:39:37 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "Patrick Wetterwald (pwetterw)" , "Grossman, Ethan A." , Lou Berger , Pat Thaler Thread-Topic: [Detnet] Use Cases preso at IETF 96 - Ethan can't make it Thread-Index: AQHRqi2ObxfMFV18LEOn4/Y+J4gdN5+yPbeg Date: Tue, 10 May 2016 14:39:36 +0000 Message-ID: <3002A87EA61E0A4DB56546AC16A0D5171EFAAD11@ESESSMB103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_3002A87EA61E0A4DB56546AC16A0D5171EFAAD11ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsUyM2K7ge7KT4bhBqf3W1j8/jSbxaLv8XZ2 i4dfEiw6mt+yWLxd+JvdYt2+mYwObB6z7p9l85jyeyOrx76JR1g8liz5yeTxYVMzWwBrFJdN SmpOZllqkb5dAlfG2a2fmQqOxVdc/3mYqYHxXGgXIyeHhICJxOs9f5khbDGJC/fWs3UxcnEI CRxhlLj2eQ0LhLOEUeJ0zyNGkCo2AVeJzx0PwapEBJYzSqzcfYwdJMEskCZx/e9XFhBbWMBN YsLZF0wgtoiAu8SWMz8YIWwjiROXb7GC2CwCqhKHzxwHqufg4BXwlZjxVgMkLCSgL/H7+TE2 EJtTwEBi9Z2FYOMZga77fmoNE8QqcYlbT+YzQVwtILFkz3moD0QlXj7+xwphK0ksuv0Zqj5f 4uzGvWAzeQUEJU7OfMIygVF0FpJRs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1dixr9DLMji CxjZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERu3BLb8NdjC+fO54iFGAg1GJh3eBg2G4 EGtiWXFl7iFGCQ5mJRHew++BQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqem FqQWwWSZODilGhhNJ5TNvff24DOliYwnPk39mvXlSZP91X45/8brHXkPQ41rxIu7NXe1xivP MHk8i23hTe7pGvcU3ZexG1RmfJN8q2Sg95/RctHsYzMtUt5fPL72SuPdwnUumxiqzV8fW+K9 UzfnX/0Ltn6b+qXzbmbFdfZLt7+MjLzaeFQszcbrX1bNGv/USj4lluKMREMt5qLiRADkXu+5 1gIAAA== Archived-At: Cc: "jouni.korhonen@broadcom.com" , "detnet@ietf.org" Subject: Re: [Detnet] Use Cases preso at IETF 96 - Ethan can't make it X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 14:39:43 -0000 --_000_3002A87EA61E0A4DB56546AC16A0D5171EFAAD11ESESSMB103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ethan, I think remote presentation has worked not so bad in Buenos Aires, so that = may be the primary option. :---))) Anyway I am also fine if Patrick presents it or I can do it also as a "huma= n fallback". Cheers Bala'zs From: Patrick Wetterwald (pwetterw) [mailto:pwetterw@cisco.com] Sent: Monday, May 09, 2016 10:01 PM To: Grossman, Ethan A.; Lou Berger; Pat Thaler Cc: jouni.korhonen@broadcom.com; detnet@ietf.org; Bal=E1zs Varga A Subject: Re: [Detnet] Use Cases preso at IETF 96 - Ethan can't make it Hi Ethan, If needed, I can present on your behalf. Thanks, Patrick From: detnet > on b= ehalf of "Grossman, Ethan A." > Date: Monday 9 May 2016 at 19:38 To: Lou Berger >, Pat Thaler > Cc: "jouni.korhonen@broadcom.com" >, "detnet@ietf.= org" >, Bal= =E1zs Varga A > Subject: [Detnet] Use Cases preso at IETF 96 - Ethan can't make it Hi Lou and Pat, I can't attend IETF 96 in Berlin (though I intend to attend the DetNet sess= ion remotely). I can put together a PPT preso summarizing the current state= of the use cases, i.e. what I would do if I were going to be there to pres= ent it, but I need someone else to present it (and contribute if they wish)= . Perhaps Bala'zs might agree to present? I could attempt the preso remotely but the results lately seem to be mixed = (though I am open to trying it with a human as a fallback). Opinions on th= is? Regarding my attendance at future IETF DetNet sessions I have requested fro= m my management to continue in-person participation, but I don't have a con= crete agreement in place yet - TBD. Ethan. --_000_3002A87EA61E0A4DB56546AC16A0D5171EFAAD11ESESSMB103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ethan,

I think remote presentati= on has worked not so bad in Buenos Aires, so that may be the primary option= . :---)))

Anyway I am also fine if = Patrick presents it or I can do it also as a “human fallback”.<= o:p>

Cheers<= /p>

Bala’zs<= /span>

 <= /p>

 <= /p>

From: Patrick = Wetterwald (pwetterw) [mailto:pwetterw@cisco.com]
Sent: Monday, May 09, 2016 10:01 PM
To: Grossman, Ethan A.; Lou Berger; Pat Thaler
Cc: jouni.korhonen@broadcom.com; detnet@ietf.org; Bal=E1zs Varga A Subject: Re: [Detnet] Use Cases preso at IETF 96 - Ethan can't make = it

 

Hi Ethan,=

 

If needed, I can present on= your behalf.

 

Thanks,

 

Patrick

 

From: detnet <detnet-bounces@ietf.org> on behalf of "Grossman,= Ethan A." <eagros@dolby.com>
Date: Monday 9 May 2016 at 19:38
To: Lou Berger <lberger@labn.= net>, Pat Thaler <pthaler= @broadcom.com>
Cc: "jouni.korho= nen@broadcom.com" <jouni.korhonen@broadcom.com>, "detnet@ietf.org" <detn= et@ietf.org>, Bal=E1zs Varga A <balazs= .a.varga@ericsson.com>
Subject: [Detnet] Use Cases preso at IETF 96 - Ethan can't make it

 

Hi Lou and Pat,

 

I can't attend IETF 96 in Berlin= (though I intend to attend the DetNe= t session remotely). I can put together a PPT preso summarizing the current state of the use cases, i.e. what I would do if I were going t= o be there to present it, but I need someone else to present it (and c= ontribute if they wish). Perhaps Bala’zs might agree to present? 

 

I could attempt the preso remote= ly but the results lately seem to be mixed (though= I am open to trying it with a human as a fallback).  Opinions on= this? 

 

Regarding my attendance at futur= e IETF DetNet sessions I have requested from my management to con= tinue in-person participation, but I don't have a concrete agreement i= n place yet - TBD. 

 

Ethan. 

--_000_3002A87EA61E0A4DB56546AC16A0D5171EFAAD11ESESSMB103erics_-- From nobody Fri May 20 16:04:15 2016 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 1B58812D662 for ; Fri, 20 May 2016 16:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 ZHW9xFOtha-f for ; Fri, 20 May 2016 16:04:12 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 9EF1212D65E for ; Fri, 20 May 2016 16:04:12 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id qo8so43951484pab.1 for ; Fri, 20 May 2016 16:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=subject:references:to:reply-to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=cEMzV6JyLwo3gmyyONRPxb2xwHVjoe/R3RCX8sHGmRU=; b=O9d71uv6ckpizXCK2vfynqU0HnyRlWr4lmue05dcsxEaCW4tkP9Heq4OYhzlAgFtcZ HPDnExc241DgZ3Hop3nsnXVgd3EYvFVTl6kAXlyxirKSaEYRWsmE8vrj6ZblxrsRjwmM HgmY13r3QE5TLn9U8OK3v7vRNoboMR4aqSMrw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:reply-to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cEMzV6JyLwo3gmyyONRPxb2xwHVjoe/R3RCX8sHGmRU=; b=UaNjeIjQw8ims9PsiF8QAc4Z/Bw6NCVn5AnDUWrSC7VoAQEwBWp0gDd6EUlMdrvm1/ Mr8b9peMwyS6dzQ5PqfDYinzTYkRgqFn8l6RkT3/RQqaCH+1svUkgvhZIIpuviXF0Jzh bScQAd0wMHjrq1aJ1CaZ/DIlEiUcmmB/zbdp9utP/vlTdMUdcAZ35Aw4UCuCianuabMl smQ1xavJXzldZapYJrhSMpulfyOOK97C7qBEbsYb+hVpdeiW8pX/SNv1+dDeOaHjcumP qWlMqt2pJTSYsVXRO0cE+4xcm7z7O/nvE42Q0eb4fpHg1wUjwQkVX9hXxswYDU+i50ZH Nsbg== X-Gm-Message-State: AOPr4FWrmZavxRRWE9EQZ6tgnQf7hlPVAbGa3S6kZbTIVsubWeksLy99bNsedRb8KIGwvzMu X-Received: by 10.66.142.199 with SMTP id ry7mr8622967pab.14.1463785451863; Fri, 20 May 2016 16:04:11 -0700 (PDT) Received: from [10.16.75.74] (5520-maca-inet1-outside.broadcom.com. [216.31.211.11]) by smtp.gmail.com with ESMTPSA id a5sm29614253pat.19.2016.05.20.16.04.10 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 16:04:10 -0700 (PDT) References: <20160519190342.15488.2118.idtracker@ietfa.amsl.com> To: DetNet WG From: Jouni Korhonen X-Forwarded-Message-Id: <20160519190342.15488.2118.idtracker@ietfa.amsl.com> Message-ID: <8bf1bc92-2118-61bd-ae26-79616375217c@broadcom.com> Date: Fri, 20 May 2016 16:04:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160519190342.15488.2118.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Detnet] Fwd: NomCom 2016-2017 Call for Volunteers X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.korhonen@broadcom.com 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, 20 May 2016 23:04:14 -0000 FYI -------- Välitetty viesti / Fwd.Msg -------- Aihe: NomCom 2016-2017 Call for Volunteers Päiväys: Thu, 19 May 2016 12:03:42 -0700 Lähettäjä: NomCom Chair 2016 Vastausosoite: ietf@ietf.org Vastaanottaja: IETF Announcement List Subject: NomCom 2016-2017 Call for Volunteers The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF = 91 (Honolulu) \ 92 (Dallas) \ 93 (Prague) -*** ANY THREE! 94 (Yokohama) / 95 (Buenos Aires) / If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this Nomcom will not be considered as a candidate for any of the positions that the 2016 - 2017 Nomcom is responsible for filling. Some 229 people have already volunteered by ticking the box on the IETF 95 registration form. 131 of these have been verified as eligible. I will contact all of these shortly. Thank you for volunteering! The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Lou Berger IAB: Ralph Droms Russ Housley Robert Sparks Andrew Sullivan Dave Thaler Suzanne Woolf IESG: Jari Arkko (GEN) Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC) Joel Jaeggli (OPS) Terry Manderson (INT) Alvaro Retana (RTG) All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (with the exception of GEN) have at least one continuing AD. The primary activity for this nomcom will begin in July 2016 and should be completed in January 2017. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a nomcom member does require some time commitment it is also a very rewarding experience. As a member of the nomcom it is very important that you be able to attend IETF97 (Seoul) to conduct interviews. Being at IETF96 (Berlin) is useful for orientation. Being at IETF98 is not essential. Please volunteer by sending me an email before 23:59 UTC June 20, 2016, as follows: To: nomcom-chair-2016@ietf.org Subject: Nomcom 2016-17 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 5 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2016/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next few weeks. Thank you! Lucy Lynch llynch@civil-tongue.net nomcom-chair-2016@ietf.org