16:59:58 #startmeeting service chaining 16:59:59 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:03 The meeting name has been set to 'service_chaining' 17:00:21 Cathy_:hi 17:00:32 Swami: hi 17:00:41 hi louis 17:00:46 Swami: hi 17:00:56 LouisF: hi 17:00:57 let's wait for a few minutes for more people to join 17:01:13 hi Vikram 17:04:42 I think we can start 17:05:05 Cathy_: hello 17:05:16 yes please, we can start 17:05:35 I am thinking about discussing the use case and the components for supporting the service chain. 17:05:43 nbouthors: hi 17:05:58 is that OK with everyone. Any other suggestion? 17:06:11 Cathy_: fine 17:06:22 #Agenda Use Case discussion 17:06:49 here is a link to the use case and the components for supporting service chaining in Neutron 17:06:55 Swami: #topic would be more appropriate :-) 17:07:18 s3wong: yes makes sense 17:08:14 Swami: would you like to post the link to the slides we prepared for the discussion? 17:08:37 sure 17:08:54 #topic use case and components discussion 17:09:13 #link https://docs.google.com/presentation/d/1SpVyLBCMRFBpMh7BsHmpENbSY6qh1s5NRsAS68ykd_0/edit?usp=sharing 17:10:28 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 By Neutron service chain API, I mean the port chain API which was presented at the OpenStack Summit 17:12:05 This basic api is needed to support chaining of vnfs 17:12:37 Is this an abstract description of the chain ? 17:12:37 let's go through slide by slide. 17:13:02 the port chain is not the Intent abstraction level API 17:13:25 It is a specification of the logical chain API 17:13:55 the abstraction level matches existing Neutron abstraction level 17:14:00 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 nbouthors: it is a specification of the chain in terms of neutron port-pairs 17:14:32 LouisF: yes 17:14:40 nbouthors: each port-pair represents a VNF 17:14:45 Swami: yes 17:15:16 LouisF: A VNF instance 17:15:26 nbouthors: correct 17:15:34 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 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 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 nbouthors: what resources do you mean? 17:17:35 nbouthors: yes in terms of the service function resource and location 17:18:12 LouisF: for example which VNF instance exists, what are the locators which can be used to send traffic to them. 17:18:26 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 nbouthors: correct, it is expected that the VNF instance resources will already be set up 17:19:36 Cathy_: OK, what about SFFs addresses ? 17:20:00 Any question on the use case? and architecture diagram in slide 2? 17:20:21 nbouthors: the steering to SFFs will be handled by the drivers 17:20:28 Cathy_: yes 17:21:29 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 LouisF: OK, so we suppose that from a VM info the driver can find the associated responsible SFF. It could work. 17:21:59 nbouthors: that is the idea 17:22:34 Cathy_: I am checking that it fits the ODL SFC data model. 17:23:28 nbouthors: OK. thanks. 17:24:46 Cathy_: I am ok with slides 2 and 3 17:25:30 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 nbouthors: good 17:26:24 let's go back to slide 4 17:26:33 go to slide 4 17:27:41 slide 4 lists the breakdown of the work we need to deliver for supporting the port chain functionality. 17:27:47 in slide 3 should there be a SDNC driver like the OVS driver? 17:28:19 LouisF: yes, there should be one inside the neutron server 17:28:55 LouisF: Can you elaborate on the SDNC driver 17:29:11 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 Hi Alan 17:30:24 Swami: there would be a common sfc driver api with various different datapath driver below it, eg OVS driver, SDNC driver 17:30:24 Cathy_: Are you talking about the "Network Controller Service Chain Driver" that you mentioned in your slide deck in the summit. 17:30:42 yes 17:30:46 Swami: yes 17:31:19 Swami: are you OK with that? 17:31:32 yes 17:32:13 #action update the diagram to reflect the Network Controller driver 17:32:58 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 any addition or modification? 17:34:06 This should be good to start with. We can add or remove as we go. 17:34:16 that looks like a complete list 17:34:22 sounds good. 17:34:41 #topic tasks assignment 17:34:44 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 Now let's see who would like to lead the development/design of which part? 17:35:13 nbouthors: yes that would be the way to go 17:35:49 LouisF: ok 17:36:07 Anyone like to lead the CLI/ Horizon/Heat part work? 17:36:13 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 back up a little bit. 17:36:35 let's start from the beginning 17:37:08 Swami: it would be translate the port chain abstraction into a form used by the SDNC 17:37:32 But should that logic reside in neutron. 17:38:08 It can be the responsibility of the North bound interface in the SDN controller where neutron feeds in. 17:38:09 Swami: correct but is a specific sdnc driver which would sit below the common sfc drriver api 17:39:17 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 What are the pros and cons. 17:40:47 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 Swami: OK with you? 17:42:24 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 Swami: are you there? 17:42:55 Swami: sure. let's focus on the OVS part 17:43:13 now let's go through the task assignment on slide 4. 17:44:10 1. repo creation. Shall we create it in Stackforge? Is Stackforge doing away? 17:44:40 I mean is Stackforge going away? 17:44:56 armax: can you comment on the repo 17:45:19 Anyone knows whether there is a new type of repo for new projects of the Big Tent? 17:45:28 hi 17:45:39 What is the new rule? 17:45:40 sorry I thought the meeting was at 11am PST 17:45:41 :( 17:45:58 let me backtrack 17:46:01 armax: :-) np. Great you are here 17:46:40 Cathy_: not sure what first steps were decided 17:47:10 I imagine that setting up a repo where we start iterating on is one of the first steps 17:47:37 Cathy_: we could use the same repo to hold the API document where the discussion can take place 17:48:00 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 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 Cathy_: and renaming isn’t a big deal either 17:49:09 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 Sorry I have not followed up with openstack-infra. I will do that 17:49:56 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 Cathy_: in that case, we created a repo, and we used to hold the API spec too 17:50:27 #action: Cathy follow up with openstack-infra about repo space for this project 17:50:57 Cathy_: if SFC is its own initiative, there’s no need to track the spec within the neutron-specs repo 17:51:20 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 Cathy_: rather than creating two repos: one for specs and one for code 17:51:57 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 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 and that can happen directly in the repo where the code exists 17:52:38 Cathy_: sounds good 17:53:05 armax: so you are proposing we use stackforge as the repo? 17:53:07 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 LouisF: yes 17:53:21 well 17:53:23 as namespace 17:53:32 the repo might be something like networking-sfc 17:53:38 or neutron-sfc 17:53:58 whichever we end up settling on in terms on naming 17:53:59 armax: neutron-sfc 17:54:11 LouisF: it’s not up to us to decide 17:54:27 armax: ok 17:54:30 armax: who decides on the repo name 17:54:30 LouisF: in the past some folks pushed back on using neutron as prefix, but things might have changed 17:54:56 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 hi 17:55:21 vikram: hi 17:55:21 Cathy_: I can help you with that 17:55:29 Sorry to be late 17:55:39 Integration with CLI, Horizon, Heat. Who would like to lead this? Vikram, are you there? 17:55:46 Meeting is from 18:00 UTC 17:55:50 armax: thanks! 17:55:59 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 I will take care 17:56:22 Cathy_: I think we need to be extremily diligent during the process becasuse the timeline is very aggessive 17:56:31 armax: sure. Will do this as the first priority 17:56:32 and we can’t afford to boil the ocean 17:56:48 otherwise by the end of Liberty we’ll have nothing to show for 17:56:51 armax: yes, will appreciate your help on this! 17:56:56 and who wants that? :) 17:57:15 armax: 100% agree with you that we can not afford to boil the ocean 17:57:52 vikram: can you take that? I am always here to help if any issue. 17:58:23 vikram: ah, so I wasn’t the only one confused about the time of the meeting! 17:58:25 vikram: I will help on that also 17:58:33 Ok.. Np 17:58:53 Hi 17:59:01 hi - the time is now right? 17:59:22 Cathy_, LouisF: Thanks 18:00:08 1800 utc now 18:00:09 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 igordcard_: yes 18:00:43 are we at time now, or are going for another hour? If so, it may make sense rebooting this conversation 18:00:54 Cathy_: I have a conflict with another meeting, but I will be glancing upon this one as well 18:01:22 let's stop here and we cna resume the discussion in next IRC meeting. 18:01:35 igordcard_: sure. np. 18:01:51 sure 18:01:57 I will work on the meeting time and send to everyone. 18:02:13 bye everyone, see you in next IRC meeting 18:02:19 Cathy_: one suggestion is not to send private emails alongside the dev list 18:02:35 Cathy_: otherwise people subscribed to the list will receive emails twice for no good reason 18:02:36 Cathy_: but is the meeting ending or starting? 18:02:37 bye 18:02:43 armax: sure. I always send to openstack-dev 18:02:47 I thought the service chaining meeting was at 1800. Is it 1700? 18:02:50 or CC openstack-dev 18:02:51 service chain meeting? 18:03:03 Cathy_: just address openstack-dev 18:03:05 Yeah, also just joined for service chaining meeting 18:03:05 fitoduarte: it just ends. 18:03:15 pcarver, igordcard_: ye\s 18:03:26 pcarver, igordcard_ there’s been a misunderstanding 18:03:28 yes I also thought it's 18:00 .. It's mentioned over the meeting page 18:03:35 +1 18:03:38 Is this a recurring meeting at 1700 weekly? 18:03:50 I have it at 1800 as well.. so it changed to 1700 utc? 18:03:51 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 1800 utc is 11:00 am pacifict time. 18:04:14 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 UTC doesn't do daylight savings 18:04:19 pcarver: it is a recurring meeting 18:04:27 Cathy_ 11am pacific 18:04:47 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 fitoduarte: really. I checked the google and it says 10am pacific time. Let me double check this. Sorry folks! 18:04:48 yep, Outlook has it as a timezone — that ’s how I keep track of it 18:05:05 make sure you distinguish between PST and PDT 18:05:46 right now it is is 1800 utc no matter where in the world you are :) 18:05:47 we overrun, we should get out of this channel 18:05:54 lates 18:06:10 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 let’s endmeeting, please 18:06:23 by now 18:06:27 #endmeeting