Hi Mark, Thanks for the write up. Initial proposal looks to be a good starting point.
Please find my feedback inline. Regards, Ankur ________________________________ From: [email protected] <[email protected]> on behalf of Mark Michelson <[email protected]> Sent: Thursday, November 15, 2018 2:20 PM To: [email protected] Subject: [ovs-dev] OVN multicast enhancements Hi everyone, In today's IRC meeting I brought up the fact I was enhancing multicast support in OVN, and I was asked to expand on this a bit. So here are details about what all I am working on. Right now, OVN logical switches treat all multicast destinations as if they were broadcast. That is, the packet gets sent to all ports on the switch. OVN logical routers block all traffic destined to a multicast address. My goal is for there to be more intelligence. IP traffic sent to multicast addresses should be sent to members of that multicast group when possible. My work consists of the following phases: Phase 1: Northbound changes; multicast on a single logical switch port. For this part, we create a new northbound table called Multicast_Group. It consists of: * A name * A multicast IP address * A list of logical switch ports The general idea is that traffic sent to the IP address should reach all logical switch ports listed. [ANKUR]: a. I am assuming this table is per logical switch. b. How will you discover the port to multicast group mapping? I am of the opinion that instead of having an out of band mechanism, OVN can leverage on igmp snopping in OVS and populate this multicast group to port mapping. We can also enhance as ovn-controller to do local igmp snooping and populate this table. c. Is it really multicast or multi unicast? i.e for intra chassis logical ports, will ovn-controller generate on packet for each endpoint? Similarly, for endpoints in a remote chassis, how many packets will source chassis generate? In practice, each northbound multicast group will result in southbound multicast groups being added to the datapaths that the logical switch ports reside on. Logical flows are introduced on the logical switch ingress pipelines to output packets that are destined for the multicast IP address and the corresponding derived multicast ethernet address [1] to the constituent ports. [ANKUR]: To be honest, i am not clear with the use case of multicast_group table in southbound DB. Can you elaborate on it please? It will help me with better understanding of the proposal. In practice, this set of changes only works if all ports in the multicast group are on the same logical switch. I already have this implemented and have a test written for the testsuite that passes. You can see what I have at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_putnopvut_ovs_tree_multicast-2Dimprovements&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=FzqJqkEOtSxSyDtTFtQYFLaAR8OPuTmCm85UStogNeI&s=kC2cxfPhTHmGGJ263RuiYNeBHuBVMBeBxjpjHCmrzlM&e= [https://avatars1.githubusercontent.com/u/1328590?s=400&v=4]<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_putnopvut_ovs_tree_multicast-2Dimprovements&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=FzqJqkEOtSxSyDtTFtQYFLaAR8OPuTmCm85UStogNeI&s=kC2cxfPhTHmGGJ263RuiYNeBHuBVMBeBxjpjHCmrzlM&e=> putnopvut/ovs<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_putnopvut_ovs_tree_multicast-2Dimprovements&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=FzqJqkEOtSxSyDtTFtQYFLaAR8OPuTmCm85UStogNeI&s=kC2cxfPhTHmGGJ263RuiYNeBHuBVMBeBxjpjHCmrzlM&e=> urldefense.proofpoint.com Open vSwitch. Contribute to putnopvut/ovs development by creating an account on GitHub. Phase 2: Add multicast routing support This expands on the work in phase 1 by creating southbound multicast groups on logical router datapaths for router ports connected to logical switches with multicast groups on them. This way, a multicast group distributed across multiple logical switches can have the traffic routed as desired. This also requires adding new logical flows for the router pipeline to ensure that traffic bound to known multicast IPs is sent where we expect. I'm currently working on this phase. I have a test written and it is not passing. [ANKUR]: Looks like this proposal is only for E-W traffic. For N-S we will have to advertise NATed IPs as multicast group member to uplink router. Phase 3: Expand to IPv6 support. The previous phases are very IPv4-centric. This phase expands on what we have already by making it work with IPv6 as well. Mostly, this means removing IPv4-centric idioms and installing IPv6 flows in parallel with the IPv4 flows. With those three phases complete, I think I'll have a decent patchset to submit for approval. There are other enhancements that can be implemented as well later on: * IGMP/MLD snooping in ovn-controller. * Installation of rules for well-known multicast addresses with semantic significance. That's all for that. If you have questions/concerns, please let me know. Mark! [1] I initially had wanted to only use the multicast ethernet address for determining where to send the packets. However, the way that multicast IP translates into multicast ethernet addresses, there can be ambiguity. Therefore the logical switch needs to also examine the multicast IP address. _______________________________________________ dev mailing list [email protected] https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=FzqJqkEOtSxSyDtTFtQYFLaAR8OPuTmCm85UStogNeI&s=52FWz085Rjvb5SniZ-Oe8I5bl3BAya6Q2-NOzFayn3o&e= _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
