15:04:44 <matrohon> #startmeeting bgpvpn
15:04:45 <openstack> Meeting started Tue Aug 11 15:04:44 2015 UTC and is due to finish in 60 minutes.  The chair is matrohon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:49 <openstack> The meeting name has been set to 'bgpvpn'
15:04:52 <janscheurich> matrohon, svinota: hi
15:05:07 <matrohon> #topic Announcements
15:05:56 <matrohon> the discussion on the spec seems slow currently
15:06:12 <matrohon> it seems we have a agreement on it
15:06:25 <janscheurich> How far are we on freezing the current scope?
15:07:23 <matrohon> <janscheurich> : actually, I think we gone freeze the scope depending on the progress we make in the code
15:08:29 <janscheurich> I didn't check the code so far. But is the southbound driver API up to date with the current API already?
15:08:38 <matrohon> <janscheurich> : once we will release the 1.0 version, we probably split the spec, and merge only the description of what has been coded
15:09:04 <matrohon> <janscheurich> : I'm currently working on the network-associate API
15:10:04 <matrohon> <janscheurich> : actually, I'm currently working on the improvment of the UT framwork
15:10:23 <matrohon> but there is already some code for the *-associate API
15:11:32 <matrohon> I think the most important right now is the test framework, since currently too few code is tested
15:12:00 <matrohon> a acceptable test framework will increase our dev efficiency
15:12:09 <janscheurich> Sounds reasonable.
15:12:37 <matrohon> any annoucment, anyone?
15:13:16 <svinota> not sure how it is directly related
15:13:33 <svinota> but may be interesting in the bgpvpn perspective
15:13:54 <svinota> matrohon, may I?
15:14:01 <matrohon> of course :)
15:14:11 <svinota> we have MPLS routes in the kernel starting from 4.1.4 or like that
15:14:33 <matrohon> ho very interesting!
15:14:42 <svinota> and the userspace part will be done in the pyroute2 this week
15:15:03 <svinota> to add/remove/modify MPLS routes
15:15:25 <svinota> that's just label switching, no label exchange
15:15:30 <svinota> but anyways.
15:15:37 <matrohon> tmorin told me that there were work in progress on this part
15:15:43 <matrohon> really good news
15:15:58 <matrohon> do you have any link?
15:15:58 <svinota> so it is not so mature, but working good enough
15:16:17 <svinota> matrohon, only the code in the git :)
15:16:17 <matrohon> may be the kernel patch?
15:16:21 <matrohon> ok
15:17:12 <matrohon> actaully, ovs 2.4 is not already out, so having an alternative to avs would be very interesting
15:17:37 <svinota> the userspace support is done in the new iproute2, but I will do it for the python API as well
15:17:41 <matrohon> moreover, I'm not sur every net/sys admin is a big fan of ovs
15:18:46 <svinota> net/mpls/af_mpls.c
15:18:50 <matrohon> #info : MPLS support is provided in kernel 4.1.4, and userspace support will be done in iproute2 soon
15:19:03 <matrohon> svinota : thanks
15:19:13 <svinota> not correct. In iproute2 it is already started
15:19:28 <svinota> but this week it will be done in pyroute2 as well
15:19:45 <matrohon> #undo
15:19:46 <openstack> Removing item from minutes: <ircmeeting.items.Info object at 0xa23b2d0>
15:20:43 <matrohon> #info : MPLS support is provided in kernel 4.1.4, and userspace support is in progress in iproute2. pyroute2 implementation will be done soon
15:20:57 <matrohon> svinota : does it sound better ? :)
15:21:11 <svinota> yep :)
15:21:26 <svinota> I hope the work will be useful to exabgp
15:21:44 <matrohon> svinota : did you make any progress on the code?
15:21:55 <svinota> matrohon, on which one?
15:22:01 <matrohon> svinota : I mean the bgpvpn code :)
15:22:18 <svinota> ;) not so much. A bit stuck with the discovery
15:22:33 <matrohon> discovery?
15:22:47 <svinota> attribute discovery.
15:22:55 <svinota> optional attribute.
15:23:12 <matrohon> for the dedicated extension?
15:23:16 <svinota> yep
15:24:04 <janscheurich> Do you have a link where can I find existing bgpvpn code defining the SB driver API? I'm interested in the context of ODL driver
15:24:30 <matrohon> svinota : I'll try to think about it deeper since I'm debugging the netron extension framework for the UT purpose
15:26:10 <matrohon> <janscheurich> : currently it is define in : https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/__init__.py
15:27:17 <matrohon> there are 3 main methods : create/delete/update
15:28:23 <matrohon> with tmorin, we was wondering if we still have to provide the ability to associate a connection with an update call to the bgpvpn_connection
15:28:56 <matrohon> or this feture should only be available through the new network_associate API
15:29:33 <janscheurich> Thanks! And the driver for the bagpipe back-end is where?
15:30:02 <matrohon> there are dummy driver here : https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/dummy.py
15:30:10 <matrohon> for tests purposes
15:30:28 <janscheurich> Do you foresee a separate driver API for the network and router association handling?
15:30:28 <matrohon> and the bagpipe driver : https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/bagpipe.py
15:30:59 <janscheurich> Thanks
15:31:35 <matrohon> Currently there is two type of inheritance for the driver, depending whether you need to store datas in the db or not
15:32:19 <matrohon> doude who is currently working on the contrail driver, made this change
15:32:32 <matrohon> because contrail manage its own db
15:33:21 <matrohon> <janscheurich>: we gone have two seperated API for net association and router association
15:33:34 <matrohon> that's the way I'm working currently
15:34:28 <janscheurich> OK. Any idea when the driver APIs for *_associations will be defined?
15:35:13 <matrohon> a WIP is currently under review : https://review.openstack.org/#/c/207371/
15:36:21 <matrohon> but this WIP showed that the tests framework is really too lazy since test passed while this patch breaks neutron :)
15:37:29 <matrohon> <janscheurich> : you can start working on the router association if you have time
15:38:35 <janscheurich> I'm not really a neutron coder (yet ;-) Just learning how things fit together
15:39:43 <matrohon> <janscheurich> : I really think it's a good way to start coding in neutron, you'll learn all the stack (extension, DB, API, service type).... :)
15:40:26 <matrohon> <janscheurich> : and of course I can help if you have any question
15:40:40 <matrohon> <janscheurich> : at least I can try to help :)
15:41:01 <janscheurich> Yes. But you need well-written examples to steal from.
15:41:09 <janscheurich> once the network association is done it should be straightforward to adapt it for router assoc.
15:41:46 <matrohon> janscheurich : the ball on my side so :)
15:42:10 <janscheurich> :-)
15:42:20 <matrohon> I encourage you to keep reviewing https://review.openstack.org/#/c/191944/
15:42:30 <janscheurich> Will try
15:43:03 <matrohon> pc_m is making good progress to converge to single vpnaas framework
15:43:27 <janscheurich> Shouldn't we use that then for BGPVPN?
15:44:12 <pc_m> matrohon: Thanks. Can use input on it for sure.
15:44:49 <matrohon> I keep thinking it would be a interesting option.
15:44:50 <pc_m> matrohon: For endpoints for BGPVPN what will be used?
15:45:04 <pc_m> For IPSec we'll use subnet CIDRs.
15:45:29 <matrohon> pc_m : currently, it's networks, but I don't know what to use instead of uuid....
15:46:17 <pc_m> matrohon: For local then, you use the uuid. For peer, it's dynamic and not specified?
15:46:30 <matrohon> pc_m : in fact in ipsec cases, the key is router+cidr
15:46:34 <matrohon> pc_m : yes
15:47:20 <matrohon> pc_m : with router+cidr you can manage overlaping cidrs in a tenant deployment
15:47:32 <pc_m> matrohon: I think the router could be implied/derived from the CIDR.
15:48:09 <janscheurich> May I bring up one more topic?
15:48:31 <matrohon> pc_m : but the tenant can use the same cidr for different networks, am I wrong?
15:49:12 <pc_m> matrohon: So have the same subnet CIDR used on two different routers?
15:49:25 <matrohon> pc_m : yep
15:49:38 <matrohon> pc_m : I think it's possible, not sure
15:49:41 <pc_m> matrohon: Don't know.
15:50:18 <matrohon> janscheurich : please go ahead
15:51:56 <janscheurich> We have been in discussion with AT&T and they are not satisfied with network/subnet granularity. They would also like to have the option to associate individual Neutron ports with a BGPVPN object, so that ports in the same Network/Subnet could be placed in different VPNs
15:52:42 <janscheurich> This would, of course, break traditional Neutron L2 forwarding semantics
15:53:01 <janscheurich> But they are not concerned about that.
15:53:06 <matrohon> janscheurich : yep, we also had a discussion with AT&T, pcarver included
15:53:49 <matrohon> janscheurich : I think the new API is suitable for that since we can easily have a port_associate API
15:53:49 <janscheurich> What was your conclusion?
15:54:40 <janscheurich> That was my impression as well. It's just the semantics that have to be carefully defined
15:55:05 <janscheurich> And perhaps not all backends will support that.
15:55:07 <matrohon> actaully, that would be quite easy for bagpipe, since it already annouces a /32 for each port
15:55:19 <matrohon> janscheurich: +1
15:55:36 <janscheurich> As most backends do, I'm sure
15:56:04 <janscheurich> How do we handle optionality of *_association in the API?
15:56:37 <matrohon> a framework with extension loadable  by backends would be really suitable for every optional attribute/API
15:56:58 <matrohon> I think it's the good way to introduce the RD optional argument too
15:57:46 <matrohon> such a framework already exist, with ML2 driver able to load their own extensions
15:58:41 <matrohon> https://github.com/openstack/neutron-specs/blob/master/specs/juno/neutron-ml2-mechanismdriver-extensions.rst
15:59:19 <janscheurich> Is that a matter of copy&paste from ML2 or something general support library that can be re-used?
16:00:08 <matrohon> I'm not sure we need the entire ML2 framework, but no, there is no dedicated lib
16:00:46 <janscheurich> Interesting but time's running out
16:01:00 <matrohon> we are out of time, you're :)
16:01:09 <matrohon> you're right!
16:01:28 <matrohon> let's see what is achievable for liberty!
16:01:51 <matrohon> thanks janscheurich, svinota
16:01:56 <matrohon> #endmeeting