On 28.5.2015, at 18.38, Juliusz Chroboczek <[email protected]> wrote: >>> (1) it is impossible to reliably snoop the protocol without contributing >>> a Node-State TLV and a full set of Neighbor sub-TLVs; >> This is not true, at least assuming the profile specifies even partially >> multicast-using profile. In pure unicast setup, you have to poll, >> I guess. (HNCP isn’t doing this, as it uses multicast also.) > Ah -- you mean that an HNCP node will reply to a Node/Network state > request even if it's not in the link state database of the requestee? > That makes sense, much more than the assumption I had made that you ignore > any nodes that you don't have in your link-state database. > > Please make this explicit in Section 5.2.
Section 5.2 explicitly says how to reach to each TLV (and no semantics about this, IIRC). Section 5.3 states what Node Endpoint TLV means (=I want to be your neighbor), section 5 (start) says that that TLV is used for forming bidirectional peer relationships.. How would you make it more explicit here? >>> (2) it is impossible to publish data within DNCP without contributing >>> a full set of Neighbor sub-TLVs; >> Full set is not required. _One_ bidirectional one per link is enough. > > How do you ensure that the graph remains connected? Suppose you have this > topology: > > --- A --+-- B > | > C > > where B and C try to minimise state. What prevents B from picking C, > C from picking B, so that the (B,C) clique becomes disconnected from the > rest of the network? Section 6.2. (You don’t pick randomly who to pick, but e.g. prefer highest ID, and everyone follows same alg and _one_ node on shared link _has_ to peer with everyone). >>> (3) it is impossible to act as a dumb DNCP forwarder without publishing >>> a Node-State TLV and a full set of Neighbor sub-TLVs. >> This is not true. Given basic bridging of ‘remember one guy on end of >> each link’, you can do essentially bridging. > Same issue as above. See above. >>> This will require changing the algorithm in Section 5.4 (since the >>> neighbor graph is no longer necessarily connected). >> That will result in state hanging around forever unless we introduce >> some TTL scheme alongside it. Considering the main design goal of DNCP >> is _not_ to have TTLs in the protocol, > Ah. Right. I'm an idiot. > > Please make this rationale more explicit in the draft -- it's said in the > introduction, please repeat it in Section 5.4. I dislike repeating myself in a document. Any suggestions on wording on how to stay this nicely? ;) > I'll think about it some more, but I think you've convinced me -- I don't > see a good way to avoid the state explosion without giving up on the > link-state nature of DNCP. (Which I understand is not likely to happen.) The main reason I am against TTL stuff is actually that it invalidates the use of Trickle; given even large static network, the TTL updates would cause Trickle never to be anything else than I_min => if you want to scale to (say) medium-sized static networks with low waste, this is the design I came up with. I _do_ welcome better designs though. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
