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 protected]> 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 <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
