Pierre, >> 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).
I think we need to separate the two discussions. let's start a separate work item for peering with LLNs. > Additionally, I **don’t** think the WG should consider defining a full > 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. Proposal #1 is, IMO, a correct trade-of. if proposal #1 is for peering with LLNs I don't think that's correct. firstly we need to get the requirements better defined. and by the way overloading the assigned prefix TLV as a "register external route" option is pretty ugly. you'll then get assigned prefixes which aren't even more specifics out of the delegated prefix. keep the prefix assignment mechanism clean please. cheers, Ole _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
