Wiki

[16:01] <joehuang> hi, good morning and afternoon

[16:01] == tallgren [~tallgren@194.251.119.201] has joined #opnfv-meeting

[16:01] <sorantis> hi!

[16:01] <tallgren> Hello

[16:01] <joehuang> it seems the summer seanson will start soon

[16:02] <tallgren> Yes, tomorrow…

[16:02] <joehuang> hi, will you spend two weeks or more for your vocation

[16:02] <joehuang> from tomorrow? how long

[16:02] <tallgren> I will be away four weeks

[16:03] <joehuang> #startmeeting Multisite Weekly Team Meeting 2015.07.02

[16:03] == fzdarsky [~fzdarsky@bzq-218-11-178.cablep.bezeqint.net] has joined #opnfv-meeting

[16:03] <joehuang> four weeks, hope you have a good summer vocation

[16:03] <tallgren> thanks!

[16:03] <sorantis> i¡¯ll be away too

[16:03] <joehuang> #startmeeting Multisite Weekly Team Meeting 2015.07.02

[16:04] <sorantis> starting from July 15 - Aug 10

[16:04] <joehuang> how long? the meetbot seems stop working

[16:04] <joehuang> Good

[16:04] <joehuang> #topic Roll Call

[16:04] <colintd> Hi

[16:04] <joehuang> hi

[16:05] <joehuang> #info joehuang

[16:05] <colintd> #info colintd

[16:05] <tallgren> #info tallgren

[16:05] <sorantis> #info dimitri

[16:05] <uli-k> #info Uli

[16:05] <joehuang> ##info agenda:

[16:05] <joehuang> #info agenda:

[16:06] <joehuang> #info use cases prioritization, B-release goal discussion

[16:06] <joehuang> #info focus on minimum viable use cases and want but at risk use cases, others will be out plan use cases

[16:06] <joehuang> #info we have 11 use cases in the list

[16:06] <joehuang> #info Use case 1. Escape from site level KeyStone failure

[16:07] <joehuang> #info Use case 2. VNF high availability across VIM

[16:07] <joehuang> #info Use case 3. VNF Geo-site Redundancy

[16:07] <joehuang> #info Use case 4. authentification and authorization service (keystone)

[16:07] <joehuang> #info Use case 5. centralized management for distributed resource

[16:07] <joehuang> #info Use case 6. centralized monitoring service

[16:07] <joehuang> #info Use case 7. centralized management of quotas

[16:07] <joehuang> #info Use case 8. global view for tenant level IP address space management

[16:07] <joehuang> #info Use case 9. A service to clone security groups across regions

[16:07] <joehuang> #info Use case 10. A service to clone ssh keys across regions

[16:08] <joehuang> #info Use case 11. A service to sync images across regions

[16:08] <joehuang> we need to prioritize these use cases, and focus on minimum viable use cases in the release B

[16:08] <sorantis> Can we merge use cases 9-10?

[16:09] <joehuang> sure.

[16:09] <colintd> Make it something like "A service to sync security information across groups"?

[16:10] <joehuang> security group is networking concept, SSH key is security access area

[16:11] <sorantis> A service to sync tenant resources (images, flavor, ssh-keys, security groups, etc.)

[16:11] <joehuang> from my point of view, we can merge the resource replication use cases, like image, SEG, ssh key

[16:11] <joehuang> similar idear. Sorantis :)

[16:12] <joehuang> Good, we can merge 9,10,11

[16:12] <colintd> Works for me

[16:12] <sorantis> when is the B-release?

[16:12] <joehuang> #info Use case 9. A service to sync tenant resources (images, flavor, ssh-keys, security groups, etc.)

[16:13] <joehuang> estimated Nov

[16:13] <joehuang> there is one OPNFV summit in Nov.

[16:13] <joehuang> may be before that, but no exact date yet

[16:14] <joehuang> BP/spec/code will have heavy dependecy on OpenStack

[16:14] <joehuang> we can control use cases/requirements/gap analysis

[16:15] <sorantis> what¡¯s the expected outcome?

[16:15] == xiaolong [a16a0005@gateway/web/freenode/ip.161.106.0.5] has joined #opnfv-meeting

[16:15] <xiaolong> sorry, I am late

[16:15] <joehuang> we may at least deliver use cases/requirements/gap analysis, for BP/spec approvement, it's up to OpenStack

[16:16] <sorantis> sounds good

[16:16] <joehuang> welcome Xiaolong, we just merger the use cases 9~11 to "Use case 9. A service to sync tenant resources (images, flavor, ssh-keys, security groups, etc.)"

[16:17] <colintd> In terms of combining usecases, is 7 a specific example of 5?

[16:17] <joehuang> and the most of the discussion will be on the implementation parts. I guess

[16:18] == hafe [~uabhafe@sessfw99-sesbfw99-91.ericsson.net] has joined #opnfv-meeting

[16:18] <joehuang> yes. there is relationship between use case 7 & 5. they are correlated to some extent

[16:18] <sorantis> colintd, good point, I think 5 is the general umbrella over 5, 9-11

[16:19] <joehuang> to sorantis, a little different. 9-11 needs replication

[16:19] <joehuang> for 5, 7 replication not required.

[16:19] <sorantis> which can also be considered as management, but that¡¯s just semantics

[16:20] <joehuang> management is a very general concept

[16:20] <colintd> Maybe. I think there are questions about where the "centralized" information would be stored, and one answer is it would be in a replicated / distributed form

[16:21] <sorantis> +1

[16:22] <colintd> 5, 7, 9-11 do all group together as the set of tools/utilities you need to effectively manage a multisite deployment, whereas most of the others are more function cases related to VNF operation.

[16:22] <joehuang> It works for me to merge use case 5,7. In fact, 5,7 9-11 has similar requirement for a set of tools

[16:23] <joehuang> Agree to colin

[16:23] <joehuang> how about use case 6

[16:23] <sorantis> isn¡¯t it Ceilometer?

[16:24] <joehuang> Can Xiaolong explain a little about use case 6: centralized monitoring service

[16:24] <colintd> I was wondering about 6. Is it some overlap tool to pull together multiple Ceilometers?

[16:24] <colintd> Sorry, overlap. please go on.

[16:24] <joehuang> distributed query is very complex

[16:25] <joehuang> for use case 6, if we have a ceilometer in each site, if we need a centralized view of monitoring data, distributed query is very complex

[16:25] <joehuang> for single metrics, you can route the request to regarding ceilometer

[16:26] <sorantis> is it?

[16:26] <xiaolong> to give an example, the same user may have multiple VMs in multiple tenants across multiple openstack regions

[16:26] <joehuang> but if multiple resources/sampling needed in the request, it become very complex

[16:26] <xiaolong> it is useful for him to centralize all the logs generated by these VMs

[16:27] <sorantis> Which, I think, can be achieved by using e.g. ElasticSearch

[16:27] <sorantis> you¡¯ll just have multiple sources

[16:27] <joehuang> the log: cpu utilization or the information produced during the API call

[16:28] <xiaolong> and for the realtime metrics, there is the need to have a central point to monitor the resource utilization

[16:28] <joehuang> for single resource (VM. volume…) or mutiple resources

