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

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

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) <[e-mail]> a écrit :
> 
> 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 <[e-mail]> On Behalf Of Michael Richardson
> Sent: jeudi 12 septembre 2019 20:57
> To: [e-mail]
> 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.  
> 
> 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
> 
> <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:
>   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"
> 
> <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:
> 
>   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?
> 
> <pt> This was fixed in https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-04 </pt>
> 
> 
> 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?
> 
> <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:
> 
> 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.
> 
> <pt> Argl, no; we took useofrplinfo off the RFC editor queue.Let's do what makes it correct when RUM ships </pt>
> 
> 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.
> 
> <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>
> 
> 3) we could significantly change useofrplinfo, explaining what supporting RULs would
>   mean, then recommending against supporting them in LLNs.
> 
> <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>
> 
> 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.
> 
> 
> <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
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll