[Roll] unware leaves --- terminology and expectations

[Michael Richardson <[e-mail]>]

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