Re: [Roll] UNaware leaves (3)

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

Hello Michael

>     > Possible, you're welcome to propose text and chat with Minimal co
>     > authors on the 6TiSCH ML : ).
> 
> Actually, we created a "Constrained Join Protocol Parameters Registry"
> parameters.  This document can allocate a value from it :-)

Works for me. So we imagine a RUL that does 6TiSCH minus RPL correct? Shouldn't that be a 6TiSCH-aware RUL draft? Like a RFC 8504 but for a 6TiSCH node?

> 
>     > Pls keep in mind that over a same L2 network a node may participate to
>     > more than one instance, so a list would be needed. Also that minimal
>     > provisions L2 and now it would be provisioning L3.
> 
>     > There's a limit to what we want to provision with AAA
>     > vs. management. The cool thing with management is that it is common to
>     > several security mechanisms.
> 
> I don't think we need a list on CoJP.
> A RAL that participated in multiple L2 networks would probably need to do
> multiple joins to get the network keys for each, and it would have to have
> enough RAM/Flash/etc. to keep track of the different keys, and also
> instanceID.

But we could have multiple instances in one network. Would you want to use one key per instance? Maybe, yes.

> 
>     >> 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.
> 
>     > Anything connected to a 6LoWPAN network is a 6LN. A 6LN is a Node, that
>     > is a host or a router.  A 6LR is a 6LN with additional capabilities. We
>     > do not have a term for a 6LoWPAN plain host (like a 6LH) but as far as
>     > RPL is concerned a RUL is good enough.
> 
> I think that a 6LoWPAN plain host (I like 6LH), is a RPL-unware-leaf (RUL) We
> have just created the RPL-Aware-Leaf (RAL), and we'd like it to become the
> status quo, right?
> 
> Oh, I think I'm confused on terms.  I'll have to come back and read it again.> 

The term 6LH was not defined, maybe that's sad. If it did it could mean for some people RFC 6775. 
A RUL MUST support RFC 8505 so we get the TID and the R flag. It also means a certain setting of the I and opaque fields. So it is a subset of what "6LH" would mean.

>     >> 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!!
>     >>
> 
>     > Agreed. But that means a change in the RUL s. RFC 8505. That's a MAY at
> best.
> 
> I think that it's the killer-app part of this work.

Yes I hope people who implement RULs support that. That's part of IPv6 support. Can you please review the way I worded it all?

All the best;

Pascal