<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>Salvatore,</div>
<div><br>
</div>
<div>First, let's do not focus this framework on just one kind of Service, I know that is your plan but I wanted to make an emphasizes on that.</div>
<div><br>
</div>
<div>All agreed on the "routed mode".. Good job!</div>
<div><br>
</div>
<div>On the "in-path": From the networking point of view, a VM (service) could be connected between two networks in the same L2 domain and it is NOT considered "routing", basic networking concept. I did run this example last year with a Web Optimization service,
the two interfaces in the service should be in "stitching mode" (IP is not needed). So, let's keep this insertion mode in our proposal.</div>
<div><br>
</div>
<div>On the "out-of-path": This use case is too different from the previous one, in this one, we need L3 domain. The reason on having these three modes in because some services are available for any of these models, we need to be Generic in our proposal, otherwise
we will let some services out of the picture for Quantum.</div>
<div><br>
</div>
<div>I have already sent you a webex meeting details for tomorrow at 10:00am PST right after the LBaaS meeting. Let me know if you can attend it.</div>
<div><br>
</div>
<div>BTW. If you send me your figures in an editable format, I can draw the new ones and we could actually merged these two wikis in only one. I think we should do that.</div>
<div><br>
</div>
<div><a href="http://wiki.openstack.org/QuantumServicesInsertion">http://wiki.openstack.org/QuantumServicesInsertion</a></div>
<div><a href="http://wiki.openstack.org/Quantum/ServiceInsertion">http://wiki.openstack.org/Quantum/ServiceInsertion</a> </div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Edgar</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Monday, November 5, 2012 7:59 AM<br>
<span style="font-weight:bold">To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Quantum] Advanced service insertion<br>
</div>
<div><br>
</div>
<div>
<div>Hi Edgar,
<div><br>
</div>
<div>please see my replies inline.<br>
<br>
<div class="gmail_quote">On 2 November 2012 23:16, Edgar Magana (eperdomo) <span dir="ltr">
<<a href="mailto:eperdomo@cisco.com" target="_blank">eperdomo@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>
<div>Salvatore,</div>
<div><br>
</div>
<div>I am sorry it took me few days in collecting all the feedback for our team about the changes in your proposal but there are few guys here interested in this framework and instead of having multiples emails back and for, I decided to collect all the feedback.
Actually, I think we are getting closer to an agreement but few things are not completely clear yet.</div>
<div><br>
</div>
<div>1. The "routed mode" is just great. This is something that we missed in our proposal and we completely agree on it but this is not "in-path" service insertion, we can called routed mode or embedded mode but it is not the "in-path" one. Another question
on this mode, how does the router know which networks will be affected for the respective service, or just all of the network behind that router entity will be affected?</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>It depends on what do you mean by "affected". What I meant is actually just that the router defines the "scope" of the advanced service being attached. And the scope in that case would be the L3 domain defined by the router and all subnets attached to
it. However, whether an advanced service "affects" or not those subnets or particular ports on them is probably something that pertains the service itself. For instance, with Load Balancing, you explicitly nominate the ports that you want to be load balanced
(pool members concepts). Similarly, I believe that an edge firewall service might apply to the entire domain; but it is completely normal that might be a service that applies only to a specific subnet (I'm think of VPN hear, but bear in mind that I'm thinking
aloud!)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>
<div> </div>
<div><br>
</div>
<div>2. Actually, the next mode in your wiki, the one that you call "floating" is the "In-path" but you caveat, it should be just one L2 domain covered instead of two like in your diagram. </div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think there a slight difference as what we're describing here is both your 'in-path' mode or another mode, where the advanced service is placed between two subnets and still does routing, but is not associated with the default gateway for your network.
John Gruber has a good discussion of this an other use cases on his wiki page (<a href="http://wiki.openstack.org/NetworkLoadBalancingIntegrationsWithQuantum">http://wiki.openstack.org/NetworkLoadBalancingIntegrationsWithQuantum</a>).</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>
<div><br>
</div>
<div>3. The "out-of-path" insertion mode is missing, we need to have one case were the routing entity is forwarding packages to the "Advance Service", they get processed and then sent back to the router entity that will be delivering them to their final network(s).</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Isn't that what I'm describing above? Could it be that in-path and out-of-path can be merged in the same use case? Or is there something fundamentally different? </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>
<div> </div>
<div>4. For the API definition, having a new resource just named "Service" should be fine, I think we should merge "serviceType" and "ServiceDefinition" in only one dictionary.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I put them as two dicts to simplify the discussion, but I too do not see ServiceDefinition as worth becoming a resource on its own, </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>
<div> </div>
<div><br>
</div>
<div>Personally, I want to understand more about it and maybe having a call between us will help, what do you think? Should we schedule a Service Insertion meeting to finalize the design this Monday?</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think it makes sense to chat about this on Tuesday either during or after the LBaaS call. This is because in that call you'll find all the other people interested in this topic.</div>
<div>I'd like however to establish a reasonable subset of topic on which there's widespread agreement and start straight with the implementation. We need to give people implementing advanced service for Quantum a minimum framework for deploying them; once we
have a minimum, but reasonable, set of framework to implement, we should keep having discussion on the remaining topic on which we have been unable to agree so far.</div>
<div><br>
</div>
<div>I think that the choices to make, with regards to G-1 are:</div>
<div>1) Which insertion modes support (this is from the tenant's perspective)</div>
<div>2) What should be the best solution for dispatching API calls to the plugin (or plugins)?</div>
<div><br>
</div>
<div>Salvatore</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>
<div><br>
</div>
<div>Thanks a lot,</div>
<div><br>
</div>
<div>Edgar</div>
</div>
<div><br>
</div>
<span>
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<div class="im"><span style="font-weight:bold">From: </span>Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
</div>
<span style="font-weight:bold">Date: </span>Tuesday, October 30, 2012 8:11 AM<br>
<span style="font-weight:bold">To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Quantum] Advanced service insertion<br>
</div>
<div>
<div class="h5">
<div><br>
</div>
<div>
<div>Hi,
<div><br>
</div>
<div>I have updated the specification for the service insertion trying the feedback from the community [3].</div>
<div>I did my best to listen to the concerns expressed by Eugene and his team, which came out with this alternative spec [1].</div>
<div>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])</div>
<div><br>
</div>
<div>I am finishing up the last details, including a list of work items that reasonably needs to be addressed.</div>
<div>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.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Salvatore</div>
<div><br>
</div>
<div>[1] <a href="http://wiki.openstack.org/Quantum/ServiceIntegration" target="_blank">wiki.openstack.org/Quantum/ServiceIntegration</a></div>
<div>[2] <a href="http://wiki.openstack.org/QuantumServicesInsertion" target="_blank">wiki.openstack.org/QuantumServicesInsertion</a></div>
<div>[3] <a href="http://wiki.openstack.org/Quantum/ServiceInsertion" target="_blank">http://wiki.openstack.org/Quantum/ServiceInsertion</a><br>
<br>
<div class="gmail_quote">On 27 October 2012 09:53, Salvatore Orlando <span dir="ltr">
<<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<div class="gmail_quote">
<div>On 27 October 2012 02:29, Edgar Magana (eperdomo) <span dir="ltr"><<a href="mailto:eperdomo@cisco.com" target="_blank">eperdomo@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="font-size:14px;font-family:Calibri,sans-serif">Salvatore,</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">It would be great if you could include in this proposal the previous Services Insertion BP:</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><a href="https://blueprints.launchpad.net/quantum/+spec/services-insertion-wrapper" target="_blank">https://blueprints.launchpad.net/quantum/+spec/services-insertion-wrapper</a></div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">It is also fully described here:</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><a href="http://wiki.openstack.org/QuantumServicesInsertion" target="_blank">http://wiki.openstack.org/QuantumServicesInsertion</a></div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>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.</div>
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">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: </div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>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.</div>
<div>I guess the code is in the Cisco plugin only?</div>
<div><br>
</div>
<div>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.</div>
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">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.</div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>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.</div>
<div>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.</div>
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">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:</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><a href="http://wiki.openstack.org/quantum-l3" target="_blank">http://wiki.openstack.org/quantum-l3</a></div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>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.</div>
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="font-size:14px;font-family:Calibri,sans-serif"></div>
<div><font face="Calibri,sans-serif">In terms of Tenant vs Provider perspective, what is exactly the proposal? Is this API tenant facing, provider or both?</font></div>
<div><font face="Calibri,sans-serif">I</font><font face="Calibri,sans-serif"> believe it should be for both, you can have services insertion at SP level and also per tenants.</font></div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>On this topic I am also fairly open. We give a default policy, but then the actual roles will vary from deployment to deployment.</div>
<div>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)</div>
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">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?</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">Scenario 1 in slide 14 is great, actually this is what we call In-Path service insertion, so we are in the same page.</font></div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>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.</div>
<div>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.</div>
<div>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).</div>
<div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">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?</font></div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>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.</div>
<div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><font face="Calibri,sans-serif">Scenario 3 is actually the realistic one, is what we call Out-of-Path service insertion, so we are good there.</font></div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>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.</div>
<div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">I</font><font face="Calibri,sans-serif"> 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?</font></div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>I am referring to the API for enabling or disabling services that the provider has made available within a service type. </div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="word-wrap:break-word">
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">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.</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">Thanks,</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<div style="font-size:14px;font-family:Calibri,sans-serif">Edgar Magana</div>
<div style="font-size:14px;font-family:Calibri,sans-serif"><br>
</div>
<span style="font-size: 14px; font-family: Calibri, sans-serif; ">
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<span style="font-weight:bold">From: </span>Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, October 23, 2012 5:15 PM<br>
<span style="font-weight:bold">To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>
<div><br>
<span style="font-weight:bold">Subject: </span>[openstack-dev] [Quantum] Advanced service insertion<br>
</div>
</div>
<div>
<div>
<div><br>
</div>
<div>
<div>
<div>Hi all,</div>
<div><br>
</div>
The blueprint for advanced services insertion has been registered and can be found here: <a href="https://blueprints.launchpad.net/quantum/+spec/quantum-service-insertion" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-service-insertion</a>
<div>The design specification is about 75% complete - your feedback is more than welcome.</div>
<div><br>
</div>
<div>Please use this email thread for discussing design details, unless you feel there's a more suitable medium.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Salvatore</div>
</div>
</div>
</div>
</div>
</span></div>
<br>
</div>
<div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</span></div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</body>
</html>