Subject: Re: [Roll] UNaware leaves: separating EDAR proxy from 'R"' flag processing

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Aug 2019 14:58:00 +0000

Hello Michael:
 
> OLD:
>    In RPL terms, a plain host that does not
>    participate to the routing protocol is called a Leaf.  It must be
>    noted that a 6LN could participate to RPL and inject DAO routes to
>    self, but refrain from advertising DIO and get children.  In that
>    case, the 6LN is still a host but not a Leaf.
> 
> NEW:
>    In RPL terms, a plain host that does not contribute forwarding services
>    to the routing protocol is called a Leaf.
>    Such a 6LN would still contribute DAO routes to itself, but would refrain
>    from advertising DIOs, and will not have any children.
> 
> But, I'm rather unclear about this next part:
>    In that case, the 6LN is still a host but not a Leaf.
> 
> I think that it should say:
>    In the case where the 6LN does not contribute DAOs to inject routes
>    to itself, then the 6LN is a host but not a Leaf.
> 
That text was obsolete. At the time of the writing a RUL was not a leaf but now we changed that, didn't we?
I mean, useofrplinfo uses RAL and RUL.
 I think we agreed that anything connected to RPL but not routing is a leaf, so no we have RAL and RUL.

   Such a 6LN would still contribute DAO routes to itself, but would
   refrain from advertising DIOs, and will not have any children.  "When
   to use RFC 6553, 6554 and IPv6-in-IPv6" [I-D.ietf-roll-useofrplinfo]
   introduces the term RPL-Aware-Leaf (RAL) for that type of 6LN.  In
   contrast, a RPL-Unaware Leaf (RUL) designates a leaf does not
   contribute to RPL but is reachable over a RPL network.  In that case,
   the 6LN is a plain host that needs an interface to the RPL router to
   obtain routing services over the LLN.

Note that this document introduces RAN that is either a RPL router or a RAL.

> Would be good to have a reference for the "kinetically powered light switch."
> I have asked some people for one, because we always talk about them in the
> abstract.
> 
> I think that section 3 should be clearer about whether the "R" bit already
> exists or not. (It is part of 8505).  I suggest:
> 
>     <t>
> -   The 'R' flag that is set if the Registering
> -   Node expects that the 6LR ensures reachability for the Registered Address,
> -   e.g., by means of routing or proxying ND.
> -   </t> <t>
> +     This document specifies the use of the existing 'R' flag. It is to be set
> +     if the Registering Node expects that the 6LR is to ensures reachability
> +     for the Registered Address, e.g., by means of routing or proxying ND.
> +   </t>
> +   <t>

Actually the use by the host is defined in RFC 8505. This specification defines the reaction of the router to the R flag setting. 
What about

    [RFC8505] specifies the use of the 'R' flag by the Registering Node.
   The Registering Node sets the 'R' flag to indicate that the 6LR
   should ensure reachability for the Registered Address, e.g., by
   means of routing or proxying ND.  This document specifies the
   behavior of the RPL router depending on the setting of the 'R' flag.

> 
> section 5:
> 
>    The behavior defined in this specification [[whereby the 6LR that
>    processes the registration advertises the Registered Address in DAO
>    messages and bypasses the DAR/DAC process for the renewal of a
>    registration]], is only triggered by an NS(EARO) that has the 'R' flag
>    set.  If the 'R' flag is not set, then the Registering Node is
>    expected to be a RAN router that handles the reachability of the
>    Registered Address by itself.
> 

> Can we just omit the [[]] part?  It's really a mouthful.
> Or give the behaviour a name/section number.
> Maybe that means a section 3.1?
> 

Well it is a bit more complicated. 

Seems to me that the suppression of DAR / DAC at the 6LR to be recreated by the root should be done regardless of the 'R' flag.
Any node will send a periodic NS (EARO) to its parent / router whether it is a RUL or a RAN of any sort . We want to have the root generate the keep alive EDAR/EDAC to the 6LBR upon a DAO as opposed to the 6LR, to save a traversal of the network. 
One problem is for the 6LR to know if the root and the 6LBR have an agreement to do the keep-alive based on DAO. This needs to be signaled by the root, we probably need a flag in the 6CO.
Another is that the keep-alive DAO from the root is lacking the ROVR unless we add an option in RPL to carry it.

> Also I want to be clear that the "This document" in section 5 refer to unware-
> leaves, and not RFC8505.
> 

