Re: [6lo] FW: New Version Notification for draft-li-native-short-address-00.txt

"Liguangpeng (Roc, Network Technology Laboratory)" <liguangpeng@huawei.com> Wed, 28 July 2021 08:17 UTC

Return-Path: <liguangpeng@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 37AA93A22D8 for <6lo@ietfa.amsl.com>; Wed, 28 Jul 2021 01:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMPkvYRn_hEx for <6lo@ietfa.amsl.com>; Wed, 28 Jul 2021 01:17:28 -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 81AEC3A22DA for <6lo@ietf.org>; Wed, 28 Jul 2021 01:17:28 -0700 (PDT)
Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GZR2z1BvRz6BBK4 for <6lo@ietf.org>; Wed, 28 Jul 2021 16:02:19 +0800 (CST)
Received: from dggpemm500003.china.huawei.com (7.185.36.56) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 28 Jul 2021 10:17:24 +0200
Received: from dggpemm500004.china.huawei.com (7.185.36.219) by dggpemm500003.china.huawei.com (7.185.36.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 28 Jul 2021 16:17:22 +0800
Received: from dggpemm500004.china.huawei.com ([7.185.36.219]) by dggpemm500004.china.huawei.com ([7.185.36.219]) with mapi id 15.01.2176.012; Wed, 28 Jul 2021 16:17:22 +0800
From: "Liguangpeng (Roc, Network Technology Laboratory)" <liguangpeng@huawei.com>
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
CC: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] FW: New Version Notification for draft-li-native-short-address-00.txt
Thread-Index: AQHXdYpE9ibq+wyyq0KObyJN5hUL8qs8MoXwgBpmCACAAXSyMA==
Date: Wed, 28 Jul 2021 08:17:22 +0000
Message-ID: <aef2e10500dc48219492787633275e56@huawei.com>
References: <162592146565.17536.2118784618713352630@ietfa.amsl.com> <751345e4b6164b6bb83a79cc45ae79fe@huawei.com> <824ab1796046fe54d84c827b56031f2a.squirrel@webmail.entel.upc.edu>
In-Reply-To: <824ab1796046fe54d84c827b56031f2a.squirrel@webmail.entel.upc.edu>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.153.195.42]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/AOiZ7Mh1Xt2ok5cig61IGBGjk3M>
Subject: Re: [6lo] FW: New Version Notification for draft-li-native-short-address-00.txt
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 28 Jul 2021 08:17:33 -0000

Thank you for detailed comments. Please see in lines

> -----Original Message-----
> From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Carles Gomez Montenegro
> Sent: Wednesday, July 28, 2021 12:32 AM
> To: Liguangpeng (Roc, Network Technology Laboratory) <liguangpeng@huawei.com>
> Cc: 6lo@ietf.org
> Subject: Re: [6lo] FW: New Version Notification for draft-li-native-short-address-00.txt
> 
> Hi Guangpeng,
> 
> Thanks for your interesting draft.
> 
> Please find a number of comments below:
> 
> - Section 1. “NSA routing does not need to spread routing messages to establish the
> node-local routing table; such diffusion action would consume too much network resources,
> thus not being suitable for large networks that consist of many nodes.”
> 
> While your proposal involves no routing protocol messages, other messages need to be sent
> (i.e. AR and the corresponding response messages). Since CNNs are often characterized by
> dynamic topologies (e.g. due to the use of wireless links and/or due to node mobility), how
> would topology changes be dealt with in your proposal?  Probably, some sort of address
> maintenance (involving the transmission of control messages) is needed.
> 
[G. L] Good comment. The node's NSA address is always managed by it's direct ancestor. In my immature thought, root and forwarder nodes at most need to maintain two bitmaps (one for child forwarder, the other for child leaf) to record which child addresses have been used. When topology changes, the neighbor relationship between parent and its children may be broken, thus trigger update of the bitmaps accordingly. So there may be no control messages needed. 

> - Figure 1: the footnote and the related text before the figure may need further clarification.
> LOWPAN_IPHC allows compressing an IPv6 header (when using global addresses) down
> to 3 bytes. Perhaps you might want to highlight that such compression degree can only be
> achieved for a reduced number of source-destination pairs in a given 6LoWPAN network (if
> that captures your intent).
> 

[G. L] Exactly. Such compression degree relies on deriving address from encapsulating (Context or lower layer address) . It may not be common case. If anyone who is familiar LOWPAN_IPHC very much and show the exact conditions to achieve 2/3 Octets (show in RFC 6282), we can discuss what's the advantages and shortcoming in view of whole networking. Whatever,I should clarify the footnote and text in the document in next version.

> - Section 5.2. “The border router (i.e., the root node) can construct IPv6 address for nodes
> by concatenating IPv6 prefix and native short address.”
> 
> I understand that NSAs are of variable size. Does the Border Router assign a prefix of a
> suitable size to each node? How does the Border Router learn about the short addresses
> being used in the NSA domain?
> 
[G. L] According to NSA solution, the network topology can be controlled in both width and depth, thus the biggest NSA length is known. Suppose it will be limited under 64bits, then we can assign a /64 prefix for all NSAs and rest of bit between prefix and NSA can be zeros


> - Are nodes in the NSA domain aware of their (uncompressed) IPv6 addresses?
> 
[G. L] Actually no. Why they need to know that?

> - It seems like the Border Router acts as an address translator.
> 
[G. L] Yes, if we define translator as a node that consuming inputs and generating different outputs.

> - Section 7: “This document requires IANA to assign the range 0101000 to
> 0101111 of the "Dispatch Type Field"”
> 
> Probably you meant the range “01010000 to 0101111”.
> 
[G. L] Apologize for the typo. I'll modify it soon. “This document requires IANA to assign the range 01010001 to
> 01011111 of the "Dispatch Type Field"”

> Also, please note that the first dispatch field value (01010000) in page 0 (RFC 8025) is
> reserved as LOWPAN_BC0 (mesh broadcast/multicast support).
> 
[G. L] Thanks for pointing this. I checked the registry table again, either NSA gives up using 01010000 because of conflict with LOWPAN_BC0 (maybe just do not use TF=00), or move NSA to page in 1-14. I have no experience with this, more suggestion in this aspect will be appreciated.

> Looking forward to your presentation in the 6lo session.
>  
> Cheers,
> 
> Carles (with no particular hat)
> 
> 
> 
> > Hi,
> >
> > This document specifies mechanisms of NSA (Native Short Address) that
> > enables IP packet transmission over links where the transmission of a
> > full length address may be wasteful. All descriptions will focus on
> > carrying IP packets across LLN (Low power and Lossy Networks), those
> > LLNs positioned as limited domains. The specifications include NSA
> > allocation, routing with NSA, header format design including
> > length-variable fields, and how to access full IPv6 networks.
> >
> > Look forwarding to discussion and comments.
> >
> > Thanks
> >
> > Guangpeng Li
> >
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: Saturday, July 10, 2021 8:51 PM
> > To: Liguangpeng (Roc, Network Technology Laboratory)
> > <liguangpeng@huawei.com>
> > Subject: New Version Notification for
> > draft-li-native-short-address-00.txt
> >
> >
> > A new version of I-D, draft-li-native-short-address-00.txt
> > has been successfully submitted by Guangpeng Li and posted to the IETF
> > repository.
> >
> > Name:		draft-li-native-short-address
> > Revision:	00
> > Title:		Native Short Address for Internet Expansion
> > Document date:	2021-07-10
> > Group:		Individual Submission
> > Pages:		10
> > URL:
> > https://www.ietf.org/archive/id/draft-li-native-short-address-00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-li-native-short-address/
> > Html:
> > https://www.ietf.org/archive/id/draft-li-native-short-address-00.html
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-li-native-short-address
> >
> >
> > Abstract:
> >    This document specifies mechanisms of NSA (Native Short Address) that
> >    enables IP packet transmission over links where the transmission of a
> >    full length address may be wasteful.  All descriptions will focus on
> >    carrying IP packets across LLN (Low power and Lossy Networks), those
> >    LLNs positioned as limited domains.  The specifications include NSA
> >    allocation, routing with NSA, header format design including length-
> >    variable fields, and how to access full IPv6 networks.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> > _______________________________________________
> > 6lo mailing list
> > 6lo@ietf.org
> > https://www.ietf.org/mailman/listinfo/6lo
> >
> 
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo