Re: [Roll] turnon-8138 review

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Mon, 08 July 2019 02:26 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 BF9471200FF; Sun, 7 Jul 2019 19:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 nCJVxGwRpvYI; Sun, 7 Jul 2019 19:26:26 -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 A171F1200D8; Sun, 7 Jul 2019 19:26:25 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B278EA243AC6ED5B7B9F; Mon, 8 Jul 2019 03:26:23 +0100 (IST)
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 8 Jul 2019 03:26:22 +0100
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 8 Jul 2019 03:26:23 +0100
Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 8 Jul 2019 03:26:22 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.50]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Mon, 8 Jul 2019 07:56:16 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: "Li Zhao (liz3)" <liz3@cisco.com>, "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: AdU1IIlA6w1MYnH1Rd6eOKlcXhIIwAAUkYsAABBZ5FA=
Date: Mon, 08 Jul 2019 02:26:14 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DF34F23@BLREML503-MBX.china.huawei.com>
References: <982B626E107E334DBE601D979F31785C5DF34E04@BLREML503-MBX.china.huawei.com> <B1550524-A197-41E6-83B5-0626BD1952CB@cisco.com>
In-Reply-To: <B1550524-A197-41E6-83B5-0626BD1952CB@cisco.com>
Accept-Language: en-IN, 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_982B626E107E334DBE601D979F31785C5DF34F23BLREML503MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/HcjUrxJSPR384NARRj1KFLkWP7s>
Subject: Re: [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 02:26:28 -0000

Thanks Zhao, Please find my comment inline.

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?
[LZ]Yes. This requires use of  capability flag. I think there is no capability flag before to identify the T-reset. One option is using reserving flag in DAO base object. Another option is leveraging draft-rahul-roll-mop-ext<https://datatracker.ietf.org/doc/draft-rahul-roll-mop-ext/>
[RJ] the point I wanted to convey is, you may need two flags if rolling back needs to be supported. Flag1 is Supports8138. Flag2 is Enabled8138. For rolling back and for nodes supporting 8138, these nodes need to inform the root with Enabled8138=0 and Supports8138=1 flag.
Secondly, the option you mentioned of using DAO base object for such flags may not be correct. These are target specific flags and a DAO object might carry multiple targets.