Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 10 December 2019 10:01 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 8FFE8120885 for <roll@ietfa.amsl.com>; Tue, 10 Dec 2019 02:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=IBy/bgXP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IJ09Mi1U
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 hvnDdKr3hogi for <roll@ietfa.amsl.com>; Tue, 10 Dec 2019 02:01:53 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9D7120883 for <roll@ietf.org>; Tue, 10 Dec 2019 02:01:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3625; q=dns/txt; s=iport; t=1575972113; x=1577181713; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BNEBR2sbvMrMqn6YP3gFn4QbhxOJI42zm45LDO1TG50=; b=IBy/bgXPDSO+kQBdzVdeyGDXeJNRko5N3AOuLK+ImHKENuuKUTkUQ6Kc JcWfslWr5/5kKm9nfSDLKxi7NVcuW1eUe5xCdWLHibAArMnuckA0KU9TS i+TKzjjFmyVXmfP1j03rXCMcUq9ARR8LXkAuThVWAxp4dyFF72Zeftr1C c=;
IronPort-PHdr: =?us-ascii?q?9a23=3ApC2rcRzFcgOiCZrXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DTDQCubO9d/4gNJK1lHQEBAQkBEQU?= =?us-ascii?q?FAYF+gUskLAWBRCAECyoKhz8DiwVOghGYBoJSA1QJAQEBDAEBLQIBAYRAAoI?= =?us-ascii?q?DJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECARIuAQElEwQHBAIBCBEEAQE?= =?us-ascii?q?vMh0IAgQTCBqFRwMOIAECoQgCgTiIYYIngn4BAQWFHhiCFwmBNoUchnwagUE?= =?us-ascii?q?/gRFHgh4uPoQtHoNAgiyWf5dnCoIvlguCQod2i0GEP4Q/oFWDZgIEAgQFAg4?= =?us-ascii?q?BAQWBaSKBWHAVgydQERSMZgwXg1CKU3SBKIxtAYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.69,299,1571702400"; d="scan'208";a="677558849"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2019 10:01:52 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xBAA1qS4017080 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Tue, 10 Dec 2019 10:01:52 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 04:01:51 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Dec 2019 04:01:50 -0600
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 10 Dec 2019 04:01:50 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L9Mmu5LU6CAJUY3jk5WESCII5+zuA64GEW/+6Qxic2JSWzBe4kg9wBCAWEL+lvH026dcWua3swZsZ6UsuqVMLjpYYsVh5w7UjPQL+LDEtPj5mN0qjTXTye6IKOjBHCWI2kGQ2Kr0BHVKf9P2YP7YL2UM1bc9dMHYoFN07QsUeMU3HV4V/U/DQr8vl2NdX1/PydMQnuVvfDkKjcGm/r7i3pOQMkgggnMD9Nej9SAivQS5DCwgyLvk5DZmUsw8y/zUDv6H3OOH+tOaHEpqhfsvuzkoJmNeJo2yIzvlUpPo9X49CCcmhipKo0bMkZkEdnBl83ZOY05AweHoKklSxKJ1Ew==
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=BNEBR2sbvMrMqn6YP3gFn4QbhxOJI42zm45LDO1TG50=; b=KtooKo/t5VOPr6HpUx1DupFCG+eLpuRxdffrLEuoOvjUtB/xRMwl1+Bju25cRMxqPbB3dJ1PFslEuGpj1w0hbcrG1XtXbfg3OL+b0aUujLHTsiCKcwhGPLj1DFpqYPquYvsiTG2FjCAYO2uSOIzSP+3EHZCbgrI+NHzNifnZQj30G87TekZRzSD2y7FIq4HKk8lTbKugBByXAcbneLjMQ4yAjX4di85FJLsHchgRPB1WNWcYne9ZAqhYGvgNajnjgLeH7bqkBwmPq80DsERlKxy547OPBsSF3DbUPs3H2qXNBOFyNyynd7WHoWMnrUbk0BhDIW1wv6agYVOLJTHVEw==
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=BNEBR2sbvMrMqn6YP3gFn4QbhxOJI42zm45LDO1TG50=; b=IJ09Mi1UiSuhDp69nN9tubo6nO+1NIZfFG94A33VaxksaxowZpgTv+3RnF84kfqbS6s8iOHNGTl51jVMLwEcC3Cpnh1HwcGBOJ+Zwx3rK9kDU/uR46WKXFvOGbhQnOZqPRMIgK4HGP+CY3ZtHXDcWX5gATlk+n4q+9TiMnpbzNY=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4288.namprd11.prod.outlook.com (52.135.37.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.16; Tue, 10 Dec 2019 10:01:49 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::3037:66f1:dc79:b564]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::3037:66f1:dc79:b564%7]) with mapi id 15.20.2516.018; Tue, 10 Dec 2019 10:01:49 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage
Thread-Index: AQHVrvcUJ5t/IdocAUKcd9xxFkggo6ezHhng
Date: Tue, 10 Dec 2019 10:01:27 +0000
Deferred-Delivery: Tue, 10 Dec 2019 10:00:44 +0000
Message-ID: <MN2PR11MB35657EDC8F8FBF9EB5359A57D85B0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CAO0Djp1K18CGXv+YC9H4qgCgyH=fkon4ihFAUmgfKwdYQy38dQ@mail.gmail.com>
In-Reply-To: <CAO0Djp1K18CGXv+YC9H4qgCgyH=fkon4ihFAUmgfKwdYQy38dQ@mail.gmail.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: [173.38.220.38]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9a435ae0-c11b-46cd-1187-08d77d57f95d
x-ms-traffictypediagnostic: MN2PR11MB4288:
x-microsoft-antispam-prvs: <MN2PR11MB428897388C9C0733834A2014D85B0@MN2PR11MB4288.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02475B2A01
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(346002)(39860400002)(136003)(189003)(199004)(13464003)(86362001)(2906002)(6916009)(66946007)(71200400001)(316002)(478600001)(26005)(6666004)(305945005)(33656002)(71190400001)(8936002)(229853002)(76116006)(52536014)(66476007)(9686003)(8676002)(53546011)(81156014)(66446008)(6506007)(66574012)(81166006)(55016002)(7696005)(64756008)(66556008)(186003)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4288; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ok9NV75bLOLGezZP5kaJf2YJvh7bdyJR8jJR1xFqueS8llbpnCpyu/SGKIcGKtVD4X3VTTh9t3rjcg4TwG4u29/aK6EXTA5tIQIWCAp8e7N/2BDahXQ4jUtBms20QSFcym+PuLhMCVL9hceFqNbcNrnHxSDH1RkweiJQm599gVUo5TOrV9N0rhfEDrU1ecXgOdTQt2MkWvQnEtI5hs1U+YD0V4qf+8aJUZ+m3br2Epu36jbkzz/qqX31oUaGcEIH1oUBNrzLXUSnkCDyFXEasvsYx/fMgoNyONgMWoEvYnD3gwgGUXyPpBfvpVf07Ku7jjGAF2lMp5hd2X6dGxKfEUD7VCkwRavmA3wrcVSiRWN28OTuCaO75bQ0tFDMW0w5TxWjIc05R8T8eOEue8Y81dEEm0NxHVKBZesAK7X2oQHlXrf10JvIzqii0RJcSXFCBB9UJmf4rTtoxBglDRAIsuqjVVJeYstM8HzOclMnosPOHTlIPXTTiKsDVnpdVyxX
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a435ae0-c11b-46cd-1187-08d77d57f95d
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2019 10:01:49.3578 (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: M2+xzVNy6pTAaaMDM21TzaKsqwL4/UvxO65dWen5U3fFPMq3xYZ+w+6vxTOvcCphD/l51tbDY3abXTYeYk4KOg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4288
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/ymAi1M7Xr894mFCUSheCX8GQ-68>
Subject: Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage
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: Tue, 10 Dec 2019 10:01:55 -0000

Hello Rahul

Fair point. Please see below







> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav
> Sent: mardi 10 décembre 2019 02:13
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage
> 
> Hello Pascal, Michael, All,
> 
> I would like to open the discussion about carrying the ND Status as part of the
> RPL Status as mentioned in the Unaware-leaves draft [1].
> 
> The proposition by Unaware-leaves draft wrt RPL status is:
> Use of RPL status to carry ND status. ND Status (RFC 8505) is 8bits, and RPL
> status is 8bits. RPL status MSB is already used to indicate outright rejection.
> Unaware-leaves draft dedicates 2nd MSB in RPL status to indicate ND status.
> This means only lower 6-bits of ND Status can be at most carried in RPL status.

It would have been immensely nicer to use the leftmost bit in ND's RC to indicate error as we do in RPL but the art was not like that. So we cannot converge on that bit with backward compatibility, sad thing.

> 
> The RPL Status carrying ND Status seems not adequate,
> 1) RPL Status can carry only lower 6bits of the 8bits of ND Status

