Subject: [6tisch] 6top and neighbour list

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jun 2015 13:17:41 -0400

1) I was reading draft-ietf-6tisch-6top-interface-03.
2) It seems that we have yet to adopt draft-wang-6tisch-6top-sublayer-01,
   it has expired, but draft-ietf-6tisch-6top-interface-03 still
   references that document.

I was looking for the description of the neighbour list that the PCE
would need to know in order to construct the desired tracks.
(The indenting of the YANG model is very inconsistent; I could pull the
XML off of bitbucket, and run it through an indenter if the authors wished)

I think that the information that I want about neighbours is:
  list NeighborList { ... }.

I think that if we have received an RPL DIO from that neighbour that
we ought to show it's rank in that Neighborlist. I think that we ought
to also indicate if that neighbour is *the* parent, and or if it is
potential parent.

We might want to go further and say WHY the indicated parent was actually
chosen: but I think that this might be difficult to code in a vendor
independant way.  I propose that we still do this, but allow the code
to be vendor dependant.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michel Veillette <[email-masked]>
Date: Tue, 9 Jun 2015 20:22:47 +0000

Hi Michael

You will find in attachment the 6TiSCH YANG modules with a more consistent indentation and the missing headers for proper validation using http://www.netconfcentral.com/run_yangdump . 

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]
www.trilliantinc.com   

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 9 juin 2015 13:18
To: [email-masked]
Subject: [6tisch] 6top and neighbour list

I was looking for the description of the neighbour list that the PCE would need to know in order to construct the desired tracks.
(The indenting of the YANG model is very inconsistent; I could pull the XML off of bitbucket, and run it through an indenter if the authors wished)

I think that if we have received an RPL DIO from that neighbour that we ought to show it's rank in that Neighborlist. I think that we ought to also indicate if that neighbour is *the* parent, and or if it is potential parent.

We might want to go further and say WHY the indicated parent was actually
chosen: but I think that this might be difficult to code in a vendor independant way.  I propose that we still do this, but allow the code to be vendor dependant.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Qin Wang <[email-masked]>
Date: Tue, 9 Jun 2015 20:45:44 +0000 (UTC)

Hi Michael and Michel,
The attached file is the Yang model, which has been embedded into 6top interface draft.
ThanksQin 

     On Wednesday, June 10, 2015 4:23 AM, Michel Veillette <[email-masked]> wrote:

 Hi Michael

Michel Veillette

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 9 juin 2015 13:18
To: [email-masked]
Subject: [6tisch] 6top and neighbour list

_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Michel Veillette <[email-masked]>
Date: Tue, 9 Jun 2015 20:57:24 +0000

Hi Qin

The file provided return some errors and warnings.
Is it an issue with the file or the validation program?
Validation results for ietf-6top.yang

*** Generated by yangdump-pro 14.08-6.2
*** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved.
*** Copyright (c) 2012-2015, YumaWorks, Inc., All Rights Reserved.

Error: Unexpected token 'greater than' in XPath expression '../EnforcePolicy <> DISABLE ./'
ietf-6top.yang:256.36: error(245): wrong token type

Warning: top-level NP container 'SecurityAttributes' is mandatory
ietf-6top.yang:1025.7: warning(1048): top-level object is mandatory

*** /home/andy/swdev/ncorg/ncorg/ncorg/workdir/ietf-6top.yang
*** 1 Errors, 1 Warnings

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>
www.trilliantinc.com<http://www.trilliantinc.com/>

From: Qin Wang [mailto:[email-masked]]
Sent: 9 juin 2015 16:46
To: Michel Veillette; Michael Richardson; [email-masked]
Subject: Re: [6tisch] 6top and neighbour list

Hi Michael and Michel,

Thanks
Qin

On Wednesday, June 10, 2015 4:23 AM, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:

Hi Michael

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>
www.trilliantinc.com<http://www.trilliantinc.com>

-----Original Message-----
From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Michael Richardson
Sent: 9 juin 2015 13:18
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] 6top and neighbour list

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works  -= IPv6 IoT consulting =-

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Qin Wang <[email-masked]>
Date: Tue, 9 Jun 2015 20:58:18 +0000 (UTC)

Hi Michael,
NeighborList contains the Link information, and the information about Parent is contained in TimeSource for saving space. Make sense?
ThanksQin   

     On Wednesday, June 10, 2015 1:33 AM, Michael Richardson <[email-masked]> wrote:

