Subject: Re: [homenet] Next Steps for HNCP

From: Dave Taht <[email-masked]>
Date: Sat, 15 Nov 2014 20:46:09 -0800

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
<[email-masked]> wrote:
>
> Mark Townsley <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

---

From: Pierre Pfister <[email-masked]>
Date: Sat, 15 Nov 2014 20:02:13 -1000

> 
> 
> 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

---

From: Ole Troan <[email-masked]>
Date: Sat, 15 Nov 2014 23:09:41 -0800

Pierre,

> 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 wo…

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

---

From: Pierre Pfister <[email-masked]>
Date: Sun, 16 Nov 2014 07:46:34 -1000

> I think we need to separate the two discussions. let's start a separate work item for peering with LLNs.

You’re right.

> 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.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 15:46:32 -0500

Pierre Pfister <[email-masked]> 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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [