(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. a) the 6tisch-minimal draft is a one-round-trip process, but, the zero-touch process requires many round trips. 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. 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. 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. 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 [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
