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

[Hendrik Mahrt <[e-mail]>]

Hi Michael,

On 9/7/22 11:12, Michael Richardson wrote:
> 
> Hendrik Mahrt <[e-mail]> wrote:
>      > First question: In the ACP RPL profile it is stated that "Nodes SHOULD
>      > select more than one parent, at least three if possible". But I'm not
>      > sure how multiple parents are selected by OF0 without nodes being
>      > greedy.
>      > The OF0 RFC [RFC 6552] does not contain any information about
>      > multiple parents, except for a 'backup feasible successor' (Section
>      > 4.2.2).
> 
> Remember that each parent is reachable over an IPsec tunnel.
> It's somewhat different than from a typical LLN situation where one could
> hear from multiple parents on a broadcast media.  (Well, in fact the GRASP
> DULL message serves that purpose)
>  > My thinking, which may be entirely wrong, is that the idea is to keep 
at most
> three IPsec tunnels up with potential parents.   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)
> 
> 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.
> 

I'm not quite sure how the type of media or its capability to broadcast
interacts with RPL parent selection. The way I understand ACP, IPSec
tunnels are established with all link neighbors of the same ACP domain.
This is done prior to RPL coming into action. It is also necessary to
exchange RPL ranks with all neighbors. How else would a node determine
its parent(s)? I guess afterwards tunnels to neighbors that are neither
parent nor child of a node could be closed again, yes.

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

The wording in ACP Section 6.12.1.7 is "The DODAG version is only
incremented under catastrophic events", therefore I was under the
impression global repair would only be done in extreme circumstances,
and not periodically.


  Hendrik