Re: [Roll] Border router failure detection

[Konrad Iwanicki <[e-mail]>]

Hello Pascal,

On 08/04/2021 16:05, Pascal Thubert (pthubert) wrote:
> If I may add: At the (early) time I contributed to the ACP design, the idea was that the Root's children were configured with a DODAGPreference (prf) that is more than the default value (of 0) inside the network. Different children may be given different prf to enforce an order in which they become the replacement for the LBR serving as Root.
> 
> When losing connectivity to the LBR, a child that does not have connectivity to the main DODAG becomes floating Root of its own DODAG. If the LBR dies, all the children lose their parent, and the floating DODAG reforms from the child with the highest prf. Nodes that are willing to jump to an alternate DODAG that is grounded will do so. This is supposed to be somewhat fast because the Trickle timers are reset.
> 
> I understand that the idea here is to be faster than that.

That's an interesting idea, which is again orthogonal to RNFD and 
related to what I wrote in the previous e-mail: RNFD's operation is 
focused on the period from the DODAG root's crash to the moment of 
detecting it by all nodes. In this case, RNFD would thus speed up the 
occurrence of the moment the root's neighbors promote themselves to the 
roots of floating DODAGs.

As to the promotion itself, I was wondering if one could additionally 
integrate the election of the root's neighbor with the best prf into 
RNFD to speed up the formation of the newly created floating DODAG. 
However, as you pointed out, DODAG construction is rapid because of 
Trickle, so modifying RNFD to also perform the election of the neighbor 
with the best prf would bring little benefit and would only make the 
algorithm more involved.

To sum up, as I mentioned in the previous e-mail, RNFD can significantly 
accelerate the detection of the DODAG root's crash and bootstrapping of 
floating DODAGs by the root's neighbors, and the prf algorithm kicks in 
after the DODAG root's crash has been detected.

Best,
-- 
- Konrad Iwanicki.


>> -----Original Message-----
>> From: Roll <[e-mail]> On Behalf Of Michael Richardson
>> Sent: jeudi 8 avril 2021 1:46
>> To: Routing Over Low power and Lossy networks <[e-mail]>
>> Subject: Re: [Roll] Border router failure detection
>>
>>
>> Konrad Iwanicki <[e-mail]> wrote:
>>      > draft. Unfortunately, just when I got the necessary pointers and a
>> few
>>      > initial comments, the pandemic broke out.
>>
>> I know the feeling.
>> I keep thinking I should be able to do *more* since I can't go out.
>>
>>
>>      > draft-iwanicki-roll-rnfd-00
>>
>>      > and created a dedicated repository on the group's GitHub.
>>
>> I see it at:
>>    https://github.com/roll-wg/draft-rnfd
>>
>> You might want to add a Makefile, either via
>>      https://github.com/martinthomson/i-d-template/blob/master/doc/SETUP.md
>> or rip of my minimal one, such as:
>>      https://github.com/roll-wg/draft-ietf-roll-enrollment-
>> priority/blob/master/Makefile
>>
>>      > Since I have no experience writing IETF documents, I would really
>> appreciate
>>      > your collaboration on either turning the text into a true draft or
>> concluding
>>      > that this should not be done.
>>
>> It looks like you did a really good job.
>>
>> RPL is being used in storing mode the ANIMA WG's Autonomic Control Plane.
>> See: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-
>> plane/
>> ( section 6.12. ).   The document is minutes away from getting an RFC#.
>>
>> We think that the border router, DODAG root, will be a device in the NOC.
>> The NOC may get replicated into multiple locations so there could
>> potentially be more than one candidate DODAG root.  Given nodes are not
>> constrained in the RFC7228 sense, supporting multiple DODAGs could be
>> done, but we simplified our life by not mandating (actually, at this
>> point, forbidding) the RPI header, so we are lacking an instanceID.
>>
>> The short of it is that I'd really like nodes to be able to float non-
>> grounded DODAG roots if they don't hear a DIO after a few seconds.
>>
>> ----
>>
>> It seems that you might want a term for the LBR's children.
>> That is, the devices at rank "1", that hear the LBR's DIOs.
>>
>> I think that I would move some of section 3.2 further forward in the
>> document.  I think that I need a gentler introduction to CFRCs here, and I
>> don't really need to know the properties, rather I need a higher-level
>> idea
>> of things.    Since section 4 goes over the operations again, I would
>> leave
>> it for that spot, and make it a section 4.1.
>>
>> Having gone forward and back a bit, I'm still a bit uncertain how nodes
>> assign themselves a bit... oh, self() in section 4 says "random".
>> Why not make this a function (hash?) of the short-IPv6 address or
>> something?
>>
>> Not every media has ACK frames at the L2 to establish that there are
>> failures.  It might be worth putting the Detecting and the Verifying into
>> separate sections.  Aside from the ANIMA case (which is usually pure
>> ethernet), there are also situations where there is an ethernet backbone
>> connecting a few 6LBRs (RFC8929), and your protocol would sensibly run on
>> both the wireless and the wired side of the 6LBRs.
>>
>> I also wonder if the RNFD could be included in DAOs (particularly storing
>> mode ones) sent to the DODAG root.
>> I know that probably seems senseless: why tell the root that you are
>> observing it to be dying....  But, it acts as interesting telemetry about
>> what the nodes are seeing, and might serve as a useful indication of
>> imminent failure, or some kind of systematic long-cycle pathology.
>>
>> Your IANA considerations are how the document will look after IANA has
>> processed it.  Prior to that point, you need to write it as a request.
>>
>> Something like:
>>
>>     IANA is requested to allocate the value TBD1 from the "RPL Control
>> Message
>>     Options" sub-registry of the "Routing Protocol for Low Power and Lossy
>>     Networks (RPL)" registry.
>>
>> I like to include the URL of the registry in my request to be really
>> really clear, and to save everyone else the time to find it.
>>
>> Your security considerations will want to cite RFC7416.
>> In particular, 7.2.4, and section 7.3.4 and 7.3.5 might be relevant.
>>
>> --
>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>