Re: [Roll] UNaware leaves (3)

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

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 <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
 More later : ) Committed so far in github.

Take care;
Pascal