15:10:00 #startmeeting Models Meeting #6A 15:10:00 Meeting started Mon Apr 18 15:10:00 2016 UTC. The chair is bryan_att. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:10:00 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:10:00 The meeting name has been set to 'models_meeting__6a' 15:10:02 #etherpad https://etherpad.opnfv.org/p/models 15:10:13 OK, any updates to the proposed agenda? 15:11:03 #link https://wiki.opnfv.org/display/models/Models+Meetings 15:11:40 or any comments on the notes I took from the last meeting? 15:12:12 Youb are talking of Vlaidation besides syntax checks by parser 15:12:18 otherwise will be a short meeting for me. I'm preparing to leave for NFV World Congress this week. 15:12:46 rprakash: what do you mean? 15:13:38 I am trying to understand, what kind of Modles like 3-node cluster etc and what val;idation like nodes links etc, but may be we can do this offline 15:14:28 of just follow vIMS and VNF to get the models as represented in YANG, TOSCA por something beyond taht 15:14:33 rprakash: when you say "what kind", do you mean what model attributes relate to those capabilities? That's a question we need to address thru use case focus. 15:14:59 OK so use case will drive Modles and one being mentioned is vIMS 15:15:19 and L3VPN, BGPVPN etc 15:15:39 yes, for the validation goals of the project. There are other goals such as standard IM convergence /assessment. 15:15:41 I think these are reference implementations. 15:16:20 The existing VNF implementations will be used as a template for other use cases, more narrowly focused (my suggestion) 15:16:22 OK so we focus on few use cases and we listed Scaling and SFC and others which I have not still looked into 15:16:28 Use cases shall be somewhat more abstract. 15:16:44 Scaling is a good example. 15:17:12 Csatari: they can be to start, but to drive specific model analysis or test activity, they need to get more specific 15:17:32 Agreed. I'm oposing only the wording. 15:17:56 #info mything was scaling in out up down for an VNF will be low hanging fruit to start with 15:18:21 Csatari: OK, good. If there are descriptions that need to change, they you can help by editing the wiki etc. 15:18:42 If we tie VNF with multiple VDUs then we may need links and Bandwidth attribute too 15:18:45 rprakash: I agree, scaling is a rich set of use cases. 15:18:52 Bryan: OK I will make a change proposal. 15:19:48 And if we add stores than we will need to see IOPs for storage too 15:21:34 I think the best will be take simple VNF scaling with single VDU and another with 2 VDUs and get some models and see how it pans out 15:21:58 Now our assumption is all are logical or virual models 15:22:07 ok, I apologize I need to run. Let's continue collecting input on the wiki, JIRA, and email. I have a minor emergency to help my daughter with. 15:22:27 OK lets work through email 15:22:27 you can continue discussing and I will collect/publish the minutes 15:22:29 Thanks 15:22:34 Thanks 15:23:31 # continuing on the subject lets take Simple TOSCA model for VNF and compare that with YANG or UML 15:24:12 #ulas do you have a TOSCA mopdel for VNF or can you describe it and does it have apropoerty called scale? 15:24:53 @rprakash I do not have a specific model other than some shallow examples 15:24:53 uck: Error: "rprakash" is not a valid command. 15:26:13 as a scale attribute one can specify number of instances 15:26:25 Simle one contains what a Hierarchial strutre of VNF with VDU with NDOES and LINKS? 15:27:57 The issue is what do you want to compare? 15:28:15 topology tempalte comes first? 15:30:30 #link http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.pdf 15:30:55 I am not sure if I understand your comment. Do you want to compare how topology is descibed in Tosca vs. yang? 15:32:22 no I am looking for scaling attribute in VNF if it is usable from TOSCA or YANG and how do they differ for a VNF scaling use case 15:33:46 at the end of the day, these are all {key,value} pairs. If you want to define a scaling property in yang, is there a limitation? 15:33:55 Is 11.2 topolgy tempalte reprentative of Scaling Methodology based on flavor described there in? 15:35:04 So are we too look at isloated VNF or VNF as part of a network Service for scaling? 15:35:54 My point is that it is up to you how you define new nodes, policies, properties, etc. 15:36:23 If you want to scale a collection of things in Tosca, you can group them and attach a scaling policy 15:36:43 # I think we have to start with use case scaling is just an absraction , so what is then the use case not scaling but a service and modeling service will inolve first lets say network service 15:37:31 Now so modeling should be of service and then say service consists of one VMNF with one VDU and so on 15:37:51 VNF not VMNF 15:39:50 #link https://wiki.opnfv.org/display/domino/Policy+Example+-+I 15:40:24 So this is one from Domino simple one an yaml file 15:41:12 If you look under policies tab "mu_anti_collocation_polic" is something quite arbitrary 15:42:31 if you check out https://wiki.opnfv.org/display/domino/Policy+Definitions , this is actually more informative 15:42:45 agreed it is arbitary but it applies to a group 15:43:56 so this is use case for Grouping nodes for anti-colocation policy application 15:44:09 For instance you can define a VNF (which is a node) composed of multiple VDUs and then define some properties to represent the bandwidth constraints between VDUs 15:44:59 SO to me it looks we need to look at models as what they represent based on Information mopdels and not data models 15:45:52 Then you can specify some triggers based on the values of these properties. 15:46:00 So for a given use case we need to start at Common Information Model, but then that still will need topology representaion and mainly logicl or virtual as we call it 15:48:54 So nodes can be compute nodes, network node, storage nodes and we assume we start with compute and all at virtual therefor VNF is the mosy agreeable unit and the draw topology of simple VNF and ulas I agree with your approach of modeling 15:49:43 that is not really my approach. I was trying to relay what I understand from Tosca. 15:50:35 OK agreed so TOSAC puts models in terms of VNF, and now where as YANG puts it in terms of network node, is that a fair statement? 15:50:51 When it comes to yang models, these are basically xml schemas and one should be easily describe what is described in Tosca also in yang. Am i missing something? 15:54:01 Ulas I am trying to co-relate YANG is tited to Data Model and TOSCA to Information Model, so may be I need rethinking just to limit it to Neteok Service 15:55:41 This is what I am trying to state, it is up to the model author to be generic or specific (informational vs. data model) and both Tosca and yang can deliver information and data models 15:56:33 naturally, a box that describes its internal working through yang will be quite specific and present a data model. 15:57:17 but, one can describe the 15:57:41 internal workings of a high level service also in yang, isn't this the case? 15:58:07 Describing in XML or YAML should noty have any differences but abstracy vs. concerete is really the difference so what should we choose abstract, concerete or hybnrid way to model logical newtork service 15:58:33 currently Tosca is a mixture 15:59:04 you can for instance specify OS and hardware in Tosca 15:59:25 Once you talk VDU Virtual Deployment Unit we are already mixing the concrete and abstract in TOSCA 15:59:26 you can also leave it at "flavor" 15:59:59 VDU can still be abstract. 16:00:10 It is a unit of scale 16:00:59 you need to add/remove resources at that granularity 16:01:15 Flavor is good for Compute service in OpenStack, still evolving in Network Services in Nova, so we will need to agree on some basic elements for both TOSCA and YANG as two main modeling for network Services, for Applications it has always been UML 16:01:24 anyhow it seems that the meeting time is over. shall we continue this discussion over coffee in the office? 16:01:47 OK hope everyone wants to leave for nect meeting 16:01:51 lets close it? 16:02:02 Any one any questions? 16:02:07 Hi 16:02:12 sure 16:02:14 Nothing from my side. 16:02:23 I thought the meeting was at 18:00 CET 16:02:34 thisis what I have in my calendar 16:03:21 It is from 17:00 CET, but most probabaly we will have a new meeting time due to the continous GTM conflicts. 16:03:27 Because of GTM conflict Bryan asked us continue of IRC and he was in a hurry to leave for flight, he said he will send polling for rescheduling the meeting for Models 16:03:44 #info OK shall i end the meeting? 16:03:53 #endmeeting 16:03:59 okay 16:04:01 bye 16:04:04 bye 16:04:09 Well the model meeting page says: 16:04:10 Weekly on Mondays at 1600 UTC (session for EU, US) and Tuesdays at 0000 UTC (session for Asia, US) 16:04:22 16:00 UTC is 18:00 CET 00:00:05 if anyone is here for the Models meeting, I will start meeting B in a minute. 00:08:11 #info Bryan Sullivan 00:08:54 #info Tianran intro's his involvement in IETF etc, for models in MANO area 00:11:22 #info Also his team is involved in "Carrier SDN" work in TOSCA. 12:10:41 #endmeeting