* 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
