[Engine-devel] port mirroring REST API
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. Thanks, Livnat
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 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
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
-- Michael Pasternak RedHat, ENG-Virtualization R&D
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
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
On 21.05.12 16:36, Michael Pasternak wrote:
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. Michael this mean that we are using Livnats design:
<nic> ... <network href="/api/networks/{network-id}" id="{network-id}"/> <port-mirroring> <network href="/api/networks/{network-id}" id="{network-id}"/> .... </port mirroring> </nic> and the engine stays with the same api, which mean that we need to "translate" to the engine the value true in VmInterface and "translate" back from the engine from boolean to network. is that ok with you?
Thanks, Livnat
--
Michael Pasternak RedHat, ENG-Virtualization R&D
--
Michael Pasternak RedHat, ENG-Virtualization R&D
On 05/21/2012 04:37 PM, Shahar Havivi wrote:
in this case +1 on your design. Michael this mean that we are using Livnats design:
yes
<nic> ... <network href="/api/networks/{network-id}" id="{network-id}"/> <port-mirroring> <network href="/api/networks/{network-id}" id="{network-id}"/> .... </port mirroring> </nic>
and the engine stays with the same api, which mean that we need to "translate" to the engine the value true in VmInterface and "translate" back from the engine from boolean to network. is that ok with you?
yep. -- Michael Pasternak RedHat, ENG-Virtualization R&D
participants (3)
-
Livnat Peer -
Michael Pasternak -
Shahar Havivi