Re: [Roll] Border router failure detection

[Michael Richardson <[e-mail]>]

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