Open Stack

Hi Reedip,
Please see my comments inline

On Tue, Mar 8, 2016 at 9:19 AM, reedip banerjee <reedip14 at gmail.com> wrote:

> While reading up the specs in [1] and [2], there are certain things which
> we may need to discuss before proceeding forward
>
> a) Reference point for Ingress/Egress traffic:
> There may be some confusion related to how we are labelling
> Ingress and Egress ( is it with respect to a VM, with a switch ,
> or any other entity).
> As we are looking from "Inside the VM" and not from "Inside the Network",
> that needs to be made clear.
>
I think it worth to be consistent with other neutron features, for example
with Security Groups

>
> b) How to perceive TaaS:
> In the section "Proposed Changes" Taas has been compared with a Core
> Neutron
> Plugin ( L3-Router) and a plugin which has emerged out of Neutron (
> Neutron LBaaS).
> This might cause confusion to the reviewers. It would be better that we
> decide
> how we would like to demonstrate TaaS:
> - Is it a plugin which can be integrated with the Neutron Core
> - Or is it an extension of the Core Neutron Services which can be used by
> selected users
>
> Based on the decision, we can modify the explanation to make the spec a
> bit more streamed.
>
I think it's advanced service adding value to the core neutron.

>
> c) Device Owner for TaaS:
> - If Tap Service creates a "destination" port, the port would have a
> device owner
> of the format of "network:tap"
> - If the "destination" port is now connected to a VM and the VM is booted
> up, nova
> changes the owner to "compute:nova"
>
Probably the difference will be if TaaS is allowed to remove this port or
not.

>
> # Is there any impact of the change of the device_owner
> # If there is an impact, should there be a change in nova so that the
> device_owner is not modified
> # When in the future, TaaS supports user providing an "already created
> port" should the device owner
> be checked and modified?
>
> d) Outcome of Deleting the VM where TaaS operates
> Following might be added to the Spec:
>
> 1. Deletion of the VM (and port attched to it) from which we were
> mirroring (source of the mirror):
> In this case we would do a cascade delete of the 'Tap_Flow' instances that
> were associated with the port that was deleted.
>
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.

>
> 2. Deletion of the VM (and port attched to it) to which we were mirroring
> (Destination of the mirror):
> In this case we would do a cascade delete of the 'Tap_Service' instance
> that was associated with the port that was deleted.
>
Same as previous comment.

>
> e) Making the API independent of OpenVSwitch
> As per our last discussion [3], it is better that w esplit our
> implementation for TaaS,
> so that
>  # the focus is not limited to OpenVSwitch, which may be a point of
> concern during review
>  # allow other vendors to create thier own pluggable implementation
>
+1

>
> f) Choice of Tapping before/after Sec Groups
>
> Security Groups can filter a lot , and implementing TaaS before or after
> the SG
> can impact the overall monitoring.
> As referenced in [1], we can provide this option as a future course of
> work, and
> in the meanwhile specify the option which we are working upon  ( Before or
> After)
> in the spec, to make it clear.
>
> I think it can be the TapFlow attribute, lets say 'position' that can be
either 'port' or 'vNIC'.
 *'vnic' *to capture ingress traffic after it passed inbound SG filters and
egress traffic before it passes outbound SG filters

'port' to capture ingress traffic before it passed inbound SG filters and
egress traffic after it passes outbound SG filters


>
> [1]:
> https://review.openstack.org/#/c/96149/8/specs/juno/tap-as-a-service.rst
> [2]:
> https://review.openstack.org/#/c/256210/5/specs/mitaka/tap-as-a-service.rst
> [3]:
> http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-03-02-06.33.log.txt
>
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedip
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/c8beee31/attachment.html>