<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Inline…</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 10:33 AM, Mohammad Banikazemi <span dir="ltr"><<a href="mailto:mb@us.ibm.com" target="_blank">mb@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
<p><font face="sans-serif">Thanks Sumit and Stephen for information provided. </font><br>
<br>
<font face="sans-serif">It appears to me that we can (and should) use the notion of services/service chains within the group policy extension (and that has been always one of our options). If this is a reasonable approach, then we need to see how we can bring in these services to our group policy and if there are changes we may require.</font><br>
<br></p></div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif">Agreed. Our thinking was that the service instance, insertion context, and the service chain are elemental abstractions on which the policy could be layered upon.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><p>
<font face="sans-serif">The first thing that comes to mind is to have a new service insertion context, namely policy (or should it be policy_rule?). If that is in place, then a service chain (we can start with a chain of one single service) gets created with it's context set to a particular policy. </font></p>
</div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">The notion of a service insertion context is being introduced in this patch:</div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<a href="https://review.openstack.org/#/c/62599/16/neutron/db/service_context.py">https://review.openstack.org/#/c/62599/16/neutron/db/service_context.py</a></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Although the service insertion context need not necessarily be aware of the policy, I think the mapping is probably the other way around. The rendering of the policy would lead to a particular service insertion context for that service/chain.</div>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><p><font face="sans-serif">While the service plugin is responsible for standing up the service, the connectivity is established through the implementation of the group policy extension, in particular the "redirect" action. Is this a reasonable approach?</font></p>
</div></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Agreed.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><p><font face="sans-serif"> This approach requires some kind of coordination wrt how these operations are done by the service plugin and the group policy extension. May be a policy simply provides the insertion context for creation of the service chain (in isolation and by the appropriate service plugin) and policy rules are then used to make the service operational. This is different from how services are expected to be instantiated right now. Right? Thinking aloud here. Please comment.</font><br>
<br></p></div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif">Agreed. That said, the two models/workflows can very nicely coexist. The first one is using the elemental abstractions (service instances, chains, etc) where the user needs to manage each of them individually to realize the entire logical topology. The second option is where a group policy plugin interprets the policy, and proceeds to render that policy using the elemental abstractions (but might also perform the same directly on a backend that supports the policy model).</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><p>
<font face="sans-serif">A lot of interesting things to work on. May be Juno is where all these efforts come to fruition together :)</font><br>
<br></p></div></blockquote><div><div class="gmail_default" style="font-family:tahoma,sans-serif">Totally. We have been incubating some of these ideas for a while now, and hopefully its becoming more apparent as to why these constructs are required in Neutron.</div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><p>
<font face="sans-serif">Mohammad</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF610DFC54FDF8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Sumit Naiksatam ---02/17/2014 02:12:12 AM---Thanks Mohammad for bringing this up. I responded in anot"><font color="#424282" face="sans-serif">Sumit Naiksatam ---02/17/2014 02:12:12 AM---Thanks Mohammad for bringing this up. I responded in another thread: <a href="http://lists.openstack.org/pipe" target="_blank">http://lists.openstack.org/pipe</a></font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Sumit Naiksatam <<a href="mailto:sumitnaiksatam@gmail.com" target="_blank">sumitnaiksatam@gmail.com</a>></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">Mohammad Banikazemi/Watson/IBM@IBMUS, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Cc: </font><font size="1" face="sans-serif">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">02/17/2014 02:12 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [neutron][policy] Using network services with network policies</font><br>
</p><hr width="100%" size="2" align="left" noshade style="color:rgb(128,145,165)"><div><div class="h5"><br>
<br>
<br>
<tt><font>Thanks Mohammad for bringing this up. I responded in another thread:<br>
</font></tt><tt><font><a href="http://lists.openstack.org/pipermail/openstack-dev/2014-February/027306.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-February/027306.html</a></font></tt><tt><font><br>
<br>
~Sumit.<br>
<br>
On Sun, Feb 16, 2014 at 7:27 AM, Mohammad Banikazemi <<a href="mailto:mb@us.ibm.com" target="_blank">mb@us.ibm.com</a>> wrote:<br>
> During the last IRC call we started talking about network services and how<br>
> they can be integrated into the group Policy framework.<br>
><br>
> In particular, with the "redirect" action we need to think how we can<br>
> specify the network services we want to redirect the traffic to/from. There<br>
> has been a substantial work in the area of service chaining and service<br>
> insertion and in the last summit "advanced service" in VMs were discussed.<br>
> I think the first step for us is to find out the status of those efforts and<br>
> then see how we can use them. Here are a few questions that come to mind.<br>
> 1- What is the status of service chaining, service insertion and advanced<br>
> services work?<br>
> 2- How could we use a service chain? Would simply referring to it in the<br>
> action be enough? Are there considerations wrt creating a service chain<br>
> and/or a service VM for use with the Group Policy framework that need to be<br>
> taken into account?<br>
><br>
> Let's start the discussion on the ML before taking it to the next call.<br>
><br>
> Thanks,<br>
><br>
> Mohammad<br>
<br>
</font></tt><br>
</div></div><p></p></div>
</blockquote></div><br></div></div>