Re: [Roll] UNaware leaves (3)

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 29 August 2019 23:57 UTC

From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <MN2PR11MB356514787CC016CD7A77F99DD8A30@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB356514787CC016CD7A77F99DD8A30@MN2PR11MB3565.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 29 Aug 2019 19:57:11 -0400
Message-ID: <23546.1567123031@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/hpPljqC8uaVsfFnQSlA32r7zVbw>
Subject: Re: [Roll] UNaware leaves (3)
Precedence: list

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    >> 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 : ).

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.

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

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

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Attachment: signature.asc

Re: [Roll] UNaware leaves (3) Pascal Thubert (pthubert)
Re: [Roll] UNaware leaves (3) Michael Richardson
Re: [Roll] UNaware leaves (3) Pascal Thubert (pthubert)

Re: [Roll] UNaware leaves (3)

Attachment: signature.asc