[openstack-dev] [neutron][chaining][policy] Port-oriented Network service chaining

Carlos Gonçalves mail at cgoncalves.pt
Tue Apr 15 19:07:39 UTC 2014


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140415/4b00492e/attachment.html>


More information about the OpenStack-dev mailing list