Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
* Juliusz Chroboczek >> If there is a more complex HNCP network, then we could probably simulate >> the L2 scenario with VXLAN, configured by HNCP. > > If memory serves, VXLAN requires support for multicast, which HNCP+Babel > doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid > the use of multicast, I'm not a fan. I think you'll find very few deployed production VXLAN networks using multicast in the underlay for BUM flooding. It is far more common to have some kind of control plane (could be distributed or centralised) that takes care of that. EVPN (RFC 7432), for example. To get rid of multicast in the underlay, you'd at minimum need to distribute information in HNCP about which routers are interested in receiving BUM traffic for a given VXLAN ID, so that all routers can install forwarding table entries for BUM traffic pointing to all the remote tunnel endpoints (VTEPs). BUM frames will then be copied and sent unicast to all the remote VTEPs (this process is called «Head End Replication»). More advanced control planes (like EVPN) will also distribute information about where individual MAC addresses are located, so that there is no need to flood and learn unknown unicast. Works like a charm. Tore ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
>> If there is a more complex HNCP network, then we could probably simulate >> the L2 scenario with VXLAN, configured by HNCP. > If memory serves, VXLAN requires support for multicast, which HNCP+Babel > doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid > the use of multicast, I'm not a fan. Another issue is that since VXLAN emulates a layer 2 network, it doesn't have any means to regulate MTU; hence, it requires either network-layer fragmentation or the use of jumbograms. Not a fan, sorry. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
> If there is a more complex HNCP network, then we could probably simulate > the L2 scenario with VXLAN, configured by HNCP. If memory serves, VXLAN requires support for multicast, which HNCP+Babel doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid the use of multicast, I'm not a fan. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
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] 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
