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> 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) > 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> > Date: Tuesday, March 29, 2016 at 6:06 AM > To: John McDowall <jmcdow...@paloaltonetworks.com> > Cc: Ben Pfaff <b...@ovn.org>, "discuss@openvswitch.org" < > discuss@openvswitch.org> > Subject: Re: [ovs-discuss] [ovn4nfv] > > On Mon, Mar 28, 2016 at 6:56 PM, John McDowall < > 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
