15:10:00 <bryan_att> #startmeeting Models Meeting #6A
15:10:00 <collabot> 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 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:10:00 <collabot> The meeting name has been set to 'models_meeting__6a'
15:10:02 <rprakash> #etherpad https://etherpad.opnfv.org/p/models
15:10:13 <bryan_att> OK, any updates to the proposed agenda?
15:11:03 <bryan_att> #link https://wiki.opnfv.org/display/models/Models+Meetings
15:11:40 <bryan_att> or any comments on the notes I took from the last meeting?
15:12:12 <rprakash> Youb are talking of Vlaidation besides syntax checks by parser
15:12:18 <bryan_att> otherwise will be a short meeting for me. I'm preparing to leave for NFV World Congress this week.
15:12:46 <bryan_att> rprakash: what do you mean?
15:13:38 <rprakash> 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 <rprakash> of just follow vIMS and VNF to get the models as represented in YANG, TOSCA por something beyond taht
15:14:33 <bryan_att> 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 <rprakash> OK so use case will drive Modles and one being mentioned is vIMS
15:15:19 <rprakash> and L3VPN, BGPVPN etc
15:15:39 <bryan_att> yes, for the validation goals of the project. There are other goals such as standard IM convergence /assessment.
15:15:41 <Csatari> I think these are reference implementations.
15:16:20 <bryan_att> The existing VNF implementations will be used as a template for other use cases, more narrowly focused (my suggestion)
15:16:22 <rprakash> 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 <Csatari> Use cases shall be somewhat more abstract.
15:16:44 <Csatari> Scaling is a good example.
15:17:12 <bryan_att> Csatari: they can be to start, but to drive specific model analysis or test activity, they need to get more specific
15:17:32 <Csatari> Agreed. I'm oposing only the wording.
15:17:56 <rprakash> #info mything was scaling in out up down for an VNF will be low hanging fruit to start with
15:18:21 <bryan_att> Csatari: OK, good. If there are descriptions that need to change, they you can help by editing the wiki etc.
15:18:42 <rprakash> If we tie VNF with multiple VDUs then we may need links and Bandwidth attribute too
15:18:45 <bryan_att> rprakash: I agree, scaling is a rich set of use cases.
15:18:52 <Csatari> Bryan: OK I will make a change proposal.
15:19:48 <rprakash> And if we add stores than we will need to see IOPs for storage too
15:21:34 <rprakash> 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 <rprakash> Now our assumption is all are logical or virual models
15:22:07 <bryan_att> 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 <rprakash> OK lets work through email
15:22:27 <bryan_att> you can continue discussing and I will collect/publish the minutes
15:22:29 <rprakash> Thanks
15:22:34 <Csatari> Thanks
15:23:31 <rprakash> # continuing on the subject lets take Simple TOSCA model for VNF and compare that with YANG or UML
15:24:12 <rprakash> #ulas do you have a TOSCA mopdel for VNF or can you describe it and does it have apropoerty called scale?
15:24:53 <uck> @rprakash I do not have a specific model other than some shallow examples
15:24:53 <collabot> uck: Error: "rprakash" is not a valid command.
15:26:13 <uck> as a scale attribute one can specify number of instances
15:26:25 <rprakash> Simle one contains what a Hierarchial strutre of VNF with VDU with NDOES and LINKS?
15:27:57 <uck> The issue is what do you want to compare?
15:28:15 <rprakash> topology tempalte comes first?
15:30:30 <rprakash> #link http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.pdf
15:30:55 <uck> 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 <rprakash> 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 <uck> 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 <rprakash> Is 11.2 topolgy tempalte reprentative of Scaling Methodology based on flavor described there in?
15:35:04 <rprakash> So are we too look at isloated VNF or VNF as part of a network Service for scaling?
15:35:54 <uck> My point is that it is up to you how you define new nodes, policies, properties, etc.
15:36:23 <uck> If you want to scale a collection of things in Tosca, you can group them and attach a scaling policy
15:36:43 <rprakash> # 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 <rprakash> Now so modeling should be of service and then say service consists of one VMNF with one VDU and so on
15:37:51 <rprakash> VNF not VMNF
15:39:50 <rprakash> #link https://wiki.opnfv.org/display/domino/Policy+Example+-+I
15:40:24 <rprakash> So this is one from Domino simple one an yaml file
15:41:12 <uck> If you look under policies tab "mu_anti_collocation_polic" is something quite arbitrary
15:42:31 <uck> if you check out https://wiki.opnfv.org/display/domino/Policy+Definitions , this is actually more informative
15:42:45 <rprakash> agreed it is arbitary but it applies to a group
15:43:56 <rprakash> so this is use case for Grouping nodes for anti-colocation policy application
15:44:09 <uck> 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 <rprakash> 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 <uck> Then you can specify some triggers based on the values of these properties.
15:46:00 <rprakash> 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 <rprakash> 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 <uck> that is not really my approach. I was trying to relay what I understand from Tosca.
15:50:35 <rprakash> 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 <uck> 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 <rprakash> 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 <uck> 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 <uck> naturally, a box that describes its internal working through yang will be quite specific and present a data model.
15:57:17 <uck> but, one can describe the
15:57:41 <uck> internal workings of a high level service also in yang, isn't this the case?
15:58:07 <rprakash> 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 <uck> currently Tosca is a mixture
15:59:04 <uck> you can for instance specify OS and hardware in Tosca
15:59:25 <rprakash> Once you talk VDU Virtual Deployment Unit we are already mixing the concrete and abstract in TOSCA
15:59:26 <uck> you can also leave it at "flavor"
15:59:59 <uck> VDU can still be abstract.
16:00:10 <uck> It is a unit of scale
16:00:59 <uck> you need to add/remove resources at that granularity
16:01:15 <rprakash> 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 <uck> anyhow it seems that the meeting time is over. shall we continue this discussion over coffee in the office?
16:01:47 <rprakash> OK hope everyone wants to leave for nect meeting
16:01:51 <rprakash> lets close it?
16:02:02 <rprakash> Any one any questions?
16:02:07 <mflauw> Hi
16:02:12 <rprakash> sure
16:02:14 <Csatari> Nothing from my side.
16:02:23 <mflauw> I thought the meeting was at 18:00 CET
16:02:34 <mflauw> thisis what I have in my calendar
16:03:21 <Csatari> 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 <rprakash> 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 <rprakash> #info OK shall i end the meeting?
16:03:53 <rprakash> #endmeeting
16:03:59 <Csatari> okay
16:04:01 <Csatari> bye
16:04:04 <rprakash> bye
16:04:09 <mflauw> Well the model meeting page says:
16:04:10 <mflauw> Weekly on Mondays at 1600 UTC (session for EU, US) and Tuesdays at 0000 UTC (session for Asia, US)
16:04:22 <mflauw> 16:00 UTC is 18:00 CET
00:00:05 <bryan_att> if anyone is here for the Models meeting, I will start meeting B in a minute.
00:08:11 <bryan_att> #info Bryan Sullivan
00:08:54 <bryan_att> #info Tianran intro's his involvement in IETF etc, for models in MANO area
00:11:22 <bryan_att> #info Also his team is involved in "Carrier SDN" work in TOSCA.
12:10:41 <bryan_att> #endmeeting