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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 06 September 2019 19:45 UTC

Return-Path: <mcr@sandelman.ca>
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 ECC77120B26 for <roll@ietfa.amsl.com>; Fri, 6 Sep 2019 12:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 XEw8XyR01ikI for <roll@ietfa.amsl.com>; Fri, 6 Sep 2019 12:45:49 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F35F120B61 for <roll@ietf.org>; Fri, 6 Sep 2019 12:45:48 -0700 (PDT)
Received: from dooku.sandelman.ca (85-76-97-171-nat.elisa-mobile.fi [85.76.97.171]) by relay.sandelman.ca (Postfix) with ESMTPS id 27EC81F47F for <roll@ietf.org>; Fri, 6 Sep 2019 19:45:46 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 139971042; Fri, 6 Sep 2019 13:15:51 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-reply-to: <MN2PR11MB3565916624AEFA679F5FC150D8BB0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB3565916624AEFA679F5FC150D8BB0@MN2PR11MB3565.namprd11.prod.outlook.com>
Comments: In-reply-to "Pascal Thubert (pthubert)" <pthubert@cisco.com> message dated "Thu, 05 Sep 2019 14:25:26 -0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 06 Sep 2019 20:15:51 +0300
Message-ID: <3821.1567790151@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/48_46FByjZ7Uu53Ba1pBwNf-9KI>
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: Fri, 06 Sep 2019 19:45:52 -0000

Thank you; these are really good questions.

pascal> I'm looking at what P-DAO would need to express as capabilities.
pascal> Here's a list, please come back with more:

I am re-ordering slightly.

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

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

pascal>   *   Express support for exposing siblings

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

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 }

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?
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.

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

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?

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

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?

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.

-- 
]               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    [