<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">


<div>On Fri, Aug 8, 2014 at 5:38 PM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">




<div> One advantage of the service plugin is that one can leverage the neutron common framework such as Keystone authentication where common scoping is done. It would be important in the policy type of framework to have such scoping</div>








</div></div></div></blockquote><div><br></div></div><div>The framework you're referring to is common and already reusable, it's not a prerogative of Neutron.</div></div></div></div></blockquote><div><br></div></div>


<div>
Are you suggesting that Service Plugins, L3, IPAM etc become individual endpoints, resulting in redundant authentication round-trips for each of the components.</div><div><br></div><div>Wouldn't this result in degraded performance and potential consistency issues?</div>


</div></div></div></blockquote><div><br></div><div>The endpoint - in the OpenStack lingo - that exposes the API abstractions (concepts and operations) can be, logically and physically, different from the worker that implements these abstractions; authentication is orthogonal to this and I am not suggesting what you mention.</div>


</div></div></div>