[ovs-discuss] [ovn4nfv]

Mon Apr 18 19:44:27 UTC 2016

I think that this is roughly what Russell had in mind,
documentation-wise.

I think there'll be a delay because Russell is out on leave for a few
weeks.

On Mon, Apr 18, 2016 at 06:55:40PM +0000, John McDowall wrote:
> Russell,
> 
> Sorry for the delay, I have edited two documents to start to address items 2 and 4, they are in my private fork of ovs. Let me know if this is what you were thinking about.
> 
> ovn-architecture.7.xml<https://github.com/doonhammer/ovs/blob/master/ovn/ovn-architecture.7.xml>
> ovn-nb.xml<https://github.com/doonhammer/ovs/blob/master/ovn/ovn-nb.xml>
> 
> I have talked to the networking-sfc team and I think we have an approach to use the networking-sfc interface in Openstack. I think it is better than the API I created in Openstack and leverages their driver model. I am going to try and get something working to illustrate the model. Simple case should be relatively easy - if we want to add multiple VNF’s it will get a little harder.
> 
> Regards
> 
> John
> 
> 
> 
> From: Russell Bryant <russell at ovn.org<mailto:russell at ovn.org>>
> Date: Wednesday, March 30, 2016 at 6:48 PM
> To: John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>>
> Cc: Ben Pfaff <blp at ovn.org<mailto:blp at ovn.org>>, "discuss at openvswitch.org<mailto:discuss at openvswitch.org>" <discuss at openvswitch.org<mailto:discuss at openvswitch.org>>
> Subject: Re: [ovs-discuss] [ovn4nfv]
> 
> I won't be at the OpenStack Summit this time around.
> 
> I'm happy to jump on the phone sometime for quick clarifications if needed, but in general I think it's best if we keep discussion in public as much as possible.  I want to make sure we include whoever else is interested.  I certainly don't have all the answers.  :-)
> 
> I feel like we have a lot of good ideas, and our instincts are saying we can do this, but I know we have some details missing.  I'd also like to feel reasonably confident that the solution we come up with more generally supports other uses of the networking-sfc API.
> 
> What I'd like to see as a next step is a detailed end-to-end design for a simple use case that shows:
> 
> 1) A sample use of the networking-sfc API
> 
> 2) How we would reflect that in the OVN_Northbound database
> 
> 3) An explanation of the logical flows we would generate to implement what was specified in OVN_Northbound
> 
> 4) Docs on the "Life Cycle of a Packet through a Service Chain".  In ovn-architecture(7), there are several very detailed "Life Cycle" sections.  I feel this functionality could really benefit from a detailed walkthrough.
> 
> I feel like I had a pretty good idea of how this could work if all the ports were on the same logical switch.  I never figured out allowing ports in the chain to exist on separate logical switches.  It'd be nice to include that in the sample.  Or is that limitation a reasonable one to accept as a first cut?  If so, we might be able to move quickly on a first iteration based on the work I had done before.
> 
> --
> Russell Bryant
> 
> 
> On Wed, Mar 30, 2016 at 1:13 PM, John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>> wrote:
> Russell,
> 
> Let me try and answer your questions:
> 
>   1.  I looked at the networking-sfc API (http://docs.openstack.org/developer/networking-sfc/api.html#rest-api<https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openstack.org_developer_networking-2Dsfc_api.html-23rest-2Dapi&d=CwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ&m=bjFO8SzAuBNWXRgV8_NHbcEXferyEEOP15T70AuyNjY&s=1qDCEkqqbrKpNuK77WIr7RKYwEJPC5u7_m53C7-LSIU&e=>) and I think we can fit into it pretty easily. I would use the neutron port-pair-create and use the service-function-parameters option to pass in a type indicating service insertion and the application-id that the service would be inserted to. Port-pair-groups could be used to do simple chain – I think but needs more investigation.
>   2.  Yes, also interested in service insertion outside of Openstack, I implemented a set of ovn-nbctl commands to enable insertion outside of openstack. I have really used Openstack as the centralized management plane.
>   3.  As a “legacy” vendor :-), we would rather remain unaware of the NSH headers, though we would change if we can see good use cases that require the VNF to participate in the service chain.
> 
> I assume you will be at the Openstack Summit in Austin perhaps we could do a f2f there.
> 
> Would like to ask everyone on the list about potential use cases so we can make sure we can address the widest audience.
> 
> Regards
> 
> John
> 
> From: Russell Bryant <russell at ovn.org<mailto:russell at ovn.org>>
> Date: Tuesday, March 29, 2016 at 6:06 AM
> To: John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>>
> Cc: Ben Pfaff <blp at ovn.org<mailto:blp at ovn.org>>, "discuss at openvswitch.org<mailto:discuss at openvswitch.org>" <discuss at openvswitch.org<mailto:discuss at openvswitch.org>>
> Subject: Re: [ovs-discuss] [ovn4nfv]
> 
> On Mon, Mar 28, 2016 at 6:56 PM, John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>> wrote:
> Russell,
> 
> Thanks of taking the time to provide a detailed response. Let me try and answer your questions, and ask a few on my own.
> 
>   1.  Yes, I want to continue working through this as we see it really important to enable easy service insertion at scale. Think of the problem of how to deploy hundreds of VNF’s that can be scaled up/down with no manual intervention.
> 
> Fantastic.  :-)
> 
>   1.  The Neutron API I created was done for much the same reason as your prototype - seeing how hard it was and making sure I could get something to work. Creating and supporting yet another API is rarely a good idea and so aligning with the networking-sfc API is the right thing to do. I have had a few off-line conversations with that team and will continue to try and fit this under that umbrella as it evolves.
> 
> Great!  Do you have specific issues with their API?  I'd be interested to hear about what changes you think should be made.
> 
>   1.  I agree with you idea of a separate table, once again I just took what I could see was the shortest path to get something working for a prototype. I will take a look at your code and see how to implement an extra table.
> 
> I totally understand.  A prototype of something working is a great way to get the conversation going!
> 
> 
>   1.  The issue with routing between subnets to chain VNF’s could be looked at in three ways, 1) If each subnet has one or more VNF’s the problem  is easy; 2) If the application being protected is communicating with applications/hosts on a different subnet then the traffic is, I assume, forwarded the default router; 3) The hardest case is if the topology is such that all the VNF’s are placed in a shared subnet, then we would need to add additional information in the API  to direct traffic to that subnet, or OVN could look up the subnet based on logical port? - have not thought about it a lot but seems doable.
> 
> IP addresses are stored in the logical port "addresses" column.
> 
>   1.  The toughest question here is what is a VNF and does it operate at L3, L2, or as a transparent bump in the wire. The related question is how complex is the service chain of these virtual functions. I would disagree a little here with Russell and suggest that the approach is not for “legacy” VNF’s but transparent VNF’s that act as a “bump in the wire" from a networking POV. The issue becomes what are the specific use cases we want to design for with ovn4nfv.
> 
> I meant no harm by using the term "legacy".  :-)  I just needed a term to differentiate from the service chaining aware VNFs that expect some additional metadata.  RFC 7665 calls it a "SFC-unaware Service Function".
> 
> I think your "bump in the wire" use case makes sense.
> 
> I honestly don't have that strong of an opinion on what use cases to support.  I just want to support whatever it is actual users want.
> 
> Let me try to start to separate/segment some of the approaches:
> 
> I think there are several segments of the market for VNF’s and NFV. The two I see most are:
> 
>   1.  Carrier networks where they are focused on virtual provider/customer edge routers (vCPE, vPE), border network gateways (BNG) , for wired to wireless networks, and SD-WAN, which is related to vCPE/PE
>   2.  Public/private cloud data centers and virtual enterprises, where the use cases are centered around virtual load balancing/scaling and security.
> 
> The needs of both are different (IMHO), the need for the carriers is to enable the creation of large scale distributed virtual routers, leveraging MPLS and/or BGP as the core transport protocol. The goal for the carriers is to be able to customize their core routing infrastructure without waiting for a new release from their hardware vendors which can take years to get into production. Here the architecture of networking-sfc has it core strengths; with its focus on dynamic routing; as it acts similarly to the ingress/egress forwarding paths of a classical router. This enables carriers to build large scale dynamic distributed virtual routing infrastructure from virtual functions.
> 
> The needs in private/public cloud (and enterprises) are simpler as the requirements are to insert either a load-balancer or security VNF to scale up/down applications or secure applications. Here change can be rapid and the need is to deploy and scale up/down in minutes if not seconds in many instances.  I have been focusing on the use cases for the second segment as it is where we are seeing a need for simplicity and speed.
> 
> A typical use case we see a lot of is protecting east-west traffic, when an application is deployed, security is deployed with it to protect it, and when the application is removed, security is removed. The goal here is to deploy a “zero trust” security model. We have deployed a similar architecture very successfully with VMWare’s NSX product, we would now like to figure out how to do it in the open source environment.
> 
> We would prefer to be transparent to networking “bump in the wire” as this simplifies the interaction between the controller (OVN) and the VNF. The only information that is shared is the logical in and out ports for the VNF. Hence configuration requires less interactions between the networking infrastructure and the VNF/Controller, moving the VNF or application also becomes easier. It becomes a simple API interaction with minimal shared state between OVN and the VNF.
> 
> Does this make sense, it is just my rough attempt at breaking down the use cases into a more specific set of cases we can solve?
> 
> That's a nice breakdown.  I like the focus on the simpler case.  I always like when a feature can be broken down into smaller useful iterations.
> 
> From an OpenStack POV, I always come back to "what API are we implementing?".  You mention that networking-sfc is built in support of #1.  Do you think it can also support #2, or do you think another API is more appropriate?  If networking-sfc works, are there some reasonable limitations we can put in place to get a first version out?
> 
> Do you have interest in this functionality in OVN outside of OpenStack?
> 
> Also what other use cases should we consider?
> 
> There seems to be some industry interest in NSH based SFC.  It's not supported by OVS yet, but it should be on our radar.  I suppose it just comes back to eventually wanting to support SFC-aware VNFs that expect some metadata.
> 
> --
> Russell Bryant
> 
> 
> 
> --
> Russell Bryant