[Roll] UNaware leaves

[Michael Richardson <[e-mail]>]

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  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [












--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-