<div dir="ltr">GP should support applying policy on exist openstack deployment, so neither implicit mapping nor intercepting works well.<div><br><div>maybe the explicit associating model is best: associate EPG with exist neutron network object (policy automatically applied to all ports on it), or with single port object (policy applied only on this port). By this way GP will be more loosely coupled with Neutron core than the spec sample: boot vm from a grand-new EP object, which need rewrite nova vif-plug, and only support new deployment. It is suitable to put GP in orchestration layer, etc, Heat, without bothering nova code. Boot vm from EPG can be interpreted by ochestration with: 1) create port from network associated with EGP; 2) boot nova from port.  In the future we may also need a unified abstract policy template across compute/stroage/network.</div>
</div><div><br></div><div>And, it's not a good idea to intercept neutron port create api for implicitly EP binding(I don't know if this has been removed now), for it severely break the hierarchy relationship between GP and neutron core. the link from GP wiki to an ODL page clearly shows that GP should be layered on top of both neutron and ODL(1st graph). </div>
<div><br></div><div><a href="http://webcache.googleusercontent.com/search?q=cache:https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin#Relationship_with_OpenStack.2FNeutron_Policy_Model">http://webcache.googleusercontent.com/search?q=cache:https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin#Relationship_with_OpenStack.2FNeutron_Policy_Model</a><br>
</div><div>(this link has hidden all picture from this week so I have to give the google cache)</div></div>