On 11/16/18 6:11 AM, Ankur Sharma wrote:
Hi Mark,
Thanks for the write up.
Initial proposal looks to be a good starting point.
Please find my feedback inline.
Regards,
Ankur
Sorry for the late response Ankur, but for some reason your response got
completely lost and I did not see it until now.
------------------------------------------------------------------------
*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.
No, the table itself is not per logical switch. The logical switch ports
may span across multiple logical switches.
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.
I agree that IGMP snooping should be a goal. For my initial work, I'm
focusing more heavily on getting a basis in place so that IGMP snooping
could be built on top of it.
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?
Let's say that a multicast group has two ports on HV A and two ports on
HV B. A multicast packet arrives on HV A.
We will send a packet on each port of HV A that is a member of the
multicast group. In other words, we sill send two packets.
We will send one packet from HV A to HV B.
When HV B receives the multicast packet, it will send a packet to each
of the ports on HV B that are members of the multicast group.
Hopefully that answers your question.
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.
Sure. Multicast_Group in the southbound database is a pre-existing
table. Each multicast group in the southbound database exists per-datapath.
ovn-northd can create logical flows that set the output port to be some
multicast group
ovn-controller treats this in a couple of ways.
* For cases where we are setting an output port, ovn-controller uses the
port key for the multicast group. This will be a value greater than 32767.
* ovn-controller evaluates each multicast group to expand it into rules
to transmit to the ports in that multicast group.
If you want to see how this works, you can trace the MC_FLOOD multicast
group from ovn-northd. This is a multicast group that is created for
every logical switch datapath in the southbound database. The multicast
group contains all logical switch ports on the datapath. It has a port
key of 0xffff. This is the way that multicast behavior in OVN currently
works. When a multicast packet arrives, we set the output port to
0xffff. Openflow rules later make it so that if the output port is set
to 0xffff, then the packet is sent to all of the ports on the datapath.
For my change, I'm installing more selective Multicast_Groups. I output
the packet to this particular Multicast_Group based on the destination
IP address that was configured in the northbound Multicast_Group.
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://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.
Yes, that is correct.
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
