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

[Michael Richardson <[e-mail]>]

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.

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

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