<div dir="ltr"><div>Hi Reedip,</div>Please see my comments inline<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 9:19 AM, reedip banerjee <span dir="ltr"><<a href="mailto:reedip14@gmail.com" target="_blank">reedip14@gmail.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 dir="ltr"><div>While reading up the specs in [1] and [2], there are certain things which we may need to discuss before proceeding forward</div><div><br></div><div>a) Reference point for Ingress/Egress traffic:</div><div>There may be some confusion related to how we are labelling</div><div>Ingress and Egress ( is it with respect to a VM, with a switch , </div><div>or any other entity).</div><div>As we are looking from "Inside the VM" and not from "Inside the Network",</div><div>that needs to be made clear.</div></div></blockquote><div>I think it worth to be consistent with other neutron features, for example with Security Groups </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 dir="ltr"><div><br></div><div>b) How to perceive TaaS:</div><div>In the section "Proposed Changes" Taas has been compared with a Core Neutron</div><div>Plugin ( L3-Router) and a plugin which has emerged out of Neutron ( Neutron LBaaS).</div><div>This might cause confusion to the reviewers. It would be better that we decide </div><div>how we would like to demonstrate TaaS:</div><div>- Is it a plugin which can be integrated with the Neutron Core</div><div>- Or is it an extension of the Core Neutron Services which can be used by selected users</div><div><br></div><div>Based on the decision, we can modify the explanation to make the spec a bit more streamed.</div></div></blockquote><div>I think it's advanced service adding value to the core neutron. </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 dir="ltr"><div><br></div><div>c) Device Owner for TaaS:</div><div>- If Tap Service creates a "destination" port, the port would have a device owner</div><div>of the format of "network:tap"</div><div>- If the "destination" port is now connected to a VM and the VM is booted up, nova </div><div>changes the owner to "compute:nova"</div></div></blockquote><div>Probably the difference will be if TaaS is allowed to remove this port or not. </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 dir="ltr"><div><br></div><div># Is there any impact of the change of the device_owner</div><div># If there is an impact, should there be a change in nova so that the device_owner is not modified</div><div># When in the future, TaaS supports user providing an "already created port" should the device owner </div><div>be checked and modified?</div><div><br></div><div>d) Outcome of Deleting the VM where TaaS operates</div><div>Following might be added to the Spec: </div><div><br></div><div>1. Deletion of the VM (and port attched to it) from which we were mirroring (source of the mirror):</div><div>In this case we would do a cascade delete of the 'Tap_Flow' instances that were associated with the port that was deleted.</div></div></blockquote><div>Are you sure you want to delete the Flow? Maybe it should reflect the status of being not operational any more. I personally  do not think user created resource should be deleted without explicit user operation.</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 dir="ltr"><div><br></div><div>2. Deletion of the VM (and port attched to it) to which we were mirroring (Destination of the mirror):</div><div>In this case we would do a cascade delete of the 'Tap_Service' instance that was associated with the port that was deleted.</div></div></blockquote><div>Same as previous comment. </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 dir="ltr"><div><br></div><div>e) Making the API independent of OpenVSwitch</div><div>As per our last discussion [3], it is better that w esplit our implementation for TaaS, </div><div>so that</div><div> # the focus is not limited to OpenVSwitch, which may be a point of concern during review</div><div> # allow other vendors to create thier own pluggable implementation</div></div></blockquote><div>+1 </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 dir="ltr"><div><br></div><div>f) Choice of Tapping before/after Sec Groups</div><div><br></div><div>Security Groups can filter a lot , and implementing TaaS before or after the SG</div><div>can impact the overall monitoring.</div><div>As referenced in [1], we can provide this option as a future course of work, and </div><div>in the meanwhile specify the option which we are working upon  ( Before or After) </div><div>in the spec, to make it clear.</div><div><br></div></div></blockquote><div>I think it can be the TapFlow attribute, lets say 'position' that can be either 'port' or 'vNIC'.</div><div> <b>'vnic' </b>to<span style="font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent"> capture ingress traffic after it passed inbound SG filters and egress traffic before it passes outbound SG filters</span></div><span id="docs-internal-guid-86ec252a-747d-31bb-1583-45d592e8a821"><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(0,0,0);font-weight:700;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">'port' </span><span style="font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">to</span><span style="font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent"> capture ingress traffic before it passed inbound SG filters and egress traffic after it passes outbound SG filters</span></p><div><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent"><br></span></div></span><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 dir="ltr"><div><br></div><div><br></div><div>[1]:<a href="https://review.openstack.org/#/c/96149/8/specs/juno/tap-as-a-service.rst" target="_blank">https://review.openstack.org/#/c/96149/8/specs/juno/tap-as-a-service.rst</a></div><div>[2]:<a href="https://review.openstack.org/#/c/256210/5/specs/mitaka/tap-as-a-service.rst" target="_blank">https://review.openstack.org/#/c/256210/5/specs/mitaka/tap-as-a-service.rst</a></div><div>[3]:<a href="http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-03-02-06.33.log.txt" target="_blank">http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-03-02-06.33.log.txt</a></div><span class=""><font color="#888888"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div>Thanks and Regards,<br>Reedip Banerjee</div><div>IRC: reedip</div><div><br></div><div><br><br><br></div></div></div></div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>