> > > while 2 and 3 require participation in HNCP, my worry is that even HNCP is > too chatty for the LLN to deal with. do we have any numbers? presumably one > could design a stub HNCP, where the peer only received messages relevant to > it, possibly even with a HNCP sleep proxy.
We could try to make HNCP more Low-Power-friendly, but there will always be cases where HNCP will kill LP nodes because HNCP provides network-wide state synchronization (e.g. a buggy node keeps sending changing updates). IMO, the reason why the ‘buddy’ approach was relevant for Low-Capacity devices like James’ is that HNCP could be useful for different things (e.g. advertise a Delegated Prefix), which we can’t really do with a routing protocol. So instead of having HNCP + RP, it would be HNCP alone. In which case the chattyness of HNCP doesn’t matter much. That said, I think the chatyness of both HNCP and the RP should be taken into account, as a ‘weak' requirement (i.e. it should not override already existing requirements). Additionally, I **don’t** think the WG should consider defining an HNCP-proxying mechanism. If HNCP is successful, and if the need appears to be strong, OK. But we should make something that works without such support first. - Pierre _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
