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

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

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: [e-mail]
> Subject: RE: [Roll] UNaware leaves: separating EDAR proxy from 'R"' flag
> processing
> 
> 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