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) <pthub...@cisco.com> 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:6tisch-boun...@ietf.org]On Behalf Of Qin Wang Sent: mardi 9 juin 2015 13:58 To: Michael Richardson; 6tisch@ietf.org 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 <mcr+i...@sandelman.ca> 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. 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 <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch