15:00:40 <carl_baldwin> #startmeeting neutron_l3
15:00:40 <tidwellr> hi
15:00:40 <openstack> Meeting started Thu May  7 15:00:40 2015 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:45 <openstack> The meeting name has been set to 'neutron_l3'
15:00:45 <johnbelamaric> hi
15:00:53 <carl_baldwin> #topic Announcements
15:00:58 <yamahata> hello
15:01:02 <yalie> hi
15:01:03 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:01:09 <devvesa> Hi
15:01:31 <carl_baldwin> I don’t think I have any announcements.  Anyone?
15:01:58 <carl_baldwin> I think we all know about summit coming up.
15:02:21 <HenryG> I have one
15:02:44 <carl_baldwin> HenryG: go
15:02:52 <HenryG> An updated wiki for IPv6 has been created
15:02:54 <HenryG> https://wiki.openstack.org/wiki/NEUTRON-IPV6-MANUAL
15:03:26 <HenryG> Please read and review. Anyone can edit and improve it.
15:03:48 <HenryG> It can be used as seed information for real docs.
15:03:49 <carl_baldwin> HenryG: Great.  We’ll link it from the subteam page.
15:03:52 <carl_baldwin> mlavalle: ^
15:04:06 <devvesa> 6
15:04:07 <mlavalle> carl_baldwin: ok, will take care of it
15:04:23 <carl_baldwin> HenryG: Looks like it covers a lot.
15:04:45 <mlavalle> HenryG: I just glanced over it and looks very good. Thanks for sharing
15:05:02 <HenryG> Yes, it has input from a lot of people who worked on the features
15:05:02 <sc68cal> o/
15:05:05 <carl_baldwin> I’m sure it represents a lot of good work from a lot of contributors.
15:05:24 <HenryG> sc68cal: Hi, see the wiki mentioned ^^
15:05:48 * mlavalle kenw sc68cal was involved
15:06:05 <carl_baldwin> Any other announcements?
15:06:18 <sc68cal> HenryG: ok, we should probably convert that wiki page into an RST doc and push a patch into openstack-manuals in the networking guide space
15:07:11 <carl_baldwin> sc68cal: +1
15:07:14 <HenryG> sc68cal: yes, it was just a place to collect information as a start
15:07:35 * carl_baldwin was just going to say the wiki can be a good place to start collecting information.
15:08:43 <carl_baldwin> BTW, welcome to the IPv6 contributors.  A lot of good stuff was done in Kilo and I’m excited for what’s coming in Liberty.
15:08:45 <sc68cal> HenryG: is there a more specific URL than just cisco.com that this came from?
15:10:08 <carl_baldwin> #topic bgp-dynamic-routing
15:10:35 <carl_baldwin> #undo
15:10:36 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x9198490>
15:10:45 <carl_baldwin> #topic Summit
15:11:06 <carl_baldwin> I wanted to use some time to start planning for summit.
15:11:51 <carl_baldwin> #link https://www.google.com/url?q=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FSummit%2FLiberty%2FEtherpads%23Neutron&sa=D&sntz=1&usg=AFQjCNHhzpV5savYHInbQ92GaSfMMT100w
15:12:17 * carl_baldwin gets a more direct link.
15:12:30 <carl_baldwin> # link https://wiki.openstack.org/wiki/Summit/Liberty/Etherpads#Neutron
15:12:35 <carl_baldwin> That’s better.
15:13:24 <carl_baldwin> On Thursday at 9:50 is a Neutron L3 session.  I’d like to poll the team for ideas about how to best use this time.
15:14:12 <carl_baldwin> There is also the Friday “Contributor meetup”  which we can make use of.
15:14:33 <carl_baldwin> So, thoughts?
15:15:12 <devvesa> I'm agree on discussing on what's already in the Etherpad
15:15:58 <devvesa> I haven't read yet Vikram's proposal, but if there is a way to define a generic dynamic routing, maybe it is the best moment
15:15:59 <vikram__> I want to include the general routing framework "https://review.openstack.org/#/c/180987/"
15:17:22 <carl_baldwin> Okay, it is noted on the etherpad.  I’ll probably include it somewhere near the end of the session.  I fear that it could dominate the entire session otherwise.
15:18:01 <devvesa> Wise
15:18:03 <carl_baldwin> I also think that a smaller group could get together during the contributor meetups on Friday might be a good place to discuss it.
15:18:06 <vikram__> thanks carl
15:18:42 <carl_baldwin> I would like to talk about the address scope blueprint:  https://review.openstack.org/#/c/180267/
15:18:53 <tidwellr> +1
15:19:14 <johnbelamaric> +1
15:19:20 <vikram__> +1
15:19:35 <Swami> +1
15:19:36 <yamahata> I want to include ML3
15:20:20 <Rui_Zang> +1
15:20:28 <carl_baldwin> yamahata: Could you add a note and some links to the etherpad?
15:21:13 <yamahata> https://review.openstack.org/#/c/105078/
15:21:21 <yamahata> It was proposed for Kilo
15:21:31 <yalie> +1
15:21:32 <yamahata> I'll restore and update it soon
15:21:46 <carl_baldwin> yamahata: thanks.
15:22:49 <carl_baldwin> In the context of address scopes, talk about how this fits in with dynamic routing, l3 vpn, and IPAM.
15:23:37 <carl_baldwin> Any other thoughts?
15:23:46 <carl_baldwin> #link https://etherpad.openstack.org/p/YVR-neutron-l3
15:24:12 <johnbelamaric> maybe also external dhcp/relay and recursive DNS?
15:24:41 <johnbelamaric> Not sure that is of interest to the whole group :)
15:24:53 <yamahata> What about distributed dhcp?
15:25:22 <vikram__> i feel this is important for taking the idea of L3VPN inside.
15:26:24 <Swami> also service-chaining
15:27:15 <carl_baldwin> johnbelamaric: The designate team has just reached out to me.  The would like to discuss some things in this area in their working session on Thursday at 1:30.
15:27:42 <johnbelamaric> carl_baldwin: great, sounds good. I saw the email from Kiall
15:27:55 <carl_baldwin> Thanks for the ideas.  Be sure to add them to the etherpad with your irc nick and I’ll be working on the agenda.
15:28:15 <carl_baldwin> johnbelamaric: Good, I wasn’t sure how broadly he sent it.
15:28:40 <carl_baldwin> #topic bgp-dynamic-routing
15:29:09 <carl_baldwin> devvesa: tidwellr:  How are things going here?  Last I knew, there was a nasty rebase coming and we had some quagga running.
15:29:26 <johnbelamaric> carl_baldwin: I meant the comment on the code review, I didn't have the time. I'll put it on my plan. Thanks!
15:29:42 <devvesa> Still like this. I haven't had time to rebase it
15:30:05 <devvesa> But I am concerned how are we going to handle all of this
15:30:19 <devvesa> I mean, if there is a 'generic dynamic routing' coming
15:30:37 <devvesa> and I think ML3 using dynamic routing as l3 plugin is also something to consider
15:31:08 <carl_baldwin> devvesa: I think the generic dynamic routing will be a good thing but I’m also concerned about it hindering development that is already going on.
15:31:51 <devvesa> So we go on with we had before
15:32:13 <vikram__> devessa: my idea of generic routing won't require much changes to your current propopsal
15:32:49 <devvesa> What about the spec? There is a new Feature Request proposal workflow
15:33:17 <devvesa> #link https://review.openstack.org/#/c/177342/
15:33:18 <tidwellr> devvesa: are you going to take on a rebase of your earlier work?
15:33:37 <devvesa> If you think that's the way to follow, yes
15:34:20 <carl_baldwin> devvesa: Keep the spec for now.  When the spec review process officially changes (i.e. the policy document merges) we’ll create a feature request following the policy.
15:34:43 <carl_baldwin> Then, I guess the spec will need to be morphed in to devref document.
15:35:06 <devvesa> Ok
15:35:27 <devvesa> So, I'll rebase the patch
15:36:02 <carl_baldwin> devvesa: I think that will be good progress.
15:36:19 <devvesa> Ok
15:36:27 <tidwellr> I'd like to deploy it and play with that patch
15:37:00 <devvesa> Actually it were three patches. One with the entities/api
15:37:12 <devvesa> Another one with agent scheduling
15:37:18 <tidwellr> devessa: right, I'd like to try out all 3 :)
15:38:02 <carl_baldwin> Cool, so I think we have a plan.
15:38:17 <carl_baldwin> Anything else for bgp?
15:38:43 <devvesa> Just announce that Vikram may take care of rebase/implement the other 2
15:39:02 <devvesa> As he kindly offered himself
15:39:59 <carl_baldwin> Thank you vikram__ .  Please feel free to ask tidwellr or /me for assistance.
15:40:08 <vikram__> devvesa: +1
15:40:14 <carl_baldwin> #topic neutron-ipam
15:40:30 <vikram__> sure. i will
15:40:57 <pavel_bondar> we have clean test pass for all 3 patches
15:41:02 <pavel_bondar> #link https://review.openstack.org/#/c/153236/
15:41:16 <carl_baldwin> pavel_bondar: That is great!
15:41:18 <amuller> carl_baldwin: it looks like specs will remain
15:41:28 <amuller> carl_baldwin: in their current form, maybe a thinner template
15:41:33 <pavel_bondar> after I have changed default to non-IPAM
15:41:33 <amuller> we'll see...
15:41:53 <pavel_bondar> and created new dependent review to run IPAM implementation
15:41:59 <carl_baldwin> amuller: I saw a note going that direction but I wanted to wait to see what merges.
15:42:37 <carl_baldwin> pavel_bondar: I saw that
15:42:38 <carl_baldwin> #link https://review.openstack.org/#/c/181023/
15:44:04 <pavel_bondar> I expect only check-grenade-dsvm-neutron should fail in #181023, due to absence of migration to IPAM
15:44:17 <carl_baldwin> pavel_bondar: The grenade test was the only thing remaining.  I think that is great progress and we — as reviewers — owe you some reviews.
15:44:58 <carl_baldwin> pavel_bondar: I will review again today.
15:45:24 <pavel_bondar> carl_baldwin: Thanks!
15:46:10 <pavel_bondar> a few things left to do in reference driver #150485
15:46:36 <carl_baldwin> I encourage others to review too.
15:46:39 <pavel_bondar> like unit tests and auto_addressed subnet question
15:46:56 <pavel_bondar> I am working on that in #150485
15:47:08 <johnbelamaric> pavel_bondar, carl_baldwin: I will go through it again as well
15:47:34 <carl_baldwin> pavel_bondar: I haven’t visited that review in a few days.  What is left?
15:48:33 <carl_baldwin> I will take another look today.
15:49:08 <pavel_bondar> for reference driver it is mostly several UT that left to do and auto_addressing
15:49:52 <pavel_bondar> #link https://review.openstack.org/#/c/150485/19/neutron/ipam/drivers/neutrondb_ipam/driver.py
15:50:09 <carl_baldwin> pavel_bondar: Right, auto_addressing.  Thanks for taking care of those items.
15:51:56 <pavel_bondar> So solution for auto_addressing will be detecting auto_addressed subnet by ip(is_eui64), or it is still on-going discussion?
15:51:58 <carl_baldwin> Anything else?
15:52:32 <johnbelamaric> pavel_bondar: the ongoing discussion is around whether we inform IPAM of auto-assigned addresses (that are not link-local)
15:53:37 * carl_baldwin is having deja vu
15:53:48 <pavel_bondar> johnbelamaric: ok, so I'll wait discussion results on this topic
15:54:56 <carl_baldwin> I tend to think that Neutron should still call IPAM and IPAM can choose what to do.
15:55:57 <johnbelamaric> carl_baldwin: agreed, then we need to decide whether IPAM can reject the auto-assigned addressing or not. If not, we may want a separate "inform" vs. "allocate" call.
15:56:51 <johnbelamaric> carl_baldwin: I see a need for visibility in IPAM (for external IPAM) to auto-assigned addresses but not rejection
15:57:01 <carl_baldwin> johnbelamaric: Interesting.
15:58:04 <johnbelamaric> carl_baldwin: but either way is fine by me - I just want to be sure we have the visibility into those addresses when they are assigned (particularly ULA) - though frankly for auto-assigned that is a nice-to-have and not critical
16:00:17 <carl_baldwin> Looking at it from an API perspective, I think it is good to give the IPAM system an opportunity to see the allocation even if it is automatic.  From the reference implementation perspective, I think it is fine to just ignore it.  That is just my opion though.  I’ll add a comment to the review.
16:00:28 <etoews> is the neutron meeting done?
16:00:30 <carl_baldwin> We should find a way to converge on a decision for this soon.
16:00:43 <carl_baldwin> etoews: thanks.  We’ll end now.
16:00:49 <carl_baldwin> #endmeeting