[16:07] <joehuang> #info today's agenda: IP movement between OpenStack instances, Cross Neutron L2/L3 networking for heart-beat/state(session)replication
[16:08] <joehuang> #info if we have time, then image replication between OpenStack instances
[16:10] <joehuang> How about address-pair to be used in the IP movement to archieve the HA for VNF across OpenStack
[16:15] <joehuang> the IP address to communicate with other VNF/PNF should be an IP address from provider network
[16:15] <joehuang> because the VNF has to talk to PNF at the pratical deployment
[16:26] <sorantis> but do we necessarily need to automate this with provider network devices?
[16:29] <sorantis> I guess, you can configure the physical router prior to, let’s say MME deployment? and then provide the configured IP addresses upon deployment of MME.
[16:31] <sorantis> you can have a separate tool working with that specific provider physical hardware and producing these IP addresses, that later on could be used as deployment parameters for MME
[16:31] <sorantis> if you mean that this tool is part of VNFM then yes
[16:32] <sorantis> on the other hand why should VNFM be concerned about this.
[16:32] <sorantis> A VNF can expect some input parameters. The values for this parameters can come from anywhere, as long as they are correct for deployment
[16:33] <sorantis> so I wouldn’t necessarily harden this function into VNFM
[16:33] <joehuang> just want to clarify whether these IP address management should be the responsibility of VIM
[16:34] <joehuang> we can exclude this functionality (IP address management, which is used for interaction among VNF/PNF) from VIM, i.e from OpenStack
[16:35] <sorantis> i think so
[16:35] <sorantis> i mean at least for this case
[16:36] <tallgren> Sorry to interrupt: some SDN solutions want to manage the IPs for the VNFs, so this should be included
[16:37] <sorantis> can SDN be used for that?
[16:37] <joehuang> these SDN controller running above OpenStack, and manipulate VNF, isn't it
[16:39] <sorantis> SDN controller interacts with network devices, no? sorry, I’m not very familiar with SDN
[16:39] <joehuang> to tallgren: can you eloborate how to do that
[16:40] <tallgren> When your VNF starts and creates a port, it gets an IP from the SDN controller
[16:41] <fzdarsky> SDN controller acting as DHCP server
[16:41] <joehuang> but currently, the IP/mac is allocated in Neutron, or with one driver
[16:41] <sorantis> so can we say that this is the SDN controller’s responsibility to provide an IP address for the VNF?
[16:42] <fzdarsky> that would be an SDN controller plugged under Neutron, right?
[16:42] <sorantis> yes
[16:43] <fzdarsky> With PNFs, the
OSS/BSS currently configures FQDNs (via the EM) and the PNFs then resolve to IP via
DNS.
[16:44] <tallgren> When you create a network in OpenStack (Neutron), you need to know how the IP management will be done
[16:44] <fzdarsky> The IP being assigned from a managed address pool by DHCP.
[16:44] <tallgren> Yes
[16:45] <joehuang> so the IP is from a VLAN provider network, or as a floating IP from external network
[16:46] <joehuang> from your description, it's from a VLAN provider network?
[16:49] <joehuang> ok, how the standby will get the IP before it become the master, if the mater failed
[16:49] <fzdarsky> Is there a figure somewhere that illustrates the use case?
[16:49] <joehuang> we can draw a figure after the meeting, but not now
[16:50] <tallgren>
BTW, I am not sure if this is a side track, but floating IPs do not really work with IPv6
[16:50] <xiaolong> sorry, I change a littel bit the subject of discussion, is there any VNF which should be d eployed across multiple site or multiple openstack instances?
-
[16:51] <joehuang> this is the use case 2. two openstack instances in one site, and the master in one OpenStack, the standby in the other one
[16:51] <tallgren> I would not deploy a VNF across OpenStack instances
[16:51] <fzdarsky> xiaolong, not a single VNF instance, but one active and one standby instance.
[16:59] <xiaolong> ok, thanks for the explanation. I think we need more clear definition about the use case
[16:59] <fzdarsky> If we talk about failover across regions that's a different thing
[17:00] <sorantis> failover between AZs technically means that you have to VNF instances running in the same cloud
[17:00] <fzdarsky> –> different
API endpoints, no coordination between regions
[17:00] <joehuang> It's difficult to draw a conclution today to include the IP address management or not. Let's continue discuss next time. Before next meeting, hope that we can discuss in mailist. And whether the use case shoudl be addressed
[17:00] <xiaolong> I also need to understand if we need to have a so complicated architecture : multi-AZ, multi-region inside multi-site
