Subject: [Roll] UNaware leaves

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Aug 2019 16:28:50 -0400

I have read draft-ietf-roll-unaware-leaves-02 anew.

I have sent a bunch of minor edits to Pascal as a diff against the XML file,
and I won't repeat them here.  I ask some deep questions in among a few
less deep questions.

The intro section is a really nice overview of RPL.
I rather suggest that we might want to use this text in other places.

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.

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>

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?

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

section 6 is rather all over the place.
I'd like subsection points, because we are going to need to refer to the
sections, and there will be 6man interaction?
Could the whole section be named, "6LN Requirements to be a Unware Leaf".
Can we get a 6man reviewer for this sooner?

>   or not.  The flows below are RPL Non-Storing Mode examples.  In
>   Storing Mode, the DAO ACK may not be present, and the DAO messages
>   cascade from child to parent all the way to the DODAG Root.

Actually, isn't the K-flag behaviour this still an open issue in the WG?
Or did we resolve this somewhere?  Last I recall it was in Rahul's big
document, not in something we had adopted.

I think that 7.1, if it is general flow, shouldn't try to do storing and
non-storing mode.  Either have two sections, or omit the differences in the
general flow, and deal with the details in subsequent sections.

I think that maybe the general flow should omit the backbone registration.
Explain it all without a backbone, and then do it again with backbone.

>   This specification does not alter the operation of a 6LoWPAN ND-
>   compliant 6LN, which is expected to operate as follows:

really... I thought that we were making it able to deal with RPL artifacts,
as specified in section 6!!!
What is the specific signal that the 6LR can use to know that the host
is an RAN rather than a RUL?

I suggest that all text like:
   o  Upon each consecutive registration, the 6LN MUST increase the TID
      field.

read like:
   o  As described in RFCXXXX section FOOBAR, upon each consecutive
      registration, the 6LN MUST increase the TID field.

because I think that the point is that there are no changes, right?
Except for the InstanceID.

Should this specification extend 6tisch-minimal (CoJP) to include a way to
set the InstanceID?

   o  A 6LN acting as a RUL MUST set the 'R' flag in the EARO whereas a
      6LN acting as a RAN SHOULD NOT set the 'R' flag.

wouldn't a 6LN acting as a RAN be a 6LR Leaf, and therefore not a 6LN?
Maybe we need another term here.

   o  the 6LN is not expected to be aware of RPL so it is not expected
      to produce RPL artifacts in the data packets.

certainly, it shouldn't do IPIP or RH3.
It would be damn useful if it would put the RPI in.

Not putting it in means the adjacent 6LR has to IPIP it, address it to the
RPL Root.
If we put it in, then in the storing case, no further IPIP is needed!!

In non-storing the root still has to add the RH3, if it's going back down.
If it's window smash alarm, it is probably going to leave the LLN anyway, so
no big deal.

I want to get rid of the IPIP headers not because they take space, but
because the represent code paths not frequently taken. In particular, the
hop-by-hop IPIP header just pisses me off.

>   From then on, the 6LN periodically sends a new NS(EARO) to refresh
>   the NCE state before the lifetime indicated in the EARO expires, with
>   TID that is incremented each time till it wraps in a lollipop
>   fashion.  As long as the 'R' flag is set and this router can still

lollipop fashion probably needs a reference.  What does TID start with?
(what's the stick of the lollipop?  I guess this is in 8505, but reviewers
probably won't know this unless we tell them)

I think that "is left to zero" is a bit awkward.
I think that "is zero" is better?
I think that the Opaque field isn't zero, but is empty?

>   o  the External 'E' flag in the Transit Information Option (TIO)
>      associated to the Target Option is set to indicate that the 6LR
>      redistributes an external target into the RPL network.  This is
>      how the Root knows in Non-Storing Mode to use IP-in-IP and
>      terminate the outters headers at the 6LR that generated the DAO.

There are a lot of other circumstances in which the root has to use an
IPIP.  I think that it would be better to say:

}   o  the External 'E' flag in the Transit Information Option (TIO)
}      associated to the Target Option is set to indicate that the 6LR
}      redistributes an external target into the RPL network.  When
}      the Root has to use an IP-in-IP [useofrplinfo], then this flag
}      indicates the IP-in-IP should be addressed to this node.

I think that traffic from the Root to the RAN will not need an IP-IP,
just the RH3/RPI, which the RAN will skip.   Traffic from elsewhere
will have an IPIP in for that Root to add the RH3/RPI.  But, since
the RAN will skip IPIP, the Root could address traffic.

Are there projected DAO interactions where the Root arranges for traffic to
go laterally across the DODAG that might need some consideration here?

ASIDE: should this document effectively Update UseofRPLINFO?

Security Considerations will probably need another page.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 27 Aug 2019 16:59:07 +0000

Continuing ...

All: Considering the efforts Michael placed in that review I invited him to coauthor.
We now use github to collaborate and the WIP is in https://github.com/roll-wg/roll-unaware-leaves/ 

Michael: Please see below

> I'd like subsection points, because we are going to need to refer to the sections,

I can propose this:

   6.  6LN Requirements to be a RPL-Unware Leaf  . . . . . . . . . .   9
     6.1.  Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . .   9
     6.2.  IPv6 Host Support of RPL Artifacts  . . . . . . . . . . .   9
       6.2.1.  Support of the HbH Header . . . . . . . . . . . . . .   9
       6.2.2.  Support of the Routing Header . . . . . . . . . . . .  10
       6.2.3.  Support of IPv6 Encapsulation . . . . . . . . . . . .  10

> and there will be 6man interaction?

Renamed. 
Note that the dependencies on IPv6 do not change IPv6, just requires an IPv6-compliant support by the host.
Not sure we need 6MAN help for that.

> Or did we resolve this somewhere?  Last I recall it was in Rahul's big document,
> not in something we had adopted.

There was never really an issue. There is a trick in one open source implementation (Kontiki) for an end-to-end ack that was useful for their use case. But that is non-standard.
The RUL draft reminds the normal expectation of RPL, that is a hop by hop ack. As I said on the mike at an early WG meeting, if the parent acks it takes responsibility to progress the DAO.
If later the parent fails to progress the DAO, it should stop being a parent and poison to the child can use some other path to progress  the DAO towards the root. 
Once the DAO reaches the root, the address becomes reachable.

> 
> I think that 7.1, if it is general flow, shouldn't try to do storing and non-storing
> mode.  Either have two sections, or omit the differences in the general flow, and
> deal with the details in subsequent sections.
> 

I made a step, to be improved, by adding the storing mode flow

> Explain it all without a backbone, and then do it again with backbone.

Removed the BBR for now

> really... I thought that we were making it able to deal with RPL artifacts, as
> specified in section 6!!!

Which is as should already be. That's not even 6LoWPAN ND, that's IPv6 if you look at it.

> What is the specific signal that the 6LR can use to know that the host is an RAN
> rather than a RUL?

Yes we have text, maybe even repeated with terminology; e.g., 

"
         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.
"

More tomorrow. I committed what I had up to here in github.

Take care,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Aug 2019 09:24:25 -0400

> Which is as should already be. That's not even 6LoWPAN ND, that's IPv6 if you look at it.

Well, I tried to push for 6man's host requirements bis (RFC8504) to include processing
of IP(dst=me)IP(dst=me) to be included, but it was a hard push, and I didn't
have the energy.

So, we are making requirements which go beyond 8504.

    > expected to be a RAN that handles the reachability of the Registered

got it.