---

From: Qin Wang <[email-masked]>
Date: Tue, 9 Jun 2015 21:06:49 +0000 (UTC)

Hi Michel,
Here is the command line we use:Python33\pythonpyang-1.4.1\bin\pyang D:\ietf-6top.yang

There is no error or warning come out.  Is it because of different compiler?
ThanksQin

     On Wednesday, June 10, 2015 4:57 AM, Michel Veillette <[email-masked]> wrote:

 #yiv0196860943 #yiv0196860943 -- _filtered #yiv0196860943 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv0196860943 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0196860943 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0196860943 {font-family:Georgia;panose-1:2 4 5 2 5 4 5 2 3 3;}#yiv0196860943 #yiv0196860943 p.yiv0196860943MsoNormal, #yiv0196860943 li.yiv0196860943MsoNormal, #yiv0196860943 div.yiv0196860943MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0196860943 h2 {margin-right:0in;margin-left:0in;font-size:18.0pt;}#yiv0196860943 a:link, #yiv0196860943 span.yiv0196860943MsoHyperlink {color:blue;text-decoration:underline;}#yiv0196860943 a:visited, #yiv0196860943 span.yiv0196860943MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv0196860943 pre {margin:0in;margin-bottom:.0001pt;font-size:10.0pt;}#yiv0196860943 span.yiv0196860943EmailStyle17 {color:#1F497D;}#yiv0196860943 span.yiv0196860943Heading2Char {font-weight:bold;}#yiv0196860943 span.yiv0196860943HTMLPreformattedChar {}#yiv0196860943 .yiv0196860943MsoChpDefault {font-size:10.0pt;} _filtered #yiv0196860943 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0196860943 div.yiv0196860943WordSection1 {}#yiv0196860943 Hi Qin    The file provided return some errors and warnings. Is it an issue with the file or the validation program? Validation results for ietf-6top.yang    *** Generated by yangdump-pro 14.08-6.2 *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. *** Copyright (c) 2012-2015, YumaWorks, Inc., All Rights Reserved.    Error: Unexpected token 'greater than' in XPath expression '../EnforcePolicy <> DISABLE ./' ietf-6top.yang:256.36: error(245): wrong token type    Warning: top-level NP container 'SecurityAttributes' is mandatory ietf-6top.yang:1025.7: warning(1048): top-level object is mandatory    *** /home/andy/swdev/ncorg/ncorg/ncorg/workdir/ietf-6top.yang *** 1 Errors, 1 Warnings       
|   | Michel Veillette
System Architecture Director Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked] www.trilliantinc.com     |

      From: Qin Wang [mailto:[email-masked]]
Sent: 9 juin 2015 16:46
To: Michel Veillette; Michael Richardson; [email-masked]
Subject: Re: [6tisch] 6top and neighbour list    Hi Michael and Michel,    The attached file is the Yang model, which has been embedded into 6top interface draft.    Thanks Qin       On Wednesday, June 10, 2015 4:23 AM, Michel Veillette <[email-masked]> wrote:    Hi Michael

You will find in attachment the 6TiSCH YANG modules with a more consistent indentation and the missing headers for proper validation usinghttp://www.netconfcentral.com/run_yangdump. 

Michel Veillette

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jun 2015 09:07:01 -0400

Qin, your file is the 2015-03-04 version, while Michel forwarded the
2015-01-01 revision.

I looked into the bitbucket for the ietf-6top.yang file, and not seeing
is split out, I'll send you a pull request via bitbucket.
I guess you live on windows, so I can't assume you have any useful tools,
but maybe you can format on linux or mac.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jun 2015 09:12:18 -0400

Qin Wang <[email-masked]> wrote:
    > NeighborList contains the Link information, and the information about
    > Parent is contained in TimeSource for saving space. Make sense?

I don't see how container TimeSource will give me a list of parents.

      leaf NodeAddress {
         type nodeaddresstype;
         description
         "Specifies the address of selected time source neighbors.";
      }

I think that the plural in the description, "neighbors" suggests that there
is a list, but I don't see that would be the case here.  I see how this
affects the source of ASN, but not how it provides a list of parents.

It's not obvious to me that the RPL parent is by definition the best
source for the ASN; and the policy definition here would suggest that
there are other criteria.

I suggest changing:
      "specify the timesource selection policy and some relative
      statistics. ";

