<html><body><p><tt>"discuss" <discuss-bounces@openvswitch.org> wrote on 06/17/2016 05:24:19 PM:<br><br>> From: Cathy Zhang <Cathy.H.Zhang@huawei.com></tt><br><tt>> To: Na Zhu <nazhu@cn.ibm.com></tt><br><tt>> Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack <br>> Development Mailing List \(not for usage questions\)" <openstack-<br>> dev@lists.openstack.org>, John McDowall <br>> <jmcdowall@paloaltonetworks.com>, discuss <discuss@openvswitch.org></tt><br><tt>> Date: 06/17/2016 05:25 PM</tt><br><tt>> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] <br>> [networking-sfc] SFC andOVN</tt><br><tt>> Sent by: "discuss" <discuss-bounces@openvswitch.org></tt><br><tt>> <br>> Hi Juno,</tt><br><tt>> </tt><br><tt>> Here is an example. </tt><br><tt>> </tt><br><tt>> Src SF DST</tt><br><tt>> | | | |</tt><br><tt>> 1 2 3 4</tt><br><tt>> OVS1==========OVS2==========OVS3</tt><br><tt>> </tt><br><tt>> For bump-in-the-wire SF type, since what it does is just to pass the<br>> packet from its ingress port to egress port, broadcast and multicast<br>> packets will form a loop on port 2 and 3. </tt><br><tt>> This problem is not specific to SFC though. A simple way to solve <br>> this is to put a bump-in-the-wire SF’s port 2 and port 3 in <br>> different subnets. For L3 SF, this is not an issue. </tt><br><br><tt>The above is a good reason for following OVN's pipeline logic</tt><br><tt>and not punting a packet to an output port in the ingress pipeline</tt><br><tt>(as I first expressed concerns about in [1]).</tt><br><br><tt>There is a loopback check in table 34 (between the ingress and egress</tt><br><tt>pipelines) that we can look at using to break the loops - program it</tt><br><tt>to drop broadcast/multicast traffic going between ports 2 and 3 and</tt><br><tt>the loop is broken.</tt><br><br><tt>Ryan</tt><br><br><tt>[1] </tt><a href="http://openvswitch.org/pipermail/discuss/2016-May/021419.html"><tt>http://openvswitch.org/pipermail/discuss/2016-May/021419.html</tt></a><BR>
</body></html>