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 <russ...@ovn.org<mailto:russ...@ovn.org>> > Date: Wednesday, March 30, 2016 at 6:48 PM > To: John McDowall > <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> > Cc: Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>>, > "discuss@openvswitch.org<mailto:discuss@openvswitch.org>" > <discuss@openvswitch.org<mailto:discuss@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 > <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@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 <russ...@ovn.org<mailto:russ...@ovn.org>> > Date: Tuesday, March 29, 2016 at 6:06 AM > To: John McDowall > <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> > Cc: Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>>, > "discuss@openvswitch.org<mailto:discuss@openvswitch.org>" > <discuss@openvswitch.org<mailto:discuss@openvswitch.org>> > Subject: Re: [ovs-discuss] [ovn4nfv] > > On Mon, Mar 28, 2016 at 6:56 PM, John McDowall > <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@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 _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
