Re: [Roll] Border router failure detection

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Konrad

At an abstract level I see your proposal as a form of BFD where the network assesses the liveliness of the root. The operation is done by a number of representatives that must agree that the root is gone. The draft does a good job at addressing the Byzantine problem once we know who the generals are, but it's unclear to me how they are elected and how they converse.

That's a family of questions around the issue of how we avoid false positive. Seems that the more sentinels the less of them. But the less efficient the algorithm is. 

- do the sentinels encompass all first hop nodes?
- how do we compute the right number of sentinels?
- do the sentinels needs direct connectivity to one another?
- how quick should the protocol react ? 
- I mean, if the root reboots, is that worth the hassle of breaking and forming the DODAG again?
- do the sentinels form a connected group ? how ? if not, what happens if one group loose connectivity to the root but the other does not?

Keep safe;

Pascal

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Konrad Iwanicki
> Sent: jeudi 8 avril 2021 23:20
> To: Routing Over Low power and Lossy networks <[e-mail]>; Pascal
> Thubert (pthubert) <pthubert=[e-mail]>
> Subject: Re: [Roll] Border router failure detection
> 
> Hi again Pascal,
> 
> On 08/04/2021 16:16, Pascal Thubert (pthubert) wrote:
> > Hello Konrad
> >
> > About this text
> > "
> >
> >     Since all DODAG paths lead to the corresponding LBR, detecting its
> >     crash by a node entails dropping all parents and adopting an
> infinite
> >     rank, which reflects the node's inability to reach the LBR.
> However,
> >     achieving this state for all nodes is slow, can generate heavy
> >     traffic, and is difficult to implement correctly [Iwanicki16]
> >     [Paszkowska19] [Ciolkosz19].
> > "
> >
> > Please note that this may be what an implementation decides to do, but
> is by far not my favorite option.
> > The alternate is to rest the "G" but and become floating root. The
> benefit is that the DODAG structure is mostly maintained and that routing
> inside may persist.
> >
> > See https://tools.ietf.org/html/rfc6550#section-18.2.4 for how to
> configure this.
> 
> OK, I think I addressed this in my previous e-mail to you and Michael.
> 
> (The next two e-mails will have to wait till tomorrow I am affraid.)
> 
> Best,
> --
> - Konrad Iwanicki.
> 
> >> -----Original Message-----
> >> From: Roll <[e-mail]> On Behalf Of Konrad Iwanicki
> >> Sent: mercredi 7 avril 2021 21:37
> >> To: Routing Over Low power and Lossy networks <[e-mail]>
> >> Subject: Re: [Roll] Border router failure detection
> >>
> >> Dear all,
> >>
> >> Approximately a year ago, I joined the WG and advertised an extension
> >> to RPL that I had been working on for some time with a goal of
> >> describing it in a draft. Unfortunately, just when I got the
> >> necessary pointers and a few initial comments, the pandemic broke
> >> out. The resulting surge of professional and personal obligations
> >> made it literally impossible for me to participate in and, at some
> >> point, even follow the group's activities, for which I am sorry.
> >>
> >> However, I did strive to regularly find a little time to get somewhat
> >> acquainted with IETF's procedures and write up something that may
> >> resemble a draft. I have just submitted it as:
> >>
> >>      draft-iwanicki-roll-rnfd-00
> >>
> >> and created a dedicated repository on the group's GitHub.
> >>
> >> 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.
> >>
> >> Please, keep mind in mind that I decided to maximally cut down the
> >> original algorithms, so that the extension is as simple as possible
> >> without losing key properties. Therefore, it is likely that if the
> >> extension as a whole or any of its parts turn out relevant or
> >> interesting, still a considerable amount of work may be necessary to
> >> have it or them described properly. Your contribution is most welcome.
> >>
> >> Thanks in advance.
> >>
> >> Best regards,
> >> --
> >> - Konrad Iwanicki.
> >>
> >> _______________________________________________
> >> Roll mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/roll
> >
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> >
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll