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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 17 December 2019 17:59 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 34A1C120CB9 for <roll@ietfa.amsl.com>; Tue, 17 Dec 2019 09:59:59 -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=JQwzLd/T; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ERje0xMs
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 jugtVaGpnhL3 for <roll@ietfa.amsl.com>; Tue, 17 Dec 2019 09:59:57 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A8D120CB5 for <roll@ietf.org>; Tue, 17 Dec 2019 09:59:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3612; q=dns/txt; s=iport; t=1576605597; x=1577815197; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2684dEUI6kjU/VKm7rmOLDa9dyp0pLcfKmIloi+N1kU=; b=JQwzLd/TxqqprF4S3fPtE6prbxJ+xznGBlmeZVY8S/ahSfGt20Qm2yeS LwQf4+Zbvbwi2oa6bxYLLDMkd2EyVKSAMN0C3GP7WKqTclOVZZJQsKFxR Rx5XzBpe11vdVbGhMciDah+ms1aoXEwP8LsuMQpUQMlhWadt6xWbypBj9 Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3AW0wN1xHguDW3nnZXGRntqp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DsDgA9F/ld/5pdJa1lHQEBAQkBEQU?= =?us-ascii?q?FAYF+gUtQBYFEIAQLKodKA4sPToIRmAaCUgNUCQEBAQwBAS0CAQGBTIJ0AoI?= =?us-ascii?q?YJDgTAgMNAQEEAQEBAgEFBG2FCwYmDIVeAQEBAQMSLgEBJRMLBAIBCBEEAQE?= =?us-ascii?q?BLjIdCAIEEwgahUcDLgECoyYCgTiIYYIngn4BAQWFGhiCFwmBNoUchnwagUE?= =?us-ascii?q?/gRFHgh4uPoQtHoNAgiyXD5d6CoI0liuaSYQ/oG+DbAIEAgQFAg4BAQWBaSK?= =?us-ascii?q?BWHAVgydQERSFOodYDBeDUIpTdIEokFUBAQ?=
X-IronPort-AV: E=Sophos;i="5.69,326,1571702400"; d="scan'208";a="392067254"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Dec 2019 17:59:56 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xBHHxuF7024801 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Tue, 17 Dec 2019 17:59:56 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Dec 2019 11:59:55 -0600
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Dec 2019 11:59:55 -0600
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 17 Dec 2019 11:59:54 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZzNZI0N3EKUkH5pbOIQuxo+ZUArlfRsBzCzK6eG4QEFUGXHCxXqlUNi8vMwVbLSxq9iK3kygrvEqF7WkRxk1DcolmohODtCObilBUKOoXss6H+vDpFKJhLUPP/JZV1i4YfvMvMggEb1syheOGgO6qV7jGwkRyFgY9NMjeBCo67OqzN5zbUnnHyrVDLYRiFmPOtMl9EOr9avDeK0zlwFzNkh4VSCQtU/cPZ7WgEFtn+XlmZsSLWnMmUpmcAtPXsBNrZiqYsk9d5bTt3zDrFv741g8IlomCYgD9OarJdp3c9dY2M1+zmDDVVDIgSc6FfS5iZhzq4kLYY5Mbgyj1NdW3w==
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=ALJMdU8k5i/cpOEp+Ji+hYkUGvmIgxNn0Ky1Zk4YJ3Q=; b=B62zNFR7rFM60Z1mZcKrhUcbCl/GbvKEXH2zuTEhCXoPAsulyhCAOOWZurOoyO/G5KEaggpx5yiSeckGm9wQ7PSfIDL4woWopDyqJ3qv+tb8NgVULRsZ4M9sx7ZrtUFOB9EAHlgqyCLkix1Aiw9ejGHd3BizwbpCrbFuXJPg5hkKvMo941rmdNeIZcAa2T0bAX4QXVlEqj/dxtpLiV8BhaSPOQXBIRnO1IcDQNwzFYlRIFfFDPhRISc1OQE6X//mrVUVoLj1Q6KwYD9DhgEvzVOr1dmxW1+n/Y4AnsMmsV6iTDdi5wSGzQ7EuSixOtH3/Yz5Wu8NccmSxifp1l/lrQ==
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=ALJMdU8k5i/cpOEp+Ji+hYkUGvmIgxNn0Ky1Zk4YJ3Q=; b=ERje0xMsRhi0o6OKDS9qgfVY8tcqsaExnn3tyso985qGvaRsumYz/SwoEfPOSi3aBA+3J027WqrN99tJz00B7kDAjhQanL/nxtgiMQ3Kc+7+DUY39yMjf00JRWDD28PKf1QrlsfLSjvF1WDMrIVLSY12RQHOsqjVUzhpvvN3YEE=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4429.namprd11.prod.outlook.com (52.135.37.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.16; Tue, 17 Dec 2019 17:59:54 +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.2538.019; Tue, 17 Dec 2019 17:59:54 +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/IdocAUKcd9xxFkggo6ezHhnggAuIQQCAAAGO4A==
Date: Tue, 17 Dec 2019 17:59:52 +0000
Deferred-Delivery: Tue, 17 Dec 2019 17:59:06 +0000
Message-ID: <MN2PR11MB356572131554810FF88AC01ED8500@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CAO0Djp1K18CGXv+YC9H4qgCgyH=fkon4ihFAUmgfKwdYQy38dQ@mail.gmail.com> <MN2PR11MB35657EDC8F8FBF9EB5359A57D85B0@MN2PR11MB3565.namprd11.prod.outlook.com> <25979.1576604888@localhost>
In-Reply-To: <25979.1576604888@localhost>
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: [2a01:cb1d:4df:6600:1dc1:efb0:ae39:e7ae]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 071f79ce-3efd-4ccb-9ca2-08d7831aeb93
x-ms-traffictypediagnostic: MN2PR11MB4429:
x-microsoft-antispam-prvs: <MN2PR11MB44290606937DAF56AE4076E5D8500@MN2PR11MB4429.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02543CD7CD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(39860400002)(346002)(366004)(396003)(189003)(199004)(13464003)(64756008)(55016002)(6916009)(71200400001)(86362001)(186003)(9686003)(478600001)(6506007)(53546011)(52536014)(66946007)(76116006)(8936002)(81166006)(316002)(66556008)(81156014)(8676002)(66446008)(66574012)(66476007)(33656002)(5660300002)(7696005)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4429; 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: BSTA5ibEzQ09f7cRb+KYnvea38+MnLuWtWj8+ey1BmQuJ1nvpjLz2eknMmgp2wVFbwxDXPJzAXHy3SMBqncqJL3SvP7azvUlD5U1yqiNJqKAPXc5VyTi7pDRwOAbdI1OMcRbYkCsxBdM/LOoeKeBchRMNWB/gfAfbHdt28XJ1RPUzALmwkjo7WKoURnwfJFqxr7KDDRfTqZ767kj8Ow7A3fhOj1DDlAIHz/RROLfqjWJdy1LIWB419K8GOaQrxiXthEy0YLW+790exr/uS86W7yS+vAkgFXt0DGsbspvSWQeDTtzCZefRkqVPBuS5DlLSAhMQFNJ+QJPar1JV8sJn75BF8mQaFBqtHTPlrAUkbM+XZR9ijVPVGhSDUy/GQvejNZGIX1I8nRacBCykHYlqcczm9N0J3pAP7njlml/E8o6IgNLdleWUG8dDKy0X2Dar5pNTWb72JTB003UL1YyVYiyW/vRwLQZR6URjSEXl5Z2oAjndRcpWiDuIGlv/FfM
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: 071f79ce-3efd-4ccb-9ca2-08d7831aeb93
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2019 17:59:53.9693 (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: n31jQJQ3ofgps0ylaUAsdaQNwAIEYFmHNH07dKiUbDfRQmSwL76PMI+BcIzUQMoUir+aXfYh21Za2aONO2oZpw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4429
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/bwY-dR7eLUPYSTAPHZcp0xvTuos>
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, 17 Dec 2019 17:59:59 -0000

Hello Michael:

> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: mardi 17 décembre 2019 18:48
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] Unaware-leaves - ND-Status and RPL-Status linkage
> 
> 
> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>     >> 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.
> 
> You mean that we could change the ND status to 6-bits in the 6lo WG?
> (I would have parsed ND status as being someing 6man takes care of)
 
Yes, or mandate that the 64 first Status values are reserved for stuff that could be carried in RPL


> 
>     >> 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?
> 
> If we can map or redefine (to have a single IANA registry) things, then i prefer
> that over a new option.

We had a mapping in a earlier version and Alvaro actually pushed back. I see his point, the way it is now done allows an implementation of RPL to carry transparently a ND Status, so if ND defines new values they can be transported as well.


> 
>     >> 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.
> 
> It seems that we need to decide this as part of architecting the RUL, right?

Well that's an open discussion of positioning RPL and ND. 

For the case of adding ND options in DIOs, e.g.,  SLLAO, this does not help a RUL since the RUL does not parse the DIO messages.

Not sure what your point is though?

Pascal


> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works  -
> = IPv6 IoT consulting =-