Re: [Roll] AD Review of draft-ietf-roll-unaware-leaves-18

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

Hello Alvaro

Many thanks again and again!

> 
> Thank you for working on this document!
> 
> I just finished reviewing it and find myself with a lot more comments,
> questions, and concerns that I thought I would.  I'm highlighting some of my
> major issues here, and have detailed comments in-line.

I see it this way: 

RFC 8504 expects classic ND, on-link subnet. We're doing ML Subnet and designed RFC 8505 as the evolution of ND to cover that case.
This draft is the first time we use RFC 8505 as a host-to-router (UNI) abstract interface to the router-to-router (NNI).
We use RPL in this case, but could be any routing protocol. 

So yes there can be a lot to iron out but it is worth the effort. Many thanks for your help and patience 😊


> (1) What is a RUL?
> 
>  I assumed that a RUL would be a "plain" IPv6 node that is not aware of RPL
>  at all.  That definition would include, of course, not being aware of this
>  document...

Yes. I believe that is how we defined it. 
The RUL is an IPv6 host connected to RPL that does not speak RPL.

> but §7 normatively defines requirements and expected behaviors
>  for the RUL.  It feels like the chicken and the egg: the RUL is not
>  aware...but it is expected to comply with this specification....but it's not
>  aware...


RPL expects only RPL Aware Nodes, and the unprepared RUL will not get connectivity in a RPL network.
So we define here what needs to be added to a classic host to connect to RPL.
Unsurprisingly, it is based on the ND version that we defined for LLNs.


>  The definition of a RUL starts in the Introduction with a simple
>  description: "RUL is an IPv6 Host [RFC8504]".

This was not meant to be a definition of a RUL but just one of its characteristics. 


 And we say it in section 2.1

"
   This document uses the terms RPL-Unaware Leaf (RUL) and RPL-Aware
   Leaf (RAL) consistently with "Using RPI Option Type, Routing Header
   for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data
   Plane" [USEofRPLinfo].
"

And useofrplinfo says :

"
   RPL Leaf: An IPv6 host that is attached to a RPL router and obtains
   connectivity through a RPL Destination Oriented Directed Acyclic
   Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a
   consumed Routing Header and as an IPv6 host, it is expected to ignore
   a Hop-by-Hop header.  It results that a RPL Leaf can correctly
   receive a packet with RPL artifacts.  On the other hand, a RPL Leaf
   is not expected to generate RPL artifacts or to support IP-in-IP
   encapsulation.  For simplification, this document uses the standalone
   term leaf to mean a RPL leaf.

   RPL-unaware-node: A device which does not implement RPL, thus the
   device is not-RPL-aware.  Please note that the device can be found
   inside the LLN.

   RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf.

"

>  I know that rfc8504 includes
>  a section on "Constrained Devices", but it just mentions that "compromises
>  may need to be made".  This document, in the very next paragraph (!), adds
>  other expectations (beyond rfc8504): support for 6LoWPAN ND...

The  RUL must be an IPv6 host, which means comply with RFC 8504; but RFC 8504 compliance is not sufficient for a RUL to connect to a RPL network, thus this spec.
This spec specifies the additions to RFC 8504 for that to happen. 
The RUL is an IPv6 host, that much is true. But not only that. It is a Leaf, which means reachable though RPL. 
Some magic must happen. That magic will not be found in classic ND because ND does not support MLSN. But 6LoWPAN ND does.

I see that the text could be read differently and that we need to reword to avoid it. Proposal:

OLD 
"
  RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND)
   [RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain
   reachability within a Non-Broadcast Multi-Access (NBMA) subnet.  In
   that mode, some nodes may act as Routers and participate to the
   forwarding operations whereas others will only terminate packets,
   acting as Hosts in the data-plane.  In [RFC6550] terms, a Host that
   is reachable over the RPL network is called a Leaf.

   "When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo]
   introduces the term RPL-Aware-Leaf (RAL) for a Leaf that injects
   routes in RPL to manage the reachability of its own IPv6 addresses.
   In contrast, the term RPL-Unaware Leaf (RUL) designates a Leaf that
   does not participate to RPL at all.  A RUL is an IPv6 Host [RFC8504]
   that needs a RPL-Aware Router to obtain routing services over the RPL
   network.

"

NEW
"   
   RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND)
   [RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain
   reachability within a Non-Broadcast Multi-Access (NBMA) subnet.
   In that mode, IPv6 addresses are advertised individually as Host
   routes.  Some nodes may act as Routers and participate to the
   forwarding operations whereas others will only terminate packets,
   acting as Hosts in the data-plane.  In [RFC6550] terms, an IPv6 Host
   [RFC8504] that is reachable over the RPL network is called a Leaf.

   "When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo]
   introduces the term RPL-Aware-Leaf (RAL) for a Leaf that injects Host
   routes in RPL to manage the reachability of its IPv6 addresses.  In
   contrast, the term RPL-Unaware Leaf (RUL) designates a Leaf that does
   not participate to RPL and cannot inject its Host routes in RPL.  The
   RUL therefore needs a Host-to-Router interface to advertise its IPv6
   addresses to its Router so the Router can inject them the RPL
   network, as detailed in Section 4. 

"

Section 4 being the uplifted location of the requirements on the RUL as you suggest later.

>  I can see in the email archive that going beyond rfc8504 is the intent, but
>  that is not clearly reflected in the document.  I would like to see, at*

You are correct in the intent. Does the change above help?

>  least, an early discussion (don't wait until §7!) of the expectations for a
>  RUL.  Move §7 *before* you start discussing 6LoWPAN ND.

Do you really want that? 
Section 7 heavily uses the description of 6LoWPAN ND provided in section 3, see 7.1.
Moving section 7 before 3 does not compile without heavy forward referencing
But I can move it right after as follows:


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  RPL External Routes and Dataplane Artifacts . . . . . . . . .   7
   4.  6LoWPAN Neighbor Discovery  . . . . . . . . . . . . . . . . .   8
   5.  Requirements on the RPL-Unware Leaf . . . . . . . . . . . . .  11
   6.  Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Updating draft-ietf-roll-efficient-npdao  . . . . . . . . . .  15
   8.  Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . .  15   <SNIP>

Note that due to a point later, text was moved away from the ".Requirements on the RPL-Unware Leaf" to become its own section " RPL External Routes and Dataplane Artifacts " because it has normative text on the router that did not fit there.

>  I believe that describing the expectations may not preclude from assuming
>  that the RUL is, in fact, unaware (of this document and RPL).  For example,
>  instead of saying "a RUL MUST implement [RFC8505]", the text could say
>  something like this:
> 
>    This document is based on the assumption that a RUL supports rfc8505...
>    If the RUL doesn't support rfc8505, then the following behavior is not
>    possible...or the node won't be able to join the LLN at all...or...
>  IOW, instead of specifying how the unaware node should behave, describe
> what
>  is expected and the resulting effect if those expectations are not met.
>  Honestly, given some of the specifics in §7.1, for example "MUST...set the
>  "R" and "T" flags in the EARO", I'm not sure it is possible to describe a
>  general RUL without it having to comply with this document...but maybe
> worth a try.

A leaf is a generic terms that says that the node gets reachability over RPL but does not say how the address is injected and by whom.
For a RAL, the leaf uses RPL. For a RUL there can be many ways, but outside of RPL. RFC 8505 was crafted in preparation of this spec.
All we need now is that the RUL uses RFC 8505 with the settings that RFC 8505 says it should in the circumstances, as reminded in section 3.
So I guess it was improper from our side to duplicate the normative language. I like your term expectation.

"

4.1.  Support of 6LoWPAN ND

   To obtain routing services from a 6LR that implements this
   specification, a RUL is expected to implement [RFC8505] and set the
   "R" and "T" flags in the EARO.  The RUL may provide support of
   [AP-ND] to protect the ownership of its addresses.  The RUL is
   expected not to request routing services from a 6LR that does not
   originate RA messages with a CIO that has the L, P, and E flags all
   set as discussed in Section 3.3.1, unless configured to do so.

   A RUL that may attach to multiple 6LRs is expected to prefer those
   that provide routing services.  The RUL needs to register to all the
   6LRs from which it desires routing services.

   Parallel Address Registrations to several 6LRs should be performed in
   an rapid sequence, using the exact same EARO for the same Address.
   Gaps between the Address Registrations will invalidate some of the
   routes till the Address Registration finally shows on those routes.

   [RFC8505] introduces error Status values in the NA(EARO) which can be
   received synchronously upon an NS(EARO) or asynchronously.  The RUL
   MUST support both cases and MUST refrain from using the address when
   the Status Value indicates a rejection.

"

>  I don't think this specification can support an rfc8504 node trying to join
>  the LLN, right?  What about cases where RPL is not used in a 6LoWPAN?

Same. This is not a LLN problem. It is a problem in a MLSN where proactive routing is used. The router must be told to inject host routes in advance and we need a host-router interface for that. If you like, Classic ND is a form of UNI, and RFC 8505 extends it for proactive operations, whereas RPL is an NNI.

RFC 8504 only mandates classic ND (RFC 8505 missed that train by 1 RFC!!! ); With classic ND, the router does not have a prior knowledge of the host. ND discovers the host reactively. To match that in a MLSN, we'd need to flood the lookup; in a RPL network you'd have to use AODV-RPL. And then implement some route maintenance is the host moves.


> 
>  [Aside: I ran into the "Advocating a generalisation of RFC8505 to non-6lo
>  LANs" thread [1].  Did anything come out of that?  Is there a draft we can
>  Informatively reference?]

Nothing, sadly. There's always a voice saying we do not need it and the discussion dries out. 
There's https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ but it is just about wireless.
There's also https://datatracker.ietf.org/doc/draft-ietf-rift-rift/ which shows how RFC 8505 can be useful in a DC.

Seems to me that 6MAN is more concerned with the interests of the host than of the router. Maybe a consequence of the way we do areas at the IETF. 
If we could get the routing area to flood 6MAN and explains the needs of modern (routed) subnets like overlays, maybe we could progress this work.

> [1]
> https://mailarchive.ietf.org/arch/msg/6lo/mKWgLd5013cTBIOlgPg1op614z0/
> 
> 
> 
> (2) RUL vs. 6LN: does the RUL act as a 6LN, or does the 6LN act like a RUL?

RFC 8505 defines a 6LN functionality and the RUL needs to implement that functionality. 
A 6LN as defined in 6LoWPAN can do things that the RUL does not need to for the sake of this spec, e.g., RFC 6282 compression.
So I need to be very careful every time 6LN is mentioned. Note that useofrplinfo uses 6LR for the border router, which is echoed here. 

> 
>  The text talks about a "6LN that is also a RUL", "a RUL acting as 6LN", a
>  "6LN acting as a RUL"...and §10 specifies the behavior of the "6LN/RUL",
>  which seems to imply that they are the same, or at least have the same
>  functionality...or that one is acting as the other...
 
Yes, I need to scan and clean that up ref by ref. here's a sample:

"
 This specification leverages the Address Registration mechanism defined in
   6LoWPAN ND to enable a RUL acting as a 6LoWPAN Node (6LN) to interface with a
   RPL-Aware Router as a 6LoWPAN Router (6LR) and request that the 6LR injects
   a Host route for the Registered Address in the RPL routing on its behalf."
"
   The unicast packet forwarding operation by the 6LR serving a RUL as described in section 4.1 of <xref target='I-D.ietf-roll-useofrplinfo'/>.
"
"
    A RPL Leaf that implements the 6LN functionality in <xref target='RFC8505'/>
   requires reachability services for an IPv6 address if and only
   if it sets the "R" flag in the NS(EARO) used to register the address to a RPL
"
"
   which means that nodes that are aware of the Host route are also
   aware of the ROVR associated to the Target Address.
"


>  If I understand correctly, the main difference between a RUL and a 6LN (as
>  defined in USEofRPLinfo) is that a 6LN connects to the RPL network through a
>  LoWPAN, but the RUL may not.  But, as pointed out above, it seems that this
>  document (§7) expects the RUL to be a 6LN (support rfc6775/rfc8505...).

Yes. In my update I'm trying to use 6LN in the context of the registration flow, which is the piece that the RUL needs to implement.

> 
>  In most cases, the two terms seem to be used interchangeably, but in others,
>  a clear distinction is made -- for example in this text from §7.2.1:
> 
>    To terminate the IP-in-IP tunnel, the 6LN, as an IPv6 Host, must be able to
>    decapsulate the tunneled packet and either drop the inner packet if it is
>    not the final destination, or pass it to the upper layer for further
>    processing.  Unless it is aware by other means that the RUL can handle
>    IP-in-IP properly, which is not mandated by [RFC8504], the Root terminates
>    the IP-in-IP tunnel at the parent 6LR.  It is thus not necessary for a RUL
>    to support IP-in-IP decapsulation.
> 



When we describe a 6LoWPAN ND flow, it is easier to speak in 6LoWPAN terms, so there are multiple places where we want to conserve that term.

So I added in the terminology:
"
   This specification uses the terms 6LN and 6LR to refer specifically to the
   roles defined in 6LoWPAN ND and does expect other functionality
   such as 6LoWPAN Header Compression <xref target='RFC6282'/> from those nodes.
"



>  As part of clarifying the expectations for the RUL (from above), please also
>  clearly distinguish between the definition of RUL and 6LN...or tell the
>  reader how they are (?) considered the same in this document.  Consistency
>  and clarity throughout the document is important.

It is indeed. I made a long pass.

> 
> (3) Formal Updates
> 
>  Please take a close look at my comments in §4, 5 and 6 about formally
>  Updating other documents.  In short, I don't believe that a formal Update is
>  necessary for all the changes mentioned in those sections.

We have this unresolved item on turnon RFC 8138. Seems very similar from my perspective and I'm concerned that we may have other reviewer asking it back.

But OK, I'll remove the formal update for now.



> 
>  Having said that, I did mention a couple of places where I think rfc6775
>  should (also) be Updated...and others for rfc6550 and rfc8505 that were not
>  listed.
> 
> 
> I expect the resolution of the major issues before moving the document
> forward.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> P.S.: I noticed too late the GitHub location...I could have at least included some
> of the nits as a PR there.  Maybe it would be a good idea to indicate in the draft
> and the datatracker when GitHub is being used. :-)

Very true, do we have a standard for that?

I'll do the nits tomorrow but would like to assess your approval on the above already so I 
Please see https://github.com/roll-wg/roll-unaware-leaves/commit/7b4e13a002ae2da39fd4655b2c2c23c70925ed6c

Many, many thanks Alvaro!

Pascal