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/ <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 <[email protected]> wrote: > > On 14 Mar 2019, at 00:40, Ted Lemon <[email protected]> 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 <[email protected]> wrote: > > Ted > > On 13 Mar 2019, at 18:35, Ted Lemon <[email protected]> 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 > <https://u8538325.ct.sendgrid.net/wf/click?upn=0nhH4OIYFtatOO7tDf-2BEy9JDHc3W7itZDB6jHoUCcMD5Ni9FWgzk-2FsCXhpoGMY1hFnwsJxISnVc9wOuhy-2BQvhIQyW2DIAvJajgsdEWX4Fo0-3D_y-2BfRiPDFCcVWHl-2FL96-2Fm4F33NRr1RuRHxcAJiOFSycOHZDHy3UZfzJA5pdts-2F6aQzbqV7C3uEqqypJ-2Fz-2FT8HnuMEryLIeGd0v9nlar2XZjpXNh8DDttt-2FalKj8YPBBC0zoNXKP7anpsdLEN2xfrQKCTnUOlfJfNNzCnS6bwUJh1tFCMZmeMHBLVAsjNAtC44-2FiWFOPSe-2BcaQZP-2BEm4VI-2Bw-3D-3D> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/homenet >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
