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

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Tue, 27 July 2021 16:32 UTC

Return-Path: <carlesgo@entel.upc.edu>
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 51CF93A0847 for <6lo@ietfa.amsl.com>; Tue, 27 Jul 2021 09:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BHaeYiuLdW1 for <6lo@ietfa.amsl.com>; Tue, 27 Jul 2021 09:31:55 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 754C33A0843 for <6lo@ietf.org>; Tue, 27 Jul 2021 09:31:49 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.40.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 16RGVc4v015067; Tue, 27 Jul 2021 18:31:38 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.40.6]) by entelserver.upc.edu (Postfix) with ESMTP id 5353F1D53C1; Tue, 27 Jul 2021 18:31:37 +0200 (CEST)
Received: from 83.38.106.144 by webmail.entel.upc.edu with HTTP; Tue, 27 Jul 2021 18:31:38 +0200
Message-ID: <824ab1796046fe54d84c827b56031f2a.squirrel@webmail.entel.upc.edu>
In-Reply-To: <751345e4b6164b6bb83a79cc45ae79fe@huawei.com>
References: <162592146565.17536.2118784618713352630@ietfa.amsl.com> <751345e4b6164b6bb83a79cc45ae79fe@huawei.com>
Date: Tue, 27 Jul 2021 18:31:38 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: "Liguangpeng (Roc, Network Technology Laboratory)" <liguangpeng@huawei.com>
Cc: "6lo@ietf.org" <6lo@ietf.org>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at violet
X-Virus-Status: Clean
X-Greylist: Delayed for 31:05:31 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Tue, 27 Jul 2021 18:31:38 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/zs5UVyDHMdr4E240z4oGHgmfWVs>
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: Tue, 27 Jul 2021 16:32:00 -0000

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.

- 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).

- 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?

- Are nodes in the NSA domain aware of their (uncompressed) IPv6 addresses?

- It seems like the Border Router acts as an address translator.

- 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”.

Also, please note that the first dispatch field value (01010000) in page 0
(RFC 8025) is reserved as LOWPAN_BC0 (mesh broadcast/multicast support).

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
>