On 28.5.2015, at 16.11, Juliusz Chroboczek <[email protected]> wrote: > >> Thank you for the recent reviews and update of draft-ietf-homenet-dncp. >> Please take the next 3 weeks to make your final reviews. > > I strongly support this work. We have recently set up an HNCP experiment > here in Paris (together with Thomas Denecker), and in the superficial > testing we did, it works beautifully. > > As I've already mentioned on a number of occasions, however, I think that > in its current state DNCP represents a missed opportunity: it is > impossible to participate in DNCP without contributing a Node-State TLV > and a full set of Neighbor sub-TLVs. This implies that: > > (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.) > (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. > (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. > Point (1) is relevant to network monitors that are not co-located with > a router, or more generally to hosts that wish to learn the network > topology without increasing the amount of replicated state. Point (2) is > relevant to hosts that wish to leverage DNCP in order to publish some data > without increasing the amount of replicated state. Point (3) is important > for routers that don't have any attached hosts, as when connecting two > wired networks over a number of wireless hop-to-hop links. > > Fixing this is not complicated -- it just requires making it clear that > publishing Neighbor sub-TLVs is optional, and that, if a node is > publishing no sub-TLVs, then publishing a Node-State TLV is itself > optional. This will require changing the algorithm in Section 5.4 (since > the neighbor graph is no longer necessarily connected). I have no idea > whether it requires changes to the link assignment algorithm. 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, I am not sure what this would accomplish. One could argue for some ‘dumb client protocol’ that lets some ‘real’ device do the publishing for them, but then dumb client’s connectivity is no longer of interest and the ‘real’ device can pretend to have the data valid as long as the TTL in the ‘dumb client protocol’ indicates.. > I think that not lifting the requirement for O(n+e) state in DNCP now > would be a serious missed opportunity, since it seriously reduces the > applicability of the protocol. Well, I am not sure I am quite convinced with this argument (yet) :) Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
