Subject: [Roll] unware leaves --- terminology and expectations

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Sep 2019 19:57:14 +0100

Some offlist emails among the authors had led me to wonder if I know what I'm
talking about.  This was brought about by the potential impact on
useofrplinfo document.  

The RPL unware document has the following definitions.

   The term RPL-Unaware Leaf (RUL) is used to refer to a node that uses
   a RPL router (without necessarily knowing it) as 6LR and depends on
   that router to obtain reachability for its addresses inside the RPL
   domain.  On the contrary, the term RPL-Aware Node (RAN) is used to
   refer to a RAL or a RPL router that participates to RPL and
   advertises its addresses of prefixes by itself.

   Other terms in use in LLNs are found in Terminology for Constrained-
   Node Networks [RFC7228].

So we have two categories of nodes:
   1) RUL --- aka classic host
   2) RAN --- modern host, or 6LR

The sentence:
   the term RPL-Aware Node (RAN) is used to
   refer to a RAL or a RPL router that participates to RPL and
   advertises its addresses of prefixes by itself.

is perhaps imprecise for me.  Does a RAL
   "participates to RPL and
   advertises its addresses of prefixes by itself"

I think the answer is mostly no. It doesn't speak RPL. It is aware
that it's among RPL, it just doesn't speak it.  It uses ND with EARO with
TIDs.  I think that what I'm saying should be unsurprising.

I'm just saying this again, because I'm not sure everyone is on the same page 
here. 

It occurs to me that our document has the wrong title, and
that the filename is also slightly misleading.  It's that want
make a class of unaware leaves, it's that we want leaves that are
unware of RPL control plane messages, but are aware of PRL data
plane messages.

Section 6 says:

   This document provides RPL routing for a 6LN acting as a plain host
   and not aware of RPL.  Still, a minimal RPL-independent functionality
   is expected from the 6LN in order to operate properly as a RLU; in
   particular:

it looks like "RLU" is a typo for "RUL", but really, shouldn't it be speaking
about RALs?

I think that we are creating a new class of leaf, the *RAL*, with a "pure"
RFC8505 host that speaks only 6lowpan being the RUL.

Do you agree?

Pascal has written some text to update useofrplinfo, and it wasn't what I
imagined.  It updates in a different place.  We have basically three choices:

1) publish useofrplinfo more or less as-is.  It explains how to deal with
   having RULs in the LLN in sufficient detail such that hopefully nobody
   will want to do that.
   Unaware leaves would then Updates useofrplinfo, obsoleting the sections
   that deal with RULs.
   
2) we could decide that having RULs in the LLN is dumb, and one should only
   have RALs, and that removes ~6, possibly 8 cases from useofrplinfo.
   We'd just delete text, which is way easier than writing new text.
   
3) we could significantly change useofrplinfo, explaining what supporting RULs would
   mean, then recommending against supporting them in LLNs.

which is best depends upon what kind of "installed base" of devices in the
production queue we think there is.   I prefer (1) or (2) above.

This is a major part of the discussion I want to have at the virtual interim.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Sep 2019 12:53:34 +0000

Hello Michael

The RUL draft:
- specifies how a RUL uses RFC 8505 without the need to understand anything about RPL
- does not care about RALs
- defines the operations that can be done by a RPL router to provide connectivity to a RUL.

To be a good citizen of the RUL draft, a RUL must support:

from  	RFC 8200		RFC 8505	RFC 6550 	

	Consumed   SRH	FULL		Nothing	
        	Ignore HbH              	

My current definitions:

- a RPL leaf is a 6LN that is attached to a RPL router, and reachable across a RPL network, though it may or may not know about it. A leaf must not show as a RPL router to other RPL nodes. A node that understands the RPL protocol but cannot do critical aspects of the configuration, e.g., it doesn't support the MOP or does not know the RPLinstanceID, can only attach as a leaf.

- a RUL is a RPL leaf that does not support anything from RFC 6550. It does not process ICMPv6 of type 155 (RPL Control Message) in any fashion, as opposed to a RAN that supports that ICMP. This is what I mean with the term awareness. A RUL may be configured with a RPLInstanceID but that's an U-8 opaque, it has no clue what that opaque represents, just like a given layer does not understand information that belongs to another layer but can transport it opaquely.

- a RAL is a RAN that is also a leaf, so it cannot show as a router. It does not send DIOs but to poison (infinite Rank). It sends unicast and multicast DAOs to advertise its ULA and GUA address(es). It receives DIOs and multicast DAOs because these are for link local use.

What is not so clear is whether the expectations that the RUL draft has on RULs are part of the definition of being a RUL or if these are things that a RUL must do on top of being a RUL to be compatible with the RUL draft. In the former acceptation it would mean that the RUL draft defines the concept of RUL. If it does then the useofrplinfo draft must have a normative ref on the RUL draft. In the latter acceptation it means that the support of the RUL draft must be on the box of the RUL device as one of the things it can do on top of being a 6LN. I wrote the text with the latter in mind so we could ship useofrplinfo with no reference on RUL. Now, if we agree to defer useofrplinfo to make a normative ref of the RUL draft, then the expectations in the table above can be made part of the definition of being a RUL. A RUL would become by definition a node that supports and does everything the RUL draft says it should. That would make life a lot easier.

More below:

-----Original Message-----
From: Roll <[email-masked]> On Behalf Of Michael Richardson
Sent: jeudi 12 septembre 2019 20:57
To: [email-masked]
Subject: [Roll] unware leaves --- terminology and expectations

Some offlist emails among the authors had led me to wonder if I know what I'm talking about.  This was brought about by the potential impact on useofrplinfo document.  

<pt> not really, the R means it is connected to a RPL network so a 6LN becomes a Rxx when deployed in a RPL network. And the A vs. U is about speaking RFC 6550. A RAL limits what it does with RPL to non-routing operations. </pt>

The sentence:

<pt> yes in my book </pt>

I think the answer is mostly no. It doesn't speak RPL. It is aware that it's among RPL, it just doesn't speak it.  It uses ND with EARO with TIDs.  I think that what I'm saying should be unsurprising.

<pt> I guess there's not right and wrong. It a matter of defining the words we use, a good thing to do early in any process. Changing the definitions I used for so far for the RUL draft may have heavy implication at this stage </pt>

I'm just saying this again, because I'm not sure everyone is on the same page here. 

It occurs to me that our document has the wrong title, and that the filename is also slightly misleading.  It's that want make a class of unaware leaves, it's that we want leaves that are unware of RPL control plane messages, but are aware of PRL data plane messages.

Section 6 says:

it looks like "RLU" is a typo for "RUL", but really, shouldn't it be speaking about RALs?

<pt> This was fixed in https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-04 </pt>

Do you agree?

<pt> 
Not per the above. I think we have the same categories in mind but the names are shifted by one. The thing that does not speak RFC 8505 for me is a plain host. A plain host leaf is reachable when RPL advertises prefix routes. This is part of the more general external route, when you redistribute something into RPL. For those we need to encaps to the parent 6LR; this is the core of my changes in useofrplinfo, because that case was missing. At some point I thought that we could do that for also for RULs, and then I reread useofrplinfo and thought gain. Useofrplinfo is correct that there are many cases when we do not need to encap to the 6LR, so let's preserve useofrplinfo as is and keep the benefit of all the review process.
</pt>

Pascal has written some text to update useofrplinfo, and it wasn't what I imagined.  It updates in a different place.  We have basically three choices:

<pt> Argl, no; we took useofrplinfo off the RFC editor queue.Let's do what makes it correct when RUM ships </pt>

<pt> the difference you're talking about is about encapsulating to the 6LR, correct? The cases are that packets internet to RUL are encapsulated whereas packets sourced at the root are not. If you look at it that has to do with RFC 8200 not RFC 8505. If we pick the definition of RUL as being the thing that supports all the RUL draft then RFC 8200 is in there, and the root to RUL stays the same. I agree that implementing a node that does RFC 8505 as per the RUL draft and does not support the basics of a host per RFC 8200 is not worth considering. </pt>

<pt> I do not see the need to do that. The text of root to RUL in usefrplinfo is compatible with rul-04, at least I made every effort in that direction.
</pt>

<pt>I favor inserting the snippet I have for routes that are external (expect to well behaved RULs) which tunnel to the parent 6LR. For well behaved RULs the text would stand as is. 

Please let me know what I missed?

About the interim: I'd like to agree on the RUL definition, whether we delay shipping useofrplinfo off the RPL editor queue because it has a normative reference on RUL. I think we should.
</pt>

All the best

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Sep 2019 18:57:50 +0000

Yes we must go to the list 😊

I thought this chat all went there. If not please cc the list now if you agree.

The RAL understands RPL but is not acting as a router. So it knows the artifacts from it’s knowledge of rfc 6550. Though Like a RUL it can only see them as a host, meaning that the RH is consumed and the HbH is ignored.

Should we define that RAL and RUL always support RFCs 8505 and 8200 ? 

Pascal

> Le 13 sept. 2019 à 14:54, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Hello Michael
> 
> The RUL draft:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Sep 2019 13:20:37 -0400

> - defines the operations that can be done by a RPL router to provide

I think that we are trying to accomplish the same thing, but I think that we
are disagreeing about how to name things.

I think that if a device supports RFC8505, and is willing to ignore RPI, RH3
*and* IPIP headers, then it's an RAL, and it's an RFCxxxx that we want to
define what it means to be an RAL.

I think that an RUL implements RFC6775(only), and RFC2460(only).
We have to do things in useofrplinfo involving removing IPIP headers at the
previous 6LR in order to accomodate them.

If we knew that all leafs were RALs, then we would not need to do much
to support them.

** RALs do not speak RPL control plane, but tolerate RPL data plane **

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 16 Sep 2019 18:36:02 +0000

Yes we are trying to accomplish the same thing.
Note that the RPL data plane the the RxL supports is just following RFC 8200. That does not mean any RPL awareness. So I really do not see why it would have RPL aware in its name...

Regards,

Pascal

> Le 16 sept. 2019 à 19:21, Michael Richardson <[email-masked]> a écrit :
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Sep 2019 14:24:38 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Note that the RPL data plane the the RxL supports is just following RFC
    > 8200. That does not mean any RPL awareness. So I really do not see why
    > it would have RPL aware in its name...

Neither RFC8200 nor RFC8504 mandate that a node must be able to handle
IP{dst=me}headers,IP{dst=me}.

If we can't handle that in the leaf, then I think we gain nothing by writing this document.

Further, if an RPL-aware-leaf can insert RPI on outgoing packets, then that
also saves inserting an IPIP header at the first 6LR.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Sep 2019 20:04:49 +0000

Actually the draft as it stands does a lot to show that IP in IP to what I call a RUL does not need to happen.

 The change I’m asking is that if IP in IP is used then it goes to the parent. This is why non storing must always be used.

So the thing I call a RUL stays within rfc 8200 / 8504 mandates.

I see value in your RAL that inserts the RPI. I did not have a taxonomy for a node that does not send it’s DAOs but still inserts RPIs. Happy to add this guy in out bestiary.

Regards,

Pascal

> Le 17 sept. 2019 à 20:25, Michael Richardson <[email-masked]> a écrit :
> 
>