[16:29] <joehuang> for single resource (VM. volume…) or mutiple resources (for example, a tenant's VM1, VM2, volume1, volume 2)

[16:29] <xiaolong> for resources per type : CPU, volume, memory, …

[16:30] <joehuang> for the log produced during api call could be upload to a central store, and then using elasticserach like tool

[16:31] <sorantis> let¡¯s go back to the list

[16:31] <fzdarsky> hi, isn't this UC covered by systems outside of OpenStack today?

[16:31] <sorantis> let¡¯s keep the title of 6 as is for now

[16:31] <fzdarsky> influxdb/grafana, new relic, …?

[16:31] <joehuang> OK. use case 6 can be there alone

[16:31] <sorantis> fzdarsky, or elasticsearch

[16:31] <xiaolong> not so simple. it is easy to centralize all the logs generated inside user's VMs, but not easy to centralize the logs generated by multiple openstack instances for the user

[16:32] <fzdarsky> are we talking about logs, KPIs, both?

[16:32] <joehuang> Use case 6 can be splited two parts, one part is about the data collected by Ceilometer (mainly real time data), the other one is the runtime log could be handled by elasticsearch

[16:32] <xiaolong> both

[16:33] <xiaolong> I agree with joe

[16:33] <fzdarsky> but not necessarily using the same mechanism I assume, so does it make sense to split?

[16:33] <joehuang> thanks. I also have more clear view on this use case

[16:34] <joehuang> diffierent mechnism required

[16:34] <joehuang> Ceilometer part is very complex, I am thinking about it these days

[16:35] <joehuang> #info: a short summary of our merged use cases

[16:35] <colintd> Joe, can we have a quick recap/restatement of where we now are with the list of use cases?

[16:36] <joehuang> #info Use case 1. Escape from site level KeyStone failure

[16:36] <joehuang> #info Use case 2. VNF high availability across VI

[16:36] <colintd> You've just read my mind

[16:36] <joehuang> #info Use case 3. VNF Geo-site Redundancy

[16:36] <joehuang> #info Use case 4. authentification and authorization service (keystone)

[16:36] <joehuang> #info Use case 5. centralized monitoring service

[16:37] == hafe [~uabhafe@sessfw99-sesbfw99-91.ericsson.net] has quit [Ping timeout: 265 seconds]

[16:37] <joehuang> I am summary the last one use case

[16:38] <xiaolong> https://etherpad.opnfv.org/p/multisite_usecase_collection

[16:38] <xiaolong> it is better to have a summary at the begin since the document is quite long

[16:38] <joehuang> #info Use case 6. centralized service for resources management and replication(sync tenant resources (images, flavor, ssh-keys, security groups, etc.))

[16:38] <joehuang> OK. will add now

[16:39] <colintd> Do we have a view on how closely use case 1 and 4 are related, and how 1 plays against keystone federation?

[16:39] <joehuang> yes, use case 1/4 can be merged for multisite identity service management

[16:39] == hafe [~uabhafe@sessfw99-sesbfw99-91.ericsson.net] has joined #opnfv-meeting

[16:39] <joehuang> how about that?

[16:40] <colintd> Good.

[16:40] <joehuang> use case 1: multisite identity service management ?

[16:40] <joehuang> then merge the use case 1 & 4

[16:43] <joehuang> Now we have only 5 use cases

[16:44] <joehuang> #info Use case 1: multisite identity service management

[16:44] <joehuang> #info Use case 2. VNF high availability across VIM

[16:44] <joehuang> #info Use case 3. VNF Geo-site Redundancy

[16:44] <joehuang> #info Use case 4. Centralized service for resources management and replication (sync tenant resources (images, flavor, ssh-keys, security groups, etc.))

[16:44] <joehuang> #info Use case 5. centralized monitoring service

[16:45] <joehuang> Our prioritization ?

[16:46] <joehuang> how about 2,3,4,5,1 ? For keystone, the fernet token and federation is still developing

[16:46] <colintd> Based on our discussions with carriers, and our current dev work, my personal preference is for 2 & 3 to have top priority. They are the cases which most directly impact the ability to deliver even basic multi-site VNFs, and might be addressable via some quite small tweaks to openstack.

[16:46] <colintd> 2,3,4,5,1 works for me.

[16:46] <joehuang> agree to colin : )

[16:47] <sorantis> ok

[16:48] <xiaolong> one second pls

[16:48] <xiaolong> I zould like to have the use case 1 as top priority

[16:48] == arturt [~arturt@c-50-184-59-37.hsd1.ca.comcast.net] has joined #opnfv-meeting

[16:49] == Jonas1 [~uabjonb@194.237.142.10] has joined #opnfv-meeting

[16:49] <tallgren> I would put 2 on a lower priority

[16:49] <colintd> Could you talk a bit about reasons?

[16:49] <tallgren> I do not see how it could be done, due to latencies between VIMs

[16:49] <xiaolong> uc 1 is the starting point to integrate any multisite multi-region instances

[16:49] <joehuang> Which is top1 for tallgren

[16:50] == hafe [~uabhafe@sessfw99-sesbfw99-91.ericsson.net] has quit [Ping timeout: 276 seconds]

[16:50] <sorantis> I¡¯d also put 1 ahead of the others

[16:50] <xiaolong> 2 is not so critical, at least at the beginning

[16:50] <tallgren> I see 1 as important

[16:50] == hafe [~uabhafe@sessfw99-sesbfw99-87.ericsson.net] has joined #opnfv-meeting

[16:50] <xiaolong> I agree with tallgren

[16:50] <sorantis> if we don¡¯t have identity in place, then the regions are basically standalone

[16:51] <xiaolong> you are right sorantis

[16:51] <joehuang> Ok, how about 1, 2, 3, 4, 5 ?

[16:51] <tallgren> Agree

[16:51] <xiaolong> agree

[16:51] <colintd> I wonder whether we're coming at this from two perspectives. 1) Manage multiple VIMs/sites in a coordinated fashion 2) Use multiple clouds/sites to deploy HA telco services

[16:52] == lijian [~Thunderbi@58.251.166.185] has joined #opnfv-meeting

[16:52] <colintd> Very happy to agree to that, but still think it is worth checking our perspectives

[16:53] == arturt [~arturt@c-50-184-59-37.hsd1.ca.comcast.net] has quit [Ping timeout: 255 seconds]

[16:54] <fzdarsky> colintd, my view is 2) has higher importance

[16:54] <fzdarsky> as 1) is provided by higher MANO layers already

[16:54] <tallgren> Are we talking about a single VNF spanning several VIMs, or two similar VNFs running on two VIMs in a coordinated fashion?

[16:55] == lijian [~Thunderbi@58.251.166.185] has quit [Client Quit]

[16:55] <colintd> VNFI spanning multiple VIMs

[16:56] <joehuang> We may learned some experience and discuss keystone use case for 1/2 weeks. I think it would help to some extent. then if it's enough, then we can continue discuss use case 2. So for compromise, the priorization would be 1,2,3,4,5

[16:57] <fzdarsky> tallgren, I guess that hinges on the question of the VNFM to VIM relation. Most folks in ETSI assume it's 1:1.

[16:58] <sorantis> gents, I will have to leave the meeting now.

[16:58] <colintd> 1:1 is the simple approach, but gives you all kinds of problems in terms of availability of VNFI and provides no good solution for VIM upgrade.

[16:59] <colintd> Let's continue the VIM/VNFM discussion on the list?

[16:59] <sorantis> does 1 2 3 4 5 sound good to everyone?

[16:59] <uli-k> May I put a question: Which operators are planning to implement VNFs spanning multiple VIMs or multiple NFVIs?

[16:59] <fzdarsky> colintd, +1

[16:59] <xiaolong> I think the 2 is not so important as uli-k implies

[17:00] <tallgren> I was thinking about a VNF like a firewall, and then synchronizing all established TCP sessions between VIMs

[17:00] <xiaolong> there is not yet VNF which needs to span over multi-VIM

[17:00] <xiaolong> why focus on that so early?

[17:00] <colintd> Most of the ones we're talking to view availability of a single OpenStack instance as too low for stateful services such as those handling voice calls.

[17:01] <joehuang> any question on the 1 2 3 4 5

[17:01] <fzdarsky> Seems like we have different types of VNFs in our minds

[17:01] == [1]JonasB [~jonas.bju@sessfw99-sesbfw99-86.ericsson.net] has joined #opnfv-meeting

[17:01] <fzdarsky> IMO, the answer will be different whether we're talking about, like, 3GPP VNFs

[17:01] <xiaolong> for me the importance order is 1 3 4 5 2

[17:01] <fzdarsky> that are independently managed per site or

[17:01] <xiaolong> not useful to work on 2 which purely theoritical work

[17:02] <colintd> Disagree. Stateful, call based services with tight SLA on things like call cutoff, need to span VIMs/NFVI from day 1.

[17:02] <fzdarsky> VNFs that are designed to be cloud native

[17:02] <uli-k> fzdarsky, do you think such native VNFs will span multiple VIMs?

[17:02] <xiaolong> have 3 for current VNFs is already sufficient

[17:03] <fzdarsky> uli-k, I think native one lend more to the single VIM case

[17:03] <joehuang> Hi, part of us need use case 2, not all.

[17:03] <fzdarsky> s/lend/tend/

[17:03] <uli-k> do you think, 3GPP VNFs will span multiple VIMs?

[17:04] <colintd> As covered in the use case 3 gives continuity of service, 2 is all about maintaining calls and client registrations by transfering IP traffic

[17:04] == hafe [~uabhafe@sessfw99-sesbfw99-87.ericsson.net] has quit [Ping timeout: 255 seconds]

[17:04] <fzdarsky> I think 3GPP VNFs that have undergone p2v transition will be more similar to

[17:04] <fzdarsky> 1 site = 1 PNF

[17:04] <xiaolong> colintd, please give a concret VNF which need to span multiple VIM. stateful service doesn't imply necessarily multiple VIM

[17:05] <fzdarsky> i.e. intra-VNF instancea redundancy on 1 VIM with multiple AZs,

[17:05] <fzdarsky> inter-VNF instance redundancy handled by the VNFs' management systems across VIMs

[17:06] <fzdarsky> (aka NMS / OSS)

[17:06] <colintd> If I have any element that deals with RTP streams, and my SLA for call cutoff can't be met by the uptime of a single cloud (most of which only manage about 3nines) then I need the ability to redirect the media between VIMs/NFVI

[17:06] <colintd> This is the same as redundancy against hardware failure in traditional deployments, where use of 1+1 pairs is common.

[17:07] <colintd> We can argue about whether you describe the two halves of the pair as 1 VNFI with 2 VNFCI (my view) or 2 VNFI, but you still need to media/IP transfer function

[17:08] <fzdarsky> colintd, +1. And it is up to the app designer whether spreading instances across multiple AZs of the same region (i.e. 1 VIM is sufficient) or needs redundancy across regions.

[17:09] == raindirve [~eseawen@sessfw99-sesbfw99-84.ericsson.net] has joined #opnfv-meeting

[17:09] <xiaolong> colintd and fzdarsky, if we follow your logic, we can see that it is a VNF architecture issue, not an infrastructure issue

[17:09] <colintd> IP transfer requires infrastructure support (see details in use case)

[17:09] <xiaolong> I wonder if use case 2 should have its place here

[17:09] <uli-k> The app designer will not know how a VNF is deployed. He may say that his app supports to run in certain deployment.

[17:10] <uli-k> I wonder whether any opertor would like to spread VNFs over multiple clouds.

[17:10] <uli-k> or rather run two VNFs, one in each cloud then.

[17:10] <fzdarsky> uli-k, well, the app designer makes his/her decision based on the "contract" provided by the platform

[17:10] <joehuang> uli, you can refer to Fu Qiao

[17:11] <colintd> I think I've already answered that We have many operators who believe that _have_to_ do this to achieve SLA.

[17:11] <joehuang> you can refer to Fu Qiao' mail, in some scenario, it would happen. maybe not all operators to deploy like this

[17:11] <fzdarsky> uli-k, colintd, let's deep dive a bit into that on the ML

[17:11] <tallgren> are we assuming that the colintd's RTP stream will go throught the VNF?

[17:12] <colintd> The issue is that current VIMs can't offer 6nines required to meet target VNF SLA. Just as with hardware redundancy, the solution isn't to try and make hardware 6nines, rather allow app to span multiple systems.

[17:12] <joehuang> Hi, Xiaolong and Colin, when will you have your summer vocation, we may jump the topic if you are on vocation. so that everyone satified

[17:12] <fzdarsky> we probably have different notions of VNFM, VIM, NFVI vs. AZs, regions, app managers.

[17:12] <colintd> Yes, I am talking about VNF which deal with media (SBCs, transcode gateways, etc)

[17:13] <colintd> Thanks. Not yet sure of vacation plans, but will post when coming up.

[17:13] <colintd> Should we bring things to a close for today?

[17:13] <tallgren> Yes, I am getting hungry…

[17:14] <xiaolong> I will be in vacation from mid-july to mid-aug

[17:16] == tallgren [~tallgren@194.251.119.201] has quit [Quit: leaving]

[17:16] <joehuang> So let's discuss KeyStone use case before you spend your vocation. And then discuss use case 2 for a while.

[17:16] == colintd [5244d461@gateway/web/freenode/ip.82.68.212.97] has quit [Quit: Page closed]

[17:20] <joehuang> For the use cases 2 has been discussed twice, let's come back the discussion after the use case 1.

[17:20] <fzdarsky> ok

[17:20] == jpekkari [~jpekkari@62.159.77.164] has joined #opnfv-meeting

[17:20] <joehuang> it may not take long time to discuss

[17:21] <joehuang> so let's take the order 1 2 3 4 5

[17:21] <joehuang> thanks for attending the meeting. See you next time

[17:22] <fzdarsky> thanks all; bye

[17:22] <joehuang> #endmeeting