> Yep, intentionally so for now; of course, we could turn it even more in > the scalable (routing) protocol direction if there is desire.
That's not quite what I meant. I'll try to put it differently. Right now, an HNCP node performs the following actions: 1. participate in Trickle-based flooding; 2a. contribute a neighbour TLV to the global state; 2b. optionally contribute other TLVs; 3a. maintain a full set of TLVs being published; 3b. maintain a copy of the topology graph. Now there are different costs associated to these activities, both for this node and for other nodes. (1) is cheap for both. (2) is cheap for this node, but expensive for other nodes -- the state being contributed is replicated in all the other nodes. (3) is the opposite -- it's expensive for this node, since it requires storing the whole replicated state, but doen't contribute anything to other nodes. Now HNCP doesn't allow participating in just some of those activities. In particular, there is no way to participate in flooding without contributing a neighbour TLV (and hence increasing the size of the replicated state and the replicated neighbour graph). When you split HNCP into DNCP, I was hoping that you were providing a means to have nodes that do (1) and (3a) without contributing to the replicated global state. But unless I'm missing something, it doesn't. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