to:
      "specify the timesource (ASN) selection policy and some relative
      statistics. ";

just so that it shows up on when searching for ASN.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Jun 2015 16:45:09 +0000

Hello Qin:

A node has a list of RPL parents per RPL instance. But that’s a RPL problem and we probably need a RPL data model to be done at ROLL.
OTOH, there is one (or more?) RPL instance that is used for 6TiSCH timing. I think all we need in 6top is an information of which RPL instance(s) is (are) used for timing and hten the admin can read the RPL info about that instance in the RPL data model.

Does that make sense?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: mardi 9 juin 2015 13:58
To: Michael Richardson; [email-masked]
Subject: Re: [6tisch] 6top and neighbour list

Hi Michael,

Thanks
Qin

On Wednesday, June 10, 2015 1:33 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
-= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jun 2015 13:38:32 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > A node has a list of RPL parents per RPL instance. But that’s a RPL
    > problem and we probably need a RPL data model to be done at ROLL.

yes, so I'm considering whether the RPL data model can take this from the
6tisch model, because we badly need a standard way to get the mesh topology
out, and I think 6tisch needs all of that information anyway.

    > OTOH, there is one (or more?) RPL instance that is used for 6TiSCH
    > timing. I think all we need in 6top is an information of which RPL
    > instance(s) is (are) used for timing and hten the admin can read the
    > RPL info about that instance in the RPL data model.

AFAIK, the RPL instance isn't just used for (ASN) timing, it's also used for
communication with a PCE, for best-effort traffic, possibly for join traffic,
and I would have assumed that the DIO multicasts are how one discovers
adjacent nodes for the NeighbourList that the PCE needs.

As far as as I can see, all we need to make NeighbourList able to provide
the RPL level neighbour information is the DAG Rank of each neighbour.
It seems to me that if we are able to pick an RPL parent, that we would also
know the signal strength that the peer hears us.

---

From: Qin Wang <[email-masked]>
Date: Wed, 10 Jun 2015 19:19:29 +0000 (UTC)

Hi Pascal,
What you say is that the RPL parents list should be in RPL data model (YANG model), and 6top data model only includes the parent used as time source. Right? It really makes sense to me.
ThanksQin

     On Thursday, June 11, 2015 12:45 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

 #yiv8604257565 #yiv8604257565 -- _filtered #yiv8604257565 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv8604257565 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv8604257565 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv8604257565 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv8604257565 #yiv8604257565 p.yiv8604257565MsoNormal, #yiv8604257565 li.yiv8604257565MsoNormal, #yiv8604257565 div.yiv8604257565MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8604257565 a:link, #yiv8604257565 span.yiv8604257565MsoHyperlink {color:blue;text-decoration:underline;}#yiv8604257565 a:visited, #yiv8604257565 span.yiv8604257565MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv8604257565 span.yiv8604257565EmailStyle17 {color:#1F497D;}#yiv8604257565 .yiv8604257565MsoChpDefault {font-size:10.0pt;} _filtered #yiv8604257565 {margin:70.85pt 70.85pt 70.85pt 70.85pt;}#yiv8604257565 div.yiv8604257565WordSection1 {}#yiv8604257565 Hello Qin:    A node has a list of RPL parents per RPL instance. But that’s a RPL problem and we probably need a RPL data model to be done at ROLL. OTOH, there is one (or more?) RPL instance that is used for 6TiSCH timing. I think all we need in 6top is an information of which RPL instance(s) is (are) used for timing and hten the admin can read the RPL info about that instance in the RPL data model.    Does that make sense?    Pascal    From: 6tisch [mailto:[email-masked]]On Behalf Of Qin Wang
Sent: mardi 9 juin 2015 13:58
To: Michael Richardson; [email-masked]
Subject: Re: [6tisch] 6top and neighbour list    Hi Michael,    NeighborList contains the Link information, and the information about Parent is contained in TimeSource for saving space. Make sense?    Thanks Qin          On Wednesday, June 10, 2015 1:33 AM, Michael Richardson <[email-masked]> wrote:    
1) I was reading draft-ietf-6tisch-6top-interface-03.
2) It seems that we have yet to adopt draft-wang-6tisch-6top-sublayer-01,
  it has expired, but draft-ietf-6tisch-6top-interface-03 still
  references that document.

---

From: Qin Wang <[email-masked]>
Date: Wed, 10 Jun 2015 20:04:22 +0000 (UTC)

