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
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
