Subject: Re: [Roll] UNaware leaves (3)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Aug 2019 15:23:28 +0000

Hello Michael:

Continuing on your very helpful comments:

> 
> I suggest that all text like:
>    o  Upon each consecutive registration, the 6LN MUST increase the TID
>       field.
> 
> read like:
>    o  As described in RFCXXXX section FOOBAR, upon each consecutive
>       registration, the 6LN MUST increase the TID field.
> 
> because I think that the point is that there are no changes, right?
> Except for the InstanceID.
> 

Done

> Should this specification extend 6tisch-minimal (CoJP) to include a way to set
> the InstanceID?

Possible, you're welcome to propose text and chat with Minimal co authors on the 6TiSCH ML : ).
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. 

> 
>    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.

> 
>    o  the 6LN is not expected to be aware of RPL so it is not expected
>       to produce RPL artifacts in the data packets.
> 
> certainly, it shouldn't do IPIP or RH3.
> It would be damn useful if it would put the RPI in.

MMod/Added text

"
  Even without support for RPL, a RUL may be aware of opaque values to
   be provided to the routing protocol.  If the RUL has a knowledge of
   the RPL Instance the packet should be injected into, then it SHOULD
   set the Opaque field in the EARO to the RPLInstanceID, else it MUST
   leave the Opaque field to zero.  In any fashion the 6LN MUST set the
   "I" field to zero to indicate that topological information to be
   passed to a routing process as specified in [RFC8505] section 5.1.

   A RUL is not expected to produce RPL artifacts in the data packets,
   but it MAY do so. for instance, if the RUL has a minimal awareness
   of the RPL Instance and can build an RPI.  A RUL that places an RPI
   in a data packet MUST indicate the RPLInstanceID that corresponds to
   the RPL Instance the packet should be injected into.  All the flags
   and the Rank field are set to zero as specified by section 11.2 of
   [RFC6550].
"

> 
> 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.

> In non-storing the root still has to add the RH3, if it's going back down.
> If it's window smash alarm, it is probably going to leave the LLN anyway, so
> no big deal.

Agreed
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
 More later : ) Committed so far in github.

Take care;
Pascal

---

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Aug 2019 19:57:11 -0400

> authors on the 6TiSCH ML : ).

Actually, we created a "Constrained Join Protocol Parameters Registry"
parameters.  This document can allocate a value from it :-)

    > 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.

    > 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.

    > 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.

--
]               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: Fri, 30 Aug 2019 05:49:28 +0000

Hello Michael

> 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?

> enough RAM/Flash/etc. to keep track of the different keys, and also

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

> 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.

> 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