[ovs-discuss] SFC using OVN

Russell Bryant rbryant at redhat.com
Tue Nov 3 20:45:45 UTC 2015


On 11/03/2015 03:13 PM, Ben Pfaff wrote:
> On Nov 3, 2015 11:57 AM, "Ben Pfaff" <blp at nicira.com
> <mailto:blp at nicira.com>> wrote:
>>
>> On Tue, Oct 27, 2015 at 01:14:42AM -0500, V_Dham at Dell.com wrote:
>> > I am currently exploring Service Function Chaining (SFC)
>> > implementation using OVN and would like to hear thoughts from the
>> > community.
>> >
>> > Has anyone implemented Service Function Chaining using OVN project and
>> > would be willing to share his/her experiences? There are proposals for
>> > adding NSH header as well as leveraging MPLS headers (interim solution
>> > for lack of NSH support) for SFC but can someone more experienced in
>> > this topic share if those modifications are really necessary for real
>> > world SFC use cases?
>> >
>> > With the native support for L2 overlays and ACLs inherently built into
>> > OVN, I am wondering if we are better off creating point to point
>> > overlay networks between the VNFs and using ACLs for traffic
>> > classification. Or is there more to it than that?
>>
>> Justin, Russell, Thomas, and I brainstormed together about SFC a bit in
>> Tokyo.  There was a brief discussion related to the topic on the
>> openstack-dev list last week as well (see the thread
>> "[neutron][networking-sfc] API clarification questions").  Thomas built
>> a strawman prototype, I believe, though as I understand it the
>> conversation on openstack-dev meant that it implemented an inadequate
>> model.
>>
>> I don't know what the immediate plans are, but I expect that there'll be
>> a place for SFC in OVN.
> 
> Correction: Russell wrote the prototype.
> 

Yeah, I tried to build a prototype but it's inadequate for a few
reasons, so it needs a do-over. I think I understand the problem better,
at least. :-)

I basically modeled it as a chain of logical ports all on the same
logical switch.  If those constraints were valid, we can send the packet
through a chain without having to modify the source/dest IP, or even the
source/dest MAC.

We need to support more interesting chains, which means we need to pass
around some additional metadata.  We can do that with Geneve.  We also
need to expose some metadata about the chain into the VM (VNF) itself.
There's lots of ways we could do that, but there seems to be more
momentum behind NSH for this for whatever reason.  We can actually
decouple how we pass metadata between hosts from how we communicate
chain related metadata in/out of a VNF.

If NSH gets into OVS, we can use it for SFC as well.  It probably makes
sense to add NSH as a generic encap for OVN.  We could also use it only
to pass metadata in/out of a VNF if we wanted.

In the meantime, we can be working on how to model this properly in
OVN_Northbound, as well as trying to work out a reasonable
implementation based on Geneve.  The modeling in my prototype isn't
expressive enough.

-- 
Russell Bryant



More information about the discuss mailing list