Hi Balaji, Great! Thank you!
Feel free to join us today at the Neutron Advanced Services sub-team IRC meeting[1] where we should continue discussing a bit more on this BP. Cheers, Carlos Goncalves [1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices On 16 Apr 2014, at 06:11, [email protected] wrote: > 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]> 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]> 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] > 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 > > _______________________________________________ > OpenStack-dev mailing list > [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
