Hi Michael, On 9/7/22 11:12, Michael Richardson wrote:
Hendrik Mahrt <[email protected]> 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
