Hi Livnat, On 05/21/2012 02:55 PM, Livnat Peer wrote: > Hi All, > > After digging into the port mirroring feature I suggest a different > modeling of it in the API. > > The current modeling is to add to vnic a boolean property of > port-mirroring, e.g. > > api/vms/{vm-id}/nics > > <nics> > <nic> > ... > <network href="/api/networks/{network-id}" id="{network-id}"/> > <port-mirroring> true </port mirroring> > </nic> > </VM> > > This modeling imply 2 limitations: > 1. The vnic must be connected to the network it wants to monitor > 2. the nic can mirror only a single network > > Both of the above limitations are correct to the current implementation. > Going forward we might want to introduce the above functionalities and > the above modeling won't hold. > Instead of the above I suggest to change the port-mirroring property to > a list of networks. > > <nics> > <nic> > ... > <network href="/api/networks/{network-id}" id="{network-id}"/> > <port-mirroring> > <network href="/api/networks/{network-id}" id="{network-id}"/> > .... > </port mirroring> > </nic> > </VM> > > In this version we'll validate that the network under port-mirroring is > equal to the network the vnic is connected to, in future versions we can > remove this validation without changing the API. iiuc you saying that in future vnic might be connected to several networks simultaneously?

> > > > Thanks, Livnat -- Michael Pasternak RedHat, ENG-Virtualization R&D

On 05/21/2012 03:54 PM, Shahar Havivi wrote: > On 21.05.12 15:38, Michael Pasternak wrote: >> >> Hi Livnat, >> >> On 05/21/2012 02:55 PM, Livnat Peer wrote: >>> Hi All, >>> >>> After digging into the port mirroring feature I suggest a different >>> modeling of it in the API. >>> >>> The current modeling is to add to vnic a boolean property of >>> port-mirroring, e.g. >>> >>> api/vms/{vm-id}/nics >>> >>> <nics> >>> <nic> >>> ... >>> <network href="/api/networks/{network-id}" id="{network-id}"/> >>> <port-mirroring> true </port mirroring> >>> </nic> >>> </VM> >>> >>> This modeling imply 2 limitations: >>> 1. The vnic must be connected to the network it wants to monitor >>> 2. the nic can mirror only a single network >>> >>> Both of the above limitations are correct to the current implementation. >>> Going forward we might want to introduce the above functionalities and >>> the above modeling won't hold. >>> Instead of the above I suggest to change the port-mirroring property to >>> a list of networks. >>> >>> <nics> >>> <nic> >>> ... >>> <network href="/api/networks/{network-id}" id="{network-id}"/> >>> <port-mirroring> >>> <network href="/api/networks/{network-id}" id="{network-id}"/> >>> .... >>> </port mirroring> >>> </nic> >>> </VM> >>> >>> In this version we'll validate that the network under port-mirroring is >>> equal to the network the vnic is connected to, in future versions we can >>> remove this validation without changing the API. >> >> iiuc you saying that in future vnic might be connected to several >> networks simultaneously? > yes, maybe in next version in this case, api should be changed as at the moment we permit single network peer vnic, another option may be: <nics> <nic> ... <networks> <network href="/api/networks/{network-id}" id="{network-id}"> <port-mirroring> true </port_mirroring> </network> <network href="/api/networks/{network-id}" id="{network-id}"> <port-mirroring> true </port_mirroring> </network> </networks> </nic> </nics> this way we won't have to double network references, only disadvantage of this approach is abuse of network link, but we already have such precedents in api.

>> >>> >>> >>> >>> Thanks, Livnat >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D

On 05/21/2012 04:22 PM, Livnat Peer wrote: > On 21/05/12 16:19, Michael Pasternak wrote: >> On 05/21/2012 03:54 PM, Shahar Havivi wrote: >>> On 21.05.12 15:38, Michael Pasternak wrote: >>>> >>>> Hi Livnat, >>>> >>>> On 05/21/2012 02:55 PM, Livnat Peer wrote: >>>>> Hi All, >>>>> >>>>> After digging into the port mirroring feature I suggest a different >>>>> modeling of it in the API. >>>>> >>>>> The current modeling is to add to vnic a boolean property of >>>>> port-mirroring, e.g. >>>>> >>>>> api/vms/{vm-id}/nics >>>>> >>>>> <nics> >>>>> <nic> >>>>> ... >>>>> <network href="/api/networks/{network-id}" id="{network-id}"/> >>>>> <port-mirroring> true </port mirroring> >>>>> </nic> >>>>> </VM> >>>>> >>>>> This modeling imply 2 limitations: >>>>> 1. The vnic must be connected to the network it wants to monitor >>>>> 2. the nic can mirror only a single network >>>>> >>>>> Both of the above limitations are correct to the current implementation. >>>>> Going forward we might want to introduce the above functionalities and >>>>> the above modeling won't hold. >>>>> Instead of the above I suggest to change the port-mirroring property to >>>>> a list of networks. >>>>> >>>>> <nics> >>>>> <nic> >>>>> ... >>>>> <network href="/api/networks/{network-id}" id="{network-id}"/> >>>>> <port-mirroring> >>>>> <network href="/api/networks/{network-id}" id="{network-id}"/> >>>>> .... >>>>> </port mirroring> >>>>> </nic> >>>>> </VM> >>>>> >>>>> In this version we'll validate that the network under port-mirroring is >>>>> equal to the network the vnic is connected to, in future versions we can >>>>> remove this validation without changing the API. >>>> >>>> iiuc you saying that in future vnic might be connected to several >>>> networks simultaneously? >>> yes, maybe in next version >> >> in this case, api should be changed as at the moment we permit single network >> peer vnic, another option may be: >> >> <nics> >> <nic> >> ... >> <networks> >> <network href="/api/networks/{network-id}" id="{network-id}"> >> <port-mirroring> true </port_mirroring> >> </network> >> <network href="/api/networks/{network-id}" id="{network-id}"> >> <port-mirroring> true </port_mirroring> >> </network> >> </networks> >> </nic> >> </nics> >> >> this way we won't have to double network references, only disadvantage >> of this approach is abuse of network link, but we already have such >> precedents in api. > > Hi Michael, > > One of the issues I raised was to avoid association between the network > the nic is attached to and the networks the nic can monitor. > > The implementation in VDSM does not require that the nic will be > connected to the network in order to monitor it. So going forward we > might connect the VM nic to intrusion-detection-network while the > monitoring will be for red network and blue network. > > > Thanks, Livnat in this case +1 on your design.

> > >> >>>> >>>>> >>>>> >>>>> >>>>> Thanks, Livnat >>>> >>>> >>>> -- >>>> >>>> Michael Pasternak >>>> RedHat, ENG-Virtualization R&D >> >> > -- Michael Pasternak RedHat, ENG-Virtualization R&D