As you point out, it will be trouble if the ND status exceeds 64 values. Do you know any status in any RFC that does that? Can you figure the case switch that tests them all with a different behavior each?
Seems more sensible to downgrade the 6lo RC to 6 bits on the next occasion.

> 2) RPL Status and ND Status may not always be correlated.

RPL must carry the ND status back whatever the status is. It's not just for RUL, it's for backbone router as well. It's actually cool that the way we defined now does not need to be aware of each value to do a mapping so the status can be transported transparently without changing a RPL spec each time ND changes (thanks to Alvaro).

The other way around, RPL only statuses can be transported with the second bit indicating so. So I do not see an issue there.


> 
> How about using a different ND Option in RPL messaging to keep the ND
> handling segregated? The unaware draft can say that this option can be carried
> in DCO or any other RPL message it requires. ND status/option may have to be
> carried only in specific cases which involves unaware leaves and as such the
> control overhead due to option header may not be much.
> 

Now, you as much as anyone have in mind that we design for a constrained space. We started with a mapping and Alvaro reacted to that. So we proposed the encapsulation that you describe. And now we'd have an new option? This seems really excessive when each bit counts. Note that so far there is not a single RPL status defined outside of those imported from ND, and each DAO-ACK is carrying 8 bits of zeroes all around the world in millions of devices. We better not increase the waste don't you think?

> This ND option could also be easily extended for future purposes since we may
> have additional fields in the future from ND to be carried with RPL.
 
RPL and ND are close family, RPL is effectively the way to support non-transit links (NBMA) that the original ND did not have. RPL carries ND options natively, consider PIO. I'm all for adding more options like SLLAOs in DIO, as we discussed at the meeting. So I fully agree with the desire/intuition. But we do not need an ND option for that, it's already meant to be this way.

What do others think?

Pascal