On February 23, 2020 at 4:23:42 PM, Michael Richardson wrote: > Alvaro Retana wrote: .... > > Interpreting and acting on the values is exactly the piece I have a > > problem with. The rank priority is an "indication of how willing this > > 6LR is to serve as an RPL [RFC6550] parent". How is the receiver > > expected to that the value into account for parent selection? That > > part is not specified. The same for the pan priority; the text says > > that a receiver "MAY consider this value when looking for an eligible > > parent device", ok...how? > > The intention is not to change the parent selection algorithm at all. > The intention is to help the *PAN* selection algorithm by giving a hint as to > what kind of parents are available on a particular PAN. > > Once the PAN has been joined (which may involve an additional onboard process > to get a 2-byte address and local keys, or might just mean pulling some keys > out of NVRAM, and synchrozing to the schedule), then the node can receive > DIOs (possibly from many other possible parents), and run the normal parent > selection algorithm. > But, it can't see multiple PANs. > > https://datatracker.ietf.org/meeting/101/materials/slides-101-6tisch-ietf101-6tisch-i-draft-richardson-6tisch-enrollment-enhanced-beacon-00
The slides help a lot and now I understand! :-) It would be great if the text reflected more what the slides say, but given the background, I think that what you added in -14 is good enough...and in any case it doesn't justifies keeping my DISCUSS, so I'm clearing. Thanks!! Alvaro. _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
