17:30:59 <mestery> #startmeeting Networking Advanced Services
17:31:00 <openstack> Meeting started Wed Jun  4 17:30:59 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:31:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:31:03 <openstack> The meeting name has been set to 'networking_advanced_services'
17:31:11 <mestery> #link https://wiki.openstack.org/wiki/Meetings/AdvancedServices Agenda
17:31:14 <rkukura> hi
17:31:24 <mestery> So, SumitNaiksatam can't be with us today, he asked me to run this.
17:31:39 <mestery> I'd mainly like to go over the BP reviews/approval process, per SumitNaiksatam's request.
17:31:57 <s3wong> mestery: OK
17:32:10 <mestery> #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan
17:32:18 <mestery> OK, so shall we walk through the JunoPlan here?
17:32:27 <s3wong> mestery: sure
17:32:34 <vinay_yadhav> ok
17:32:36 <cgoncalves> hi!
17:32:37 <banix> yeah
17:32:41 <mestery> OK, so lets just start at the top.
17:32:53 <mestery> The over-arching BP was approved already.
17:33:02 <mestery> The next one on the list is flavor framework.
17:33:06 <mestery> enikanorov: Are you around?
17:33:23 <banix> so this one has been under review for a long time
17:33:36 <mestery> Yes, there were some issues which markmcclain had wiht htis one if I recall.
17:33:42 <mestery> There is a ML thread as well I believe from enikanorov.
17:33:49 <banix> mestery: yes
17:33:50 <mestery> We need to close on this one ASAP I believe.
17:34:10 <mestery> #action enikanorov to re-post ML thread.
17:34:19 <mestery> #action mestery to bringup flavor framework discussion at Neutron meeting on Monday.
17:34:26 <mestery> Anything else with flavor framework?
17:34:44 <s3wong> no
17:34:48 <enikanorov> mestery: sorry, i'm late
17:34:50 <mestery> OK, cool,
17:35:01 <mestery> Next one is service insertion.
17:35:13 <mestery> This one has gone through many iterations as well.
17:35:17 <enikanorov> so i think it makes sense to limit initial implementation to those aspects that don't involve integration with services
17:35:25 <s3wong> mestery: well, since enikanorov is here, does he have anything else to say about flavor framework?
17:35:26 <enikanorov> so the question posted to ML could be addressed later
17:35:36 <mestery> enikanorov: for flavor framework?
17:35:39 <enikanorov> yes
17:35:50 <pgpus> Servicde Insertion I did not find any sharing of a given service, any comments?
17:35:52 <mestery> enikanorov: OK, got it.
17:36:10 <enikanorov> i'm planning to have implementation at ~J-1 time so we could spend J-2 reviewing and hopefully merge it by J-02
17:36:19 <mestery> enikanorov: Perfect!
17:36:26 <s3wong> enikanorov: J-1 is next week, right? :-)
17:36:39 <enikanorov> s3wong: right, but flavors API is no big deal IMO
17:36:49 <enikanorov> still hoping to get whole patch < 1k lines
17:37:31 <s3wong> enikanorov: that's including STF, which is still part of flavor, right?
17:37:31 <mestery> enikanorov: Cool!
17:37:45 <pgpus> I have added mysellf to service Insertion and will see what I can contribute after review
17:37:49 <enikanorov> that's probably it from my side
17:37:59 <enikanorov> feel free to approve flavor framework bp
17:38:00 <enikanorov> :)
17:38:08 <banix> enikanorov: done!
17:38:18 <mestery> enikanorov: Ha! I will review it again this afternoon.
17:38:21 <mestery> enikanorov: Thanks!
17:38:27 <mestery> OK, so service insertion now.
17:38:46 <mestery> This one is also looking like it's ready for some core reviewer and approval love I think.
17:38:49 <s3wong> mestery: OK, since kanzhe and kevinbenton aren't here, I will take this one
17:38:55 <mestery> s3wong: thanks!
17:39:18 <s3wong> mestery: yes, I have been advertising it everywhere, so it is now waiting for cores to look at, if they have time
17:39:43 <banix> this one has not received many reviews outside the advanced service sub team
17:39:49 <s3wong> as kanzhe talked about last week, the division of tasks between kanzhe, kevinbenton and me were decided
17:40:11 <pgpus> Does the Service Insertion bp require any reveiw or is it approved?
17:40:12 <mestery> OK, perfect!
17:40:16 <s3wong> and I believe kanzhe and kevinbenton are currently working on API and db
17:40:21 <mestery> pgpus: It's not approved yet, reviews welcome.
17:40:23 <SridarK> s3wong: so first target will be fwaas - no change correct ?
17:40:41 <s3wong> SridarK: FWaaS is the natural first, the tough one is LBaaS
17:40:50 <SridarK> s3wong: :-)
17:40:55 <pgpus> ok did one pass and will do another to make sure it meets J-1 time farme deliveries
17:41:02 <mestery> s3wong: Lets see if we can get this integrated before LBaaS departs Neutron. ;)
17:41:21 <mestery> pgpus: J-1 is next week, none of this is targeted for J-1
17:41:23 <s3wong> and luckiy and forunately, LBaaS is going through model change at J-2, so we can work with their db migration naturally
17:41:27 <mestery> This is all J-2 and beyond at this point. :)
17:41:27 <s3wong> on the right time :-)
17:41:28 <SridarK> mestery: without this no one can go anywhere :-)
17:41:47 <pgpus> Has anyone looked at ServiceBase class definitions?
17:42:27 <pgpus> or is it wating for Data Models?
17:42:41 <s3wong> pgpus: I deifned it, please look into it and see if it fits into your expectation :-)
17:42:54 <banix> regXboi: Any comments wrt the service insertion beyond your comments on the review system?
17:43:09 <regXboi> banix: sorry for being late - no - I need to re-read the new patch
17:43:11 <pgpus> Thanks s3wong
17:43:15 <banix> regXboi: just noticed you joined; thats the topic being discussed
17:43:50 <banix> s3wong: what are you referring to? in the service insertion spec?
17:43:50 <regXboi> I read through all the BPs on the status page as of Sunday and added comments where I had them - haven't had a chance to follow up on all of them since
17:44:00 <pgpus> will we cover more than l2, l3 insertion in j-1
17:44:09 <s3wong> banix: regarding love outside of adv serv. subteam, what we really want is people from LBaaS (no one), FWaaS ( SridarK ) and VPNaaS ( nachi_ueno )
17:44:20 <mestery> pgpus: Again, none of this work is being done for J-1, the specs are targeted to be approved by J-1.
17:44:27 <pgpus> https://review.openstack.org/#/c/93128/9/specs/juno/service-base-and-insertion.rst
17:44:31 <mestery> pgpus: J-1 is next week, it may be cut Tuesday, but as late as Thursday. :)
17:44:42 <banix> s3wong: speak of love got me confised for a second :)
17:45:00 <s3wong> banix: no love so far :-(
17:45:10 <regXboi> actually, banix, I'm worng
17:45:16 <regXboi> I did read through the new SI draft
17:45:22 <mestery> s3wong: I'm from the LBaaS team, I'll review in more detail and spread the word with the broader team.
17:45:23 <pgpus> ok atleast lets get bp clerared for coding on service insertion
17:45:30 <regXboi> and I still want some text on equating service port and service attachment point
17:45:42 <s3wong> mestery: cool, but you are everywhere, so I don't know if it counts :-)
17:45:52 <regXboi> because if I read it as someone from outside, the equivalency isn't obvious
17:45:57 <mestery> s3wong: :P
17:46:00 <s3wong> mestery: but we do need your approval eventually  for sure :-)
17:46:06 <banix> regXboi: agree; that should be easily addressed
17:46:24 <SridarK> s3wong: i am on board - have had many discussions with u and kanzhe - will put my +1 soon - just minor things i am trying to work out
17:47:11 <s3wong> SridarK: cool, We can talk more if you want (even f2f)
17:47:20 <SridarK> s3wong: sure thanks
17:47:38 <mestery> OK, should we move on to traffic steering now?
17:47:49 <pgpus> Integration with devstack, heat and other modules for service insertion is bit unclear and does anyone have any clue on that?
17:47:50 <s3wong> mestery: sure, I have nothing else to say :-)
17:48:26 <mestery> pgpus: There are people signed up for some of those, but I don't see devstack under that project at all.
17:48:37 <pgpus> or we leave the impact to later time frames?
17:48:57 <s3wong> pgpus: not yet, though Louis volunteered for Heat
17:49:22 <s3wong> and kanzhe , kevinbenton , and I will likely include devstack work as part of our ongoing development and testing
17:49:27 <pgpus> Good atleast Heat as Orchestartion tools and template of Service will help us give some idea
17:49:39 <banix> s3wong: need to add devstack to the tables
17:49:39 <s3wong> pgpus: however, if you want to volunteer to join in, we welcome you :-)
17:49:54 <s3wong> banix: yes
17:50:00 <pgpus> May I can look into devstack and add my comments to bp
17:50:01 <banix> s3wong: thanks
17:50:19 <s3wong> pgpus: of course. Thanks!
17:51:00 <mestery> OK, on to traffic steering.
17:51:05 <mestery> cgoncalves: This is your area I believe.
17:51:13 <cgoncalves> mestery: indeed
17:51:15 <pgpus> devstack will need nova / neutron config changes for service creation by few params possibly will verify by flow one time
17:51:33 <cgoncalves> since last week we addressed some comments and submitted a new patchset
17:51:46 <cgoncalves> we are in need of more reviewers I believe
17:51:50 <s3wong> pgpus: OK
17:51:55 <pgpus> Ok we move to traffic steering
17:51:55 <mestery> cgoncalves: OK, good to know!
17:52:06 <mestery> #info Traffic Steering BP is in need of more reviewers
17:52:10 <s3wong> cgoncalves: will review
17:52:10 <cgoncalves> and I apologise for the late patchset
17:52:23 <cgoncalves> s3wong: thanks
17:52:24 <regXboi> mestery: I plan on reading
17:52:41 <s3wong> cgoncalves: though I am still hoping that traffic steering will take advantage on the connectivity map that we are going to store in ServiceBase objects
17:52:46 <mestery> s3wong regXboi: Thanks!
17:52:54 <shivharis> cgoncalves: link?
17:52:57 <cgoncalves> traffic steering can play a significant role in the new openstack nfv sub-team vision
17:53:03 <mestery> #link https://review.openstack.org/#/c/92477
17:53:12 <cgoncalves> mestery: tks
17:53:15 <shivharis> mestery: thx
17:53:38 <s3wong> cgoncalves: yes, I noticed your participation during the NFV meeting this morning
17:54:16 <cgoncalves> also, I have not nominated myself to all items that are in the wiki
17:54:37 <s3wong> cgoncalves: there are others in your team as well, right?
17:54:37 <mestery> cgoncalves: OK, can you remove yourself where appropriate?
17:54:47 <cgoncalves> so I look forward for volunteers wanting to help me on heat, horizon, etc
17:54:48 <pgpus> https://blueprints.launchpad.net/neutron/+spec/traffic-steering-abstraction
17:55:05 <cgoncalves> mestery: ok
17:55:28 <cgoncalves> s3wong: yes, but not directly involved in openstack
17:55:45 <cgoncalves> s3wong: jsoares is collaborating with me on the proposal though
17:55:49 <pgpus> looks like port to port traffic forwarding is involved and will help service chaining is it states
17:56:02 <cgoncalves> pgpus: yes
17:56:03 <banix> s3wong: have a pointer to the nfv meeting wiki?
17:56:06 <mandeep> pgpus: Correct
17:56:12 <cgoncalves> #link https://wiki.openstack.org/wiki/Meetings/NFV
17:56:16 <cgoncalves> banix: ^
17:56:21 <banix> cgoncalves: thx
17:56:28 <s3wong> banix: https://wiki.openstack.org/wiki/Meetings/NFV
17:56:39 <banix> s3wong: thx
17:57:04 <pgpus> Are we using ovs flolw control to steer traffic and does it mean control plane data plane seperation as sdn/nfv here?
17:57:24 <cgoncalves> on the implementation side I have still some concerns, but probably are out of scope for now
17:57:47 <pgpus> Sure I will lookinto nfv meetings and join that besides here
17:58:42 <mestery> OK, anything else on traffic steering or should we move onto the service chaining BP?
17:58:57 <cgoncalves> mestery: I think I've nothing more to add for now. thanks
17:59:03 <mestery> cgoncalves: Thanks!
17:59:51 <mestery> mandeep: I believe Service Chaining is your BP?
17:59:58 <mandeep> mestery: Correct
18:00:03 <mestery> How is the review going for this one?
18:00:03 <mandeep> The status is:
18:00:12 <pgpus> I am still not sure what's the assumption here , do we steer traffic first or chain the phyiscal pipe (logical pipe ) first, as what preceeds what, chaining or steering?
18:00:20 <mandeep> 1. A use-case needs to be added to the BP, that is still pending
18:00:43 <mandeep> 2. I just updated the plan and I am targeting J1 for BP approval and J3 for code in neutron/CLI
18:00:44 <pgpus> OK mandeep that's a good point to start
18:01:18 <pgpus> for which one steering or chaining you mean?
18:01:21 <mandeep> 3. I still need to identify volunteers for Heat/Horizon/Devstack - TBD
18:01:31 <mandeep> mestery: That is all
18:01:51 <mandeep> pgpus: Chaining
18:01:55 <mestery> mandeep: thanks!
18:02:17 <mestery> mandeep: I had one comment in the latest review around creating a separate launchpad BP for this one as well so we can track it with LP milestones.
18:02:22 <mestery> mandeep: I added it in the review.
18:02:35 <mandeep> OK, will do.
18:02:37 <pgpus> devstack for neutron service shaining you mean mandeep, may be let me review it for you
18:02:40 <regXboi> I'm still concerned about the non-sunny day
18:02:51 <mandeep> pgpus: Sure
18:02:53 <mestery> regXboi: I saw your concerns as well
18:03:01 <mandeep> regXboi: non-sunny day?
18:03:18 <regXboi> what happens in re notifications if something goes wrong
18:03:42 <regXboi> the statement "	1. All updates to service-chain resources need to be relayed to the configured service-chain-providers"
18:03:52 <regXboi> needs clarification around what happens if the relay fails
18:03:53 <s3wong> regXboi: somethig goes wrong meaning something within the chain going down?
18:03:53 <mandeep> regXboi: I am hoping that is where an infrastructure like group-policy can hep
18:04:37 <regXboi> mandeep: I think you should identify that dependency in the text then
18:04:45 <mandeep> regXboi: Got it. That is a function call, not a message,
18:05:00 <mandeep> regXboi: Good point. I will add that
18:05:04 <pgpus> Are we looing Infra GP and Service GP as layered GP for Endpoints involved?
18:05:08 <regXboi> mandeep: ah, I read the text as a message, not an rpc
18:05:46 <s3wong> pgpus: by service GP do you mean an EPG wrapping a service?
18:05:48 <regXboi> in general though, I'm going to be thinking about the "how do we handle something not working" aspect
18:05:57 <mandeep> regXboi: So ignore my comment on GP, that was in a generic sense - not for this specific interaction
18:05:59 <pgpus> Sure that is Group Policy within Group Policy hierarcy that was demoed by Sumit's team and had some codes in github I believe
18:06:06 <regXboi> mandeep: got it
18:06:37 <s3wong> pgpus: that is hierarchical contracts, which is division more between infra owner and app owner (roles)
18:06:46 <pgpus> OK lets move on ignore GP for now
18:06:48 <regXboi> but I will followup with the "fixup" concept on 175 needs some thought about what do we do if a servicechaininstance can't be "fixed up"
18:06:58 <cgoncalves> regXboi: it should also be of interest for this spec to know what are ODL plans on this as I see there is a Service Function Chaining proposal there and you're somehow involved :-)
18:07:20 <cgoncalves> #link https://wiki.opendaylight.org/view/Project_Proposals:Service_function_chaining
18:07:25 <pgpus> Service failure is diff from Infra failure so will need some thinking and borrow some ideas from service VM or wherever
18:07:33 <regXboi> cgoncalves: guilty as charged - I'm not 100% sure yet - I'm only peripherally involved at this point
18:07:59 <mestery> regXboi: You are involved in more than I am I believe. ;)
18:08:03 <regXboi> cgoncalves: I'll have a better idea when I have a chance to dig through the proposed yang models
18:08:10 <mandeep> pgpus: My comment was that in general, your "actual" can deviate from "expected" and there needs to be a way to recover to the "expected" state, anf group-policy allows a clean way to achieve that.
18:08:11 <cgoncalves> mestery: jealous? hehe
18:08:15 <mestery> cgoncalves: Ha!
18:08:43 <regXboi> mandeep: that's a very good thing to say in the BP I think
18:08:55 <regXboi> because it takes care of a lot of my budding concerns :)
18:08:57 <mandeep> regXboi: Yes, I will add that.
18:09:04 <regXboi> mandeep: thx
18:09:13 <pgpus> Is Service chaing tied to ODL or is it generic ? this links shows ODL way?
18:09:15 <cgoncalves> regXboi: ok, thanks. I'd also like to get a peek on ODL's work on this matter. anyway... i'm offtopic-ing, sorry
18:09:31 <s3wong> pgpus: I certainly hope we don't have to tie it to the ODL project
18:09:32 <regXboi> cgoncalves: there is a patch spec in ODL gerrit right now...
18:09:35 <regXboi> will pm it to you
18:10:01 <mandeep> pgpus: As defined, it is designed to independent of any specific backend/provider
18:10:19 <regXboi> mandeep: +1
18:10:21 <banix> yeah lets not mix in the group policy here
18:10:48 <banix> this is more generic as mandeep said
18:10:56 <mestery> OK, 20 minutes left and 2 BPs to go.
18:11:03 * mestery thinks we have a chance at completing these.
18:11:11 <s3wong> banix: yes, a service chain can be implemented by GBP
18:11:15 <mandeep> banix: Agreed
18:11:20 <pgpus> That is welcome, so the focus is stitching service and default is OVS for underlay and for overlay we need Group or Chain policy
18:11:24 <regXboi> mestery: don't say that - murphy will hear!
18:11:31 <mestery> regXboi: hehehehe
18:11:37 <mandeep> regXboi: ;-)
18:12:33 <mestery> OK, moving on to L3 agent consolidation.
18:12:51 <pgpus> Looks this needs more detail look into bp, will try cover this offline, but what's the last date for approval on this one?
18:14:12 <pgpus> Could be per Service Chaining policy
18:14:12 <regXboi> pgpus: +1
18:14:37 <pgpus> add to that per Tenant
18:14:37 <mestery> Does anyone know the IRC nick of hte L3 agent consolidation author?
18:15:05 <mestery> Looks like it's iwamoto, who likely is sleeping right now. :)
18:15:23 <s3wong> yes
18:15:46 <mestery> I have some serious concerns with this BP, adding comments now.
18:15:56 <mandeep> pgpus: Please go ahead and add review comments, it is more important that we get it right.
18:16:06 <regXboi> mestery: join the club, we've got jackets?
18:16:09 <pgpus> Ok madeep will do that
18:16:10 <mestery> regXboi: :)
18:16:33 <mestery> Anyways, lets move on to the last one, and my personal "favorite named BP of all time": Tap as a Service.
18:16:41 <vinay_yadhav> :)
18:16:46 * regXboi hears trumpets in the background
18:16:51 <s3wong> it is on Tap!!!
18:17:00 <vinay_yadhav> good one
18:17:16 <regXboi> I haven't had a chance to read the new patchset
18:17:36 <vinay_yadhav> well reviews are on and we are refining it each patch set
18:18:00 <vinay_yadhav> targeting juno 2 for spec as well as neutron code
18:18:03 <regXboi> understood I'm just saying I commented on ps 3 and haven't had a chance to re-read ps 4
18:18:11 <mestery> vinay_yadhav: Cool, thanks! I haven't reviewed this one yet either.
18:18:19 <regXboi> so I still owe a re-read
18:18:22 <mestery> regXboi: Get on that man! ;)
18:18:25 <vinay_yadhav> regXboi: i got it :)
18:18:26 <cgoncalves> vinay_yadhav: great work on quickly addressing reviewers' comments!
18:18:31 <regXboi> mestrey: right behind you :)
18:18:36 <pgpus> where is the link for tap, I see virtualResource one did I miss tap one?
18:18:49 <regXboi> #link https://review.openstack.org/#/c/96149/
18:19:23 <anil_rao> Did not see any major concerns
18:19:25 <regXboi> so, one thing that jumps out at me
18:19:32 <pgpus> is this tp mirroring intended for HA or reslliance to service?
18:19:32 <regXboi> who can create a tap service?
18:19:37 <vinay_yadhav> i will start a dev thread soon as sumit suggested
18:19:49 <vinay_yadhav> tenant can create the service instance
18:20:04 <pgpus> tap mirroring on tap iterface of VM?
18:20:08 <vinay_yadhav> the work flow for using the service is described in short in the spec
18:20:15 <anil_rao> Several use cases are documented - debugging and more importantly traffic monitoring/visiblity for security and analytics
18:20:21 <s3wong> vinay_yadhav: and admin can redirect traffic flow to it if they use GBP :-)
18:20:57 <s3wong> then we can rename this NSA-as-a-Service
18:21:09 <vinay_yadhav> haha sure :)
18:21:35 <mandeep> s3wong: Or the copy action for GBP can use the tap service ;-)
18:21:36 <regXboi> so... how does this interact with shared networks?
18:21:36 <vinay_yadhav> pgpus: we mirror the traffic transiting the port in the VSwitch
18:21:51 <pgpus> I see good use cases for port mirroring on neutron a good one need to study this , but what's security risk on this , any thoughts?
18:21:54 <s3wong> mandeep: yes, forgot about that, sorry :-(
18:22:29 <mandeep> s3wong: Nothing to be sorry about, another option!
18:22:30 <anil_rao> We have documented the security aspects in the spec. We try to honor the existing Security Group policies .
18:22:53 <pgpus> What if some spurious process redirects the traffic will it not cause serious attack or compromise on the service?
18:23:00 <regXboi> anil_rao: you've identified the security aspects at the traffic/port level
18:23:12 <regXboi> anil_rao: I'm asking the administrative/tenant level
18:23:48 <anil_rao> the service can be initiated by a tenant owner and its scope is restricted to that tenant.
18:23:50 <vinay_yadhav> regXboi: do u mean tenant misbehaving
18:24:18 <regXboi> vinay_yadhav: I'm thinking if I have a shared network and the tenant of the network can tap any port on that network, that might be an issue
18:24:20 <s3wong> regXboi: you want admin to have the ability to remove a tap from tenant?
18:24:24 <pgpus> well secuirty is wast bust aslong it covers for the said use case we should be OK
18:24:51 <regXboi> s3wong: I'm starting to think *only* admin can set up TaaS
18:24:59 <mestery> regXboi: Have you expressed these concerns in the BP review? If not, please do.
18:25:14 <anil_rao> we would like a tenant on say a public cloud to be able to initiate traffic monitoring for his/her tenat. Ideally without cloud admin intervention.
18:25:14 <regXboi> mestery: will do - honestly, I only started thinking of them just now
18:25:15 <mestery> Why would a non-admin need to setup TaaS?
18:25:15 <vinay_yadhav> regXboi: need to think on the acpects of shared networks
18:25:26 <banix> regXboi: i think even that may have unwanted implications
18:25:45 <vinay_yadhav> anil_rao: agree
18:25:47 <regXboi> vinay_yadhav: I'll craft some comment text for the security impact section
18:25:56 <vinay_yadhav> sure thanx
18:25:59 <anil_rao> The scope of the Tap is limited to the tenant that initated the service, so I believe it should be okay.
18:26:04 <s3wong> regXboi: please do
18:26:29 <s3wong> anil_rao: only on the tenant's own vport, right?
18:26:51 <banix> anil_rao: which may be more reasonable than allowing the admin to do so
18:26:56 <s3wong> stuff like external port is something tenants can't tap
18:27:00 <anil_rao> Yes, that is correct. The ports in question must belong to the tenant
18:27:04 <vinay_yadhav> s3wong: yes only on tenants vports
18:27:08 <mestery> 3 minutes left folks, I think we should start wrapping this up now.
18:27:15 <mestery> I propose this discussion move to the BP at this point.
18:27:24 <mestery> It seems serious enough to warrant some thought, per regXboi.
18:27:25 <regXboi> anil_rao: aha! let me see if I find that text
18:27:47 <s3wong> mestery: sure
18:27:47 <pgpus> I believe port redirection is important for VM agents to Hypervisopr Agents communication and hence this should get priority irrespective of security which will evolve overtime
18:27:49 <anil_rao> Vinay and I will make sure to update the spec with some additional detail
18:27:55 <vinay_yadhav> sure
18:28:06 <regXboi> anil_rao: ok, I found that text
18:28:09 <mestery> pgpus: I'm not following that comment at all.
18:28:17 <regXboi> but I still need to think through shared networks
18:28:28 <regXboi> pgpus: er?!?!?!
18:28:36 <mestery> regXboi: It's not just me at least.
18:28:50 <regXboi> mestery: no, I want an explanation before I say -1
18:29:10 <mestery> Agreed, but with 1 minute left, not sure we'll get there. :)
18:29:14 <mestery> OK, lets wrap this up for this week.
18:29:18 <regXboi> yes - let's go BP on this one
18:29:21 <mestery> I think we're all focused on BP review at this point.
18:29:30 <vinay_yadhav> regXboi: Can you please leave your comment on the spec
18:29:38 <pgpus> tenant isolation is different but network sharing yes from that perspeactive, logical noverlays are allocated to tennat can be restricted to tenant to avoid security risks for those tenents who desire it
18:29:41 <regXboi> vinay_yadhav: yes
18:29:41 <banix> bye all
18:29:41 <mestery> Please keep the momentum up, and I'll see if we can focus some attention on service BPs at the Neutron meeting on MOnday.
18:29:44 <mestery> Thanks!
18:29:45 <s3wong> bye
18:29:47 <mestery> #endmeeting