Open Stack

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/20121027/8eeed2bf/attachment.html>