14:02:04 <sgordon_> #startmeeting TelcoWG
14:02:06 <openstack> Meeting started Wed Nov 19 14:02:04 2014 UTC and is due to finish in 60 minutes.  The chair is sgordon_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:09 <openstack> The meeting name has been set to 'telcowg'
14:02:14 <sgordon_> #chair amitry
14:02:15 <openstack> Current chairs: amitry sgordon_
14:02:22 <sgordon_> #topic roll call
14:02:30 <mkoderer> hi
14:02:32 <DaSchab> hi
14:02:34 <ybabenko> hi
14:02:35 <sgordon_> hi all, who is here for the telco working group meeting (formerly nfv)
14:02:37 <amitry> Hello
14:02:37 <b3nt_pin> hi
14:02:40 <amuller> hiya
14:02:46 <margaret__> hi
14:02:50 <dgollub> hi
14:02:50 <ybabenko> Deutsche Telekom
14:02:54 <yamahata> hello
14:02:57 <ajo> me :) hi
14:03:03 <angelomatarazzo> Hi
14:03:03 <margaret__> I'm AT&T
14:03:09 <nyechiel> hi
14:03:10 <amitry> Comcast
14:03:18 <mkoderer> Deutsche Telekom++
14:03:18 <sgordon_> excellent, welcome all
14:03:24 <jannis_rake-reve> hi, deutsche telekom
14:03:37 <ybabenko> Hi T-Labs >)
14:03:41 <jannis_rake-reve> :)
14:03:43 <sgordon_> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
14:03:58 <dkusidlo_> hi
14:03:59 <sgordon_> agenda is at the above location, feel free to add additional items if you need to
14:04:12 <sgordon_> #topic wiki gardening
14:04:25 <sgordon_> #info team page moved to https://wiki.openstack.org/wiki/TelcoWorkingGroup
14:04:34 <sgordon_> i got a start on updating the team page
14:05:01 <sgordon_> there is still refinement of mission/scope to do to add the clarity that seemed to be missing
14:05:10 <sgordon_> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup#Mission_statement_and_scope
14:05:34 <sgordon_> i have split out the membership page
14:05:43 <sgordon_> and also intend to split out the use cases page(s)
14:05:58 <sgordon_> though we still need to move towards a different way of tracking these imo
14:06:10 <sgordon_> ideas tossed around at summit were google doc or possibly storyboard
14:06:19 <sgordon_> i still need to do some investigation of the latter
14:06:32 <sgordon_> #action sgordon_ to investigate current state of storyboard and report back
14:06:44 <mkoderer> sgordon_: but we can already start to create some google docs? or should we wait?
14:07:01 <sgordon_> mkoderer, i dont think we necessarily need to wait
14:07:09 <sgordon_> after all we already have *some* use cases now on the wiki
14:07:16 <sgordon_> atm there is very variable depth though
14:07:28 <sgordon_> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup#Session_Border_Controller
14:07:34 <sgordon_> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup#Virtual_IMS_Core
14:07:35 <margaret__> If I wanted to add other use cases where do i this - on the wiki?
14:07:47 <sgordon_> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup#VLAN_Trunking
14:07:48 <ybabenko> sgordon > how to we decide/prioritize on use-cases? What are the criteria?
14:07:57 <sgordon_> margaret__, i think on the wiki in the first instance
14:08:11 <sgordon_> margaret__, my thinking is to create https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases and link from there
14:08:19 <DaSchab> Virtual_IMS_Core and Session_Border_Controller are more or less ervices not a real use-case, isn't it?
14:08:37 <sgordon_> DaSchab, that's up to the group - atm it's the best we have
14:08:37 <aveiga> DaSchab: I'd argue that they imply a use-case, though
14:08:40 <ybabenko> "some" use-cases does not sound compeling to me - i think we should work on real pain points first?
14:08:45 <margaret__> what is the goal of the use case?
14:08:57 <sgordon_> the rest are directly the ETSI use cases which arent as useful from an openstack developer perspective
14:09:17 <margaret__> I think the goal of the use cases should be to flush out openstack - which is instantiation of a VNF service
14:09:22 <sgordon_> +1
14:09:24 <ybabenko> Use-case is a a telco scenario to be implemented on top of infra/open stack
14:09:25 <DaSchab> treu
14:09:39 <DaSchab> true
14:09:56 <margaret__> We are proposing this type of use cases in OPNFV as we speak - we can also submit it here
14:10:11 <margaret__> But our goal is to actually try and execute it with openstack, odl....
14:10:11 <sgordon_> right
14:10:22 <sgordon_> we can also link to those directly if that makes sense rather than repeating
14:10:44 <sgordon_> though ultimately we do need to provide enough use case info in a blueprint/spec that developers can understand why we're requesting/doing something
14:10:55 <jannis_rake-reve> does it make sense to have use cases in there that do not need alterations/ additions to OS?
14:10:56 <ybabenko> margaret - let us stay in openstack community and use the tooling provided here - why double the work and do it in two places?
14:11:02 <margaret__> oh that would be great - Metaswitch also submitted their SBC to OPNFV and here i noticed
14:11:07 <jannis_rake-reve> e.g. Clearwater IMS
14:11:41 <ybabenko> one use case for me would be a service chain use-case
14:12:02 <ybabenko> deployed either in one DC or multiple DC
14:12:16 <jannis_rake-reve> ybabenko: could you be more specific pls?
14:12:32 <sgordon_> so, it seems there is a lot of enthusiasm to provide use cases and what is perhaps needed is some structure/guidance on where to put them?
14:12:45 <jannis_rake-reve> as far as i understand we need a reference implementation eventually
14:12:59 <ybabenko> service chain is a number of function connected in a particular way to produce a specific telco service. One example could be business VPN usecase with firewall. But again it is just an example
14:13:01 <mkoderer> sgordon_: a template would be useful ;)
14:13:05 <amitry> Also, maybe a default template that encourages enough depth
14:13:08 <jannis_rake-reve> sgordon_: +1
14:13:15 <sgordon_> mkoderer, why do i have a feeling i took that action item :)
14:13:26 <mkoderer> sgordon_: :P
14:13:28 <ybabenko> sgordon yes
14:13:35 <sgordon_> amitry, right - i dont think the section in the specs template does this enough
14:13:54 <sgordon_> #info need structure/guidance on where to put use cases
14:14:11 <sgordon_> #info need a template that encourages enough depth
14:14:18 <ajo> +1
14:14:24 <sgordon_> #action sgordon_ to update wiki structure and provide a draft template for discussion
14:14:34 <mkoderer> +1
14:14:50 <ybabenko> need prioriy criteria - what is important for telco folks here? what is missing?
14:14:53 <sgordon_> now on that note, do we think it's still useful to keep the minimal descriptions of the ETSI use cases on the page:
14:14:57 <sgordon_> #link https://wiki.openstack.org/wiki/TelcoWorkingGroup#ETSI-NFV_Use_Cases_-_High_Level_Description
14:15:09 <sgordon_> the gap analysis document is relatively useful but i am not sure about the rest
14:15:11 <DaSchab> do we have the same understanding what the scope of a use-case should be?
14:15:48 <sgordon_> DaSchab, i think margaret__ summed it up well earlier "I think the goal of the use cases should be to flush out openstack - which is instantiation of a VNF service"
14:16:06 <sgordon_> does anyone see additional scope on top of this at least initially?
14:16:07 <margaret__> I agree the HL use cases aren't useful - you need more specific instantiation flows
14:16:12 <ybabenko> Use-case is realisation of specific telco service on top of plain open stack?
14:16:29 <DaSchab> ...but not the service itself
14:16:32 <sgordon_> ybabenko, i think it helps illustrate something "real" to the wider community
14:16:44 <ybabenko> no. not the service itself. service comes from some service folks
14:16:59 <margaret__> as part of telco instantiation - SDN controllers come into the picture.
14:17:15 <ybabenko> margaret - can you clarify?
14:17:38 <sgordon_> #topic use case scope
14:17:55 <sgordon_> #info need to agree on scope/intent of use cases
14:18:03 <margaret__> If you instantiate a VPN service - you may need to instantiate a vPE. well connectivity between vPE, TOR, LAN, WAN is needed - so where is this done? (SDN controller is one)
14:18:13 <ybabenko> SDN controller is not part of open stack - it will need to come as an addon - openstack will provide the necessary API via Neutron towards SDN controller
14:18:19 <margaret__> will connect to vPE...
14:18:27 <sgordon_> question there is arguably, how much of this needs to be orchestrated using OpenStack APIs
14:18:29 <sgordon_> ideally
14:18:43 <sgordon_> ybabenko, right
14:18:52 <margaret__> yes but you now need an SDN controller of some sort to maybe flush out neutron
14:18:59 <sgordon_> ybabenko, and i think that is the key point - as regardless of controller backend we need  a common API yes?
14:19:06 <ybabenko> For us it is important that we have stable neutron API
14:19:15 <ybabenko> as we would expect SDN vendor to comply to it
14:19:16 <margaret__> placement becomes important due to latency - does that exist in openstack?
14:19:20 <matrohon> margaret__: VPN services does'nt need a vPE, we have a proposal for do it in neutron agent directly
14:19:43 <amitry> Maybe the step one running VNF on top of openstack, step two orchestration  using openstack apis
14:19:53 <matrohon> ybabenko : +1 (from Orange)
14:20:06 <sgordon_> #info "do we have the same understanding what the scope of a use-case should be?"
14:20:10 <margaret__> matrohon_ don't understand why you say VPN doesn't need a vPE
14:20:15 <sgordon_> #info "Use-case is realisation of specific telco service on top of plain open stack?"
14:20:29 <sgordon_> #info "Maybe the step one running VNF on top of openstack, step two orchestration  using openstack apis"
14:20:50 <sgordon_> so there are a number of areas touched on in the above conversation
14:20:53 <jannis_rake-reve> i believe it is also important to keep the API stable and focus in its core: so dont just add vendor feature to the api
14:20:54 <sgordon_> as amitry notes
14:21:10 <sgordon_> a good use case would ideally illustrate how these would be exercised in an ideal case
14:21:20 <sgordon_> without delving into implementation so much
14:21:28 <ybabenko> Do we have a common understanding of SDN in this context? Does everyone see it as an additional component plugged via openstack api?
14:21:45 <ybabenko> Who "orchestrates" the stuff? The SDN controller?
14:22:05 <matrohon> margaret_ : the vPE can be the l3 agent or even the l2 agent from neutron. what is missing is the compatible dataplane and BGP speaker
14:22:15 <jannis_rake-reve> margaret__: what do you mean by placement
14:22:17 <margaret__> That is the question - who connects everything and decides when to call the orchstrator to spin up the VNF
14:22:51 <DaSchab> isn't that the job of an orchestrator?
14:22:55 <sgordon_> +1
14:23:10 <sgordon_> but perhaps we have some terminology overload
14:23:14 <sgordon_> when saying orchestrator
14:23:16 <jannis_rake-reve> margaret__:  should OS be the overall orchestrator or rather "just" the infrastructure rchestrator
14:23:19 <ybabenko> BGP speaker is the gateway router,right? Or a VM running stuff like Quagga
14:23:24 <jannis_rake-reve> sgordon_:  yes
14:23:24 <sgordon_> as there are potentially different levels of orchestration
14:23:30 <ybabenko> Jannis +1
14:23:41 <DaSchab> +1
14:24:05 <jannis_rake-reve> Should we reference the NFV architecture first or is that too high level?
14:24:05 <DaSchab> we should decouple application from infrastructure orchestration
14:24:09 <margaret__> matrohon_: I assume it isn't sufficient for us but that is another debate
14:24:17 <jannis_rake-reve> DaSchab: yes
14:24:20 <DaSchab> IaaS as demarcation line
14:24:27 <sgordon_> jannis_rake-reve, i think it's useful at a high level for this group but not so much for broader community
14:24:37 <sgordon_> jannis_rake-reve, i think it's useful for defining scope of this group though
14:24:50 <jannis_rake-reve> DaSchab: although one might argue infrastructure goes beyond the OS datacentre
14:24:51 <sgordon_> as i primarily see it as describing use of OpenStack as a VIM
14:24:54 <ybabenko> So, can we vote on the start "use-case"?
14:25:03 <sgordon_> and how an external orchestrator (whatever that may be) would use it
14:25:04 <margaret__> So that is the next debate - what is the role of an SDN controller vs an orchestrator - we have our view which I know is different from others
14:25:27 <jannis_rake-reve> sgordon_: i agree
14:25:35 <mkoderer> sgordon_: I think we should move on and bring that topics to the ML
14:25:36 <aveiga> margaret__: that's the real issue here, no matter what everyone will hav a different definition
14:25:41 <sgordon_> +1
14:25:42 <dgollub> I guess what would be interesting for the community ... to clarify what this *orchestrator* actually is would be to fill/clarify following gap: TOSCA CSAR (or HOT) ----> ....*big orchestrator gap*.... ---> running VNF
14:25:47 <aveiga> do we define some of these thigns explicitly to avoid confusion?
14:25:47 <matrohon> margaret__ : +1 :) sorry for the troll
14:25:53 <sgordon_> my proposal would be that i organize the wiki and draft a template
14:26:12 <sgordon_> people can propose use cases, and then we can debate priorities, appropriateness etc
14:26:26 <ybabenko> sgordon +1
14:26:39 <amitry> Sgordon_: +1
14:26:40 <aveiga> sgordon_: I think we should really have a glossary in here for definining terms like "orchestrator"
14:26:40 <sgordon_> i think this also drifts into the clarification of group scope
14:26:44 <aveiga> insofar as we are able
14:26:53 <sgordon_> aveiga, +1 i think that's a good idea
14:27:02 <sgordon_> we had discussed a glossary previously (as nfv team)
14:27:13 <sgordon_> and didnt want to open that can of worms but i think a limited one would be good
14:27:21 <aveiga> I don't think it's optional anymore, as we have differing opinions even within this group
14:27:29 <sgordon_> does anyone want to take an action on the glossary aspect?
14:27:31 <jannis_rake-reve> aveiga: I would really not like to reinvent the veil here but have a reference to sth existing, either a model, standard or implementation example
14:27:45 <ajo> aveiga +1 for the glossary
14:27:51 <aveiga> jannis_rake-reve: right, but which reference do you want to use?
14:27:51 <margaret__> Should refer to ETSI ISG NFV docs on terminology before we re-invent... And then build from there
14:28:13 <margaret__> This also has been debated in ETSI ISG NFV
14:28:13 <jannis_rake-reve> aveiga: I do not know since it depends on the people involved in this group
14:28:28 <jannis_rake-reve> margaret__:  yes, maybe
14:28:34 <aveiga> jannis_rake-reve: that's why I brought it up, since it can vary wildly
14:28:35 <sgordon_> #action sgordon_ to kick off M/L discussion about template for use cases
14:28:55 <sgordon_> #info need a glossary for overloaded terms, e.g. orchestration, to define common understanding
14:29:01 <dgollub> I guess it would help if we could start mapping the ETSI NFV MANO components to existing OpenStack components/services ....
14:29:05 <sgordon_> #info should refer to ETSI ISG NFV docs first
14:29:17 <jannis_rake-reve> sgordon_:  how can we get started with the gloss?
14:29:26 <sgordon_> jannis_rake-reve, i would suggest just on the wiki
14:29:44 <sgordon_> either as a subsection of https://wiki.openstack.org/wiki/TelcoWorkingGroup
14:29:46 <sgordon_> or create https://wiki.openstack.org/wiki/TelcoWorkingGroup/Glossary
14:30:04 <mkoderer> sgordon_: +1 for a new page
14:30:07 <ajo> I'm new here, but are those ETSI NFV documents available?
14:30:26 <margaret__> I can pull in the ETSI terminology doc - I just can't attend these IRCs alot since this is my first one
14:30:37 <margaret__> yes docs are available
14:30:42 <akhila-chetlapal> would the NFV orchestration be of interest to this group
14:30:52 <ajo> margaret__, can they be linked to the wiki?
14:30:56 <jannis_rake-reve> ajo: yes :http://www.etsi.org/technologies-clusters/technologies/nfv
14:31:06 <sgordon_> #link http://www.etsi.org/technologies-clusters/technologies/nfv
14:31:11 <margaret__> there you go!
14:31:13 <mkoderer> akhila-chetlapal: we have it on the agenda for today
14:31:25 <ajo> thanks! :)
14:31:40 <jannis_rake-reve> i believe we can use them as a reference but not take them as a SPoT
14:31:41 <sgordon_> akhila-chetlapal, per the enthusiastic discussion above it depends what we mean by orchestration ;)
14:31:45 <ybabenko> mkodere +1
14:32:13 <sgordon_> ok being mindful of time, who wants to take the action to update the wiki wrt glossary?
14:32:15 <jannis_rake-reve> i have seen too much lobbying in that area, we need to focus on the ability to implement short to medium term
14:32:49 <jannis_rake-reve> sgordon_:  shouldnt that be a grp effort anyway?
14:33:05 <sgordon_> jannis_rake-reve, someone still needs to create the page etc
14:33:23 <jannis_rake-reve> sgordon_:  sure put me down
14:33:45 <sgordon_> i also dont want to drift the group to far towards committee style interaction - i think it is fine for someone to propose something on the wiki
14:33:50 <akhila-chetlapal> am specifically referring to the VNF lifecycle management which cannot happen via neutron plug-in components or SDN controllers
14:33:53 <sgordon_> and then we debate/discuss either here or on M/L
14:34:23 <sgordon_> #action jannis_rake-reve to create glossary page on wiki
14:34:23 <jannis_rake-reve> how can we make sure that we dont overload on the gloss and drill down to the specification of the use cases?
14:34:49 <sgordon_> jannis_rake-reve, i would keep it limited to terms where we have contention specific to the openstack context
14:34:52 <amitry> sgordon_: +1
14:34:56 <sgordon_> that arent covered in the ETSI material
14:35:05 <ajo> sgordon_: +1
14:35:06 <akhila-chetlapal> i can put up a blueprint for review and update that based on comments so that we have a context for VNF orchestration
14:35:30 <sgordon_> #info keep glossary limited to terms where there is contention specific to the openstack context that aren't covered in the ETSI material
14:35:33 <akhila-chetlapal> or should it be in the NFV wiki
14:36:06 <sgordon_> akhila-chetlapal, there is an item on orchestration in the other discussion that i think mkoderer
14:36:09 <sgordon_> let's try and get to it then
14:36:19 <sgordon_> #topic Third Party CI
14:36:46 <sgordon_> there has been some ongoing discussion about the need for third party CI for some of the functionality that was implemented in juno and is being expanded in kilo
14:36:59 <sgordon_> i dont think there is much to discuss atm other than that the relevant parties are working on it
14:37:27 <sgordon_> e.g. imendel, ahoban, ijw, russellb and myself
14:37:38 <sgordon_> #info third-party ci work and discussion continuing
14:37:51 <sgordon_> #topic Meeting times
14:38:17 <sgordon_> i proposed on mailing list an alternate time of Wednesday's @ 2200 UTC (starting next week)
14:38:30 <sgordon_> so we would alternate between 1400 UTC one week and 2200 UTC the next
14:38:47 <sgordon_> i have not had any feedback/positive or negative on this but will confirm on monday hopefully
14:39:01 <sgordon_> #action sgordon_ to lock in meeting time for next week on monday barring further feedback
14:39:29 <sgordon_> i am going to skip over vlan trunking and come back to it if we have time
14:39:34 <amitry> Isn't next Wednesday right before thanksgiving?
14:39:41 <sgordon_> amitry, yes
14:39:54 <sgordon_> so in general expecting not the highest attendance regardless of time
14:39:58 <aveiga> amitry: mostly American holiday ;)
14:40:08 <amitry> True
14:40:14 <jannis_rake-reve> sgordon_: i think for EU that alternation is fine
14:40:16 <aveiga> that timeslot is for APAC, so we should still have the meeting
14:40:23 <sgordon_> i live in the true white north so no holiday for me though
14:40:31 <aveiga> yours was last month :)
14:40:37 <sgordon_> :)
14:40:47 <jannis_rake-reve> back to topic :)
14:40:51 <aveiga> sorry
14:40:56 <sgordon_> we can pick up the most important piece (use cases) via M/L though
14:40:56 <amitry> Sorry
14:40:57 <jannis_rake-reve> aveiga: np
14:41:03 <sgordon_> #topic telco orchestration
14:41:10 <mkoderer> all right
14:41:14 <sgordon_> mkoderer, you had added https://etherpad.openstack.org/p/telco_orchestration
14:41:16 <sgordon_> #link https://etherpad.openstack.org/p/telco_orchestration
14:41:29 <sgordon_> #info (ijw) I think you'd need to make clear what orchestration would be an Openstack *service* and what would be better implemented as an Openstack *application* - what you've described there could be an application but pretty much all Openstack projects today are integrated services.
14:41:31 <mkoderer> yep, so we just have a short meeting and put things together
14:41:34 <jannis_rake-reve> mkoderer: i like it
14:41:51 <sgordon_> ian had added the above feedback to the agenda, other comments etc. welcome
14:42:24 <dgollub> wtr. to ijw comment: I guess by service a full "service" telcos are offering to customers is meant ... e.g. a full fledged IMS deployment
14:42:37 <sgordon_> i think the key piece is the mapping on line 45
14:42:38 <mkoderer> yep... IMHO the goel would be to move as much as possible to OS components
14:42:50 <sgordon_> and drilling down on the gaps on line 57 in much more detail
14:43:08 <aveiga> dgollub: that's an application though, as OpenStack doesn't offer IMS
14:43:11 <aveiga> it runs on top of it
14:43:34 <sgordon_> right
14:43:38 <aveiga> it's a service from the telco POV, but an over the top application from OpenStack's view
14:43:39 <sgordon_> ian is coming at it from the pov
14:43:48 <sgordon_> of "im an openstack dev, what do i need to do to help you"
14:44:00 <aveiga> yup, and this WG should take a similar approach
14:44:00 <dgollub> aveiga: good point ..then we should rewrite that statement and replace the term "service" with "application"
14:44:04 <aveiga> otherwise the work won't get done
14:44:12 <jannis_rake-reve> +1
14:44:20 <mkoderer> dgollub: +1
14:44:26 <Jakiro> t+1
14:44:34 <DaSchab> +1
14:44:54 <mkoderer> I think we spend some more time in the etherpad
14:45:02 <mkoderer> and then I would like to create a document in the wiki
14:45:03 <sgordon_> #info need to rewrite to make clearer what's OpenStack "service" versus "application"
14:45:07 <sgordon_> that seems reasonable
14:45:09 <dgollub> updated the etherpad ...
14:45:19 <sgordon_> etherpad is good for quick collaborative editing
14:45:29 <ajo> +1 service->application
14:45:35 <sgordon_> once we have something everyone is comfortable with in terms of scope then it makes sense to put it in the wiki
14:45:44 <mkoderer> sgordon_: +1
14:45:47 <jannis_rake-reve> agree
14:46:00 <akhila-chetlapal> agree
14:46:04 <Jakiro> agree
14:46:11 <sgordon_> #info further edits to be done in etherpad, once consensus is reached move to wiki
14:46:44 <mkoderer> should we also start a M/L discussion and point to the etherpad?
14:46:50 <sgordon_> mkoderer, yes please
14:47:07 <mkoderer> sgordon_: ok, sound good to me
14:47:20 <sgordon_> note that since we renamed the group atm i am using the [NFV] and [telco] tags to denote these messages
14:47:20 <jannis_rake-reve> maybe focus on things that help other interest groups first
14:47:30 <sgordon_> after a while probably makes sense to just use [telco]
14:47:53 <sgordon_> #action mkoderer to kick off mailing list thread to get wider feedback
14:48:00 <sgordon_> thanks for that
14:48:00 <mkoderer> jannis_rake-reve: do you have some suggestions?
14:48:20 <dgollub> jannis_rake-reve: we put this on the etherpad "Improve/extend OpenStack orchestration in such gerneral/common way that they are useful also outside Telco-OpenStack setups"
14:48:23 <jannis_rake-reve> mkoderer: IPv6 feature parity is the most obviious one
14:48:29 <ybabenko> jannis  it looks like a lot of tention is around neutron?
14:48:35 <ybabenko> IPv6 +1
14:48:59 <ybabenko> multi-site openstack support ?
14:49:02 <amitry> IPv6 +1
14:49:41 <mkoderer> ybabenko: yep, we would like to spend some effort to build a multi region heat for instance
14:49:42 <jannis_rake-reve> i would really like to have more standardized QoS APIs
14:49:52 <aveiga> federation (multi-site) is in progress but will be a requirement for proper service chaining
14:49:55 <jannis_rake-reve> and not rely on telling OS to use SRIOV etc
14:50:11 <aveiga> jannis_rake-reve: +1 on QoS, you should talk to sc68cal...
14:50:13 <amitry> QoS +1
14:50:13 <jannis_rake-reve> so rather specify certain limits / thresholds instead of tec
14:50:14 <ybabenko> aveiga: is a must for carrier setup with openstack
14:50:24 <jannis_rake-reve> sry -technology
14:50:39 <matrohon> there was an agreement on Qos in neutron design summit
14:50:51 <ybabenko> jannis_rake-reve: QoS in OVS?
14:50:53 <jannis_rake-reve> matrohon: thanks didnt know that
14:51:14 <matrohon> a lightweight version of Qos should la,d, which deal only with traffic shaping
14:51:22 <jannis_rake-reve> ybabenko: should not be specific to OVS, and I know that it is hard
14:51:35 <dgollub> coming from the VNF vendor side: I would not underestimate the importance on setting an open source standard how to provision/configure an actual VNF ... if we as OS community take her the lead hopefully this will become the defacto standard without too much proprietary stuff on top of OS
14:51:37 <ybabenko> matrohon: who manages QoS settings? OpenStack Neutron?
14:51:39 <jannis_rake-reve> matrohon: yes as a start, do not overspecify
14:52:04 <matrohon> neutron yes; ovs and linuxbridge are targeted
14:52:06 <ybabenko> jannis_rake-reve: QoS for overlays?
14:52:27 <mkoderer> dgollub: are you refering to netconf yang?
14:52:35 <ybabenko> jannis_rake-reve: we are thinking mainly in terms of overlays, right? guess, few ppl will just use plaing VLAN Taggins
14:52:43 <jannis_rake-reve> maybe we should take the QoS discussion to the etherpad
14:52:43 <dgollub> mkoderer: for instance ... or what ever will be OS's answer to configure a VNF
14:53:05 <jannis_rake-reve> as a subpoint of what makes VNFs special
14:53:13 <jannis_rake-reve> as started by mkoderer
14:53:33 <jannis_rake-reve> ybabenko: yes, but it should be agnostic
14:53:38 <ybabenko> dgollub: where NFV manager gets complete topology information? provided we have multi-site. This issues is still open for me
14:53:50 <dgollub> right now vendors pushing in the market with random VNFs ... in different format with different interfaces... and want to put their metadata for provision/configuration in random places
14:54:11 <jannis_rake-reve> we are now appraoching top down and bottom up at the same time :)
14:54:19 <aveiga> so, middle-out?
14:54:22 <aveiga> ;)
14:54:45 <jannis_rake-reve> how about the expansion of https://etherpad.openstack.org/p/telco_orchestration or a dedicated pad
14:54:53 <jannis_rake-reve> regarding "special" requirements
14:54:56 <sgordon_> i completely agree with the line of thought wrt QoS
14:54:58 <aveiga> ybabenko: I'd caution against overlay-only.  I'm a telco, and I run VLAN tags...
14:55:04 <jannis_rake-reve> mkoderer: what do you think?
14:55:11 <dgollub> ybabenko: that is open for me as well ... that is why I wanted to move the attention again on a higher layer on the OS stack ...
14:55:21 <jannis_rake-reve> aveiga: we are to and we mix overlay and underlay
14:55:28 <jannis_rake-reve> *too
14:55:34 <mkoderer> jannis_rake-reve: yep sounds good.. this it acutally a very important topic
14:56:04 <ybabenko> aveiga: see no chance taking l2 failure domains, security and multitenancy into account
14:56:04 <margaret__> another debate - overlay - underlay...
14:56:50 <jannis_rake-reve> margaret__: thats why i would like to keep it agnostic
14:56:55 <jannis_rake-reve> as OS already does
14:57:02 <margaret__> agree
14:57:03 <jannis_rake-reve> regarding the network creation e.g.
14:58:34 <sgordon_> #info discussion aboute qos, underlay versus overlay, etc. ensues in the context of what makes a VNF special
14:58:43 <sgordon_> wary that we're reaching the top of the hour here
14:58:52 <sgordon_> lots of good discussion though
14:59:06 <sgordon_> some of these points i feel would be well suited to further hashing out in that etherpad or on the mailing list
14:59:19 <jannis_rake-reve> does anyone have a link to the discussion on QoS in the summit and can link in the pad?
14:59:23 <mkoderer> sgordon_: yep I think let's bringt it to the ML
14:59:24 <sgordon_> and ideally via use cases once i complete my action to provide a framework :)
14:59:28 <jannis_rake-reve> +1
14:59:41 <sgordon_> ok
14:59:45 <margaret__> what is ML?
14:59:50 <jannis_rake-reve> mailing list
14:59:51 <sgordon_> mailing list, sorry
14:59:52 <mkoderer> margaret__: Mailing list
14:59:57 <margaret__> ok thanks
15:00:08 <sgordon_> inventing more terminology ... :)
15:00:14 <sgordon_> thanks all!
15:00:14 <amuller> I'd like to mention that VLAN trunking in Neutron is kind of stuck
15:00:40 <matrohon> jannis_rake-reve : tahre agreement on Qos has been decided on friday, so no ehepad
15:00:40 <sgordon_> amuller, ah - i hadn't caught up on that thread and didn't see eric or ian so hadn't brought it up
15:00:41 <ybabenko> sgordon_: thanks
15:00:47 <sgordon_> need to discuss in neutron meeting monday i guess?
15:01:13 <amuller> sgordon_: We need to get Eric and Ian talking to one another and Neutron cores, otherwise it'll continue to be stuck
15:01:17 <jannis_rake-reve> matrohon: thx
15:01:26 <jannis_rake-reve> sgordon_: thanks for modding
15:01:30 <amuller> in the upstream meeting or any other form
15:01:45 <sgordon_> #info amuller notes vlan trunking stuck - need eric and ian to discuss amongst themselves and with cores
15:01:53 <sgordon_> #action sgordon_ to follow up on vlan trunking
15:01:57 <sgordon_> thanks amuller
15:02:01 <sgordon_> #endmeeting