[openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN
jmcdowall at paloaltonetworks.com
Fri Jun 17 21:10:59 UTC 2016
From: Ryan Moats <rmoats at us.ibm.com<mailto:rmoats at us.ibm.com>>
Date: Friday, June 17, 2016 at 7:35 AM
To: John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>>
Cc: Na Zhu <nazhu at cn.ibm.com<mailto:nazhu at cn.ibm.com>>, Srilatha Tangirala <srilatta at us.ibm.com<mailto:srilatta at us.ibm.com>>, "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, discuss <discuss at openvswitch.org<mailto:discuss at openvswitch.org>>
Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC andOVN
"discuss" <discuss-bounces at openvswitch.org<mailto:discuss-bounces at openvswitch.org>> wrote on 06/15/2016 05:51:20 PM:
> From: John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>>
> To: Na Zhu <nazhu at cn.ibm.com<mailto: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<mailto:dev at lists.openstack.org>>, discuss <discuss at openvswitch.org<mailto: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<mailto:discuss-bounces at openvswitch.org>>
> 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
JED> I mentioned this in a reply to Cathy too, the issue I worry about is when the VNF is acting as a router or a switch. Then we have
JED> multiple actors that need to coordinate with each other. If we decide that VNFs must support BitW then there is not an issue.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev