Re: [Roll] [Anima] ACP RPL profile and dynamics

Toerless Eckert <tte@cs.fau.de> Thu, 08 September 2022 23:30 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 4D221C14CE31; Thu, 8 Sep 2022 16:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.657
X-Spam-Level:
X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csoBW3nguvkP; Thu, 8 Sep 2022 16:30:14 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2A3C14CE44; Thu, 8 Sep 2022 16:30:12 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 60DC158C4AF; Fri, 9 Sep 2022 01:30:04 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4AF184EB9B6; Fri, 9 Sep 2022 01:30:04 +0200 (CEST)
Date: Fri, 09 Sep 2022 01:30:04 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr@sandelman.ca>
Cc: Hendrik Mahrt <hendrik.mahrt@kit.edu>, anima@ietf.org, roll@ietf.org
Message-ID: <Yxp6/M6r6y8Vc3Yu@faui48e.informatik.uni-erlangen.de>
References: <861c74d7-4fe0-9b27-6075-faa94bd6ee7a@kit.edu> <43629.1662541964@dooku>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <43629.1662541964@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/7eQR7X2QKvS9ypS9gGDfzRHC628>
Subject: Re: [Roll] [Anima] ACP RPL profile and dynamics
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 08 Sep 2022 23:30:18 -0000

On Wed, Sep 07, 2022 at 05:12:44AM -0400, Michael Richardson wrote:
> My thinking, which may be entirely wrong, is that the idea is to keep at most
> three IPsec tunnels up with potential parents.

I think ACP does not describe anything like this (which is fine, because
optimizations only need to be compliant with what the spec does write).
(i am saying "i think", because details of the RPL profile from Pascal
 could imply something like this, but i don't think it does).
 
More importantly, i think we can not do such an optimization:
The role of parent/candidate parent is AFAIK determined from received
RPL information. We only want to get RPL information across the ACP channels
(aka: IPsec or DTLS tunnels). As soon as we would try to do such an
opimization, how would we be able to learn when such a link turns from a
parent to a child ? I think we can not.

Aka: you've got a neighborship with an ACP node wheree you determine that
it would be the fourth possible parent. So you remove the link. Now the
region that that neighbor is in looses its connection to the root, and we
would become the only connection to the root. 

Arguably, that other node could then try to re-create the ACP connection
to us in search of a root connection, BUT: That type of optimization/minimiation
of adjacencies is something i would like to NOT INVENT for ACP, but have as
a general purpose, ROLL-WG vetted RPL optimization. If it exists, great, we
can likely use it for ACP. If not, but you think it should work, then
we should rather try to write it up as a ROLL document to get appropriate
review/approval.

> DAOs should go down those
> tunnels so that:
> a) each end is aware of each other's rank
> b) were we ever to do p2pRPL, or DAO projection, that we'd have some lateral
>    tunnels to use.
> c) that we somehow learn of the ETX and latency across that link, and derive
>    a metric for that direction.
>    We could do this within the tunnel, using RPL messages, ICMPv6s, or
>    we could do this using the tunnel, using IKEv2 DPD messages.

> On the one had we could have situations where there is some ACP-unaware L2 fabric
> connecting many ACP nodes, and it really would be silly to form all the
> adjacencies.   In this case, initiate at most three, and pick one as parent,
> but keep the other two up (and monitor them)

This seems like an easier problem that _might_ already exist more likely
in non-ACP RPL deployments, given how there should easily be a possibility
for large LANs. For example RPL over WiFi where an SSID is such an L2 entity
and you have maybe 2 or more actual RPL routers, the other 500 are RPL leafs
(sensors/actors).

> On the other hand, a more typical ISP situation is there is a router with
> three or four WAN links, each of which is a p2p ethernet.  In that case,
> there is really only one peer on each link, and it makes no sense not to have
> a tunnel up on every interface.

Right. transit L2 domains with many routers on them in service-providers has
been for more than a decade been a big pain for me, because they don't work
well for PIM-SM IP-Multicast, so whenever i worked with customers, we tried to
upgrade the L2 switching in such domains to L3. But there are some natural
L2-only type of equipment where this can not be done. 802.17 (RPR) rings come
to mind. I have not seen them with more than 100 routers connected, and while
a full-mesh of 100x100 IPsec tunnels is not ideal, it also is nothing that wouldn't
work just fine for the high-speed routers that use them. If on the other hand
we would get ACP with RPL into future 2-wire 10 Mbps industrial L2 domains
where the routers are much more low-poer, then an optimization would certainl
be welcome. But i think that optimization would equally be useful without ACP -
and i would hope that 100 IPsec SA isn't really the big issue... But i am just
guessing.

>     > But if I understand correctly this successor is not 'actively'
>     > sought after, i.e., the node does not actively increase its rank to
>     > obtain it, as that would surely violate the rules of RPL on greediness
>     > formulated in RFC 6550 in sections 3.7.1 and 8.2.2.4?! Or am I
>     > mistaken?
> 
> Yes, that's right, the parent is not *selected*, but rather kept in reserve.
> See for instance, some of the recent RPL work
>   https://datatracker.ietf.org/doc/draft-ietf-roll-rnfd/
> 
> which would use these "lateral" relationships to detect if the parent had died.
> 
>     > Second question: The ACP RPL profile, as I understand it, features no
>     > form of global repair or DODAG version increase (except manual
>     > intervention by admin). How would that work with node mobility (which
>     > is mentioned in Appendix A.4)? MaxRankIncrease would limit a node's
> 
> It's a good question, and I assumed that global route repair would occur
> periodically, and whenever the NOC found that it couldn't reach some nodes.
> There is probably a gap in knowledge/experience here.

Whats the most easy example series of events to trigger a possible problem
without this global repair ? currently selected root goes down ?

Cheers
    toerless