Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 21 October 2019 09:58 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 AC1441201B7 for <roll@ietfa.amsl.com>; Mon, 21 Oct 2019 02:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, 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=FfzFAoue; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=r3zyCgdP
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 yzCbASAxPbgC for <roll@ietfa.amsl.com>; Mon, 21 Oct 2019 02:57:59 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FF91200E6 for <roll@ietf.org>; Mon, 21 Oct 2019 02:57:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3728; q=dns/txt; s=iport; t=1571651879; x=1572861479; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LIugqHdBOWwwKfGG6idzixuzsOSs/JqnVGJk8Y3i7HM=; b=FfzFAoueNNPK8bCKnMyQhTXpA9B7lhZcC4OuTtL2eVaf+yeW4kE0/7rq J/K4kaZjRXcs8domQjSNe2q2bZNX+IZJpEsioy0N6UJE3pXqZZTLSSFqd kPo1HKHgO9Sul4biSXGdGVCushA1398HnYkjJeEUxlYrOCKSPbyT5Rmgy s=;
X-IronPort-AV: E=Sophos;i="5.67,323,1566864000"; d="scan'208";a="428688846"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Oct 2019 09:57:34 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x9L9vYPZ030172 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Mon, 21 Oct 2019 09:57:34 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 21 Oct 2019 04:57:33 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 21 Oct 2019 04:57:32 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 21 Oct 2019 04:57:32 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nh/uiXXZdsXRHqMXBh5hRJv8H80bjqhNJBfBjvd5a8E+81gf19QzlXtHQrc07slIs/Vxu1eEYjwHlfJAlgu5aD/GXPJlGKXwYOrY5vgxOcMnGLvB+0PUOWvMr8IVPYK+FDrqzDXAi4cYBP9yIK5fKTIGYbMsYfrSbtNEea946RO64FHDxKbNHkpMV9vt60h4wvmFYKmrEStFjEqKML/UYDkREOwXMyMcdv6jp1/Kh2bhNvB7TwpRELNmo7nfn3Yq/CfbFJQLg38LBWEb0T1Pdt7htkTHuuL6E9e4G4cDgmNBUHtBwWQV2CdTsdn5D9FJl2YtCLKZb8SacvcxUI9JRg==
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=LIugqHdBOWwwKfGG6idzixuzsOSs/JqnVGJk8Y3i7HM=; b=cZqMhvBvcRzELm82EEOquMfbt/UawURWYrhweA0UKCGm4EFPkDafNvq2UsWbhyAdD35CZuma0U3F8Ip7Ud28QyeBNv94/qwPfRyUhK7fVXoXWKfVCgPBtGy5lsIczGVSgWxOGtdNv6EFXNODNf1+5Io8lES6ZEke4sUfIVkM4cYX+z9Ev2r+CCJU8A8VYLCsDIN6+gQBmS0yP04es+7DwWkofz0KyHxzpJ3UclR128fbu5af4QfIrMAylrVFVd/0CXnGALNZ9ARE+mT5+mPnGJpzUD5EmV1WBcovhLwcE4WiNu4k1WTu65Nwoj7XkRrtzFdLL4oEet0oJRLC3rK9zw==
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=LIugqHdBOWwwKfGG6idzixuzsOSs/JqnVGJk8Y3i7HM=; b=r3zyCgdPmNgJz5c9wXQQ0Ks3ER+LSovAHYw0RSa0zO0NtgSMVNtGHJj6+6rW8zqtSal1OiiOuvKgy6CSV9T9E+fA/I+tNRMceRuvFS1E2oBjeB4JMxoJaQDfryZH2pey873jXrHohejM5A7PZSajkZ672ltn1vr37lmTwnhNk10=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3663.namprd11.prod.outlook.com (20.178.253.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Mon, 21 Oct 2019 09:57:31 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920%6]) with mapi id 15.20.2347.028; Mon, 21 Oct 2019 09:57:31 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
Thread-Index: AQHVhWPlvolp6YcUTEixv+i6F591iKdgEgGggAToGAD//9YaYA==
Date: Mon, 21 Oct 2019 09:57:23 +0000
Deferred-Delivery: Mon, 21 Oct 2019 09:56:45 +0000
Message-ID: <MN2PR11MB35657509C2D7C9DC71637C5FD8690@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <8372B6BA-145A-4C72-A785-895999FE938C@cisco.com> <MN2PR11MB35654A749D01E575EC5C1085D86C0@MN2PR11MB3565.namprd11.prod.outlook.com> <F9FB76CE-AF5F-44DB-A9BF-A0967A8023C1@cisco.com>
In-Reply-To: <F9FB76CE-AF5F-44DB-A9BF-A0967A8023C1@cisco.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:fc9e:730:2c16:4060]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d12f5a06-f032-4c42-2e46-08d7560d1706
x-ms-traffictypediagnostic: MN2PR11MB3663:
x-microsoft-antispam-prvs: <MN2PR11MB366350F9F542206AA3885EDCD8690@MN2PR11MB3663.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0197AFBD92
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(136003)(396003)(346002)(39860400002)(199004)(189003)(6506007)(8676002)(66946007)(99286004)(9686003)(33656002)(229853002)(6436002)(66446008)(64756008)(66556008)(66476007)(76116006)(52536014)(6246003)(102836004)(6666004)(14454004)(186003)(81156014)(81166006)(478600001)(8936002)(66574012)(11346002)(7696005)(316002)(446003)(7736002)(2906002)(46003)(86362001)(15650500001)(71190400001)(71200400001)(256004)(6116002)(25786009)(74316002)(486006)(305945005)(76176011)(55016002)(5660300002)(476003)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3663; 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: BCL:0;
x-microsoft-antispam-message-info: 2Was1KHuujXRMVDQSuiTWYi01GVwSdXElX6H5iiEfxwdC0LomwUfXZ30LQEPJHsZ5b9AHFNNj05KsaNhksi8/8sIoknteH3FtDwMxWoE1z1aw7+ucKKbiGRPzt7DZuH2iyTxdEzobLob/eZT14V2IZ0EeBRRngpEBcgZZv1G5JDsL0L4Tfszk5CSquSnHy0ZoDlZtDvocl/ZQlcl7SoWPaCR4mshkjUscy4yyF6BI9cAQvK2sb2d72RyuA98kZ0/7B6oOqeZYVpKkKgK9NseP4pPqsjtX1EU7sdMdASfiEmfni+lmsZDDzo2g0U4/EXVoRAz6W6lM2hGMjQy9YbvxhTFPm6vl5v/sZe8C83IxYBUZb7bk9YYHuAx2GyyGW5rIEeX5bmm/0TE553KugRlU3ML8Z4Ka63s/KNnQoHbA5c=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d12f5a06-f032-4c42-2e46-08d7560d1706
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2019 09:57:31.5140 (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: UVoVaqAXqmhWSe8KpDMoiFSczTksUVr/IGx2Jb1ZUqXFGbh5cE7PZKOvtK9tNW/xpfJbSKDhXmkAQ4mXFDw/Cw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3663
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Kr1zdLJdPQEg1-JWKj7yrRguxms>
Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
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, 21 Oct 2019 09:58:02 -0000

Hello Li (and all, please read on as there are additional things we could be doing with the draft listed below)

Let's see below

[Li] Do you mean that child should know ALL option type it needs before select the parent? E.g. one child need R/D/P/M/O to join network but another child only need R/D/P.
So how does child know this info? Is it pre-defined in child?

<Pascal> The draft assumes that all R/D/P/M/O are always present and always needed. This seems to be the general case. We can make it so that one option would not be present by indicating in the DIO if you think that case is relevant. Please let me know. 

But how will a child know that it does not need an option that is present? Maybe there is something in there that is mandatory to know, e.g., to act as a router. We could say that a node that does not pull all the options can only act as a leaf. Is that what you have in mind?

    
    
    2. Is AOO necessary? If DIO can fragment options and don't always send all options, can we use DIO without options to indicate the AOO? 
        The shortest DIO Base Object without DODAGID is only 8 bytes.
    
 <Pascal> AOO is RECOMMENDED to elide the option. A DIO an option elided (no option, no abbreviation) and an unchanged RCSS is perfectly OK. But if an option is elided AND the RCSS is incremented then after a reasonable time-out the children will pull the options to check if they changed and the parent will need to send either the AOO or the option in full or both in which case the RCSS of the AOO wins. It is always possible to place the option in full without a AOO but if it is done with an increased RCSS in the DIO that will mechanically increase the "RCSS of the option" as seen by the children and will cause the whole subdag to pull the option to no avail. 
 
 [Li] Agree, AOO is better than DIO with no option. It’s a nice abbreviated mechanism for RPL Control Message.
       Can we consider to extend AOO for DAO? Maybe put AOO in a new Control Message Options, then DIO/DAO can both leverage it.
       In some case, child will send large DAO packet to parent periodically. E.g. 1. child notifies its capability to parent .2 child has several RPL Target or Transit Information (storing mode?).

<Pascal> Yes we could. Say that the content of a non-storing DAO is fully stable, it could be all replaced by a sequence. Would you be interested in adding that?

If we have to abbreviate elements therein, per target, then we still need to indicate the target so we'll save little, and a different technique like indexing the targets with a BIER bit, would be more efficient.


Many thanks again and again Li, for your excellent comments.
    
Pascal