[openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

Ryan Moats rmoats at us.ibm.com
Fri Jun 17 14:35:08 UTC 2016

In-line below

"discuss" <discuss-bounces at openvswitch.org> wrote on 06/15/2016 05:51:20

> From: John McDowall <jmcdowall at paloaltonetworks.com>
> To: Na Zhu <nazhu at cn.ibm.com>
> Cc: Srilatha Tangirala/San Francisco/IBM at IBMUS, "OpenStack
> Development Mailing List \(not for usage questions\)" <openstack-
> dev at lists.openstack.org>, discuss <discuss at openvswitch.org>
> Date: 06/15/2016 05:51 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
> Sent by: "discuss" <discuss-bounces at openvswitch.org>
> Juno,
> Apologies – I see your issue now, also I have got nothing done today
> – got sucked into an all day meeting. I was thinking very much from
> a  ovs/ovn perspective and also my first prototype was very simple.
> So while in networking=sfc/ovn the port-cahin does not have a switch
> I think port-chain needs a lswitch context as that is where the
> port-chain table is created. Let me try and lay this out. I am not
> sure if I am getting this right but it is a starting point for
> discussion and comment by the community.
> The first thing is that there could be three different types of
> VNF’s, L3, L2, and Bump in the Wire (BITW). I am not sure if it
> would be possible to mix and match these different types in a series
> of port-pair-groups. Also as a first phase I have been trying to
> remove the need for the VNF to participate in the service chain (or
> be aware of it). In addition I also wanted to remove the need for
> any “proxy” as documented in the NSH model, by moving a lot of the
> functionality to the ovn-northd.
> Mode 1: BITW
> Port-Pairs: The logical ports need to be on the same logical switch
> Port-pair-groups: They are made up of sets of port-pairs, until we
> see the load-balancing proposal for ovs/ovn not sure if port-pairs
> can be on different logical switches or not. This translates to a
> set of rules in the port-chain table that chains output ports of one
> VNF to the input port of the next VNF, until the last VNF when the
> traffic is forwarded to the final destination of the packet. If the
> port-chain is bi-directional then the rule set has to be implemented
> in reverse (many VNF’s Firewalls, Load Balancers etc need to see
> both legs of the traffic).
> Flow-classifier: Is a set of rules that are set as an ACL rule with
> first logical port of the first pair in the first port-pair-group.
> Likewise if the port-chain is bi-directional then the rules have to
> be symmetric to steer the traffic in both directions.
> Port-chain: defined on the same logical switch as the first logical-
> source-port of the flow-classifier, as this is where the port-chain
> table is created and the rules for traffic steering are inserted.
> Mode 2: L2
> I think this would be similar to the BITH case but instead of
> steering by logical ports the steering would be done by VLAN tags.
> This would also mean that the VNFs would have to be aware of the
> steering rules and be able to manipulate VLAN tags.
> Mode 3: L3
> This would require the VNF’s to be aware of the routing rules and
> set static routes/net hop rules for each step in the service chain.
> Modes 2 & 3 would require a much more sophisticated control plane to
> program both OVN and the VNFs.

[Snip to save BW]

I'm not so sure John.  I agree that OVN would have to know about the
VF type (BiW/L2/L3) and further that OVN would need to be told about
the appropriate L2/L3 "next port" information - either VLAN tags or
IP addresses, but once I have that, I think the actual vswitch
programming is fairly straightforward:  for L2, the vswitch is
programmed to use the VLAN tag to select the next PPG bucket and
for L3, the existing template for programming static routes can be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160617/38dd6c8b/attachment.html>

More information about the OpenStack-dev mailing list