17:31:24 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:31:25 <openstack> Meeting started Wed Jul 16 17:31:24 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:31:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:31:28 <openstack> The meeting name has been set to 'networking_advanced_services'
17:31:34 <SumitNaiksatam> #info agenda: https://wiki.openstack.org/wiki/Meetings/AdvancedServices
17:31:52 <SumitNaiksatam> #info Juno specification submission deadline: July 10th, specification approval deadline: july 20th
17:32:08 <SumitNaiksatam> i think i had earlier mentioned SAD to be july 17th
17:32:16 <SumitNaiksatam> its actually july 20th!
17:32:25 <SumitNaiksatam> so we have a little more time than we thought we had
17:33:03 <SumitNaiksatam> that said, i think we are definitely starved on the reviewer attention from neutron cores
17:33:11 <SumitNaiksatam> so its an uphill task
17:33:37 <SumitNaiksatam> so a few people are not able to make it today for different reasons and provided their updates
17:33:51 <SumitNaiksatam> #topic Flavors
17:34:07 <SumitNaiksatam> enikanorov_ cannot make it, and i believe mark is on a vacation
17:34:17 <SumitNaiksatam> #link https://review.openstack.org/102723
17:35:01 <SumitNaiksatam> there is also on an ongoing mailing list thread on this:
17:35:04 <SumitNaiksatam> #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/040336.html
17:35:15 <SumitNaiksatam> for the latest set of discussions
17:35:40 <SumitNaiksatam> per enikanorov_ he has posted a WIP patch #link https://review.openstack.org/#/c/105982
17:36:02 <SumitNaiksatam> the above is for the implementation, and makes certain assumptions on the spec
17:36:38 <SumitNaiksatam> from enikanorov_’s point of view the main pending item is the exposing of extensions list
17:36:55 <banix> hi everybody (sorry for being late)
17:37:04 <SumitNaiksatam> banix: np, welcome
17:37:33 <SumitNaiksatam> i think enikanorov_ and mark are not in agreement on the extensions list
17:38:09 <SumitNaiksatam> anything we want to discuss here in that regard?
17:38:29 <SumitNaiksatam> i know we have beaten this horse to death, so i dont know what to say :-)
17:38:35 <dougwig> we could argue a bunch, just so it really feels like a flavors update.
17:38:43 <SumitNaiksatam> on the topic of flavors that is
17:39:16 <regXboi> is there any way we can get those two to agree on something and go forward with it?
17:39:25 <SumitNaiksatam> regXboi: :-)
17:39:33 <SumitNaiksatam> thats what we have been trying
17:39:41 <regXboi> I was afraid that would be the answer
17:39:56 <SumitNaiksatam> dougwig: you had a specific point that you wanted to discuss or you were making the point, that we should move ahead
17:40:03 <cgoncalves> not much to say from my end. personally I've been not following closely the ongoing discussion. enikanorov_ and mark should first agree on the flavor proposal and then we can continue reviewing it
17:40:08 <dougwig> i was just being snarky; no point.
17:41:15 <SumitNaiksatam> all i can say is that if we have a strong preference in terms of one approach versus the other, please make it known on the review
17:41:32 <SumitNaiksatam> that might help in getting two opinions to reconcile
17:41:52 <cgoncalves> SumitNaiksatam: good point
17:42:11 <garyduan> I think in the meeting dedicated to Flavor, we kind of make an agreement, right?
17:42:11 <SumitNaiksatam> there was also the other discussion on the service type but i think there is a better chance of consensus on that
17:42:26 <SumitNaiksatam> garyduan: apparently not on exposing the extensions’s list
17:42:52 <garyduan> right. I saw discussion on the spec review
17:43:09 <SumitNaiksatam> alright, so can i request everyone to weigh on the review: #link https://review.openstack.org/102723
17:43:26 <SumitNaiksatam> in the next day or so, more specifically in the context of the extensions discussion
17:43:42 <SumitNaiksatam> perhaps looking at #link https://review.openstack.org/#/c/105982
17:43:51 <SumitNaiksatam> might help you to understand better
17:44:48 <SumitNaiksatam> per the neutron project goals, flavors has a priority among the adv services’ blueprints, so please prioritize accordingluy
17:44:57 <SumitNaiksatam> ok moving on
17:45:14 <SumitNaiksatam> since cgoncalves is here
17:45:26 <SumitNaiksatam> #topic Traffic steering
17:45:34 <SumitNaiksatam> #link https://review.openstack.org/#/c/92477
17:46:21 <cgoncalves> not much to report this week. there is no blockers
17:46:31 <SumitNaiksatam> cgoncalves: ok good
17:46:43 <banix> SumitNaiksatam: i think salvatore is essentially suggesting posponing the flavor work to next cycle.
17:46:47 <SumitNaiksatam> that said, salvatore has put a comment that he prefers that this be deferred to K
17:47:09 <cgoncalves> Salvatore -1'ed suggesting postponing it to K cycle
17:47:10 <SumitNaiksatam> banix: you mean flavors or traffic steering?
17:47:25 <banix> SumitNaiksatam: i was referring to flavors
17:47:29 <marios> o/ sorry am late, am still on another call
17:47:43 <SumitNaiksatam> banix: ah ok, i did not catch that comment
17:47:56 <cgoncalves> banix: so salvatore is suggesting deferring at least three BPs to K? mmm
17:48:16 <cgoncalves> TS, flavors and TAPaaS
17:48:29 <banix> cgoncalves: i think so
17:48:59 <SumitNaiksatam> what does the team here feel about the TS spec, are there any major disagreeents?
17:49:43 <SumitNaiksatam> cgoncalves actually has the implementation in place for a long time
17:49:50 <marios> service base &  insertion still a possibility for J3 right? Or is that also k
17:49:55 <mandeep> No technical concerns that I have heard of.
17:49:56 <cgoncalves> regarding TS work, we should not be able to implement OVS support in time. we've internally a working ODL and ODL driver implementation. not sure we could open-source it as of now
17:50:04 <banix> he is saying even if this is implemented (wrt flavors) it wont be used in code in this cycle so postpone to next cycle
17:50:06 <SumitNaiksatam> marios: thats next in the agenda
17:50:11 <marios> k thx sorry
17:50:27 <LouisF> cgoncalves: have you considered the case of using the classifiers to branch to different ports?
17:50:27 <SumitNaiksatam> marios: np
17:50:36 <cgoncalves> SumitNaiksatam: yes. this week we integrated openstack+ODL. I've been testing it today
17:51:27 <cgoncalves> LouisF: I did not forget your suggestion, although I've been trying to keep on track internally with the implementation side
17:51:52 <SumitNaiksatam> any other questions for cgoncalves?
17:51:53 <cgoncalves> LouisF: I *promise* I will not overlook your suggestion and will get back to you
17:52:04 <LouisF> cgoncalves: thx
17:52:11 <cgoncalves> LouisF: sorry for that
17:52:57 <mandeep> But the process is that if we do not approve it in this cycle, we have to go over the approval process all over again for K. That seems like a significant waste of resources.
17:53:41 <LouisF> cgoncalves: i would like to see that added to the bp
17:53:48 <SumitNaiksatam> mandeep: i believe you are referring to: #link https://wiki.openstack.org/wiki/NeutronJunoProjectPlan
17:53:49 <banix> mandeep: i think even if we approve, if code doesnt merge we need to get spec approved again. my understanding. need to verify.
17:53:50 <cgoncalves> mandeep: if most non-core reviewers keep their +1 votes, it should be fast to get +2s
17:54:05 <SumitNaiksatam> banix: i think that is correct
17:54:16 <cgoncalves> banix: yeah, my understanding as well
17:54:19 <SumitNaiksatam> cgoncalves: if only!
17:54:30 <banix> cgoncalves: is the optimist today!
17:54:44 <cgoncalves> hehe :D
17:54:46 <SumitNaiksatam> ok any other questions for cgoncalves?
17:54:52 <mandeep> cgoncalves: I am told that it is not how it has typically happened in past
17:54:58 <mandeep> cgoncalves: :-(
17:55:16 <SumitNaiksatam> #topic Service base definition and Insertion
17:55:24 <SumitNaiksatam> #link https://review.openstack.org/#/c/93128
17:55:37 <SumitNaiksatam> both kanzhe and s3wong are not able to make it today
17:56:07 <SumitNaiksatam> the latest update from s3wong was that he had posted a new patchset and there are no outstadanding comments
17:56:41 <SumitNaiksatam> s3wong also has been working on the implementation based on what Kanzhe had done before with the API and DB code
17:57:25 <SumitNaiksatam> there was an action item from last week for s3wong and marios to reachout to the VPNaaS team on the removal of the router_id attribute from the VPNaaS model (in the context of this spec)
17:57:38 <SumitNaiksatam> i think the plan for now is to not remove it
17:57:41 <SumitNaiksatam> marios: is that right?
17:57:57 <SumitNaiksatam> at least not being suggested in the spec
17:58:18 <SumitNaiksatam> and put it on the deprecation path if we make progress with this service insertion model
18:00:01 <SumitNaiksatam> any other questions on this?
18:00:24 <marios> SumitNaiksatam: right, sorry, still on a call
18:00:31 <marios> SumitNaiksatam: its not a blocker but something to think about
18:00:32 <SumitNaiksatam> marios: no worries
18:00:39 <SumitNaiksatam> marios: yes definitely
18:00:58 <SumitNaiksatam> #topic Service Chaining
18:01:08 <SumitNaiksatam> #link https://review.openstack.org/#/c/93524
18:01:11 <SumitNaiksatam> mandeep: there?
18:01:13 <mandeep> No significant updates this week.
18:01:27 <SumitNaiksatam> mandeep: ok, i felt that this was pretty well speced out
18:01:39 <SumitNaiksatam> mandeep: and the only -1 was from me for not having an example
18:01:53 <mandeep> There was a request for CLI example, and I will work with songle to add that
18:02:12 <SumitNaiksatam> songle -< songole
18:02:28 <mandeep> SumitNaiksatam: Thanks@
18:02:29 <SumitNaiksatam> i believe he needs to be added to the spec as well?
18:02:45 <SumitNaiksatam> any questions for mandeep on the service chaining spec?
18:02:49 <mandeep> Yes, the plan was to add both at the same time
18:03:08 <LouisF> mandeep: what is plan for horizon chnages?
18:03:14 <cathy_> I have a quesiton on the port, needs Mandeep to confirm
18:03:21 <SumitNaiksatam> cathy_: go ahead
18:03:35 <cathy_> So from the replies, it seems the port is the ingress port of the service chain, right?
18:03:42 <mandeep> LouisF: No plan yet on horizon
18:04:15 <mandeep> cathy_: The port identifies the traffic to which the services apply, it does not require that be the ingress/egress port
18:04:23 <mandeep> cathy_: That is left to the implementation
18:05:01 <hemanthravi> mandeep: can we view the chain itself as a service, in which case it could
18:05:05 <LouisF> mandeep: but is does represent the start of the service chain - right?
18:05:13 <hemanthravi> have attachment ports (multiple) like a service
18:05:16 <LouisF> it
18:05:39 <mandeep> hemanthravi: YEs you could, but then it would have to inherit from serviceBase and that implies service ports etc.
18:05:39 <hemanthravi> mandeep: and those could be ingress/egress
18:05:45 <cathy_> This classifier will identify the traffic, what do you mean by the port identify the traffic? every service port along the service chain needs to identify the traffic
18:05:55 <mandeep> LouisF: It can be implemented that way
18:06:29 <mandeep> cathy_: There is no service port specified, or required, in the chaining API
18:07:06 <LouisF> mandeep: or the port can be ignored and a gbp redirect action to steer traffic to the service chain
18:07:06 <mandeep> cathy_: Also, no classifier is specified in the chaining spec
18:08:01 <mandeep> LouisF: That would depend on GBP's usage of service chain, that would be covered in GBP spec (still work in progress)
18:08:09 <SumitNaiksatam> mandeep: so all traffic that hits the particular port is subject to the chain?
18:08:32 <mandeep> SumitNaiksatam: Correct. There is no other classifier or service port
18:08:55 <cathy_> I am saying that becasue you said the port is for idnetifying the traffic. I think the spec might need to explain more clearly about what that port refers to? Maybe in more concrete examples so people will not misunderstand it since "port" is used in many places and mean differently in different scenarios
18:09:21 <mandeep> cathy_: In the example, bullet #3 tries to do exactly that
18:09:23 <SumitNaiksatam> mandeep: and you could potentially use a classifier and steering to direct traffic to that port (but thats independent of this spec)?
18:09:59 <mandeep> SumitNaiksatam: That is probably better handeled in the service spec (for example by TS)
18:10:13 <mandeep> SumitNaiksatam: And it does not help to recreate that functionality in chaining spec
18:10:28 <SumitNaiksatam> mandeep: okay, yeah that is how i understood this
18:10:39 <SumitNaiksatam> cathy_: does that answer your question?
18:11:00 <mandeep> cathy_: When we add CLI, perhaps that will be clearer?
18:11:13 <mandeep> cathy_: When we add CLI for the example, perhaps that will be clearer?
18:11:37 <cathy_> not really. There are so many ports involves in a service chain (I am not talking about the API), it is still not clear which port this "port" in the API refers to?
18:11:49 <cathy_> OK, let's see the CLI
18:11:52 <cathy_> Thanks
18:11:53 <SumitNaiksatam> cathy_: if i understand what mandeep is saying, the use of classifier and steering is complementary to this service chaining spec
18:12:06 <mandeep> cathy_: The spec has only one type of port - neutron port. There is NO other port in the spec.
18:12:24 <mandeep> cathy_: Where did you see reference to any other port in the BP?
18:12:27 <cathy_> But there are multiple neutron ports involved in a service chain, right?
18:12:44 <cathy_> Each service funciton could have a attachment neutron port, right?
18:13:02 <mandeep> cathy_: No. Not in this spec. That is an impelentation choice (and one may choose not to implement any service ports)
18:13:29 <LouisF> mandeep: you mean item 2 on line 148
18:13:36 <cathy_> I am not talking about the port in BP. I am talking about in general, a service chain consists of a sequence of service function instances and each instance has a port.
18:13:38 <hemanthravi> odl gbp chaining (https://meetings.opendaylight.org/opendaylight-group-policy/2014/gbp_usecase/opendaylight-group-policy-gbp_usecase.2014-07-14-20.03.html) refers to a in/out terminal for a chain
18:13:49 <mandeep> cathy_: Do not confuse a specific provider's choice with the API intent
18:14:19 <mandeep> hemanthravi: This is not refering to ODL chain, that is a different project
18:14:46 <hemanthravi> mandeep: thought the disc could be useful for the model
18:14:53 <mandeep> LouisF: Let me check the line numbers
18:15:13 <mandeep> hemanthravi: ODL chain is closer to TS implementation of this spec
18:15:32 <cgoncalves> the ODL SFC is a whole new beast :-)
18:15:37 <SumitNaiksatam> mandeep: yeah i believe cgoncalves has mapped that to ODL
18:15:53 <cathy_> mandeep: looks like people have confusion about the "port" in SC BP. I think more examples could help to make it clear, such as in the scenario that a chain is composed of multiple service instances, then which port does thi "SC BP port" refers to?
18:15:58 <hemanthravi> mandeep: got it
18:15:59 <mandeep> hemanthravi: This is a declarative spec (what I want), not a imperative spec (how to do it) - like TS or ODL are
18:16:21 <cgoncalves> SumitNaiksatam: yes. we've extended ODL and added Neutron TS API as well as its implementation
18:16:23 <SumitNaiksatam> i believe the cloud abstraction is different from a network controller abstraction
18:16:44 <SumitNaiksatam> which i believe is being reflected in mandeep’s spec (say as compared to the ODL spec)
18:17:04 <mandeep> As in the example, the port refers to a an existing neutron port. No new types of ports are specified
18:17:37 <mandeep> cathy_: (that was the example that I refered to in bullet #3 above)
18:17:47 <SumitNaiksatam> okay, cathy perhaps you can put the comment on the spec, i believe mandeep is already planning a new rev to address that (i had a similar comment on the spec)
18:18:00 <cathy_> SumitNaiksatam: OK, sure, will do
18:18:06 <SumitNaiksatam> cathy_: thanks
18:18:20 <SumitNaiksatam> moving on
18:18:35 <cgoncalves> mandeep: I've not had time to review your latest SC bp patchset, but 'port' is an existing neutron port associated to a e.g. neutron service or a SC entry point for traffic?
18:18:35 <SumitNaiksatam> #topic Tap as a Service spec
18:18:42 <SumitNaiksatam> #undo
18:18:43 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x2648790>
18:19:01 <mandeep> cgoncalves: Yes, that is exactly right.
18:19:19 <vinay_yadhav> We found some opposition form Salvatore Orlando
18:19:21 <cgoncalves> mandeep: which one of the two options? :-)
18:19:31 <SumitNaiksatam> vinay_yadhav: one sec
18:19:36 <vinay_yadhav> sorry
18:19:39 <SumitNaiksatam> vinay_yadhav: lets wrap this one
18:19:41 <mandeep> cgoncalves: And that was what I was trying to explain to cathy_, the port refers to an existing neutron port (as in the example) and not a service port
18:19:44 <SumitNaiksatam> vinay_yadhav: no worries
18:20:30 <SumitNaiksatam> cathy_: sound okay?
18:20:33 <cgoncalves> mandeep: ok. I will definitly need to to review it to get a better looking of it. thanks
18:20:47 <cgoncalves> SumitNaiksatam, vinay_yadhav: sorry for that. please continue
18:20:50 <SumitNaiksatam> oh it was cgoncalves who had the question
18:20:54 <SumitNaiksatam> ok moving on
18:20:55 <SumitNaiksatam> #topic Tap as a Service spec
18:21:08 <SumitNaiksatam> #link https://review.openstack.org/#/c/96149
18:21:16 <SumitNaiksatam> vinay_yadhav: sorry, go ahead
18:21:35 <vinay_yadhav> Armando and Salvatore had some objections to the spec
18:21:39 <cathy_> SumitNaiksatam: I have the same question as cgoncalves , looks like the "port" in SC is the entry point for traffic?
18:22:01 <cathy_> anyway I will post the comment again
18:22:06 <SumitNaiksatam> cathy_: thanks :-)
18:22:06 <vinay_yadhav> they basically do not want 'tap' aas but as a port mirror extension
18:22:39 <vinay_yadhav> but i guess we have discussed this in the last summit and decided to have it as a service
18:22:42 <SumitNaiksatam> vinay_yadhav: i dont have any strong feelings on that
18:23:04 <SumitNaiksatam> is anil_rao here?
18:23:20 <vinay_yadhav> i guess so
18:23:28 <anil_rao> Tap-aaS is more generic in my opinion because other possible implementations can be done in the future
18:23:53 <anil_rao> for the first version we are planning to rely on port-mirorring but this doesn't have to be the case for other situations.
18:24:47 <SumitNaiksatam> anil_rao: yes, i believe port mirroring in this case is one/first feature
18:24:57 <SumitNaiksatam> anil_rao: if i understand your comment correctly
18:25:03 <mandeep> IMO, When you start extending TaaS with de-dup or time-stamps, it really becomes more of a service and less of a port "feature"
18:25:17 <anil_rao> that is correct.
18:25:17 <cgoncalves> vinay_yadhav: in cloud, everything is (or should be) *aaS so I see not much reason in suffixing it with "as a service". 'port mirroring' though potentially be more self-explanatory
18:25:23 <vinay_yadhav> correct
18:25:59 <SumitNaiksatam> i dont see what the big issue is with the name though
18:26:05 <cgoncalves> vinay_yadhav: having said that, expect no -1 vote just because of that
18:26:19 <SumitNaiksatam> the point is whether this is being offere as a service abstraction or not
18:26:39 <mandeep> cgoncalves: IMO *aaS is cosmetic matter, I guess we could have called FWaaS as FW and VPNaaS as VPN ...
18:26:40 <SumitNaiksatam> you can call it tap as a service or just a tap
18:26:53 <SumitNaiksatam> mandeep: ah, just the point i was trying to make
18:26:53 <vinay_yadhav> mandeep: agreed
18:27:12 <cgoncalves> mandeep: in the end, it's all about fancy names
18:27:31 <mandeep> cgoncalves: The real question is, is it a "service" with a distinct resource API or "feature" that extends an existing resource
18:27:41 <vinay_yadhav> also i want to know the opinion of other reviewers on whether we should have it as service or a extension API
18:28:01 <SumitNaiksatam> mandeep: exactly, and i believe what is being proposed is a service, right?
18:28:14 <mandeep> vinay_yadhav: Is that "new resource" vs. "extending existing resources" question?
18:28:22 <SumitNaiksatam> that was not meant for mandeep specifically, that was a question for vinay_yadhav and anil_rao
18:28:34 <vinay_yadhav> yes
18:28:51 <vinay_yadhav> we are proposing Tap as a resource
18:28:58 <SumitNaiksatam> changing the name does not change the fact that this is a service interface, if that is the approach we want to take
18:29:07 <vinay_yadhav> yes
18:29:08 <anil_rao> The service abstraction allows more room for growth, so I will recommend that we stay with it.
18:29:22 <SumitNaiksatam> anil_rao: i tend to agree
18:29:27 <vinay_yadhav> anil: agreed, that was the idea
18:29:43 <SumitNaiksatam> anil_rao vinay_yadhav: can you please provide a response on the review to that effect
18:29:49 <anil_rao> Sure will do
18:29:52 <SumitNaiksatam> and we can hopefully move on from there
18:29:56 <vinay_yadhav> yes we will
18:30:00 <SumitNaiksatam> vinay_yadhav anil_rao: thanks
18:30:07 <SumitNaiksatam> ok we have hit our time
18:30:15 <SumitNaiksatam> #topic open discussion
18:30:19 <mandeep> anil_rao: Specifically handling something like (distributed) de-dup is probably not representable as an extension to existing resources
18:30:28 <SumitNaiksatam> if there is nothing else, we can wrap up here
18:30:37 <SumitNaiksatam> mandeep: agree
18:30:40 <anil_rao> mandeep: exactly.
18:30:51 <SumitNaiksatam> ok lets wrap it up
18:30:59 <SumitNaiksatam> thanks for all your reviews and work on the patches
18:31:09 <banix> thanks
18:31:16 <SumitNaiksatam> lets keep up the momentum and hopefully we can get the specs approved in time
18:31:24 <SumitNaiksatam> thanks all, bye!
18:31:29 <cgoncalves> cya!
18:31:34 <anil_rao> Bye!
18:31:35 <mandeep> bye
18:31:39 <SumitNaiksatam> #endmeeting