Re: [6tisch] Alvaro Retana's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Alvaro Retana <[e-mail]> wrote:
    >> Alvaro Retana wrote:
    >> > The text you propose helps a little, but it makes me uneasy that a
    >> > significant part of the (1!) structure defined in a Standards Track
    >> > document is experimental. Also, the fact that the WG does not in
    >> > general have a clear prescription and that there's work to be done in
    >> > RPL, makes the text sound speculative.
    >>
    >> > It would be more appropriate (again, for a Standards Track document) to
    >> > simply declare the specific use and determination of the different
    >> > priorities as out of scope (vs the subject of future research). You
    >> > might still want to include a separate non-normative section (or an
    >> > appendix) to deal with "future work", but having that discussion while
    >> > the fields are being specified does not seem right to me.
    >>
    >> I understand your point.
    >> I think that it's not much different than BGP4's MED attribute.
    >> I think that 80% of operators still have no idea how to set it :-)

    > Very different!  Setting policies in BGP is not straight forward for
    > some, specially when some of the attributes interact with someone
    > else's policy, which is unknown.  Operators may have a hard time
    > setting the MED, but its behavior is clearly specified.

I claim the same is true for rank priority :-)

    > 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

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




--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-