16:59:58 <Cathy_> #startmeeting service chaining
16:59:59 <openstack> Meeting started Thu Jun  4 16:59:58 2015 UTC and is due to finish in 60 minutes.  The chair is Cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:03 <openstack> The meeting name has been set to 'service_chaining'
17:00:21 <Swami> Cathy_:hi
17:00:32 <Cathy_> Swami: hi
17:00:41 <Cathy_> hi louis
17:00:46 <LouisF> Swami: hi
17:00:56 <Swami> LouisF: hi
17:00:57 <Cathy_> let's wait for a few minutes for more people to join
17:01:13 <Cathy_> hi Vikram
17:04:42 <Cathy_> I think we can start
17:05:05 <nbouthors> Cathy_: hello
17:05:16 <Swami> yes please, we can start
17:05:35 <Cathy_> I am thinking about discussing the use case and the components for supporting the service chain.
17:05:43 <Cathy_> nbouthors: hi
17:05:58 <Cathy_> is that OK with everyone. Any other suggestion?
17:06:11 <Swami> Cathy_: fine
17:06:22 <Swami> #Agenda Use Case discussion
17:06:49 <Cathy_> here is a link to the use case and the components for supporting service chaining in Neutron
17:06:55 <s3wong> Swami: #topic would be more appropriate :-)
17:07:18 <Swami> s3wong: yes makes sense
17:08:14 <Cathy_> Swami: would you like to post the link to the slides we prepared for the discussion?
17:08:37 <Swami> sure
17:08:54 <Cathy_> #topic use case and components discussion
17:09:13 <Swami> #link https://docs.google.com/presentation/d/1SpVyLBCMRFBpMh7BsHmpENbSY6qh1s5NRsAS68ykd_0/edit?usp=sharing
17:10:28 <Cathy_> the neutron service chain API is used for the case that the user wants to use OpenStack Neutron and OVS to support service chaining. Any comments on this?
17:11:05 <Cathy_> By Neutron service chain API, I mean the port chain API which was presented at the OpenStack Summit
17:12:05 <LouisF> This basic api is needed to support chaining of vnfs
17:12:37 <nbouthors> Is this an abstract description of the chain ?
17:12:37 <Cathy_> let's go through slide by slide.
17:13:02 <Cathy_> the port chain is not the Intent abstraction level API
17:13:25 <Cathy_> It is a specification of the logical chain API
17:13:55 <Cathy_> the abstraction level matches existing Neutron abstraction level
17:14:00 <Swami> Cathy_: I think what you are trying to say is inorder for the intent based port chaining to occur here are the high level actions items that has to be taken in neutron.
17:14:04 <LouisF> nbouthors: it is a specification of the chain in terms of neutron port-pairs
17:14:32 <Cathy_> LouisF: yes
17:14:40 <LouisF> nbouthors: each port-pair represents a VNF
17:14:45 <Cathy_> Swami: yes
17:15:16 <nbouthors> LouisF: A VNF instance
17:15:26 <LouisF> nbouthors: correct
17:15:34 <Cathy_> The high level intent Infra can map the high level intent abstraction API to this Neutron level port chain API if it wants to leverage the Neutron module functionality
17:16:43 <Cathy_> But in this project, we will not cover the Intent Engine. We will concentrate on implementing the Neutron port chain API and the related service chain plugin to support this API
17:16:47 <nbouthors> So a lot of work has been done prior to using the Neutron Port Chain API, in term of resource identification and location.
17:17:29 <LouisF> nbouthors: what resources do you mean?
17:17:35 <Cathy_> nbouthors: yes in terms of the service function resource and location
17:18:12 <nbouthors> LouisF: for example which VNF instance exists, what are the locators which can be used to send traffic to them.
17:18:26 <Cathy_> So the user needs to first create the service function (like FW) and gets the port of the FW before using this port chain API.
17:19:30 <LouisF> nbouthors: correct, it is expected that the VNF instance resources will already be set up
17:19:36 <nbouthors> Cathy_: OK, what about SFFs addresses ?
17:20:00 <Cathy_> Any question on the use case? and architecture diagram in slide 2?
17:20:21 <LouisF> nbouthors: the steering to SFFs will be handled by the drivers
17:20:28 <nbouthors> Cathy_: yes
17:21:29 <Cathy_> nbouthors: SFF addresses are not specified at the API level and will be automatically decided at the Service chain Plugin and driver level
17:21:32 <nbouthors> LouisF: OK, so we suppose that from a VM info the driver can find the associated responsible SFF. It could work.
17:21:59 <LouisF> nbouthors: that is the idea
17:22:34 <nbouthors> Cathy_: I am checking that it fits  the ODL SFC data model.
17:23:28 <Cathy_> nbouthors: OK. thanks.
17:24:46 <nbouthors> Cathy_: I am ok with slides 2 and 3
17:25:30 <Cathy_> for the case the SDN Controller is plugined into the Neutron, then the SDN Controller will decide the SFF based on the SF locator information. For the case that OVS is plugined into the Neutron, the OVS driver will do that.
17:25:54 <Cathy_> nbouthors: good
17:26:24 <Cathy_> let's go back to slide 4
17:26:33 <Cathy_> go to slide 4
17:27:41 <Cathy_> slide 4 lists the breakdown of the work we need to deliver for supporting the port chain functionality.
17:27:47 <LouisF> in slide 3 should there be a SDNC driver like the OVS driver?
17:28:19 <Cathy_> LouisF: yes, there should be one inside the neutron server
17:28:55 <Swami> LouisF: Can you elaborate on the SDNC driver
17:29:11 <Cathy_> LouisF: we can update the slide to reflect it. Actually if you refer to the service chain presentation slides in the OpenStack Summit, it has that driver
17:29:25 <Cathy_> Hi Alan
17:30:24 <LouisF> Swami: there would be a common sfc driver api with various different datapath driver below it, eg OVS driver, SDNC driver
17:30:24 <Swami> Cathy_: Are you talking about the "Network Controller Service Chain Driver" that you mentioned in your slide deck in the summit.
17:30:42 <Cathy_> yes
17:30:46 <Cathy_> Swami: yes
17:31:19 <Cathy_> Swami: are you OK with that?
17:31:32 <Swami> yes
17:32:13 <Cathy_> #action update the diagram to reflect the Network Controller driver
17:32:58 <Cathy_> now let's go to slide 4. Is it a complete list of the tasks for supporting this service chain functionality in openStack?
17:33:29 <Cathy_> any addition or modification?
17:34:06 <Swami> This should be good to start with. We can add or remove as we go.
17:34:16 <LouisF> that looks like a complete list
17:34:22 <Cathy_> sounds good.
17:34:41 <Cathy_> #topic tasks assignment
17:34:44 <nbouthors> LouisF: Is this something like an ML2 driver structure, where a set of ports are managed by a specific driver, with a plugin mechanism to keep the specific driver out of the main ce tree?
17:35:08 <Cathy_> Now let's see who would like to lead the development/design of which part?
17:35:13 <LouisF> nbouthors: yes that would be the way to go
17:35:49 <nbouthors> LouisF: ok
17:36:07 <Cathy_> Anyone like to lead the CLI/ Horizon/Heat part work?
17:36:13 <Swami> Cathy_: LouisF: I still have a question on the Network Controller Service Chain driver - what would be the functionality of this driver.
17:36:29 <Cathy_> back up a little bit.
17:36:35 <Cathy_> let's start from the beginning
17:37:08 <LouisF> Swami: it would be translate the port chain abstraction into a form used by the SDNC
17:37:32 <Swami> But should that logic reside in neutron.
17:38:08 <Swami> It can be the responsibility of the North bound interface in the SDN controller where neutron feeds in.
17:38:09 <LouisF> Swami: correct but is a specific sdnc driver which would sit below the common sfc drriver api
17:39:17 <Swami> LouisF: this is basically from your block diagram, what I am asking will it be neutron's responsibility to provide that abstraction or can we leave it to the SDN controllers to handle it.
17:39:22 <Swami> What are the pros and cons.
17:40:47 <Cathy_> Swami: basically different service chain driver (OVS driver or some vendor's network controller driver) will do their own translation from the common service chain driver API to their specific SFC API. Yes the translation should be handler by the network Controller
17:41:34 <Cathy_> Swami: OK with you?
17:42:24 <Swami> Cathy_: I still have a confusion on that aspect, but I don't want to slow your progress, for now let us focus on the OVS Driver for the first release and move on. I can chat with you later to understand it in more detail.
17:42:27 <Cathy_> Swami: are you there?
17:42:55 <Cathy_> Swami: sure. let's focus on the OVS part
17:43:13 <Cathy_> now let's go through the task assignment on slide 4.
17:44:10 <Cathy_> 1. repo creation. Shall we create it in Stackforge? Is Stackforge doing away?
17:44:40 <Cathy_> I mean is Stackforge going away?
17:44:56 <Swami> armax: can you comment on the repo
17:45:19 <Cathy_> Anyone knows whether there is a new type of repo for new projects of the Big Tent?
17:45:28 <armax> hi
17:45:39 <Cathy_> What is the new rule?
17:45:40 <armax> sorry I thought the meeting was at 11am PST
17:45:41 <armax> :(
17:45:58 <armax> let me backtrack
17:46:01 <Cathy_> armax: :-) np. Great you are here
17:46:40 <armax> Cathy_: not sure what first steps were decided
17:47:10 <armax> I imagine that setting up a repo where we start iterating on is one of the first steps
17:47:37 <armax> Cathy_: we could use the same repo to hold the API document where the discussion can take place
17:48:00 <Cathy_> armax: could you clarify what you mean? We are wondering whether there is a new repo for new project targeted at Big Tent or Neutron Tent? Or shall we use Stackforge? We would like to do this right to avoid moving the repo.
17:48:40 <armax> Cathy_: did you follow up with openstack-infra? I don’t think we’re quite ready to accept projects under the openstack namespace
17:48:52 <armax> Cathy_: and renaming isn’t a big deal either
17:49:09 <Cathy_> armax: could you clarify "we could use the same repo to hold the API document where the discussion can take place"? Which repo is that? Shall we develop code in that repo?
17:49:50 <Cathy_> Sorry I have not followed up with openstack-infra. I will do that
17:49:56 <armax> Cathy_: I think we agreed that it makes sense to have this SFC initiative take place the same way other initiatives have taken place, for instance networking-l2gw
17:50:25 <armax> Cathy_: in that case, we created a repo, and we used to hold the API spec too
17:50:27 <Cathy_> #action: Cathy follow up with openstack-infra about repo space for this project
17:50:57 <armax> Cathy_: if SFC is its own initiative, there’s no need to track the spec within the neutron-specs repo
17:51:20 <armax> Cathy_: as we won’t have rights to ‘merge’ it if we have reached a consensus on what the API should look like
17:51:45 <armax> Cathy_: rather than creating two repos: one for specs and one for code
17:51:57 <Cathy_> armax: Ok, I will do contact openstack-infra and maybe contact you off line to get this sorted out and the repo created.
17:52:15 <armax> Cathy_: we could just trailblaze the new RFE process where effectively we go straight from RFE to documentation of what the API needs to look like
17:52:25 <armax> and that can happen directly in the repo where the code exists
17:52:38 <armax> Cathy_: sounds good
17:53:05 <LouisF> armax: so you are proposing we use stackforge as the repo?
17:53:07 <armax> Cathy_: my suggestion is: let’s create the repo and move over on the existing related SFC documents to be devref docs in the newly created repo
17:53:18 <armax> LouisF: yes
17:53:21 <armax> well
17:53:23 <armax> as namespace
17:53:32 <armax> the repo might be something like networking-sfc
17:53:38 <armax> or neutron-sfc
17:53:58 <armax> whichever we end up settling on in terms on naming
17:53:59 <LouisF> armax: neutron-sfc
17:54:11 <armax> LouisF: it’s not up to us to decide
17:54:27 <LouisF> armax: ok
17:54:30 <Swami> armax: who decides on the repo name
17:54:30 <armax> LouisF: in the past some folks pushed back on using neutron as prefix, but things might have changed
17:54:56 <Cathy_> armax: I needs to digest all your points:-) I will investigate and create the repo offline instead of stuck at this repo point. Now let's move on
17:55:09 <vikram> hi
17:55:21 <LouisF> vikram: hi
17:55:21 <armax> Cathy_: I can help you with that
17:55:29 <vikram> Sorry to be late
17:55:39 <Cathy_> Integration with CLI, Horizon, Heat. Who would like to lead this? Vikram, are you there?
17:55:46 <vikram> Meeting is from 18:00 UTC
17:55:50 <Cathy_> armax: thanks!
17:55:59 <armax> the sooner we move past this the quicker we can start iterating on what the API needs to look like on all the various levels and what type of use case we want to achieve by the end of Liberty
17:56:06 <vikram> I will take care
17:56:22 <armax> Cathy_: I think we need to be extremily diligent during the process becasuse the timeline is very aggessive
17:56:31 <Cathy_> armax: sure. Will do this as the first priority
17:56:32 <armax> and we can’t afford to boil the ocean
17:56:48 <armax> otherwise by the end of Liberty we’ll have nothing to show for
17:56:51 <Cathy_> armax: yes, will appreciate your help on this!
17:56:56 <armax> and who wants that? :)
17:57:15 <Cathy_> armax: 100% agree with you that we can not afford to boil the ocean
17:57:52 <Cathy_> vikram: can you take that? I am always here to help if any issue.
17:58:23 <armax> vikram: ah, so I wasn’t the only one confused about the time of the meeting!
17:58:25 <LouisF> vikram: I will help on that also
17:58:33 <vikram> Ok.. Np
17:58:53 <numan> Hi
17:59:01 <igordcard_> hi - the time is now right?
17:59:22 <vikram> Cathy_, LouisF: Thanks
18:00:08 <s3wong> 1800 utc now
18:00:09 <Cathy_> I am sorry about the time. BTW, two developer who have expressed in interest in joining the code development can not join today due to holiday in their country and conflict with another meeting.
18:00:11 * armax confused
18:00:23 <Cathy_> igordcard_: yes
18:00:43 <armax> are we at time now, or are going for another hour? If so, it may make sense rebooting this conversation
18:00:54 <igordcard_> Cathy_: I have a conflict with another meeting, but I will be glancing upon this one as well
18:01:22 <Cathy_> let's stop here and we cna resume the discussion in next IRC meeting.
18:01:35 <Cathy_> igordcard_: sure. np.
18:01:51 <Swami> sure
18:01:57 <Cathy_> I will work on the meeting time and send to everyone.
18:02:13 <Cathy_> bye everyone, see you in next IRC meeting
18:02:19 <armax> Cathy_: one suggestion is not to send private emails alongside the dev list
18:02:35 <armax> Cathy_: otherwise people subscribed to the list will receive emails twice for no good reason
18:02:36 <igordcard_> Cathy_: but is the meeting ending or starting?
18:02:37 <vikram> bye
18:02:43 <Cathy_> armax: sure. I always send to openstack-dev
18:02:47 <pcarver> I thought the service chaining meeting was at 1800. Is it 1700?
18:02:50 <Cathy_> or CC openstack-dev
18:02:51 <fitoduarte> service chain meeting?
18:03:03 <armax> Cathy_: just address openstack-dev
18:03:05 <johnsom> Yeah, also just joined for service chaining meeting
18:03:05 <Cathy_> fitoduarte: it just ends.
18:03:15 <armax> pcarver, igordcard_: ye\s
18:03:26 <armax> pcarver, igordcard_ there’s been a misunderstanding
18:03:28 <vikram> yes I also thought it's 18:00 .. It's mentioned over the meeting page
18:03:35 <xgerman> +1
18:03:38 <pcarver> Is this a recurring meeting at 1700 weekly?
18:03:50 <fitoduarte> I have it at 1800 as well.. so it changed to 1700 utc?
18:03:51 <Cathy_> johnsom: sorry about the mess-up on the meeting time. Is 1800 UTC 10am pacific time, right? Am I wrong on the meeting conversion time?
18:04:09 <fitoduarte> 1800 utc is 11:00 am pacifict time.
18:04:14 <armax> pcarver, igordcard_ the meeting was supposed to start now but it started an hour before, I suppose we’ll read the log on eavesdrop to catch up what happened, and next week we’ll get it right! 18UTC == 11am for the PST folks
18:04:15 <pcarver> UTC doesn't do daylight savings
18:04:19 <Cathy_> pcarver: it is a recurring meeting
18:04:27 <johnsom> Cathy_ 11am pacific
18:04:47 <armax> Cathy_: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=18+UTC converts the time in the local timezone
18:04:47 <Cathy_> fitoduarte: really. I checked the google and it says 10am pacific time. Let me double check this. Sorry folks!
18:04:48 <xgerman> yep, Outlook has it as a timezone — that ’s how I keep track of it
18:05:05 <pcarver> make sure you distinguish between PST and PDT
18:05:46 <fitoduarte> right now it is is 1800 utc no matter where in the world you are :)
18:05:47 <armax> we overrun, we should get out of this channel
18:05:54 <fitoduarte> lates
18:06:10 <Cathy_> pcarver: Oh, yeh, let's me check again. Sorry again. I guess we need to go now and I will modify the meeting time and send it out to everyone.
18:06:15 <armax> let’s endmeeting, please
18:06:23 <Cathy_> by now
18:06:27 <Cathy_> #endmeeting