Hi Michael,
Regarding to including DAG rank into 6top NeighborList, I think,  besides RPL, there may be other routing protocols working on top of 6top in the future. Thus, it could be better to decouple 6top sublayer and upper layer protocol like RPL.
What do you think? 
What other people think?
ThanksQin   

     On Thursday, June 11, 2015 1:38 AM, Michael Richardson <[email-masked]> wrote:

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > A node has a list of RPL parents per RPL instance. But that’s a RPL
    > problem and we probably need a RPL data model to be done at ROLL.

    > OTOH, there is one (or more?) RPL instance that is used for 6TiSCH
    > timing. I think all we need in 6top is an information of which RPL
    > instance(s) is (are) used for timing and hten the admin can read the
    > RPL info about that instance in the RPL data model.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Jun 2015 20:14:12 +0000

That is exactly right, Qin.

Cheers,

Pascal

From: Qin Wang [mailto:[email-masked]]
Sent: mercredi 10 juin 2015 12:19
To: Pascal Thubert (pthubert); Michael Richardson; [email-masked]
Subject: Re: [6tisch] 6top and neighbour list

Hi Pascal,

Thanks
Qin

On Thursday, June 11, 2015 12:45 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Qin:

Does that make sense?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: mardi 9 juin 2015 13:58
To: Michael Richardson; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] 6top and neighbour list

Hi Michael,

Thanks
Qin

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Jun 2015 20:15:31 +0000

Same here.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: mercredi 10 juin 2015 13:04
To: Michael Richardson; [email-masked]
Subject: Re: [6tisch] 6top and neighbour list

Hi Michael,

What do you think?

What other people think?

Thanks
Qin

On Thursday, June 11, 2015 1:38 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Jun 2015 20:21:00 +0000

Hi Michael
>     > RPL info about that instance in the RPL data model.
There may be multiple instances, and one at least is used for ensuring a loopless structure for time sync. 6top exposes its rank in that instance in the beacons, so that's something we can expose in our data model as well since we understand its abstract semantics. But apart from that rank and the instance ID that is used for clock sync, all the RPL info should be coming from the RPL data model, else it is duplicated which looks like a bad idea as well as a layer violation.

Note that the clock sync instance is not necessarily the one used for reaching out to the PCE. It is not necessarily grounded. There can be scattered GPS-based time sources that form small dodags around them, and time is distributed independently of the DAGs used for IP traffic and PCE reachability.

Cheers,

Pascal

---

From: Qin Wang <[email-masked]>
Date: Wed, 10 Jun 2015 20:21:12 +0000 (UTC)

Hi Michael,
According to my understanding, there are two levels of synchronization in 6TiSCH network, i.e. (1) all nodes work on same ASN, which is presented in EB; (2) the node corrects its clock periodically by communication with its timesource. The description in TimeSource is about (2).
make sense?
ThanksQin 

     On Wednesday, June 10, 2015 9:12 PM, Michael Richardson <[email-masked]> wrote:

Qin Wang <[email-masked]> wrote:
    > NeighborList contains the Link information, and the information about
    > Parent is contained in TimeSource for saving space. Make sense?

      leaf NodeAddress {
        type nodeaddresstype;
        description

I suggest changing:

to:

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 10 Jun 2015 20:26:29 +0000

I agree,  we are  using RPL now, but we may use other protocols tomorrow.
Better we leave it opened.
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, June 10, 2015 10:16 PM
To: Qin Wang; Michael Richardson; [email-masked]
Subject: Re: [6tisch] 6top and neighbour list

Same here.

Cheers,

Pascal

Hi Michael,

What do you think?

What other people think?

Thanks
Qin

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jun 2015 18:19:59 -0400

> There may be multiple instances, and one at least is used for ensuring
    > a loopless structure for time sync. 6top exposes its rank in that
    > instance in the beacons, so that's something we can expose in our data
    > model as well since we understand its abstract semantics. But apart
    > from that rank and the instance ID that is used for clock sync, all the
    > RPL info should be coming from the RPL data model, else it is
    > duplicated which looks like a bad idea as well as a layer violation.

okay, fair enough.
I will consider spinning up a YANG model for RPL info.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Jun 2015 23:19:15 +0000

Fantastic Michael!

I'm willing to give a hand after August if that's useful?

Pascal

> Le 10 juin 2015 à 18:20, Michael Richardson <[email-masked]> a écrit :
> 
>