17:31:25 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:31:26 <openstack> Meeting started Wed Jul  2 17:31:25 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 <anil_rao> Hi
17:31:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:31:30 <openstack> The meeting name has been set to 'networking_advanced_services'
17:31:35 <SumitNaiksatam> #info agenda: https://wiki.openstack.org/wiki/Meetings/AdvancedServices
17:31:37 <dougwig> o/
17:31:52 <vinay_yadhav> can we start with TaaS today
17:32:00 <SridarK> Hi
17:32:08 <SumitNaiksatam> #info announcement: Juno specification submission deadline: July 10th, specification approval deadline: july 17th
17:32:09 <marios> tapas for starter?
17:32:27 <cgoncalves> marios: yeah, I'm starving :)
17:32:34 <s3wong> Yes, let's do tapas as a starter :-)
17:32:34 <vinay_yadhav> :)
17:32:35 <banix> just a couple of minutes on flavor to get going ;)
17:32:41 <banix> just kidding
17:32:59 <SumitNaiksatam> we switch the agenda order today per last week’s request
17:33:17 <marios> cgoncalves: me too mate just got home :)
17:33:34 <SumitNaiksatam> so we have a week to submit any new blueprint specs (i think we are good here)
17:33:58 <SumitNaiksatam> and we have a couple of weeks to converge on teh specs we have in review, and have them approved
17:34:11 <SumitNaiksatam> the later is of course subject to reviewer feedback
17:34:25 <enikanorov__> here
17:34:31 <SumitNaiksatam> wanted to make sure that everyone is aware of the time timelines
17:34:43 <s3wong> SumitNaiksatam: sure
17:34:47 <SumitNaiksatam> enikanorov__: hi, switiching the agenda order a bit today to be fair to everyone
17:34:57 <enikanorov__> SumitNaiksatam: sure!
17:35:04 <vinay_yadhav> thanx
17:35:05 <SumitNaiksatam> ok drumroll…
17:35:09 <s3wong> enikanorov__: can't just have your flavor all the time :-)
17:35:20 <SumitNaiksatam> #topic TaapAAS
17:35:28 <SumitNaiksatam> https://review.openstack.org/#/c/96149
17:35:31 <SumitNaiksatam> #link https://review.openstack.org/#/c/96149
17:35:48 <SumitNaiksatam> vinay_yadhav: you have the stage!
17:36:06 <vinay_yadhav> the last patch(Patch 5) got good reviews
17:36:17 <marios> vinay_yadhav: apologies didnt get chance to review latest
17:36:26 <SumitNaiksatam> vinay_yadhav: ok, my apologies i hae not been as active either
17:36:39 <vinay_yadhav> i have address some editorial comment and added afew clarification in the new patch
17:36:41 <SumitNaiksatam> i believe anil_rao has also been responding to the reviews
17:36:48 <anil_rao> Yes
17:36:51 <vinay_yadhav> yes
17:37:10 <SumitNaiksatam> one high level question - why do we have the “Tap_service” table?
17:37:30 <vinay_yadhav> that is the data model that represents the service
17:37:50 <vinay_yadhav> to which u can add flows (ports) that u want to mirror
17:38:04 <SumitNaiksatam> vinay_yadhav: can this not be collapsed into the “tap_flow"
17:38:12 <vinay_yadhav> the Tap_Service will set up the destination of the mirror
17:38:12 <SumitNaiksatam> we could call it something else
17:38:22 <marios> vinay_yadhav: there havent been any major objections so far right?
17:38:23 <SumitNaiksatam> maybe just a tap
17:38:33 <vinay_yadhav> yes no major objections
17:38:56 <vinay_yadhav> sumit: ok, but collapsing is not good
17:39:04 <SumitNaiksatam> i would prefer to avoid proliferation of resources where we can
17:39:11 <SumitNaiksatam> vinay_yadhav: why?
17:39:32 <SumitNaiksatam> vinay_yadhav: unless there is no 1:1 association between tap_flow and tap_service
17:39:32 <vinay_yadhav> because the Tap_Service sets up the destination port for mirrored data
17:39:59 <SumitNaiksatam> vinay_yadhav: yeah, but its a 1:1 association with a tap_flow, right?
17:40:00 <vinay_yadhav> can there is a n:1 association between flow and service
17:40:22 <vinay_yadhav> multiple flows can be associated to a single service
17:40:22 <SumitNaiksatam> vinay_yadhav: ah ok
17:40:32 <vinay_yadhav> flow: ports u want to mirror
17:40:49 <vinay_yadhav> service: destination port to sent the mirroed data where a servicer VM can collect it
17:41:02 <vinay_yadhav> hence its N:1
17:41:06 <marios> vinay_yadhav: like monitoring more than one source port u mean?
17:41:11 <s3wong> host of event asks us to take a group photo. brb
17:41:14 <marios> to one service
17:41:17 <vinay_yadhav> marios: yes
17:41:41 <SumitNaiksatam> vinay_yadhav: ok, wasnt clear to be from the table
17:42:13 <vinay_yadhav> u can check the work flow text.... but i will see if i can calrify it better
17:42:15 <marios> SumitNaiksatam: is there a process whereby we can say 'ok we have worked this spec tbrough a few iterations can we now have some core attention'?
17:42:35 <vinay_yadhav> marios: yes that would be good
17:42:40 <anil_rao> Also, separating the tap-service from the tap-flow means that we can add/remove flows from the service
17:42:46 <SumitNaiksatam> marios: no forma process, but thats why i wanted that as a team we support our specs by putting a +1
17:42:51 <SumitNaiksatam> *formal
17:42:52 <vinay_yadhav> anil:true
17:42:58 <marios> SumitNaiksatam: 17th july isnt that far off especially if there will be any unexpected issues
17:43:25 <vinay_yadhav> on the 5th patch set we had a 8-9 +1s
17:44:29 <vinay_yadhav> so if every one can review it once more and +1 it, that wold be greate
17:44:37 <SumitNaiksatam> vinay_yadhav: currently one +1, so hopefully we can get those +1s back
17:44:48 <vinay_yadhav> sumit: yeah
17:45:04 <SumitNaiksatam> vinay_yadhav anil_rao: any blockers on this (apart from reviewer attention)?
17:45:05 <vinay_yadhav> i hope people go over it again and +1 it again
17:45:14 <marios> vinay_yadhav: will do hopefully tomorrow
17:45:17 <vinay_yadhav> not at this point
17:45:24 <vinay_yadhav> marios: thanx
17:45:28 <banix> vinay_yadhav: will do
17:45:31 <anil_rao> No blockers at the moment, Sumit
17:45:31 <SumitNaiksatam> vinay_yadhav: ok thanks
17:45:33 <vinay_yadhav> thanx
17:45:50 <banix> (By the way, Ryan apologizes for not being able to participate today)
17:46:04 <SumitNaiksatam> #topic Traffic steering
17:46:18 <SumitNaiksatam> #link https://review.openstack.org/#/c/92477
17:46:22 <SumitNaiksatam> cgoncalves: hi
17:46:32 <cgoncalves> SumitNaiksatam: hello
17:46:53 <SumitNaiksatam> cgoncalves: thanks to you (and joao) for the follow up  on this
17:46:54 <cgoncalves> SumitNaiksatam: do you want first to summarize yesterday's F2F meeting?
17:47:31 <banix> whose face 2 whose face?
17:47:36 <SumitNaiksatam> cgoncalves: sure, this was mostly to get Cathy and LouisF upto speed with what we are doing in the adv services’s team, and where the different blueprint specs
17:47:46 <SumitNaiksatam> banix: ^^^
17:47:46 <banix> got it
17:47:54 <cgoncalves> SumitNaiksatam: sure, no problem. not sure you all got my view I stressed on -dev last week
17:48:28 <cgoncalves> banix: oops, it was a secret f2f. you wasn't supposed to know it :)
17:48:34 <SumitNaiksatam> cathy_ and LouisF: had questions on the use of classifiers in teh group policy spec versus in the TS spec
17:48:34 <cgoncalves> SumitNaiksatam: ok
17:49:02 <SumitNaiksatam> but nothing that we have not discussed in this IRC before
17:49:14 <banix> cgoncalves: I was there. I work for NSA ;)
17:49:39 <SumitNaiksatam> banix: and i thought i could you out by not inviting you :-P
17:49:51 <cgoncalves> :)
17:50:10 <LouisF> cgoncalves: can you state the concerns you raised in your email
17:50:36 <SumitNaiksatam> cgoncalves: go ahead ^^^
17:50:37 <LouisF> cgoncalves: regarding steerings
17:50:38 <banix> just wanted to know if i missed a call i was supposed to be on. thanks for not including me when not necessary.
17:50:48 <cgoncalves> SumitNaiksatam: ok, my idea was that the f2f was to also get to some aggreement on the TS and SC blueprints and you would eventually give us some feedback
17:50:49 <s3wong> back
17:51:22 <SumitNaiksatam> cgoncalves: mandeep has a new planned on the chaining spec, which will hopefully help
17:51:28 <SumitNaiksatam> *new rev
17:51:35 <cathy_> cgoncalves: The conclusion is that  the GBP group classifier applies at the ingress point of the chain. The TS classifier can be applied for reclassification use. If there are inconsistency between the two classifiers, the TS classifier takes precedence
17:51:56 <SumitNaiksatam> cathy_: thanks
17:52:22 <cgoncalves> LouisF: in short, TS may not be the best way to use as backend of SC, although it can be used but putting some constraints
17:52:29 <mandeep> SumitNaiksatam: cgoncalves: Yes I will clarify in the spec as cathy_ explained.
17:52:55 <LouisF> mandeep: when can we get the updated bp?
17:53:10 <mandeep> cgoncalves: Yes, I am working on it today
17:53:11 <SumitNaiksatam> in general we dont expect the reference implementation of Group Policy to directly use the Traffic Steering classifier
17:53:13 <banix> will wait for the spec as what cathy_ said just doesn’t make sense to me
17:53:14 <cgoncalves> LouisF: and AFAIK there is no way defined yet as to how traffic should be steered to a SC
17:53:27 <cgoncalves> (sorry, intermitent connection)
17:53:43 <cgoncalves> mandeep: nice, thanks
17:53:47 <LouisF> cgoncalves: agree i thinkthe ts bp needs work
17:54:24 <mandeep> banix: Essentially what service or TS does in opaque to the GBP - it just forwards the packets to the appropriate port
17:54:26 <cgoncalves> cathy_: ok, thanks.
17:55:07 <cgoncalves> I've been this week internally getting some code working (based on the ones submitted to review.o.o) and interacting with ODL
17:55:08 <cathy_> cgoncalves: Actually I read the existing service chaining blueprint again after the f-f meeting. It seems that the only difference bwtween the service chain BP API and the TS API is that the TS include Classifier specification. Is that correct?
17:55:26 <banix> mandeep: yes that was my understanding. i thought the staement above was contradicting that but dont want to distract. will look at the specs.
17:55:39 <mandeep> banix: ok
17:55:50 <cgoncalves> that's for PoC internally and I believe could all code be open-sourced (on the ODL side too)
17:55:54 <SumitNaiksatam> cathy_: as we discussed that is not the only difference, the difference is at the level of abstraction
17:56:18 <SumitNaiksatam> cathy_: service chain bp deals with chain service instances
17:56:18 <cgoncalves> cathy_: I believe so, yes.
17:56:32 <cgoncalves> SumitNaiksatam: sure
17:56:34 <SumitNaiksatam> cathy_: whereas, TS bp deals with chaining ports
17:56:47 <cathy_> From the API point of view, it seems that is the diff. Maybe internal design has difference.
17:57:20 <SumitNaiksatam> cgoncalves: at this point we have -1 from cathy_ and akihiro
17:57:28 <SumitNaiksatam> cathy_: are your concerns addressed?
17:57:30 <cgoncalves> while SC could potentially spin new neutron services and create a chain, the TS doesn't
17:58:10 <SumitNaiksatam> cgoncalves: i think SC operation will be clarified in mandeep’s new rev of the spec
17:58:25 <cathy_> cgoncalves: Does the SC API covers the spin of new neutron services ? I did not see this in the API
17:58:28 <SumitNaiksatam> cgoncalves: but should be independent of the TS bp, so we can make progress in paralled
17:58:34 <cathy_> Maybe I missed that part.
17:58:34 <SumitNaiksatam> *parallel
17:58:37 <cgoncalves> all: I know I've some comments from you to catch up. sorry about that. I've been reviewing them but not commenting on review.o.o due to some time constraints on my end. truly apologies
17:58:44 <marios> sorry for the silly question, but for clarity... SC = service chaining and TS is traffic steering right?
17:58:57 <SumitNaiksatam> marios: yes
17:58:59 <mandeep> marios: Correct
17:59:08 <cathy_> SumitNaiksatam: My concern about classifers are addressed. Thanks for asking
17:59:16 <cgoncalves> cathy_: I'm not sure. just said it could *eventually*. we will have to wayt for mandeep to upload a new rev
17:59:24 <SumitNaiksatam> cgoncalves: no need to apologize, you have been very prompt and sincere on this, big thanks for leading this initiative!
17:59:29 <cathy_> marios: yes
17:59:37 <cgoncalves> SumitNaiksatam: of course, we can work independently
18:00:04 <mandeep> cgoncalves: I will do so today. I got occupied by the 'day job' for a couple of weeks, catching up now ;-)
18:00:05 <cathy_> cgoncalves: OK, I will review the new version.
18:00:15 <SumitNaiksatam> cgoncalves: we might need to indepedently reach out to akihiro to see if his concerns are addressed
18:00:19 <cgoncalves> cathy_: thanks
18:00:24 <LouisF> mandeep: great
18:00:30 <SumitNaiksatam> mandeep: thanks, we fully understand :-)
18:00:40 <mandeep> SumitNaiksatam: ;-)
18:00:57 <cgoncalves> SumitNaiksatam: yeah, as he is a core reviewer \o/ :)
18:01:07 <SumitNaiksatam> any other questions or suggestions for cgoncalves?
18:01:11 <SumitNaiksatam> cgoncalves: ;-P
18:01:27 <cgoncalves> bring them on! (but be gentle though)
18:01:28 <LouisF> cgoncalves: when will you update the bp?
18:01:35 <cathy_> cgoncalves: very good work and good points in your email.
18:01:55 <SumitNaiksatam> cathy_: +1
18:02:08 <cgoncalves> LouisF: lets say this week
18:02:20 <SumitNaiksatam> cgoncalves: great thanks!
18:02:37 <SumitNaiksatam> #topic Service base definition and Insertion
18:02:45 <SumitNaiksatam> s3wong: ?
18:02:53 <s3wong> yes
18:02:55 <SumitNaiksatam> i believe kanzhe is not back yet
18:03:03 <SumitNaiksatam> #link https://review.openstack.org/#/c/93128
18:03:13 <SumitNaiksatam> s3wong: you posted a new rev, thanks
18:03:21 <SumitNaiksatam> not sure how many got a chance to review
18:03:23 <s3wong> Some of us had a f2f meeting on Monday - and the team-members suggested a set of feedback for update
18:03:37 <SumitNaiksatam> i had put some comments on monday
18:03:42 <s3wong> so the spec has been updated to reflect those points
18:03:42 <SumitNaiksatam> to narrow the scope of this
18:04:32 <s3wong> we also drop flavor framework as a dependency (because it really isn't)
18:04:35 <SumitNaiksatam> s3wong: i will read through again (see some white spaces in red though ;-) )
18:04:56 <marios> SumitNaiksatam: i only saw your comments in passing today,but, will it still make sense without e.g. register/unregister service?
18:05:04 * marios will look more closely tomorrow
18:05:08 <SumitNaiksatam> i believe people will need some time to read through the new rev
18:05:15 <s3wong> SumitNaiksatam: yes, I noticed that after I uploaded. And since I will do another patch update due to not addressing some comments at revision 13, I will fix them on the next patch :-)
18:05:39 <SumitNaiksatam> marios: per discusison with kanzhe and s3wong the register/unregister is something we can add as an enhancement in a later rev
18:06:02 <s3wong> marios: yes, the register/unregister were intended to support services that aren't aware by Neutron (non Neutron network services)
18:06:02 <SumitNaiksatam> marios: since it was targeted more specifically at services not recognized by neutron
18:06:15 <s3wong> but still can do service insertion with the proposed framework
18:06:26 <SumitNaiksatam> marios: i fully agree with the goal here, however, we need to focus on what we want to achieve as a first iteration
18:06:34 <s3wong> but SumitNaiksatam suggested that we should simplify and NOT address this use case in phase 1
18:06:41 <s3wong> and we all agreed
18:06:50 <marios> SumitNaiksatam: i see... yes i recall now that the point was '(neutron) services are already assumed available... e.g. via flavor framework'
18:06:52 <SumitNaiksatam> marios: and make this very easy for the core reviewers to review and approve in the short time we have left
18:07:15 <SumitNaiksatam> marios: yes what s3wong said her
18:07:36 <marios> SumitNaiksatam: ok thanks i will try and look more closely tomorrow.
18:08:28 <SumitNaiksatam> for the record (and to put timelines into context), the service insertion discussion has been going for well over two years now, and we still dont have anything which begins to address this
18:08:31 <marios> s3wong: sorry, am on mobile and the screen is pretty small... i miss a lot of stuff here
18:08:39 <s3wong> yes - for all the previous reviewers who gave +1s, please review again :-)
18:08:54 <SumitNaiksatam> hence we need to make sure that we make progress
18:08:55 <banix> s3wong: you said you will have a new patch soon?
18:08:59 <s3wong> for those who wanted to give +1s, please also review :-)
18:09:21 <s3wong> banix: yes, just minor comments - but I would encourage reviewers to look at current revision and give comment
18:09:27 <s3wong> that way I can address them also
18:09:37 <SumitNaiksatam> s3wong: i believe marios volunteered for teh vpnaas piece
18:09:52 <banix> s3wong: ok thx
18:10:01 <marios> s3wong: there is code already?
18:10:03 <SumitNaiksatam> s3wong: can you add him to the assignees? i think marios had requested it
18:10:21 <s3wong> SumitNaiksatam: yes - that is one of the revision 13 comments that I missed - add marios as a team-member, I will make that change
18:10:38 <marios> s3wong: i noticed that :)
18:10:40 <s3wong> marios: yes, Kanzhe will upload the preliminary DB model changes soon
18:10:41 * marios hurt
18:10:47 <SumitNaiksatam> s3wong: thanks, ah it was the earlier rev comment, got it
18:10:52 <marios> s3wong: great thanks
18:11:01 <SumitNaiksatam> marios: dont worry, i got your back :-P
18:11:09 <marios> SumitNaiksatam: hehe thanks :)
18:11:38 <SumitNaiksatam> all please, review this spec, this has to be a prirority for us as a team
18:12:10 <SumitNaiksatam> now our favorite topic
18:12:17 <SumitNaiksatam> #topic Flavors
18:12:18 <cgoncalves> SumitNaiksatam: ok
18:12:44 <enikanorov__> hi
18:12:50 <enikanorov__> markmcclain: hi
18:13:04 <LouisF> s3wong: when will Kanzhe post the update?
18:13:18 <s3wong> LouisF: before Friday for sure :-)
18:13:26 <SumitNaiksatam> #link https://review.openstack.org/#/c/90070#link https://review.openstack.org/102723
18:13:40 <enikanorov__> so I've made two suggestions on Mark's proposal which I think will make it as simple as possible and implementable in juno
18:13:49 <SumitNaiksatam> enikanorov__: thanks
18:14:05 <SumitNaiksatam> so for those who missed the party, we had a dedicated IRC meeting on Friday
18:14:11 <enikanorov__> basically, I'd like to merge 'profiles' approach with providers
18:14:14 <SumitNaiksatam> to discuss the flavors topic
18:14:36 <enikanorov__> and also i seems that extension list on a flavor is not necessary for various reasons
18:14:41 <SumitNaiksatam> #link http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-06-27-17.30.log.html
18:14:48 <enikanorov__> i have left inline comments there as well as generic comment
18:14:52 <SumitNaiksatam> enikanorov__: okay
18:15:04 <enikanorov__> basically we need markmcclain to respond...
18:15:12 <SumitNaiksatam> enikanorov__: do you anticipate we will need another IRC meeting for this? :-P
18:15:31 <SumitNaiksatam> on 4th of July, may be? ;-P
18:15:52 <s3wong> SumitNaiksatam: your idea of (forced) quick resolution?
18:15:54 <s3wong> :-)
18:15:55 <marios> enikanorov__: is the idea to start converging on one of the two open reviews and abandon the other?
18:15:57 <enikanorov__> I would not mind, but if markmcclain agrees with my comments we'll have a consensus
18:16:16 <enikanorov__> marios: something like that
18:16:23 <SumitNaiksatam> jokes apart, i think we have limited time
18:16:35 <enikanorov__> although i'd treat tag-based proposal as further development of the idea
18:16:57 <SumitNaiksatam> enikanorov__: i believe we agreed on that during the IRC meeting discussion
18:16:58 <enikanorov__> that's all from my side
18:17:07 <enikanorov__> SumitNaiksatam: yes
18:17:47 <SumitNaiksatam> enikanorov__: i guess we need to assess the progress on a day to day basis, since we are short on time
18:17:59 <SumitNaiksatam> enikanorov__: will you be implementing the eventual spec?
18:18:27 <enikanorov__> do you mean the spec itself?
18:18:40 <SumitNaiksatam> enikanorov__: i meant the code
18:18:55 <marios> ftr.. here is the meeting log from friday (didn't know it existed till i saw the mailing list this afternoon) http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-06-27-17.30.log.html
18:18:57 <enikanorov__> well, yes, I'd like to implement whatever is the consensus
18:19:25 <SumitNaiksatam> marios: i did post that earlier in the thread (if you scroll up)
18:19:45 <marios> SumitNaiksatam: oh my apologies!
18:19:52 <marios> (was a pita to find on mobile as well!!)
18:20:07 <SumitNaiksatam> marios: no worries, i guessed as much
18:20:26 <SumitNaiksatam> enikanorov__: ok, perhaps if you have cycles, may be you can start updating your earlier PoC patch with what has been agreed upon
18:20:43 <SumitNaiksatam> enikanorov__: just thinking loud here
18:21:08 <enikanorov__> SumitNaiksatam: oh, sure, in fact i've already started the coding, but halted it once we continued the discussion
18:21:10 <enikanorov__> ok
18:21:21 <SumitNaiksatam> enikanorov__: fully understand, and thanks!
18:21:38 <SumitNaiksatam> any other questions for enikanorov__ or markmcclain?
18:22:48 <SumitNaiksatam> ok moving on
18:23:04 <SumitNaiksatam> #topic Service Chaining
18:23:14 <SumitNaiksatam> #link https://review.openstack.org/#/c/93524
18:23:19 <SumitNaiksatam> i know we already discussing this
18:23:30 <SumitNaiksatam> in case if there are any lingering questions for mandeep
18:23:45 <mandeep> I have responded to all questions on the review, and I will be posting a new BP today
18:23:58 <SumitNaiksatam> mandeep: or any blockers at your end (apart from your day job time constraints ;-P)
18:24:04 <SumitNaiksatam> mandeep: great
18:24:13 <mandeep> No, I am good for now.
18:24:21 <SumitNaiksatam> mandeep: thanks!
18:24:37 <LouisF> mandeep: is config going to be removed from serviceNode?
18:25:03 <cgoncalves> mandeep: will the new BP rev describe how one can use a chain? i.e., how traffic should be sent to a chain
18:25:38 <mandeep> I was hoping to leave it in for use in future (say to define a service not yet specified in neutron), but I can add that when that use case shows up
18:25:52 <mandeep> Os that can be in a a vendor extension as well
18:25:54 <cgoncalves> mandeep: ok
18:26:15 <mandeep> cgoncalves: Yes, I am adding an example
18:26:17 <LouisF> mandeep: a ServiceInstance can be associated with many chains - right?
18:26:19 <cathy_> mandeep: If your BP can describe the service instances more clearly, that will be good, especially how they are used in the API
18:26:27 <mandeep> LouisF: Correct
18:26:54 <mandeep> (now called ServiceChainSpec or, ServiceChainFalvour)
18:27:08 <mandeep> cathy_: OK
18:27:19 <LouisF> mandeep: why is there a single chain in ServiceInstance?
18:27:41 <LouisF> mandeep: should be a list of chains?
18:27:48 <cgoncalves> LouisF, mandeep: I guess the tricky part with shared services is how to separate the waters
18:27:48 <cathy_> mandeep: thx. Also how the service instance correlate to the ports speficied in the API table
18:27:54 <mandeep> Pointer to the ServiceChainSpec that it was created from.
18:28:09 <mandeep> LouisF: Pointer to the ServiceChainSpec that it was created from.
18:28:37 <mandeep> LouisF: A specific Instance is only created from a single chain spec
18:29:02 * SumitNaiksatam hoping that we are still on track to finish on time for once today
18:29:17 <s3wong> SumitNaiksatam: one minute :-)
18:29:17 <LouisF> mandeep: I'm confused
18:29:26 <SumitNaiksatam> s3wong: and counting down
18:29:57 <SumitNaiksatam> mandeep: perhaps a quick reponse and we can wrap it up here
18:29:59 <mandeep> cgoncalves: service-chain conveniently hands that problem to the provider (say traffic steering) and just specifies the expected semantics
18:30:07 <SumitNaiksatam> LouisF: we can follow up on the spec of offline
18:30:19 <LouisF> SumitNaiksatam: will do
18:30:26 <SumitNaiksatam> LouisF: thanks!
18:30:31 <SumitNaiksatam> mandeep: thanks for the update
18:30:32 <mandeep> LouisF: Let me post the updated BP and we can review that
18:30:40 <LouisF> mandeep: ok
18:30:42 <mandeep> SumitNaiksatam: Sure
18:30:47 <SumitNaiksatam> lets call it a wrap for today (still a minute over)
18:30:59 <banix> bye everybody
18:31:01 <s3wong> SumitNaiksatam: is progress :-)
18:31:02 <SumitNaiksatam> thanks all, keep up the great work (both on writing the specs/code and the reviews)
18:31:04 <s3wong> bye
18:31:06 <cgoncalves> mandeep: I know :) hence my comment on that the TS bp is limited by not been able to attend that requirement
18:31:09 <SumitNaiksatam> bye
18:31:10 <cathy_> bye everyone
18:31:13 <SumitNaiksatam> #endmeeting