Re: [homenet] Next Steps for HNCP
Pierre Pfister wrote: >> 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). Huh? Nobody is suggesting HNCP or RP (other than RPL) for the LLN. It's about the gateway (which in James' case, is the Nest Thermostat platform) to the LLN which is also on the home wifi (does it have a cable too?). I don't know the Nest at all, I assume that it has a power source, my digital (non-smart) one gets 12V from the furnace. The gateway has to run LLN-happy protocol (RPL or another), as well as something to advertise the LLN's stub network (probably a different ULA than the homenet; no renumbering allowed) into the homenet. James has come with the belief that his gateway would be unable to run RP. I think is fear is unfounded. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ pgpA4BKvGyYi7.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for HNCP
> > > 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
Re: [homenet] Next Steps for HNCP
> 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. You’re right. > >> 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. I agree, the discussion is a dead-end if we don’t define whether the Low-Power stub device can run HNCP or not. IMHO I don’t think we want to think about situations where it can’t. > 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. In James’ problem, the prefix would actually belong to an advertised DP. But I agree that could not be always the case. There may be other possibilities, like defining a dedicated TLV. I don’t know which is the best design choice. > > cheers, > Ole > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for HNCP
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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for HNCP
> > > 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 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. - Pierre ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for HNCP
I think this conversation has got off on the wrong foot - the start of
it was about routing protocol choice, and the other was how to
interoperate with a stubby nest network in hncp.
On Sat, Nov 15, 2014 at 8:43 PM, Michael Richardson
wrote:
>
> Mark Townsley wrote:
> > routing protocol. A technical solution was proposed and discussed
> > ("proposal #1"), using the attached slides. "Proposal #2" in the
> > attached slide deck explored one way to support "HNCP Fallback" plus a
> > to-be-named "Routing Protocol" at the same time in a Homenet. Consensus
>
> I think that the two things are not mutually exclusive, or did I
> mis-understand?
>
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
--
Dave Täht
thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
