Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Zhe Lou <zhe.lou@huawei.com> Fri, 19 August 2022 10:49 UTC

Return-Path: <zhe.lou@huawei.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0A6C15948A for <6lo@ietfa.amsl.com>; Fri, 19 Aug 2022 03:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAxgwBqc95O0 for <6lo@ietfa.amsl.com>; Fri, 19 Aug 2022 03:49:53 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EEBC15948E for <6lo@ietf.org>; Fri, 19 Aug 2022 03:49:53 -0700 (PDT)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4M8JRM1dTDz6839H for <6lo@ietf.org>; Fri, 19 Aug 2022 18:49:35 +0800 (CST)
Received: from fraeml713-chm.china.huawei.com (10.206.15.32) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 19 Aug 2022 12:49:51 +0200
Received: from fraeml713-chm.china.huawei.com ([10.206.15.32]) by fraeml713-chm.china.huawei.com ([10.206.15.32]) with mapi id 15.01.2375.024; Fri, 19 Aug 2022 12:49:51 +0200
From: Zhe Lou <zhe.lou@huawei.com>
To: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03
Thread-Index: AQHYpbcLm+3fBg7AqEi0pKaBGoaPXK2epSMAgAD1VgCAABDeAIABV5MAgAmNpw6AAGJKgIAK/XyggAAAi2CAADEkYA==
Date: Fri, 19 Aug 2022 10:49:51 +0000
Message-ID: <275177c14d594403a164a13e98aef47b@huawei.com>
References: <1d6aeaec89c928b305d82c4c53f87156.squirrel@webmail.entel.upc.edu>, <76D139FE-0BA1-4B9A-853C-11DF751ADF3C@unifi.it>, <32AA571A-F44D-4DD7-9EBB-B521C17162AF@cisco.com>, <578552483d93409b8f1a3e68a486f76c@huawei.com>, <CACt2foE4pdu3F1FdFwxxmwpkY7aX8e1HyO45rwmtJXYF7U163Q@mail.gmail.com> <2022081209533321792626@chinamobile.com> <27953.1660318979@localhost> <2366879af12a44aa879851d8870fdd2e@huawei.com> <013801d8b3a6$52faf0b0$f8f0d210$@com>
In-Reply-To: <013801d8b3a6$52faf0b0$f8f0d210$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.221.99.34]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/hlzBtE6Ayu9DpmiTSTa32LNQIxw>
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2022 10:49:57 -0000

Dear 6lo,
 
For the past 3 weeks, I saw many people support the adoption of the draft-li-6lo-native-short-address-03. Meanwhile, we received some concerns on the applicability and reliability of the NSA solution as well. Regarding to the applicability, the draft clearly states that the NSA solution is suitable for “scenarios and applications with static network topologies and stable network connections leveraging on wired technologies…” In the draft-ietf-6lo-use-cases-13, it lists at least 2 use cases using wireline technologies. For instance the smart grid use case has wide applicability, which typically contains a star/tree-based topology as indicated in the 6lo-use-case draft and many other academic publications.* NSA can be perfectly applied here. On top of that, smart manufacturing as indicated in the Kiran’s email is another use case example. In the shop floor of a factory, most of the devices are connected in wire. In the light of Industry 4.0, the manufacturers expects the sensors and actuators deployed in the shop floor can communicate to the cloud directly. NSA could be a good candidate to bridge most of the industrial Ethernet protocols (e.g. EtherCAT, Sercos, Powerlink, cc-link IE, etc.) towards the Internet. The one mentioned by Rong is another good example.
 
Another concern is the reliability. As NSA is suitable for wireline use cases, the system stability is by nature much higher than wireless systems. In the smart grid use case for instance, I believe the NSA solution defined in the draft-li-6lo-native-short-address-03 could work. One may argue when the electricity is down, the network is off. But in reality, power outage doesn’t happen so often. Anyway, based on the feedback from the community, we wrote another draft-li-nsa-reliability-00 to illustrate how to further improve the reliability of the system by adding an extra redundant link to make sure that one child will have at least 2 parents. We may dive into deep discussion on the reliability draft in a separate thread.
 
As one of the authors, I support the WG adoption of the draft-li-6lo-native-short-address-03.
 
*D. Seo, H. Lee, A. Perrig, “Secure and Efficient Capability-Based Power Management in the Smart Grid”, IEEE Ninth International Symposium on Parallel and Distributed Processing with Applications Workshops, May 2011
*T. Hartmann, F. Fouquet, J. Klein, et. Al, “Generating realistic Smart Grid communication topologies based on real-data”, IEEE International Conference on Smart Grid Communications (SmartGridComm), November, 2014
 

Kind regards
David Lou



-----Original Message-----
From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of longrong
Sent: Friday, 19 August 2022 10:33
To: 6lo@ietf.org
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

I support this adoption. To response of challenges to use case and applicability, I would share a concrete use case described as follows:

Companies(including CMCC) build more and more huge datacenters as the development of business. However, not all of them comply with the newest regulations for power & environment(P&E) supervision. So, there are requirements to setup extra P&E supervision sensors and devices in those datacenters.
The current P&E supervision system employ Field Supervision Unit(FSU) for data transmission and power supply, however, due to the shortage of ports and limitation of voltage supply, FSU cannot fulfill the massive sensor requirement of the smart/intelligent datacenter, which often requires over 600 or 1000 sensors, so additional power supply or batteries are often used. In this case, although massive sensors can help reduce the power consumption of datacenter cooling, but the data transmission of those sensors also caused huge power consumption, which can be improved by low power transmission protocol. And wireless is not the most optimized approach for connection because of electromagnetic interference. Field supervision unit(FSU) will connect to sensor by wired technology, such as AI/DI/RS232/RS485/single pair ethernet. Multiple FSUs will connect to hierarchical supervision centers and then make data communication with supervision platform by IPv6.

I believe the NSA solution is a good attempt to be used in this use case. And Data center supervision is just one typical use case, with emerging of various smart applications, massive terminal or sensors connection will become regular method, thus a low power transmission method is necessary for reduce heavy power consumption.



Research Institute of China Mobile
32 West XuanWuMen Ave, Xichen District,
Beijing 100053, China

Mobile:13701354531 
E-mail:longrong@chinamobile.com



-----Original Message-----
From: 6lo <6lo-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: Friday, August 12, 2022 11:43 PM
To: 6lo <6lo@ietf.org>
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03


    > believe that it has positive feedback from 6lo WG.  As Pascal said,
    > this draft has better to consider the narrow applicability and try to
    > find a common/general use case.

Why would we spend time on a document that hasn't got a clear use case?

I watched the 6lo recording (conflict with jwp BOF) yesterday, and the question about resiliency and alternate paths is a very serious one.
Is this a routing protocol or not?

I do not support adoption of the document.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide







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