Open Stack

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, Balaji.P at freescale.com 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:mail at cgoncalves.pt] 
> 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 <kanzhe at gmail.com> 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 <mail at cgoncalves.pt> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>  
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140416/62a032c0/attachment.html>