Re: [homenet] Homenet market gap analysis...

[Ted Lemon]

Thanks for clarifying.   I was trying to answer your questions and didn’t get 
that you were suggesting changes to the document; now that’s more clear.   
Regarding “naming interfaces” versus “naming nodes,” you might want to look at 
https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ 
 which specifically 
addresses that problem, although it doesn’t say it the way you said it.  :)

> On Mar 14, 2019, at 6:19 AM, Tim Coote  wrote:
> 
> On 14 Mar 2019, at 00:40, Ted Lemon  wrote:
> 
> Tim, it’s pretty clear that in the case of constrained networks, there needs 
> to be subnetting. Homenet is uniquely positioned to make that possible—if you 
> have a regular router that doesn’t support something like HNCP, there’s no 
> way to make it work.
> 
> Agreed. I thought that from a market gap analysis, that it was worth bringing 
> out this weakness for existing (L2 based) approaches, otherwise there will be 
> a tendency for readers to assume the best.
> 
> In the case of a multi-premise homenet, either you have to bond the two 
> homenets together, which we don’t currently support, or you need end-to-end 
> to work, which means IPv6, and you need to make sure that only authorized 
> hosts can talk to devices.
> I see. The usecase wasn’t missing, it’s covered by the 'internet to leaf’ + 
> ‘leaf to internet’ scenarios. Again, for the casual reader, I think that it’s 
> worth pointing this out. But it’s your document, of course.
> 
> Toke and I have been discussing the endpoint roaming problem.   In L2, it’s 
> all handled by the layer 2, so it’s transparent, which doesn’t necessarily 
> mean that it’s any better than the less-transparent way it would need to be 
> handled at L3.   I think we should do a comparison between these two 
> approaches.
> Mapping names to addresses can be done with service discovery; please see the 
> simple homenet naming architecture document for a discussion of this, and 
> also RFC6763.   We will be doing some work on this at hackathon if you want 
> to see it in action.
> Node identity can be managed with DNSSD Service Registration Protocol, which 
> allows a host to claim and defend a name using public key cryptography.   
> Bear in mind that there are privace implications to this, and so it isn’t 
> always the right thing to do.   Your printer should probably do it.   Your 
> phone, perhaps not.   Private service discovery is being seriously discussed 
> in the DNSSD working group.   Because private service discovery necessarily 
> uses public key encryption, unique identifiers aren’t a problem; claiming a 
> unique name remains a problem, but not a very big problem, because the name 
> doesn’t change after pairing.
> I was thinking more of ‘pet names’, ie human invented and associated, rather 
> than names used for well-known services, how these propagate on movement to 
> new networks etc (eg I call my dad’s spO2 meter oxydad, no matter where it is 
> or where he is).
> 
> What concerns me about dns based approaches is that dns knows nothing about 
> nodes, only interfaces. That’s mostly ok in an world with ~1 address per 
> node, but it quickly becomes difficult as that constraint is broken. This is 
> certainly an issue in enterprise environments. otoh, in some circumstances, 
> it may be confidential that specific addresses are associated with the same 
> host, or service on a host.
> 
> I did get a suggestion that nodes are better managed using handle.net’s model.
> 
> I’ll read your suggestions. Thanks.
> 
> IoT meshes are out of scope for homenet.   I agree that there are some 
> interesting problems to contemplate when using them. :)
> I was really showing how bad things get. I am concerned that all mesh 
> networks will go the same way, leading to very large support costs. IMO, 
> there’s a tendency for computer based systems to avoid the engineering 
> principle of fail fast (give up early and raise an alarm), which gives an 
> impression that all is well until there’s a catastrophic failure. Even the 
> original Ethernet wiring exhibited this with workarounds for signal 
> deterioration and fallback to lower performance.
> 
> On Mar 13, 2019, at 6:45 PM, Tim Coote  wrote:
> 
> Ted
> 
> On 13 Mar 2019, at 18:35, Ted Lemon  wrote:
> 
> In Bangkok I gave a talk about what Homenet gets right, what new solutions 
> have emerged in the market since homenet started, and what is better about 
> those solutions, as well as what homenet still adds. I’ve written up a 
> document that discusses this in a bit more depth, and would appreciate 
> feedback. It’s not very long, and should be a pretty easy read—it would be 
> great if we could start talking about this before the meeting, so that when 
> we get to the meeting we can have an informed discussion and maybe decide on 
> a way forward if that seems warranted.
> 
> https://tools.ietf.org/html/draft-lemon-homenet-review-00 
> 

Re: [homenet] Homenet market gap analysis...

[Michael Thomas]

On 3/13/19 11:35 AM, Ted Lemon wrote:
In Bangkok I gave a talk about what Homenet gets right, what new 
solutions have emerged in the market since homenet started, and what 
is better about those solutions, as well as what homenet still adds.   
I’ve written up a document that discusses this in a bit more depth, 
and would appreciate feedback.   It’s not very long, and should be a 
pretty easy read—it would be great if we could start talking about 
this before the meeting, so that when we get to the meeting we can 
have an informed discussion and maybe decide on a way forward if that 
seems warranted.


https://tools.ietf.org/html/draft-lemon-homenet-review-00



Thanks, Ted. This is really useful.

Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet market gap analysis...

[Ted Lemon]

Tim, it’s pretty clear that in the case of constrained networks, there needs to 
be subnetting.   Homenet is uniquely positioned to make that possible—if you 
have a regular router that doesn’t support something like HNCP, there’s no way 
to make it work.

In the case of a multi-premise homenet, either you have to bond the two 
homenets together, which we don’t currently support, or you need end-to-end to 
work, which means IPv6, and you need to make sure that only authorized hosts 
can talk to devices.

Toke and I have been discussing the endpoint roaming problem.   In L2, it’s all 
handled by the layer 2, so it’s transparent, which doesn’t necessarily mean 
that it’s any better than the less-transparent way it would need to be handled 
at L3.   I think we should do a comparison between these two approaches.

Mapping names to addresses can be done with service discovery; please see the 
simple homenet naming architecture document for a discussion of this, and also 
RFC6763.   We will be doing some work on this at hackathon if you want to see 
it in action.

Node identity can be managed with DNSSD Service Registration Protocol, which 
allows a host to claim and defend a name using public key cryptography.   Bear 
in mind that there are privace implications to this, and so it isn’t always the 
right thing to do.   Your printer should probably do it.   Your phone, perhaps 
not.   Private service discovery is being seriously discussed in the DNSSD 
working group.   Because private service discovery necessarily uses public key 
encryption, unique identifiers aren’t a problem; claiming a unique name remains 
a problem, but not a very big problem, because the name doesn’t change after 
pairing.

IoT meshes are out of scope for homenet.   I agree that there are some 
interesting problems to contemplate when using them. :)


> On Mar 13, 2019, at 6:45 PM, Tim Coote  wrote:
> 
> Ted
> 
>> On 13 Mar 2019, at 18:35, Ted Lemon  wrote:
>> 
>> In Bangkok I gave a talk about what Homenet gets right, what new solutions 
>> have emerged in the market since homenet started, and what is better about 
>> those solutions, as well as what homenet still adds.   I’ve written up a 
>> document that discusses this in a bit more depth, and would appreciate 
>> feedback.   It’s not very long, and should be a pretty easy read—it would be 
>> great if we could start talking about this before the meeting, so that when 
>> we get to the meeting we can have an informed discussion and maybe decide on 
>> a way forward if that seems warranted.
>> 
>> https://tools.ietf.org/html/draft-lemon-homenet-review-00
>> 
> 
> Some points/questions. Pls excuse my hamfisted articulation/miss an obvious 
> point, I’m no network specialist.
> 
> - IoT isolation for L2: a common scenario is that the IoT network has a 
> vastly different performance profile to other in-home networks. I don’t think 
> that this works well for Flat L2
> - for some IoT scenarios, the scope of a home isn’t one premises, eg wanting 
> to control a camera in one house from a controller in another. There is no 
> general IPv4 solution to this as protocols such as STUN/ICE are too slow, in 
> human reaction time terms, to use to set up the control link.
> - how is an endpoint reconnected if it’s moving about and getting renumbered? 
> Is this done via some naming service?
> - how are human understandable names mapped to addresses, automatically? Is 
> this service discovery?
> - node identity: if a node is moving about and/or has multiple addresses at 
> the same time, how does a human understand that it’s the same thing. For s/w 
> this is quite easy, although non-standard. Is this an application layer 
> concern?
> - a point wrt meshes: although these potentially provide resilience, they can 
> also provide confusion as the end to end service can move up and down over 
> various timescales. I have experienced some very expensive support situations 
> that were caused by (IoT) mesh networks breaking the principle of 
> ‘fail-fast’. In these situations, as the world changes, L2 networks adopt a 
> ’string of pearls’ topology, but do not report the changes. Ultimately there 
> is a network partition, which breaks things in interesting ways from an 
> engineering point of view and confusing ways from the point of view of users.
> 
> I hope that this is useful.
> 
> tc
> 
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet market gap analysis...

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> I suppose a point to be investigated is that however roaming happens,
> unless all packets are flooded to all links, the layer 2 switch always
> triggers a routing change, whether at layer 2 or layer 3.
>
> So it might be worth doing an analysis of the pros and cons of L2 versus L3
> roaming. I know Dave Täht has looked into doing it at L3 at the host, but
> that isn’t practical and is in any case out of scope for homenet. What is
> easier if it’s done at L2?  At L3?

Yeah; off the top of my head: getting the address to distribute is
easier at L2 (it's built in to the WiFi handshake), and there's only one
of them; but distributing it (them) once you know it may be easier (or
more efficient) at L3. Assuming you already have a decent layer 3
routing protocol available, of course (which is why it makes sense to
solve it in a homenet context) :)

L3 also has the advantage that it can aggregate lots of host routes into
a covering prefix, so fewer routes when no one is roaming; but when
clients do roam, you mostly have to announce host routes anyway, so in
the worst case we get back to "one route per address"... A longer
analysis would probably be needed to assess performance in the worst
case.

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet market gap analysis...

[Ted Lemon]

I suppose a point to be investigated is that however roaming happens,
unless all packets are flooded to all links, the layer 2 switch always
triggers a routing change, whether at layer 2 or layer 3.

So it might be worth doing an analysis of the pros and cons of L2 versus L3
roaming. I know Dave Täht has looked into doing it at L3 at the host, but
that isn’t practical and is in any case out of scope for homenet. What is
easier if it’s done at L2?  At L3?

On Wed, Mar 13, 2019 at 17:27 Toke Høiland-Jørgensen  wrote:

> Mikael Abrahamsson  writes:
>
> > I especially agree with the statement on wifi roaming between APs does
> > require shared L2, and there has been discussions about this and how
> > to solve that, and I think it's a requirement for homenet to become a
> > useful solution in that space. This would probably require some kind
> > of tunneling or vlan encapsuatlion between homenet devices to be
> > controlled somehow. There are routing protocols out there that already
> > do this, can perhaps be used as inspiration.
>
> You don't actually need encapsulation or VLANs if all access points
> participate in the routing protocol. You can just announce routes for
> each of the clients' IP addresses on roaming. You'll need some mechanism
> for discovering those IP addresses of course; one option is something
> like l3roamd[0] (which more or less just sniffs the addresses used by
> the client), but others are certainly possible. I remember discussing
> other approaches with Juliusz at some point, but I guess none of us ever
> got around to implementing something.
>
> Either way, I guess this is something homenet could conceivably specify
> a solution for if there was sufficient interest... :)
>
> -Toke
>
> [0] https://github.com/freifunk-gluon/l3roamd
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet market gap analysis...

[Toke Høiland-Jørgensen]

Mikael Abrahamsson  writes:

> I especially agree with the statement on wifi roaming between APs does
> require shared L2, and there has been discussions about this and how
> to solve that, and I think it's a requirement for homenet to become a
> useful solution in that space. This would probably require some kind
> of tunneling or vlan encapsuatlion between homenet devices to be
> controlled somehow. There are routing protocols out there that already
> do this, can perhaps be used as inspiration.

You don't actually need encapsulation or VLANs if all access points
participate in the routing protocol. You can just announce routes for
each of the clients' IP addresses on roaming. You'll need some mechanism
for discovering those IP addresses of course; one option is something
like l3roamd[0] (which more or less just sniffs the addresses used by
the client), but others are certainly possible. I remember discussing
other approaches with Juliusz at some point, but I guess none of us ever
got around to implementing something.

Either way, I guess this is something homenet could conceivably specify
a solution for if there was sufficient interest... :)

-Toke

[0] https://github.com/freifunk-gluon/l3roamd

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet market gap analysis...

[Mikael Abrahamsson]

On Wed, 13 Mar 2019, Ted Lemon wrote:

In Bangkok I gave a talk about what Homenet gets right, what new 
solutions have emerged in the market since homenet started, and what is 
better about those solutions, as well as what homenet still adds.  I’ve 
written up a document that discusses this in a bit more depth, and would 
appreciate feedback.  It’s not very long, and should be a pretty easy 
read—it would be great if we could start talking about this before the 
meeting, so that when we get to the meeting we can have an informed 
discussion and maybe decide on a way forward if that seems warranted.


https://tools.ietf.org/html/draft-lemon-homenet-review-00 



Thanks for doing this, it's a valuable write-up. I agree with what's 
written in the draft, but I missed some parts that would involve 
DHCPv6-PD. I have done this myself and it's very useful to be able to 
stack several routers deep into the home, for instance for L2 isolation of 
devices (I had a real problem involving Spanning Tree that I wanted to 
solve this way, and it worked well). Doing this with non-HOMENET routers 
expands the number of devices one can support.


I especially agree with the statement on wifi roaming between APs does 
require shared L2, and there has been discussions about this and how to 
solve that, and I think it's a requirement for homenet to become a useful 
solution in that space. This would probably require some kind of tunneling 
or vlan encapsuatlion between homenet devices to be controlled somehow. 
There are routing protocols out there that already do this, can perhaps 
be used as inspiration.


Looking at the kind of devices typically available to people, most of them 
are SoCs with 2 NIC ports, one connected to a WAN port and one to a switch 
that then provides multiple ports. This doesn't lend itself very well to 
arbitrary topologies, but it does lend itself well to creating trees. Here 
the service discovery proxies and turning off firewalls/NAT of HOMENET is 
very useful. I also think it's useful for wired devices to have the L3 
isolation that HOMENET design calls for, but we also need to support L2 
domains across APs (multiple probably, as people also like to have 
isolation between different SSIDs).


There is now work in the IETF on IoT onboarding etc, does HOMENET have 
mechanisms that can be used there or the other way around?


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet