Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
STARK, BARBARA H wrote: > I am involved in the joint BBF effort that they mentioned. If someone > wanted to join that project (it's free to join -- just requires > agreeing to IPR policy and BSD+Patent open source license) and suggest > and provide code for HNCP, they could. I will followup with you, unicast. > But since this is a purely Layer > 2 network (routers will break it), the HNCP would really only be for > other routers (e.g., IoT gateways attaching a Thread network) that > aren't part of the Multi AP L2 network. If you'd like more info for > joining the joint BBF/prpl project, let me know. If the border routers are on the same L2 as the extensions, then it shouldn't be a problem. If there is a more complex HNCP network, then we could probably simulate the L2 scenario with VXLAN, configured by HNCP. There are probably some advantages to doing that as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
> > prplMesh solves the wifi broadcast domain issue. > > > > >From their website: « prplMesh is an open-source, carrier-grade and > certifiable implementation of the WiFi Alliance’s Multi-AP specification. » > > That's a purely layer 2 solution that relies on a central controller. > It depends on IEEE 1905: > You can get the Wi-Fi Alliance MAP (branded EasyMesh) spec that prpl is implementing from the WFA website (after providing your name and contact info if you aren't a member): https://www.wi-fi.org/file/multi-ap-specification-v10 You can also see the prplMesh code in its current (incomplete -- the project is still underway) state at: https://github.com/prplfoundation/prplMesh I am involved in the joint BBF effort that they mentioned. If someone wanted to join that project (it's free to join -- just requires agreeing to IPR policy and BSD+Patent open source license) and suggest and provide code for HNCP, they could. But since this is a purely Layer 2 network (routers will break it), the HNCP would really only be for other routers (e.g., IoT gateways attaching a Thread network) that aren't part of the Multi AP L2 network. If you'd like more info for joining the joint BBF/prpl project, let me know. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
> prplMesh solves the wifi broadcast domain issue. >https://prplfoundation.org/working-groups/prplmesh/ >From their website: « prplMesh is an open-source, carrier-grade and certifiable implementation of the WiFi Alliance’s Multi-AP specification. » That's a purely layer 2 solution that relies on a central controller. It depends on IEEE 1905: https://en.wikipedia.org/wiki/IEEE_1905 -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] homenet.org
So... who owns homenet.org then? Whois is of course, now neutered. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] wifi broadcast domain - Mikael Abrahamsson's comments
prplMesh solves the wifi broadcast domain issue. https://prplfoundation.org/working-groups/prplmesh/ I don't think we can fight this. I'm upset that this is a gated organization, and I hate it more than you. Perhaps we can ask for a formal liason, perhaps via Broadband Forum. My question is how can we use HNCP to help manage this. I don't know, as I haven't read their specification, but I'd like to figure it out. I think it's further layer-2 hacks inspired from 30 years of living in IPv4. A reason we need to delve into prplMesh is that it permits us to hairpin traffic between two wifi devices to go through the (security) gateway so that they can't attack each other. I, like Juliusz, think we can do this better in layer-3 with much less complex machinery, but I'm not sure that Homenet should solve this problem itself. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] multiple routers vs IoT
The way for multiple routers in the house is to recognize that the IoT gateway *is* the second router. It's not a second uplink. So there are in fact three situations: 1) multiple uplinks. (rare at this point, we all agree, partly I think because it's hard to do) 2) multiple routers. (rather common, often by mistake) 3) IoT routers (usually on purpose) Let's recharter to address (2) and (3). As for Ted's comments about backbone router in 6lo... that's rather esoteric Industrial IoT stuff. It's not, I think, quite right for the home. At least, not yet. {ps: I have the thread that the chairs started partly unread, because I had contributed to the questions, and I wanted to let others chime before I argued with them} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet