Ben, Thanks I wondered why I did not hear from him.
One of the other questions he asked was about either adding a new table for SFC. If we did that I would assume it would be before Ingress Table 4: Destination Lookup, as it would override existing destinations. Right now I have implemented roughly the same thing by giving the SFC rules a higher priority. Also I have skeleton networking-sfc driver implemented for OVN, that uses my existing changes to ovn-northd - but there are a lot of corner cases and other aspects to work through. Regards John On 4/18/16, 12:44 PM, "Ben Pfaff" <b...@ovn.org> wrote: >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://urldefense.proofpoint.com/v2/url?u=https-3 >>A__github.com_doonhammer_ovs_blob_master_ovn_ovn-2Darchitecture.7.xml&d=C >>wIDaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1 >>ED54jEjvAE36A8TVJroVlrOQ&m=lKkgUGfwpdf40pGt5ho8vfQruHa9W_C-SOB4ZbzEM1s&s= >>C4q9xqoNtYkg-EXfHNArcsTb-6wu1idMltqzgvalMhA&e= > >> >>ovn-nb.xml<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.co >>m_doonhammer_ovs_blob_master_ovn_ovn-2Dnb.xml&d=CwIDaQ&c=V9IgWpI5PvzTw83U >>yHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ >>&m=lKkgUGfwpdf40pGt5ho8vfQruHa9W_C-SOB4ZbzEM1s&s=XtZo_6uqSmqLeePpc6zX4jzY >>3wVZLMZCM0H3mtQwa28&e= > >> >> 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 >>(https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openstack.org_d >>eveloper_networking-2Dsfc_api.html-23rest-2Dapi&d=CwIDaQ&c=V9IgWpI5PvzTw8 >>3UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlr >>OQ&m=lKkgUGfwpdf40pGt5ho8vfQruHa9W_C-SOB4ZbzEM1s&s=0p76aZBJqBZOu0Jz3KHIFv >>ewgtRiNpkN0Hc9DA9MloE&e= >><https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openstack.org_d >>eveloper_networking-2Dsfc_api.html-23rest-2Dapi&d=CwMFaQ&c=V9IgWpI5PvzTw8 >>3UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlr >>OQ&m=bjFO8SzAuBNWXRgV8_NHbcEXferyEEOP15T70AuyNjY&s=1qDCEkqqbrKpNuK77WIr7R >>KYwEJPC5u7_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
