Open Stack

Hi,

I have updated the specification for the service insertion trying the
feedback from the community [3].
I did my best to listen to the concerns expressed by Eugene and his team,
which came out with this alternative spec [1].
Also, I did explicitly take into account also the thoughts contained in a
presentation from Edgar at the Boston summit (related wiki page at [2])

I am finishing up the last details, including a list of work items that
reasonably needs to be addressed.
I would like to leverage today's LBaaS meeting to sort out priorities, as
load balancing is depending on this feature; but feel free to comment on
this email thread or reach out to me on the IRC channel.

Regards,
Salvatore

[1] wiki.openstack.org/Quantum/ServiceIntegration
[2] wiki.openstack.org/QuantumServicesInsertion
[3] http://wiki.openstack.org/Quantum/ServiceInsertion

On 27 October 2012 09:53, Salvatore Orlando <sorlando at nicira.com> wrote:

>
> On 27 October 2012 02:29, Edgar Magana (eperdomo) <eperdomo at cisco.com>wrote:
>
>>  Salvatore,
>>
>>  It would be great if you could include in this proposal the previous
>> Services Insertion BP:
>>
>> https://blueprints.launchpad.net/quantum/+spec/services-insertion-wrapper
>>
>>  It is also fully described here:
>>  http://wiki.openstack.org/QuantumServicesInsertion
>>
>
> I am aware of this blueprint, which was presented at the Essex summit in
> Boston. Within certain limits, the work that we've done for presenting this
> new blueprint includes also the thoughts in that blueprint.
>
>
>>
>>  I see a lot of common work between these two proposals, actually this
>> one should be an extension of previous BP instead of having a new one. The
>> mayor point of contribution in your BP is the API side that in the previous
>> summit we decided to not targeted but for Grizzly is a great opportunity.
>> So, in terms of common areas I found these ones:
>>
>
> I looked for your blueprint, but could not find it. The reason for this,
> now that I see it, is that the blueprint is marked as implemented.
> I guess the code is in the Cisco plugin only?
>
> And I do apologise again for not giving you the right credit for this
> work. It was not our intention to "steal" work performed by other members
> of the community.
>
>
>>
>>  You described three insertion points: network-level, router-level and
>> port-level. The first and the second ones are exactly on the same lines
>> that what is explained in the previous BP named as: In-Path (Bump in the
>> Wire) and Out-of-Path (Redirection) insertion models, the third one is a
>> new one and I completely agree with it.
>>
>
> And actually the port-level insertion is a bit out of topic in my
> blueprint as I think it is best described as attributes you apply to ports.
> I know the models are similar - you might now believe it, but I've
> actually looked at your work :) - but also slightly different as the
> advanced services are not independent objects which are inserted in the
> topology. We left the topology very simple (logical routers + logical
> switches), which is also equivalent to the concepts of L3 domains and L2
> domains proposed by Sasha.
>
>
>>
>>  I don’t think that floating IPs is really a good example of Services
>> Insertion, it is just a functionality that it was needed for nova parity
>> but a formal L3 service is indeed required. We could also take a look to
>> the work that Sumit presented last summit:
>>  http://wiki.openstack.org/quantum-l3
>>
>>
> I'm trying to be very programatic, and consider as L3 only the mere
> Layer-3 forwarding. This will allow us to define service offerings which
> can potentially have different providers for every possible functionality.
> This unless we decide that SNAT/DNAT are capabilities that should be
> offered by the basic L3 service. I think most, if not all, of the thoughts
> in Sumit's presentation are faithfully represented by the implementation
> that is shipped as an extension in Folsom.
>
>
>>  In terms of Tenant vs Provider perspective, what is exactly the
>> proposal? Is this API tenant facing, provider or both?
>> I believe it should be for both, you can have services insertion at SP
>> level and also per tenants.
>>
>
> On this topic I am also fairly open. We give a default policy, but then
> the actual roles will vary from deployment to deployment.
> The idea is that admin will define the "service offerings", whereas
> tenants insert services in their logical L2/L3 networks. So for instance a
> tenant creates a router and chooses the service offering. In that service
> offering, the provider has specified which services the tenant can enable,
> and has also specified how those service should be provide (a detail that
> the tenant should not be concerned wide)
>
>
>>
>>  API description in slide 10 is not really clear, I think we should just
>> have one resource, SERVICE with all required CRUD operations, what do you
>> think? Could you explain a little bit more on this area?
>>
>>  Scenario 1 in slide 14 is great, actually this is what we call In-Path
>> service insertion, so we are in the same page.
>>
>
> Correct. The only difference is that the idea here is to not actually
> "plug" the service into the path between the router and the networks, but
> rather "attach" the service to the router itself.
> It might seem only a technical detail, but the goal is to avoid the
> sprawling of complex virtual topologies which end up replicating the
> complexity of the physical data centre.
> The L2/L3 topology which came out of the Folsom release, together with
> service insertion, represent a "blueprint" for a virtual network topology
> with rich capabilties; tenant can then define arbitrary topologies by
> replicating this "blueprint" (but this is post-grizzly work).
>
>
>>  Scenario 2 in slide 15 is not very clear, how the traffic is redirected
>> to the LB services in this example? Could you bring some light on this?
>>
>
> Yeah, as I said in the summit session I love to make things more complex
> than what they should be. The scenario I am describing on the right part of
> the slide would be one where you perform load balancing across ports on the
> same network (basically both the VIPs and the services are on the same
> network). This is what happens when you do load balancing in a "Flat"
> network - if you do that (one-arm) on a Quantum network, you'll end up with
> scenario 3.
>
>
>
>> Scenario 3 is actually the realistic one, is what we call Out-of-Path
>> service insertion, so we are good there.
>>
>
> Yes. One difference I've noticed is that in you blueprint all the services
> behind a gateway, which I believe is still part of the topology itself. In
> the slides you're referring to instead, the router providing load balancing
> only has VIPs attached directly to the external network.
>
>
>>
>>  I think the API should be exclusively for managing services insertion
>> but in slide 18 you mention "Tenant APIs for handling services types" what
>> do you mean with that? How different is that one from the SP one?
>>
>
> I am referring to the API for enabling or disabling services that the
> provider has made available within a service type.
>
>
>>  We did not have enough time during the summit to discuss about this but
>> I hope we can continue this discussion over the mailing list. This is a
>> very exiting work and we want to work together on the development.
>>
>>  Thanks,
>>
>>  Edgar Magana
>>
>>   From: Salvatore Orlando <sorlando at nicira.com>
>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>> Date: Tuesday, October 23, 2012 5:15 PM
>> To: OpenStack List <openstack-dev at lists.openstack.org>
>>
>> Subject: [openstack-dev] [Quantum] Advanced service insertion
>>
>>   Hi all,
>>
>>  The blueprint for advanced services insertion has been registered and
>> can be found here:
>> https://blueprints.launchpad.net/quantum/+spec/quantum-service-insertion
>> The design specification is about 75% complete - your feedback is more
>> than welcome.
>>
>>  Please use this email thread for discussing design details, unless you
>> feel there's a more suitable medium.
>>
>>  Regards,
>> Salvatore
>>
>> _______________________________________________
>> 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/20121030/1afef67d/attachment-0001.html>