[Roll] MOP value calculation with MOPex

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Wed, 31 July 2019 07:34 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 2EBB01200C1 for <roll@ietfa.amsl.com>; Wed, 31 Jul 2019 00:34:43 -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 GKACht-8km0p for <roll@ietfa.amsl.com>; Wed, 31 Jul 2019 00:34:41 -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 CF790120098 for <roll@ietf.org>; Wed, 31 Jul 2019 00:34:40 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 98257665886067F71E72 for <roll@ietf.org>; Wed, 31 Jul 2019 08:34:38 +0100 (IST)
Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 31 Jul 2019 08:34:38 +0100
Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 31 Jul 2019 08:34:38 +0100
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 31 Jul 2019 08:34:37 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.138]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 13:04:24 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: MOP value calculation with MOPex
Thread-Index: AdVHcgSjh88c1CYFSWS6jvynxbl3ow==
Date: Wed, 31 Jul 2019 07:34:25 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DF7A230@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_982B626E107E334DBE601D979F31785C5DF7A230BLREML503MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/WdYaCkoja542rQIV9aLHiUASj50>
Subject: [Roll] MOP value calculation with MOPex
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: Wed, 31 Jul 2019 07:34:43 -0000

Hello All,

During ROLL session, it was suggested that using "Final MOP = Base MOP + MOPex" may not be a good idea, since the implementation becomes more complex.

My initial reasoning behind using such a scheme/calculation was to:

a.       Reuse all the values in base MOP. We do not lose a single value i.e., there is no MOP value reserved for extn. If base MOP value is 7 and if MOPex is absent then the final MOP is 7.

b.      When anyone references a MOP value X, it need not be referred to in context to base MOP or extended MOP. For e.g., when we say MOP=11 ... there will be only one Mode of Operation it refers to and need not be specified in the context of base or extended MOP.
Essentially we keep using the base MOP and add up from MOPex (if present) to derive final MOP.

How will the implementation handle it?

1.       Process DIO base object and get the base MOP.

2.       Keep processing DIO Options and on encountering MOPex add the MOPex value to the same var in step 1.

3.       At the end of DIO message processing check if the node supports MOP.
Section 3.2. makes it clear that if base MOP is 7 and MOPex is not present then the final MOP is 7.

Another way of handling this would be, If MOPex is present then ignore base MOP and just use the value of MOPex as MOP. In this case we will lose out on 7 values of mop.
Please share your thoughts on this.

Regards,
Rahul