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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 27 October 2021 13:48 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 567F93A0C0E for <6lo@ietfa.amsl.com>; Wed, 27 Oct 2021 06:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pKDvf4EzlcRe for <6lo@ietfa.amsl.com>; Wed, 27 Oct 2021 06:48:52 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CC53A0C12 for <6lo@ietf.org>; Wed, 27 Oct 2021 06:48:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E32118018; Wed, 27 Oct 2021 09:49:55 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Vir_JEiynEoa; Wed, 27 Oct 2021 09:49:52 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 364C51800D; Wed, 27 Oct 2021 09:49:52 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A35E8585; Wed, 27 Oct 2021 09:48:44 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: 6lo@ietf.org, "Liguangpeng (Roc, Network Technology Laboratory)" <liguangpeng@huawei.com>
In-Reply-To: <6f5011be5c4643b4bdbbb5f3810e50d1@huawei.com>
References: <163456199834.10176.4136112187090246468@ietfa.amsl.com> <664fe95d6d4d4c70a3f8287fb7e38a44@huawei.com> <6f5011be5c4643b4bdbbb5f3810e50d1@huawei.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 27 Oct 2021 09:48:44 -0400
Message-ID: <22823.1635342524@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/-1HLxf66aHpzX5ukkZV_ZaHl6x4>
Subject: Re: [6lo] FW: New Version Notification for draft-li-6lo-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, 27 Oct 2021 13:48:59 -0000

"Liguangpeng (Roc, Network Technology Laboratory)" asked me to review
draft-li-6lo-native-short-address-00 and to post to 6lo.

    > update the draft a lot and get support from China Mobile.

but since this is yet another constrained network protocol, are there
commitments to write code?
For OpenWSN, Contiki-NG, RIOT-OS, Linux, *BSD, FreeRTOS,  Thread...?

I see in your draft that you have comparison against current 6lowpan, and
that it is a few bytes shorter, but I didn't yet read deep enough to
understand how often it is shorter, and if there were cases that were simply
not supported, or if they wind up longer.

I see the bit pattern at the beginning that means it could operate in the
same network as 6lowpan, but it seems that every node that forwards will need
to understand the new format before it can be turned on.

It seems really late in the day for a new mechanism.

    > Thirdly and most importantly, to avoid drawbacks brought by
    > renumbering, we added a new mechanism to avoid the renumbering during
    > the topology change, by adding/updating routing entries along the
    > affected path. The cost is comparable with the local repair of
    > RPL. Routing related procedures is refined according to this design,
    > see Section 5, 6 and 8.

I'm unaware of a large need to renumber.
Maybe that's a result of lack of IPv6 deployment.

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