Hi Carlos, IMHO, Neutron port abstraction for traffic steering API will be good option. Based on the Flows (SFC) created for SFC, we may need to have the frame-work which will take care of creating the OVS flows on the compute nodes for the SFC-Flows created.
We are interested in participating and contributing this BP and Framework. Regards, Balaji.P From: Carlos Gonçalves [mailto:[email protected]] Sent: Wednesday, April 16, 2014 12:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][chaining][policy] Port-oriented Network service chaining Hi Kanzhe, First off, thank you for showing interest in discussing this proposal! I'm not fully sure if I understood your point. Could you elaborate a bit more on the L1, L2, L3 part? Regarding the traffic steering API, as I see it the Neutron port is the virtual counterpart of the network interface and would allow L1, L2 and L3 steering within OpenStack. Within a single OpenStack deployment I think the Neutron port abstraction might be enough. Nevertheless in the API data model proposal we have the service function end point abstraction which can (eventually) be mapped to something else than a Neutron port (e.g., remote IP). Thanks, Carlos Goncalves On 15 Apr 2014, at 02:07, Kanzhe Jiang <[email protected]<mailto:[email protected]>> wrote: Hi Carlos, This is Kanzhe. We discussed your port-based SFC on the Neutron advanced service IRC. I would like to reach out to you to discuss a bit more. As you know, Neutron port is a logic abstraction for network interfaces with a MAC and IP address. However, network services could be used at different layers, L3, L2, or L1. In L3 case, each service interface could be easily mapped to a Neutron port. However, in the other two cases, there won't be a corresponding Neutron port. In your proposal, you mentioned DPI service. What is your thought? Neutron doesn't have traffic steering API. Is Neutron port the right abstraction to introduce traffic steering API? Or May Neutron need separate abstraction for such? Love to discuss more! Kanzhe On Tue, Mar 25, 2014 at 3:59 PM, Carlos Gonçalves <[email protected]<mailto:[email protected]>> wrote: Hi, Most of the advanced services and group policy sub-team members who attended last week's meeting should remember I promised to start a drafting proposal regarding network service chaining. This week I got to start writing a document which is accessible here: https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU It should not be considered a formal blueprint as it yet requires large discussion from the community wrt the validation (or sanity if you will) of the proposed idea. I will be joining the advanced service IRC meeting tomorrow, and the group policy IRC meeting thursday, making myself available to answer any questions you may have. In the meantime you can also start discussing in this email thread or commenting in the document. Thanks, Carlos Goncalves _______________________________________________ OpenStack-dev mailing list [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
