[Roll] turnon-8138 review

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Mon, 08 July 2019 00:40 UTC

Return-Path: <rahul.jadhav@huawei.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D43120045; Sun, 7 Jul 2019 17:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 x-Y0QNgcc5Wc; Sun, 7 Jul 2019 17:40:22 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7C512120047; Sun, 7 Jul 2019 17:40:22 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 10DB953B316A476990F6; Mon, 8 Jul 2019 01:40:21 +0100 (IST)
Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 8 Jul 2019 01:40:20 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.50]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0439.000; Mon, 8 Jul 2019 06:10:10 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: "draft-thubert-roll-turnon-rfc8138@ietf.org" <draft-thubert-roll-turnon-rfc8138@ietf.org>
CC: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: turnon-8138 review
Thread-Index: AdU1IIlA6w1MYnH1Rd6eOKlcXhIIwA==
Date: Mon, 08 Jul 2019 00:40:10 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DF34E04@BLREML503-MBX.china.huawei.com>
Accept-Language: en-IN, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.109.81]
Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DF34E04BLREML503MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/mJy781KAuqaRp5w9wkYGVM-UBz0>
Subject: [Roll] turnon-8138 review
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2019 00:40:25 -0000

Hello Authors,

Following is my review of draft-thubert-roll-turnon-rfc8138-02:

Section 5.4. "Rolling Back", says, the administrator SHOULD make sure that all nodes have converged to the "T" flag reset before allowing nodes that do not support the compression in the network.
[RJ] How would a root know that all the nodes have accepted the T-reset? Doesn't this require use of capability flag ? Also I'm not sure if the same capability flag used before can be used here?

Section 5.3. "Double Instance Scenario", says that nodes that do not support 8138 would either not be configured for the new instance, or would be configured to join it as leaves only.
[RJ] Thus I believe there is some non-RPL management involved to tell the legacy nodes to not join the Instance-with-T-flag.

Section 5.2. "Single Instance Scenario", The root encapsulates packets to the leaves all the way to the parent, which decapsulates and distribute the uncompresses inner packet to the leaf.
[RJ] When it says encapsulate/decapsulate, it means IP-in-IP encapsulation/decapsulation, right?

Section 4. "Updating RFC 8138"
[RJ] I didn't find any updates to 8138! I believe the text in the section does not result in 8138 update.

Regards,
Rahul