22:01:08 <sgordon> #startmeeting telcowg
22:01:09 <openstack> Meeting started Wed Feb  4 22:01:08 2015 UTC and is due to finish in 60 minutes.  The chair is sgordon. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:13 <openstack> The meeting name has been set to 'telcowg'
22:01:15 <jaypipes> sgordon: heyo
22:01:23 <sgordon> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
22:01:28 <sgordon> #topic roll call
22:01:28 <beagles> hi
22:01:33 <sgordon> hi jaypipes, beagles
22:01:40 <sgordon> who else is here for the telco working group meeting
22:01:45 <pjnaik1990_> Hello, I am a newbie to Openstack. I found it very interesting and a good platform to learn. I read about the Congress project and would like to contribute towards it. Could anybody help me with any idea or a small part where I could contribute.
22:01:45 <sgordon> mkoderer ?
22:01:48 <pgpus> Hi rprakash hetre and have MNO-MVNO use case added today
22:02:00 <sgordon> pjnaik1990_, might be better off asking in #openstack
22:02:04 <pgpus> await steveg
22:02:15 <aveiga> o/
22:02:30 <pgpus> This is telcowg right?
22:02:33 <sgordon> yes
22:02:35 <jaypipes> yep
22:02:43 <sgordon> #topic action items from last week
22:02:44 <pgpus> OK then I am finne
22:02:51 <sgordon> mkoderer was to define scope of OpenStack HA use case clearly
22:03:05 <sgordon> i had a look at the minutes and relevant etherpad since i was afk last week
22:03:06 <pgpus> Ok
22:03:09 <sgordon> seems like this is still wip
22:03:12 <pjnaik1990_> okay
22:03:17 <sgordon> so i will carry the action item over for us to check back next week
22:03:23 <sgordon> #action mkoderer define scope of OpenStack HA use case clearly
22:03:27 <sgordon> #topic use cases
22:03:34 <sgordon> #topic use cases - mechanism
22:03:48 <pgpus> OK I can share this MNO-MVNO use case for discussion if this is right time
22:03:52 <sgordon> before we attempt to dive in there was a lot of discussion in the previous meetings about how we facilitate
22:03:55 <pgpus> #link https://etherpad.openstack.org/p/mno-mvno
22:04:00 <sgordon> the recording and reviewing of use cases
22:04:06 <sgordon> pgpus, please hold up until we get to it
22:04:18 <sgordon> agenda is in the etherpad https://etherpad.openstack.org/p/nfv-meeting-agenda
22:04:21 <pgpus> No problems will wait
22:04:21 <sgordon> i added your item
22:04:37 <sgordon> so in terms of trying to record use cases we started off with the wiki
22:04:47 <sgordon> we then moved to etherpad
22:05:03 <sgordon> and now there is a suggestion to use gerrit (e.g. https://review.openstack.org/#/c/152940/1 )
22:05:17 <sgordon> i dont really have a strong preference except that we should use ONE
22:05:23 <sgordon> :)
22:05:25 <jaypipes> ++
22:05:33 <sgordon> so e.g. if we pick etherpad
22:05:42 <sgordon> we should remove the stuff on the wiki and just have the links
22:05:54 <sgordon> conversely if we choose wiki let's scrub the etherpads and so on
22:06:10 <sgordon> i think etherpad or gerrit best provides for inline feedback which is what we seemed to be missing to start with
22:06:12 <sgordon> thoughts?
22:06:24 <aveiga> I'll +1 not the wiki
22:06:42 <jaypipes> gerrit ++
22:06:51 <jaypipes> it's the "openstack way"
22:07:04 <aveiga> I'd prefer gerrit as well, but not all Telcos contribute code and would know how to use it...
22:07:11 <sgordon> yes, the main concern about gerrit has been having a barrier to use
22:07:14 <jaypipes> just have a repo called nfv-specs or something like that
22:07:19 <sgordon> mkoderer bucked the trend a bit by just doing it
22:07:22 <pgpus> sure it is Etherpad way +
22:07:28 <aveiga> and since these are use cases used to identify gaps instead of writing the specs...
22:07:28 <jaypipes> just like he openstack-specs repository.
22:07:33 <sgordon> and suggesting those of us that know how to gerrit could submit
22:07:41 <jaypipes> mkoderer is awesome like that :)
22:07:54 <sgordon> indeed
22:08:02 <sgordon> so i think if we go with a repo we dont want to name it specs
22:08:07 <aveiga> +1
22:08:13 <sgordon> per what aveiga was saying in that we are aiming for it to be use cases
22:08:23 <jaypipes> sure, makes sense
22:08:24 <sgordon> which ideally would end up in the justification/use case section of specs eventually
22:08:38 <aveiga> specs are for definining how code shuld be writte, use cases are here to figure out what we need to write
22:08:56 <sgordon> does someone have to have signed the CLA to provide feedback on gerrit?
22:09:01 <sgordon> or just be a member?
22:09:02 <jaypipes> yes
22:09:11 <jaypipes> CLA, IIRC
22:09:13 <aveiga> gerrit login requires the CLA
22:09:20 <jaypipes> oh wait, no...
22:09:42 <jaypipes> gerrit login does not require CLA. only launchpad ID.
22:09:50 * aveiga thinks maybe we should check?
22:09:52 <sgordon> right
22:09:55 <pgpus> See even if we use etherpad we can add diagrams using asciflow like IETF docs and that helps in use case expalinations
22:09:56 <jaypipes> to submit a patch you need to sign the CLA, though.
22:09:59 <sgordon> i will take a note to double check if you can comment
22:10:06 <sgordon> you definitely do to submit of course
22:10:21 <sgordon> #info sgordon to check if you need to sign CLA to *comment* on gerrit
22:10:28 <jaypipes> sgordon: you do not need to sign the CLA to comment.
22:10:32 <sgordon> #info consensus seems to be "not the wiki" for use cases
22:10:46 <sgordon> #info jaypipes points out that you do not need to sign the CLA to comment.
22:10:50 <jaypipes> heh
22:11:07 <sgordon> ok
22:11:15 <sgordon> so i think i am happy enough if we go down the gerrit path
22:11:52 <pgpus> #info without CLA how do you get to use etherpad , I thought thats normal
22:12:05 <sgordon> #action sgordon to request git repo via infra
22:12:09 <aveiga> let's make sure the wiki points to a gerrit filter for the use cases, at least
22:12:29 <sgordon> #info wiki will need to point to a gerrit filter for use cases, if not specific links
22:12:30 <aveiga> it's likely to be a jumping in point for lots of people
22:12:33 <sgordon> yeah
22:12:51 <sgordon> #info wiki will also need links to the how to contribute info to get people up and running with a lp account
22:13:04 <sgordon> #action sgordon to update wiki reflecting all of the things
22:13:13 <sgordon> ok
22:13:17 <sgordon> so having said all that
22:13:24 <sgordon> #topic use cases - wip
22:13:31 <sgordon> pgpus, you wanted to raise your WIP use case?
22:13:48 <sgordon> #link https://etherpad.openstack.org/p/mno-mvno
22:14:41 <sgordon> for me, as a relative noob, the links between the characteristics, requirements and associated blueprints
22:14:45 <sgordon> are not immediately obvious
22:15:43 <sgordon> pgpus, can you comment for example on the link to https://blueprints.launchpad.net/keystone/+spec/hierarchical-administrative-boundary  ?
22:16:24 <sgordon> (not saying this isn't a desirable thing, just wondering how it is specific to this use case)
22:17:41 <pgpus> yes
22:18:07 <pgpus> So do you want me to describe the use case
22:18:50 <pgpus> See what happens is MNO and MVNO form a Hierarcy
22:19:03 <pgpus> That can be addressed in one way through Keystone
22:20:23 <pgpus> So this is one of the requirments to help Provider to eg lease resouces to sub-provider (like MNO to MVNO)
22:21:10 <pgpus> MNO services to MVNO is critical for the both MNO wholesale & MVNO retails markets. As we look to virtualize our Network Functions, VNF instantiation on a  MNO/MVNO needs to be addressed since resource pooling, IP address management and placement of VNF is important. This Proposal is to focus on Resource Pooling,  MNO/MVNO IPAM designs and VNF placements in Openstack orchestration for Mobile Networ
22:21:10 <pgpus> k Nodes Topology.  This will allow interoperable VNF  for an MVNO  to use its and MNO resources optimally, within the address space allocated top dpown, plus  configuring  subscriber SIM & APN service on a Mobile Phone  to use MVNO or MNO (in-network)  as preferred access end points. Thus the effort will contribute to standardization of MNO, MVO and subscriber interactions from whole sale, retail t
22:21:11 <pgpus> o operations and third party billings.
22:21:31 <sgordon> so i guess what i am getting at is reading the description as is
22:22:06 <sgordon> the link is not immediately obvious because the description doesn't actually explain what the use case is, from an openstack pov
22:22:54 <sgordon> that is, it doesn't explain what MNO or MVNO actually is, and how it would be designed/deployed/used
22:23:05 <pgpus> DO you want me describe the use case through examples are state just requirments?
22:23:38 <sgordon> i would recommend revisiting the description section in the etherpad
22:24:04 <sgordon> and trying to explain it in clearer terms for the non-telco crowd we need to reach to actually design/implement solutions
22:24:34 <sgordon> the requirements section isn't as bad, but for instance to an openstack developer what does "3. Ability to provision a Subscriber SIM  for LTE from MNO (like AT&T)  by  MVNO" actually mean
22:24:39 <pgpus> An MNO sells their resources like P=GW, S-GW with saome address ranges to use and MVNO in turn uses the segment or slice allocated to issue SIMS based on APNs etc
22:24:52 <sgordon> im not asking for the explanation now :)
22:25:04 <sgordon> just suggesting updating the etherpad some more keeping these points in mind
22:25:11 <pgpus> OK correct me what your feedback is and will fix it
22:25:28 <jaypipes> ugh, so many damn TLAs.
22:25:34 <sgordon> indeed
22:26:01 <sgordon> i think it's important to note that we're trying to bridge the gap between telcos and the broader openstack community here
22:26:10 <pgpus> Certainly Mobile Network has this will add Glosaryy to expain TLAs
22:26:21 <sgordon> and a lot of the TLAs common in the telco land are not well understood here
22:26:56 <pgpus> Agreed , let me try simply (what terminology you want changed) suggest please
22:27:28 <pgpus> shall i call MONO Opeartps and MVNO a Virtual Opeartor for example
22:27:47 <jaypipes> what is "Opeartps"?
22:28:13 * beagles is hoping it is a typo  - Operator and virtual operator
22:28:13 <pgpus> Operator is Carrier or Provider of Mobile Network Services
22:28:28 <jaypipes> and Virtual Operator == reseller?
22:29:39 <pgpus> can call it Wholesale provider and reseller but indusry uses term as MNO and MVNO like Google is becoming an MVNO by using T-Mobile and Sprint for issuing its Phone subscriptions
22:29:56 <jaypipes> I see, ok, thank you pgpus
22:30:39 <aveiga> pgpus: I think what sgordon was trying to tell you is most people writing code for OpenStack aren't part of your industry, so terms you take for granted will not be well understood
22:30:52 <jaypipes> right.
22:30:53 <sgordon> right, so that makes more sense to someone coming from a non-telco background
22:31:04 <sgordon> which is what i would recommend keeping in mind throughout
22:31:05 <pgpus> We have a firealarm here I will be forced to quit please advice me on your feednbacks and will fix it
22:31:46 <sgordon> ok no problem
22:31:47 <pgpus> Fortunate it was afalse alarm
22:31:59 <sgordon> there were a couple of implementation things on my list to check in on
22:32:00 <pgpus> I am back
22:32:04 <sgordon> ijw_, do you happen to be around?
22:32:11 <ijw_> no
22:32:19 <jaypipes> heh
22:32:21 <ijw_> Never heard of the guy
22:32:26 <beagles> nice
22:32:42 <ijw_> VLAN and MTU?
22:32:49 <jaypipes> pgpus: soo.....
22:32:56 <sgordon> #topic implementation
22:32:59 <sgordon> ijw_, why yes :)
22:33:12 <ijw_> In progress, though I've just had someone sound worried about the implementation timeline, so I'll be warming up my emacs to get a few of the bits done myself
22:33:15 <aveiga> ijw_: do tell, as I'm sorely interested
22:33:27 <sgordon> ijw_, what are the actual deadlines from neutron POV
22:33:33 <jaypipes> pgpus: when I read this use case, I have a stream of questions for each bullet point, starting with "how is this relevant to OpenStack -- specifically Neutron and nova"
22:33:40 <ijw_> 3 March is the one they raised
22:33:41 <sgordon> for nova everything is basically frozen for work not on the priorities list as of tomorrow
22:33:56 <jaypipes> pgpus: for example: "Standardize the APIs for Mobile Network Provisioning, Usage, recharging, billing, payments  both Resource facing South Bound and Subscriber/Prvider facing North Bound"
22:34:07 <jaypipes> pgpus: what does that have to do with OpenStack?
22:34:10 <ijw_> We may have an MTU change in Nova, it sets up the veth gubbins (technical term) and so we might want to pass the MTU across the plugging interface
22:34:29 <pgpus> Since the SIM (Subscriber ID Module)  can be issued with private labeling and APN (Access Point Names) or private DNS Names used in Carrier for public access to Originating or Terminating Mobile devices with IP alloacted from Packet Gateway Pools
22:34:43 <aveiga> ijw_: will this carry over in a method consumable by the ml2 architecture?
22:34:51 <sgordon> ijw_, ok - that might be problematic based on my understanding of the rigidness with which the freeze is to be enforced this time
22:34:53 <ijw_> pgpus: joining in quickly - I don't think what you're talking about is a VIM level requirement
22:34:56 <aveiga> i.e. telling the local mech driver to set to X
22:35:18 <ijw_> aveiga: this isn't nova-network, this is the Neutron side of a standard OVS VIF plug
22:35:37 <ijw_> In fact, it's more than Neutron itself needs to do, and shouldn't affect future implementations
22:35:50 <ijw_> sgordon: can we check with someone?
22:36:07 <aveiga> wekkm doesn't the layer 2 implemention need to at least meet if not exceed that MTU?
22:36:23 <aveiga> wel, even
22:36:24 <aveiga> well and damn this keyboard
22:36:27 <ijw_> aveiga: and at least initially we ask the mech driver what X it would prefer - the setting, at the moment, is not going to be implemented, per the spec
22:36:31 <pgpus> Neutron Side ML2 has Type and Mechanism drivers, Type does Proptoal selection and Mechnism the run times for the  APIs supported for Objetts
22:36:46 <ijw_> aveiga: I think you have it upside down
22:36:54 <aveiga> ah, ok
22:36:58 <aveiga> that's what I thought
22:37:01 <pgpus> like Openflow using OVS or other like OVSDB for ODL
22:37:09 <ijw_> aveiga: Idea is that we find out what the fabric will do (for now) and report it
22:37:16 <sgordon> right
22:37:18 <sgordon> and that is all
22:37:20 <ijw_> pgpus: I think you're in the wrong channel.
22:37:26 <aveiga> that's much better
22:37:37 <pgpus> So Plugin has standard API for Neutron and Driver does deply them on Compute nodes
22:37:45 <pgpus> rest is RPC mecahnism
22:37:55 <ijw_> Bearing in mind that nothing you say is relevant to this meeting and this meeting will be recorded and googleable for all time
22:38:36 <sgordon> pgpus, we're talking about a fairly specific change now
22:38:59 <pgpus> OK I will listen rather coment for now
22:39:42 <sgordon> ijw_, i think the challenge is atm from a nova perspective we don't have a code change to point to
22:40:08 <aveiga> sgordon: chicken and egg?
22:40:14 <sgordon> aveiga, yeah
22:40:22 <sgordon> aveiga, normal neutron/nova interaction :)
22:40:53 <aveiga> kinda like the IPv6 adoption argument :)
22:40:53 <ijw_> sgordon: usual problem, I'm afraid
22:41:01 <sgordon> ijw_, am i correct in understanding that the nova part would be desirable but not mandatory?
22:41:05 * sc68cal grumbles
22:41:05 <ijw_> At the point that Neutron does all its side of the MTU work the Nova side is kind of a bug
22:41:37 <ijw_> sgordon: it's the veth MTU that matters, we could probably just configure it large
22:41:38 <aveiga> sgordon: you need it for the guest interface to actually use the MTU
22:42:01 <aveiga> otherwise, nova's just going to plug like a standard 1500byte
22:42:28 <sgordon> yeah
22:43:17 <sgordon> there is no nova work on the vlan reporting right?
22:43:56 <ijw_> Nope.
22:44:06 <ijw_> Nova either works with vlans or we're buggered, I think
22:44:27 <sgordon> indeedy
22:45:06 <ijw_> And while I admit I'm a bit qemu-centric it's hard to see what could go wrong with vlans (or indeed MTUs) between the Neutron binding point and the machine in any circumstance
22:45:15 <sgordon> #info vlan trunking and mtu advertisement/selection implementation pending, potential issues with nova changes for the latter colliding with freeze
22:45:31 <sgordon> yeah i agree
22:46:14 <sgordon> i had a couple of other fun ones
22:46:21 <sgordon> start with the easy one and work back
22:46:46 <sgordon> #info I/O based NUMA scheduling is looking relatively good
22:46:54 <sgordon> not sure if it merged or is somewhere in the gate still
22:47:12 <sgordon> soft affinity for server groups is in a fair amount of bother i would say
22:47:15 <sgordon> #link https://review.openstack.org/#/q/topic:bp/soft-affinity-for-server-group,n,z
22:47:42 <sgordon> Balazs has been iterating on them but still a number of items outstanding
22:47:54 <sgordon> reviews welcome etc.
22:48:47 <pgpus> #info But looks it was abandoned
22:48:53 <sgordon> ijw_, now i might need your help wrapping my dense head around where the ML2 port security implementation is up to, are these competing implementations?:
22:48:57 <sgordon> https://review.openstack.org/#/q/topic:bp/ml2-ovs-portsecurity,n,z
22:49:18 <sgordon> pgpus, no it's alive, the abandoned one was the juno proposal
22:49:22 <ijw_> sgordon: the one thing we require is that there is a way to turn the bloody address/mac filtering off
22:49:24 <sgordon> pgpus, it was approved again for kilo
22:49:34 <pgpus> #ino OK i see
22:50:07 <sgordon> ijw_, right - so is this just a continuation of trying to boil the ocean on this?
22:50:09 <ijw_> sgordon: and Isaku's proposal was the one that seemed to have the most support and be compatible with that
22:50:25 <ijw_> sgordon: well, no-one would let me make a nice cup of tea
22:50:32 <aveiga> haha
22:51:17 <sgordon> ok
22:51:49 <sgordon> i dont know what else to say about that lol
22:51:59 <ijw_> So I see it's blocked, but that seems to be because it's a WIP block.  I don't think we're looking at a problem here.  I'll check with Shweta.
22:52:09 <pgpus> #info rk mentions the use of session level security rather at Plugin level as each time security context may change thus he is right on that
22:52:10 <sgordon> yeah
22:52:18 <sgordon> it seems to be getting good feedback from bob
22:52:25 <sgordon> just needs some more iterations
22:52:56 <sgordon> #action ijw_ checking with Sweta if any blocking issues on ML2 port security
22:53:14 <sgordon> #topic open discussion
22:53:19 <sgordon> anyone got any good jokes?
22:53:34 <sgordon> again i will mention the operators mid-cycle is coming up
22:53:52 <sgordon> this is a general event for openstack operators of all types, agenda here:
22:53:54 <sgordon> #link https://etherpad.openstack.org/p/PHL-ops-meetup
22:54:07 <aveiga> if you plan on atending, make sure you register
22:54:13 <sgordon> i would encourage attendance more from a meeting other types of operators point of view
22:54:14 <aveiga> it's a limited seat event
22:54:22 <sgordon> we may have a small telco gathering based on who is there
22:54:32 <sgordon> but i dont think at this stage i would recommend travelling just based on that
22:54:39 <aveiga> even if it's informal; I'm up for taking a Telco BoF to a pub
22:54:47 <sgordon> but rather the opportunity to provide feedback on some of the more general sessions
22:54:48 <sgordon> yeah
22:54:50 <ijw_> Translation of pgpus's comments earlier, btw: MVO would be an owner of basestations like ATT, Verizon etc.  MVNO is someone who buys capacity and resells it - Cricket come to mind because of their annoying ads
22:55:12 <pgpus> Any even at LF meet at Santa Rosa Feb 18-20?
22:55:20 <ijw_> I'm there
22:55:54 <pgpus> #action we shall meet and see how OPNFV passes use cases to telcowg
22:55:54 <ijw_> aveiga: +1
22:55:56 <sgordon> #link http://events.linuxfoundation.org/events/collaboration-summit
22:56:19 <sgordon> i assume you are referring to OPNFV meetings running in conjunction with the collab summit?
22:56:23 * ijw_ has seen your homebrew work, and expects careful thought and selection of said pub
22:56:37 <aveiga> ijw_: I won't disappoint
22:56:40 <ijw_> sgordon: yup - I think there's a panel session planned, too
22:56:44 <sgordon> kk
22:56:53 <sgordon> think i am headed in the opposite direction those dates
22:57:01 <pgpus> #info its a side note but helpfull besides whole gamut of LF KVM SDN etc
22:57:28 <sgordon> ok
22:57:34 <sgordon> i am going to call that time
22:57:37 <sgordon> thanks all for coming
22:57:44 <beagles> cheers
22:57:47 <sgordon> #endmeeting