IronPort-PHdr: =?us-ascii?q?9a23=3AdntDbxEbxmsjomxHBFt39p1GYnJ96bzpIg4Y7I?=
 =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?=
 =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?=
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] UNaware leaves (3)
Thread-Index: AdVdrJQ325t5EgpaR3OV/cTL4cmzdABGOTaAAAvdJSA=
Date: Fri, 30 Aug 2019 05:49:28 +0000
Deferred-Delivery: Fri, 30 Aug 2019 05:48:30 +0000
Message-ID: <MN2PR11MB35652F69ADC393E445069CF2D8BD0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB356514787CC016CD7A77F99DD8A30@MN2PR11MB3565.namprd11.prod.outlook.com>
 <23546.1567123031@localhost>
In-Reply-To: <23546.1567123031@localhost>
Accept-Language: fr-FR, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: cisco.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 09bb3801-4c69-49f4-17c2-08d72d0de31b
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 05:49:56.3503 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DrsL89N5MGchZHSGXxWxV0BRegXk8MdFVH+XicHK0k/YI2B8oA5P9SDz44pvzj7Ouy8skAhYHYdiPo/Mprm5AA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4319
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Ou9J02MY4alUALGqcpN4_IKsumA>
Subject: Re: [Roll] UNaware leaves (3)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>,
 <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>,
 <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Aug 2019 05:50:19 -0000

Hello Michael

>     > Possible, you're welcome to propose text and chat with Minimal co
>     > authors on the 6TiSCH ML : ).
>=20
> 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? Shoul=
dn't that be a 6TiSCH-aware RUL draft? Like a RFC 8504 but for a 6TiSCH nod=
e?

>=20
>     > 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 minima=
l
>     > provisions L2 and now it would be provisioning L3.
>=20
>     > 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.
>=20
> 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 hav=
e
> 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.

>=20
>     >> 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.
>=20
>     > 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.
>=20
> 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 th=
e
> status quo, right?
>=20
> Oh, I think I'm confused on terms.  I'll have to come back and read it ag=
ain.>=20

The term 6LH was not defined, maybe that's sad. If it did it could mean for=
 some people RFC 6775.=20
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 "6=
LH" would mean.

>     >> Not putting it in means the adjacent 6LR has to IPIP it, address i=
t to the
> RPL
>     >> Root.
>     >> If we put it in, then in the storing case, no further IPIP is need=
ed!!
>     >>
>=20
>     > Agreed. But that means a change in the RUL s. RFC 8505. That's a MA=
Y at
> best.
>=20
> 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 supp=
ort. Can you please review the way I worded it all?

All the best;

Pascal