4.  Updating RFC 6550

   This document specifies a new behavior whereby a 6LR injects DAO
   messages for unicast addresses registered through the updated 6LoWPAN
   ND [RFC8505] on behalf of leaves that are not RPL-aware.

   [RFC8505] specifies the use of the 'R' flag in the EARO by the
   Registering Node.  With that specification, the Registering Node sets
   the 'R' flag to indicate whether the 6LR should ensure reachability
   for the Registered Address, e.g., by means of routing or proxying ND.

   Conversely, this document specifies the behavior of the RPL router
   depending on the setting of the 'R' flag.  The 6LR advertises the
   Registered Address in DAO messages, if and only if it is triggered by
   an NS(EARO) that has the 'R' flag set, indicating that the 6LN is a
   RUL.  If the 'R' flag is not set, then the Registering Node is
   expected to be a RAN that handles the reachability of the Registered
   Address by itself.

   As prescribed by [RFC8505], a RPL router SHOULD NOT set the 'R' flag,
   unless it relies on the 6LR to generate the DAO messages on its
   behalf.

5.  Updating RFC 8505

   [RFC8505] specifies a periodic Extended DAR/DAR exchange that takes
   place between the 6LR and the 6LBR.  It is triggered by a NS(EARO)
   message and is intended to create and then refresh the corresponding
   state in the 6LBR for a lifetime that is indicated by the 6LN.
   Conversely, RPL [RFC6550] specifies a periodic DAO that maintains the
   routing state in the RPL network for a lifetime that is indicated by
   the source of the DAO.  This means that there are two periodic
   messages that traverse the whole network to indicate that an address
   is still reachable, one to the root and one to the 6LBR.  This
   specification enables to synchronize the liveness monitoring at the
   root and the 6LBR, which may or may not be the same node.  A same
   value of lifetime is used for both, and a single keep alive message,
   the RPL DAO, traverse the RPL network.

   Upon the renewal of a 6LoWPAN ND registration, this specification
   changes the behavior of a RPL router acting as 6LR for the
   registration as follows: If the root indicates the capability to
   proxy the keep-alive EDAR/EDAC exchange, then the 6LR refrains from
   sending an EDAR message.  If the root is separated from the 6LBR, it
   regenerates a keep-alive message to the 6LBR upon a DAO message.  In
   that flow, the RPL Root acts as a proxy on behalf of the 6LR to
   refresh the state in the 6LBR, which saves the traversal of the
   network by a second keep-alive message.

   This document also specifies a keep-alive EDAR message that the RPL
   Root may use to maintain an existing state in the 6LBR upon receiving
   DAO messages.  The keep-alive EDAR message may only act as a
   refresher and can only update the Lifetime and the TID of the state
   in the 6LBR.

   This document similarly specifies a keep-alive NS(EARO) message that
   the RPL Root may use to maintain an existing state in a 6BBR upon
   receiving DAO messages when the root is located on a same link as the
   6LBR.  The keep-alive NS(EARO) message may only act as a refresher
   and can only update the Lifetime and the TID of the state in the
   6BBR.

I'll continue with you review in another thread, this is already a lot!

Many thanks Michael

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Aug 2019 17:33:37 +0000

Dear all

It would be neat to suppress the keep alive DAR across the network for all 6LNs from the 6LN to the 6LBR. 
The problem is that the 6LR needs to make sure that there is a DAO to trigger a proxy DAR from the root to the 6LBR to replace it.
For a RUL the 6LR knows because it generates it. For a RPL aware node that does its own DAOs, the 6LR may not see them (e.g., in non-storing mode).
So suppressing the keep alive DAR would be on the faith that the 6LN does the right thing and injects a or whatever else will trigger a DAR to the 6LBR.

All the best,

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: lundi 26 août 2019 16:57
> To: [email-masked]
> Subject: RE: [Roll] UNaware leaves: separating EDAR proxy from 'R"' flag
> processing
> 
> Hello Michael:
> 
> > OLD:
> > I have asked some people for one, because we always talk about them in
> > the abstract.
> >
> > I think that section 3 should be clearer about whether the "R" bit
> > already exists or not. (It is part of 8505).  I suggest:
> >
> >     <t>
> Actually the use by the host is defined in RFC 8505. This specification defines
> the reaction of the router to the R flag setting.
> What about
> 
> Seems to me that the suppression of DAR / DAC at the 6LR to be recreated by
> the root should be done regardless of the 'R' flag.
> Any node will send a periodic NS (EARO) to its parent / router whether it is a
> RUL or a RAN of any sort . We want to have the root generate the keep alive
> EDAR/EDAC to the 6LBR upon a DAO as opposed to the 6LR, to save a traversal
> of the network.
> One problem is for the 6LR to know if the root and the 6LBR have an
> agreement to do the keep-alive based on DAO. This needs to be signaled by
> the root, we probably need a flag in the 6CO.
> > Also I want to be clear that the "This document" in section 5 refer to
> > unware- leaves, and not RFC8505.
> >
> 
> 4.  Updating RFC 6550
>