Re: [Roll] MOP value calculation with MOPex

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 04 September 2019 14:13 UTC

Return-Path: <pthubert@cisco.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 5BCBF120089 for <roll@ietfa.amsl.com>; Wed, 4 Sep 2019 07:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TUEn0bXq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xndjDALF
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 9OnkF4q1ew7f for <roll@ietfa.amsl.com>; Wed, 4 Sep 2019 07:13:05 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3A912001A for <roll@ietf.org>; Wed, 4 Sep 2019 07:13:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16095; q=dns/txt; s=iport; t=1567606385; x=1568815985; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=56ES479hmyN2RVAN2Y5Bs+jgsAuduBTqBNEnQPKa7Y8=; b=TUEn0bXqTZuneBlBKsP69KyJNJmCt3iIY/DFqpphnEoqmhWDFCbQc3VE 4S9X9A2rD03hvRzzgjLARo0ytMKdde5v/KYF1TGJficEMuPir+Gj/1lw/ S6vhVe4qBxwdl5LZGm/XoayE/5tpbsk6hP10Tj9gaWubJoIqYPVxjvpqk 8=;
IronPort-PHdr: 9a23:gtNfSRCMmm1912oAWhRXUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHwQAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BhAgD3xW9d/4wNJK1lHAEBAQQBAQcEAQGBVgQBAQsBgRUvUANtViAECyqHaAOKdE2CD5AKgwMDhFyBQoEQA1QJAQEBDAEBLQIBAYQ/AoIyIzcGDgIDCAEBBAEBAQIBBgRthS4MhUoBAQEBAxIbEwEBOA8CAQgVMTIlAQEEEwgagwGBHU0DHQECnmcCgTiIYYIlgnwBAQWFFRiCFgmBNAGLdxiBQD+BEUaCTD6EDDqDO4ImjE+IAJdZCoIfjhWGZ4I0hzaKXYQkpkYCBAIEBQIOAQEFgWYigVhwFYMngkKDcopTc4EpjlIBAQ
X-IronPort-AV: E=Sophos;i="5.64,467,1559520000"; d="scan'208,217";a="538409184"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Sep 2019 14:13:04 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x84ED4D1016822 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Wed, 4 Sep 2019 14:13:04 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Sep 2019 09:13:03 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 4 Sep 2019 09:13:03 -0500
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 4 Sep 2019 09:13:03 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MZGKYl+1s+nbDCCjLLXOuwX3BH1MaKeQDhbCNnU/pC4+ao/6xzGIp/PLxf+q2o7UHo1waeJjIEvha0we42pofRfQl+Ne+eepZmWK6A8zgq7Szb3ivRjjcXrUcJ+U+GfIRDdq0gLbcnBeKV6jupfz6pThiHUfp58oNvH2majkbBbBXKEOvP43SCZ8gqObwimmhTIsMpXEeWMoVjirkPtZSBP1zFgF1OTbuBmEXQyUWo79acsYqpKpUkPyfOiUWuPZA/5U9quhIqi2fmny7cH/LKq4o2Erw4tWhvgVt42oDVHp6XXnUZt/9cSGJtniaHMUNXD5QfJfi5fm+lz4OP+xew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EEyDYWurcMENfRr4Ag+VB+uc9rxrs/q5Zt2wZDKfrfU=; b=WSYEPWnRsQMU9Knh1xQwG4uqtOpHWsLY0UXD5OCYiEbfZCH/CmND7ifrM3Ov/vWOPOemO+l/+mM/So/DemL+jXiUe37OXBHOxtXr8935lPEwvHj45UtHfEnDVP5tARGmhnOFQY3dCWw5bN+Vw9pssvGNPkoopsjsGxS0GqD68w3gDqpF+k/Oifi42pEFkvrwR5pQoK8u6+dVLA8d1jy5PseUqxwogMkLruwggM3lsG97IAqHYisAQQAi4r5UQfazi1tqknAlxTo9pVy0T+eJC7+3IaaQUOCNdHUpX2VTDoogzWglTypVSIJTzwVHVYsttXX55LB5zSozT7iyavTFIA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EEyDYWurcMENfRr4Ag+VB+uc9rxrs/q5Zt2wZDKfrfU=; b=xndjDALFhbDC1CiUuRLenJZWoV2F0hh+cgA8C5ONTnKceMoZBe7KlTiRo/tZpraBK2no466HiQjF7YATjmXlruxkct1GrUMfl6mDa2k+IPuq9LghTpR0xwge/5qc9QCBopSfWx9b5V6Umyfqqq2VjCv+LFHIQ67/pUpWYtrEv1U=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4478.namprd11.prod.outlook.com (52.135.36.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.20; Wed, 4 Sep 2019 14:13:02 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2220.022; Wed, 4 Sep 2019 14:13:02 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: MOP value calculation with MOPex
Thread-Index: AdVHcgSjh88c1CYFSWS6jvynxbl3owbtvRkQ
Date: Wed, 04 Sep 2019 14:12:59 +0000
Deferred-Delivery: Wed, 4 Sep 2019 14:12:21 +0000
Message-ID: <MN2PR11MB35656F1E687B23924E524836D8B80@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <982B626E107E334DBE601D979F31785C5DF7A230@BLREML503-MBX.china.huawei.com>
In-Reply-To: <982B626E107E334DBE601D979F31785C5DF7A230@BLREML503-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:44f3:1300:8170:98a7:7988:d19d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f3bbe6c1-f75d-4710-ee6c-08d73141ff53
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4478;
x-ms-traffictypediagnostic: MN2PR11MB4478:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MN2PR11MB447889E4124844B6B187E889D8B80@MN2PR11MB4478.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0150F3F97D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(366004)(396003)(136003)(39860400002)(199004)(189003)(9686003)(81166006)(33656002)(6246003)(81156014)(256004)(6116002)(446003)(46003)(186003)(54896002)(71190400001)(6506007)(14454004)(790700001)(8936002)(6306002)(8676002)(7696005)(64756008)(66556008)(66476007)(486006)(86362001)(66446008)(66946007)(76176011)(476003)(11346002)(76116006)(71200400001)(478600001)(55016002)(99286004)(6436002)(5660300002)(74316002)(66574012)(52536014)(2906002)(316002)(6666004)(6916009)(229853002)(25786009)(7736002)(102836004)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4478; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: djgZfVGO8n9LnDkwlP5EIPEc5hGJksanj4poL4tOdAyfZYxIiH53YF/u3zWhiHoOHDX/iHLRKScYKTUpyMyiPXLBzxTPABbpb6/kUIYcMoKwkc8Ety7/48MMcegORQpUIjkqA5j4DYR0aOs0mo3zP7gplcAcnD/sVpgTDJ6B5+qhH4O3B5aWCIZQvNe9KCPlqqUtswFWVg8AsnSVxbXfKN+9mbJRXQfJVEbIKcPpCGx1PrMG19hIXaLajwVG1IW4GcdlBOynn9xikL0A1eqL89+8gqlfykjUBKG/cCPV2+fZohlS6WurLI5B0VziVbJ5LjKiBIfsXUSY3wrXIoVMGEE+rCjOQjVr4BPqaraI0YAtEPuquLhsg1yYWrGT5H+Utme5Olp09z/e+6ocwNerAKKUH3+Lm6KZh7ungMbP1M4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35656F1E687B23924E524836D8B80MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f3bbe6c1-f75d-4710-ee6c-08d73141ff53
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2019 14:13:02.0801 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vD0F/UaErNaQwRJh6NJ3lZneYnbNmhpD3Ez1kRVYGuKoCw8IZKDOxIA3PoovLjeCnYMQOyRBn/HSMh/XOp1yYg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4478
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/uRMEgEZPPiJw0Qujrd5_9NyvKIs>
Subject: Re: [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, 04 Sep 2019 14:13:08 -0000

Dear all

Please see below

All the best,

Pascal

From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Arvind Jadhav

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:

  1.  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.
  2.  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.


?    My reasoning was that like the configuration option, the MOP > 7 could be elided, IOW not repeated upon every DIO. So we can place the MOPex in the config option if we liked. So 7 would mean, the MOP is elsewhere, whereever we decide that is.

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.


?    It really matters if it is the first DIO the node sees for that instance.  If that is the case the node needs the config option and the DAG Metric Containers to figure if it can participate as a router, as a leaf or not at all. If those are elided, e.g., because the network has been stable, I guess the node should DIS to get them. Note that it is an intention that the MOP does not change on the fly. So once the MOP has been seen it can be remembered.

Section 3.2. makes it clear that if base MOP is 7 and MOPex is not present then the final MOP is 7.


?    I'd like to change that to say that means it is in the MOPex. No MOPex means elided, if the node already has it then no problem. The processing becomes much easier since there is no addition to make.

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.


?    That could be a backward compatibility problem. Say the MOP says 2 and the MOPex says 12. A lecacy node that ignores MOPex will use the wrong value. OTOH a legacy node that does not understand 7 will join as leaf.

All the best

Pascal