Michael, See inline.
Mališa On Fri, Jul 27, 2018 at 12:04 AM Michael Richardson <[email protected]> wrote: > > (Listening to the youtube recording) > > Tero clarified the slide 8, about when the JP could throw away the > neighbour > state, and whether or not the JP could blacklist a pledge. > > The JP is not entirely stateless: it benefits from maintaining a neighbour > state entry for the pledge. However, depending upon how the stateless > proxy > token is implemented by the JP, it could essentially store some of the > neighbour info for the pledge. > > The fundamental mis-communication between Tero and Malisa in the audio > recording is because they are looking at the pledge from different points > of > view. Tero is considering more situations where the Pledge is either > malicious, or poorly configured, while Malisa is considering situations > where > the join fails for (less) non-malicious reasons, but the pledge is > otherwise well > behaved. > I don't fully agree with this summary: this was discussed in more details within the "My comments to the draft-ietf-6tisch-minimal-security-06" thread on the ML. See in particular the last response. > a) the 6tisch-minimal draft is a one-round-trip process, but, the > zero-touch process > requires many round trips. > Sure, we discussed this on the same thread. > b) re: two-step process: this is how the 2014-era join process was going to > work, with the pledge saying hello, and the JRC would then drive the > process. We left that process. > I don't understand this comment, is this related to Tero's comment on having the signaling from JRC to JP on whether the join was successful? > > c) the stateless token that needs to be returned to the JP in order to > route > the packet to the pledge, *could* be defined to include a "LAST" (FIN) > flag. > That would let the JP immediately garbage collect the neighbor entity. > Whether the JP would then accept the pledge again in another round, is > another question to me. > Yes, the main point here is that all of this does not by any means impact interoperability and that JP may include in the stateless token whatever it may need to operate fully statelessly. For example, if it has multiple interfaces, uses non-default ports, ND entries, etc, etc. > > I don't really want the JP to have that kind of history, but I think it > would > be useful to have a communication from the edges to the root to indicate > if they are having resources issues with leaf nodes. This might be a ROLL > level thing however, and could have a lot to do with balancing trees. > In particular, DAOs are only sent when a parent *accepts* a child, not > (AFAIK) when they reject the child due to resource constraints. > Agreed, I think this approach should be advanced within the enhanced-beacon draft// > > So in the spirit of ROLL's, when a tree-falls-and-nobody-hears-it, maybe we > only need to solve the resource constraint problem when we run out of > resources? > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on > rails [ > > > > > > > > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
