Re: [Roll] P-DAO requirements on MOP-ext

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 09 September 2019 06:19 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 EF37212004E for <roll@ietfa.amsl.com>; Sun, 8 Sep 2019 23:19:29 -0700 (PDT)
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=JmpUuIL8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TgHNKcBt
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 VdbpVMgDsk7Q for <roll@ietfa.amsl.com>; Sun, 8 Sep 2019 23:19:27 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B41120046 for <roll@ietf.org>; Sun, 8 Sep 2019 23:19:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4587; q=dns/txt; s=iport; t=1568009967; x=1569219567; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rCgqzmKGzdUX8i0ExdjG+0NeMM0sq+TZFyWCbAZEbFg=; b=JmpUuIL8Q7rd7JVa+DmRo+otCazWeNEx+7M9Vvv+zfAPNV956hQo0Hi2 OY97TX0P2wywYQf+40F2AQFdF2anNumkMEKYdJp617wkEW/H6EupJvKn3 ahVZlOooQE85ZkOFGiRBw0Tzmw2FXin74xDRMUQfvllBhhz3ALrzt3VFk c=;
IronPort-PHdr: 9a23:enZWLRZypzJQHjjCDJIWG6n/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtL1A=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BKDACl7nVd/5pdJa1lHgEGBwaBZ4FFKScDbVYgBAsqh2gDinRNgw2WcoFCgRADVAkBAQEMAQEfDgIBAYFLgnQCgjcjOBMCAwkBAQQBAQECAQYEbYUuDIVLAgEDEigGAQE4DwIBCC0JEDIlAQEEEwgagwGBagMdAQKZTwKBOIhhgiWCfQEBBYURGIIWCYE0hQCGeBiBQD+BEEeCFzU+g38xFj2CfoImjF2fCV4KgiGISIxHgjSHPIQhhkeEKo82lzMCBAIEBQIOAQEFgWkhgVhwFYMnCYI5gScBCYFtVIpTc4EpjHSCUwEB
X-IronPort-AV: E=Sophos;i="5.64,483,1559520000"; d="scan'208";a="627586051"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Sep 2019 06:19:01 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x896J1hL001050 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Mon, 9 Sep 2019 06:19:01 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Sep 2019 01:18:54 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Sep 2019 02:18:53 -0400
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 9 Sep 2019 01:18:53 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=krzDyPr89SF5Y3mLiCz9It/zMssnzqkj6MmLb0nsanUzzANv49pGKF4LAN4hlwJgzeJo625aaUlCt8ANw1WdN1PQUN815sYYwRU9xsbUT6gxt6BC6A9DCrR+MmzYqYe0F4pWa3DfCCgA/IiirlYHQnGV6SAADaDi89EmS9nqVmOL6yfOIa7pCSXe8KzE1EKPmd77PxeBOruxt8vtwGybKXxHDoWsj4K6ABvrU7dX+Uk1Tl+Rp9NrFyHWJXuQMXIeaYjiAZn7RJ5ecuXJ6FZbMVzUckNtBub8KRqn7pgJAuVjKUG6IGrtyDKhTsF3HoDVe2hj+AzAoRmRPBERCvzVAA==
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=MHDrV0E/Zf/gjNRLYHckmzrcsAuYXShzskahc0umyoY=; b=PQXYHftmpZq0w+ywe4s7Pr/Y+339PwsQZa64X0pX2QDVwmHeS30X32In3D4Wi6stFCCaYzm49B52VsJQwzfgrRSebylbDcHhXlZd+6ged0JUGbj6FbO6pLBegze0YvNK62Dc2SaqmZU7HPzPzBjr113t67L74R1aL/PJoqx+/C3z6bEPd+E1oGVwl5cNODHuWAOA7VTvMownqWVc43MSyBhDoFQU7pQucsNbw6DmQKq5AkiE/mtXs0Co0F9WublsXFKsx67/XqVPCIJwCmnA6zIBYBdUEokAbBWokxSD8Fr7F3DEcCjLb6pKkNZl+Irj9Pq52Lfk1L3NMsLVcFBvjA==
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=MHDrV0E/Zf/gjNRLYHckmzrcsAuYXShzskahc0umyoY=; b=TgHNKcBt24oUpbzlJsHbZv5NPGev3rFyf5tDpqy6PWmMgDjB1hiveYhWg+NFtmnyyoqMAr82UaF73D1/I3hfGJrM503LPddPNQ7OSPmrZg2+EG/zDxOI9Ir4Bowr1M7AFP1lyUWsNxfQ+soJHuZYMWI33DbDlCbEyfRejW22Fq0=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4461.namprd11.prod.outlook.com (52.135.39.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.15; Mon, 9 Sep 2019 06:18:52 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::6986:12d5:b54f:f5ee]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::6986:12d5:b54f:f5ee%7]) with mapi id 15.20.2241.018; Mon, 9 Sep 2019 06:18:52 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] P-DAO requirements on MOP-ext
Thread-Index: AdVj88Fvp4nJxVuORiikWxv/YxyIoAA4voiAAH8BaBA=
Date: Mon, 09 Sep 2019 06:18:40 +0000
Deferred-Delivery: Mon, 9 Sep 2019 06:17:55 +0000
Message-ID: <MN2PR11MB3565DE1BEE0048134AD37318D8B70@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB3565916624AEFA679F5FC150D8BB0@MN2PR11MB3565.namprd11.prod.outlook.com> <3821.1567790151@dooku.sandelman.ca>
In-Reply-To: <3821.1567790151@dooku.sandelman.ca>
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:c0c0:1006::65]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0e843f4a-0caa-4b94-43a2-08d734ed964f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4461;
x-ms-traffictypediagnostic: MN2PR11MB4461:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB4461798880F86E4B6420A3B1D8B70@MN2PR11MB4461.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 01559F388D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(376002)(346002)(366004)(199004)(189003)(25786009)(6916009)(86362001)(8676002)(316002)(2906002)(14454004)(66446008)(305945005)(478600001)(33656002)(966005)(229853002)(6116002)(66476007)(74316002)(66946007)(46003)(186003)(256004)(76116006)(99286004)(66556008)(64756008)(14444005)(6246003)(11346002)(446003)(486006)(476003)(102836004)(71200400001)(71190400001)(6506007)(53936002)(7736002)(9686003)(6306002)(81156014)(55016002)(6666004)(81166006)(5660300002)(52536014)(6436002)(7696005)(8936002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4461; 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: AUsUWYWbAkxdpTKKRCJbe89oEOrxOlF1vsa3WGQSwf0CzJ3IARjiv2KSEzjMWrdeJUwTorrM+BTcLfi1tVOeH7+IuBOW328Z4mUxsSOicA65oqUnQUgKuNiF8SSpXxpe2Nbzp9SIaolKJlh8aN5wE4lplrsnloCOqtc636ApF3O9j3ZRPKJRUFO/C4VcZhQy7yhDhmzpYUBr1VpmCWLiM6DYDbcHzJFzz/x//Agy3XuWK40+hx+YvsMoJTNl/V+ZbAxdnvfhVuYKgoTjCVRwPuXcyOIVH2pTDco9hHPXJQ74khtZQ5L0HH94VCLphPpCADpWz0rVgjF2iipxs4NF5zLr96YoDwcEIMmwFCXEzyIgVLV7mjAs5Y4NjNy31Hcjzz3W+EkPDiNEB0CyhsvuuvmpVTD2PqU0EvBL3T6M30c=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e843f4a-0caa-4b94-43a2-08d734ed964f
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2019 06:18:52.8795 (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: leKNY0372WU+pNoNR/6vYOeTO8MZcu635xnX2q9MaCgBRtVNv6alQbNtd2It54IBjfNNDS0pvoS108Ak9p7JMg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4461
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/4AR2bwEsicJCEue7_4gdhKUBnj0>
Subject: Re: [Roll] P-DAO requirements on MOP-ext
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, 09 Sep 2019 06:19:30 -0000

Hello Michael

Please see below


pascal>   *   Signal supported OFs
pascal>   *   Express support for RFC 8138 (needed for draft-thubert-roll-turnon-rfc8138 as well)

mcr> It seems like these are capabilities separate from P-DAO itself.
mcr> That these are things that could be enabled or not even without P-DAO.
mcr> That P-DAO could run without them.  Is that correct, or is there a dependancy that I'm ignorant of?

The need for turnon predates P-DAO. But still, knowing whether to encapsulate to the parent depends on whether 8138 is used. The RUL could ignore RPL artifacts as a good RFC 8200 soldier, but it may not disgest the compression as easily. This is why I wish to ship MOP ext and turnon quickly, they are part of the foundation.

-----------------

pascal>   *   Express support for exposing siblings

mcr>  guess I need to read P-DAO again to understand why this isn't part of P-DAO.

I want to put in in P-DAO now. I'm asking the OK since that was not originally there.

------------------

pascal>   *   Express support for storing P-DAO
pascal>   *   Express the capacity in terms of routes {
pascal>      *   approximate Nb of routes that can be installed,
pascal>      *   Current % route storage used,
pascal>      *   Target % route storage used - if target < current then Root should move some paths
pascal>      *   overload bit that means do not use me for now }

mcr>  Clearly if you say you support P-DAO, then you also need to say how many routes you can support.  In non-storing mode, the node would store zero routes, so the root would always know how many routes there are, and does not need to know % and target, does it?

I mean not storing P-DAO. This installs a route in the tunnel ingress somewhere in the network. Nodes along the path would be transparent as long as they support RFC 6550 non storing mode and do not expect the root to be the encapsulator, why would they, but hey, that could be a slightly different code path. Note that we want to enable any form of P-DAO on any RPL mode, apart from MOP 0 (collection MP2P).

mcr>  In storing mode, it seems that the root won't learn how much space there is at each level from the DAOs, just how many routes are used in each directly children, so we do need to know how many are used and how much space there is.

Yes, the root manages a space in the device

mcr>  Clearly, how many are used, and the overload bit are things that need to updated regularly, while the total capacity is updated once.

mcr>  I suggest therefore that what we need to do is to inform the root on a periodic basis how many available slots there are.  This would seem to capture all of the data you indicate into a single number?

WFM. I agree we need to make that efficient. E.g., the collection of the data could be aggregated as it goes up.

-------------------

pascal>   *   Same for non-storing P-DAO using an average number of hops per route, e.g., 5.
pascal>      *   Plus: Maximum nb hops in a route

mcr>   Your thought is that a node will have X many slots for "hops", and that a route would consist of a some number of hops, so that it's not destinations that we need to account for, but rather hops?

Yes, we need to express how mush resources a SRH state costs in the tunnel ingress, and that seems to be a linear function of the number of hops. If b is the cost of a storing mode P-DAO state, and a in the incremental cost per hop in SRH, then with x hops the cost would be ax+b.

mcr>   I feel that the amount of active space does not really fit into capabilities as I had originally imagined.  That capabilities are something that are communicated once after the node joins a particular DODAG. While available slots for hops is something that requires more frequent updates and should use a different mechanism. But perhaps I'm thinking too much about this, and that one mechanism can do both.

I agree. It could be a similar transport with options. Like the root pulls something and all report that something. Or a node asynchronously update. I think the NIQ/NAO mechanism would have very different properties than the DIO/DAO.

All the best

Pascal 

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [