15:03:41 <tmorin1> #startmeeting bgpvpn
15:03:41 <openstack> Meeting started Tue Jul 28 15:03:41 2015 UTC and is due to finish in 60 minutes.  The chair is tmorin1. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:45 <openstack> The meeting name has been set to 'bgpvpn'
15:03:55 <tmorin1> hi everyone
15:04:11 <tmorin1> hi svinota pcarver doude matrohon
15:04:19 <svinota> hi!
15:04:20 <matrohon> hi
15:04:26 <janscheurich> hi
15:04:29 <pcarver> hi
15:04:29 <tmorin1> hi jan
15:04:35 <doude> hi
15:05:16 <tmorin1> are we waiting for anyone else ?
15:05:35 <tmorin1> doesn't seem so
15:05:41 <tmorin1> #topic API
15:05:53 <tmorin1> we have a few items to close on the API
15:06:12 <tmorin1> first it the API URIs/JSON for the associations
15:06:16 <tmorin1> matrohon ?
15:06:24 <matrohon> ok
15:06:41 <matrohon> so this concern the association
15:07:13 <matrohon> the current proposal for the URI doesn't seem reasonnable regarding the neutron framework
15:07:41 <matrohon> I still have to dig into the framework to have a better idea of what is doable
15:08:16 <janscheurich> Is it a problem to follow the API model used for router interfaces?
15:08:30 <matrohon> but it seem we have to choose between an "action" URI : associate/disassociate_network
15:09:05 <matrohon> janscheurich : this first proposal whould lead to the model used for router interfaces
15:09:38 <tmorin1> janscheurich: the issue is not specific to router association, same issue for network association
15:09:59 <janscheurich> Understood
15:10:23 <matrohon> but the fact is that with the model used for router interfaces doesn't include the network uuid at the end of the URI
15:10:25 <tmorin1> as I understand, if we have an association in the URI, what follows must be an association uuid, and can't be a BGPVPN uuid
15:10:39 <matrohon> tmorin1 : +1
15:11:21 <matrohon> this lead to the second proposal which is to have a network/router_association object with an UUID
15:11:52 <tmorin1> and the network/router uuid as json data
15:11:59 <matrohon> and the action would be driven by the POST/PUT/DELETE operation on this object
15:12:30 <matrohon> tmorin : +1 in both cases, the  network/router would be in the json data
15:12:39 <tmorin1> yes
15:13:55 <janscheurich> Sounds doable but looks a lot like normalized relational database design. Good for machines but hard for humans
15:14:48 <tmorin1> janscheurish: hard, I don't know, but more bookeeping/db work for sure
15:16:28 <janscheurich> I haven't seen other places in Neutron APIs where associations are modeled with explicit objects having their own UUIDs.
15:16:31 <matrohon> this might lead to a dedicated table
15:16:56 <matrohon> janscheurich : this is done in lbaasv2
15:17:28 * matrohon : seeking a link
15:18:40 <matrohon> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/extensions/loadbalancerv2.py#L315
15:19:48 <tmorin1> I would tend to opt for the associate/disassociate_network approach, with the BGPVPN uuid in JSON data
15:20:15 <matrohon> the corresponding uri would be  : /lbaas/pools/{pool_id}/members/{member_id}
15:21:23 <matrohon> I don't have a strong preference, so option 1 is fine for me : associate/disassociate_network approach
15:21:25 <pcarver> matrohon: This sort of URL makes sense to me, but I can't offer any input on what can be done under the hood in Neutron's API handling
15:21:59 <pcarver> If LBaaS can do it, then I think it makes sense for BGPVPN to do it the same way
15:22:55 <tmorin1> the sub-resource approahc like in LBaaS makes sense if we want to have others attribute to a router or network Association
15:23:40 <tmorin1> but if we don't, then I'd rather go the simpler path similar as what is done in Neutron for router interfaces (with add_router_interface/remove_router_interface)
15:24:11 <tmorin1> in LBaaS members have their own attributes, so their approach makes sense
15:24:25 <tmorin1> but in our case, associations don't have attributes
15:24:59 <tmorin1> unless we want attributes later...
15:25:10 <matrohon> I tend to agree; if we don't nedd to fine manage the association, let's use the action URI
15:25:13 <janscheurich> I think a LBaaS Pool Member is an object that has a meaning on the API level. I'm not sure we could argue the same for the association between a Router/Network and a BGPVPN
15:25:36 <janscheurich> +1 for the action API
15:26:11 <tmorin1> janscheurich: agreed, but we thus make the assumption that we won't want to give attributes to associations
15:29:05 <tmorin1> ok, lets not fully close the door, but let's assume we'll opt for the action URI approache
15:30:11 <tmorin1> approach
15:30:20 <tmorin1> next topic then ?
15:30:39 <tmorin1> #topic static routes in the API
15:30:39 <matrohon> If anybody has some use cases that needs the association object, please ping me, we can still come back to the 2nd approach
15:30:52 <tmorin1> matrohon: agreed
15:31:33 <tmorin1> janscheurich has identified the need for being able to have static routes pointing to Neutron ports
15:31:45 <tmorin1> that would result in the corresponding route to be advertised in a BGP VPN
15:31:59 <janscheurich> Have you seen the new blueprint and Etherpad I created?
15:32:00 <tmorin1> I fully agree that its important to have in the toolbox
15:32:22 <tmorin1> #link https://blueprints.launchpad.net/bgpvpn/+spec/static-routes
15:32:24 <tmorin1> yes
15:32:27 <tmorin1> thanks for creating one
15:32:30 <matrohon> janscheurich : yep, thanks for that
15:32:56 <tmorin1> thanks also for the summary of options at #link https://etherpad.openstack.org/p/bgpvpn_static_routes
15:33:34 <janscheurich> Any immediate comments/suggestions?
15:33:36 <tmorin1> after giving some thinking, I'm thinking that this is very close semantic to what allowed_address_pair is doing
15:34:04 <tmorin1> in fact, if we wanted to allow this now based on allowed_address_pair, we could without any new API call
15:34:38 <tmorin1> allowed_address_pair means: this Neutron port is allowed to send traffic with a source IP in prefix X
15:35:08 <tmorin1> if we assume bidirectional traffic, this means X is reachable through that Neutron port
15:35:58 <tmorin1> my suggestion would be to start by saying that, in the presence of allowed_address_pair the Neutron BGPVPN service would advertise the said prefixes so that the traffic to these prefixes ends up forwarded to that port
15:36:13 <janscheurich> I have been searching for an explanation of allowed_address_pair and its intended use. Do you have any pointers?
15:37:23 <tmorin1> and, if we later find we want a semantic distinct from allowed_address_pair (eg. because we'd want something non bidirectional) we would work on a Neutron generic way of having static routes pointing to Neutron ports independent of the notion of Router / that would have to be discussed with the whole neutron community and would not be specific to BGPVPN
15:37:33 <tmorin1> janscheurich: let me try to find one
15:38:03 <janscheurich> The fact that it is part of the base Neutron Port API indicates that this is old and may be superseded by other security mechanisms such as Neutron Security Groups and Rules.
15:38:22 <tmorin1> #link http://specs.openstack.org/openstack/neutron-specs/specs/api/allowed_address_pairs.html
15:38:33 <tmorin1> but I guess everyone had it already ;)
15:38:51 <matrohon> allowed_addr_pair is firstly made for vrrp, to disable ip anti spoofing rules
15:39:10 <matrohon> which would be need for your feature too
15:40:04 <matrohon> but it doesn't play with SG AFAIK
15:40:09 <tmorin1> janscheurich: I don't believe so, sec groups control what goes to a port, and for egress to where traffic goes, but does not look at source addressess of traffic coming from a port
15:41:01 <janscheurich> OK thanks
15:41:28 <tmorin1> I don't think this has been superseded
15:41:46 <tmorin1> there was a recent fix in the OVS agent related to allowed_address_pair
15:42:17 <tmorin1> e.g. https://review.openstack.org/#/c/194741/
15:42:20 <tmorin1> #link https://review.openstack.org/#/c/194741/
15:42:29 <matrohon> janscheurich : what kind of implemention do you consider for the static route feature with bgpvpn?
15:43:21 <janscheurich> tmorin1: Wouldn't the fact that BGPVPN does routing between Network/Subnets outside of the Neutron Router also be hard to swallow by the Neutron community?
15:44:10 <tmorin1> janscheurich: can't tell yet, but how related to static routes ?
15:44:49 <matrohon> janscheurich : +1, which makes hard to overcome the constraint on the current extra route extension
15:44:54 <janscheurich> Implementation: Static routes are inserted into the L3 FIBs and exported through BGP, with the same MPLS label as used for the connected /32 route to the Neutron port.
15:45:44 <janscheurich> In our ODL L3-VPN implementation the addition of static routes to the VPN seems straightforward.
15:45:44 <tmorin1> janscheurich: the fact is that Neutron router could also leverage allowed_address_pair additionally to extra_routes
15:45:58 <tmorin1> janscheurich: +1, in bagpipe driver too
15:46:37 <matrohon> janscheurich : ok, but I mean do you consider a new extension, and do you prefer to leverage existing extensions (allow_addr_pair, extra_route...)?
15:46:55 <janscheurich> matrohon: What constraints on the current extra route extension?
15:47:28 <matrohon> janscheurich : the one you mention on the etherpad
15:47:42 <janscheurich> I think the extra-route extension on the Router should just work in BGPVPN when the Router is associated to the VPN
15:47:55 <tmorin1> janscheurich: +1, I agree with that
15:48:27 <tmorin1> janscheurich: we just need to determine what to do for Network assocations
15:49:10 <janscheurich> I just realized: Allowed address pairs are not sufficient. Think about a static default route!
15:49:41 <tmorin1> janscheurich: allowed_address_pair does allow to specific a 0/0 prefix
15:50:45 <janscheurich> OK, I didn't see the CIDR in the description and all examples just had full IP addresses
15:51:05 <tmorin1> janscheurich: yes
15:51:32 <matrohon> I recently discovered that CIDR was usable too with allow_addr_pair :)
15:51:41 <janscheurich> have you ever played around with allowed address pairs?
15:52:34 <tmorin1> would we agree on giving some thought to the allowed_address_pair option and try to cover other topics before the end ?
15:52:42 <tmorin1> janscheurich: no
15:53:24 <tmorin1> janscheurich: but it is for sure needed to let traffic through in the case of static routes (even if we end up expressing static routes in a different way)
15:53:24 <matrohon> the best that I know is the l2pop issue with this feature : https://bugs.launchpad.net/neutron/+bug/1445089
15:53:26 <openstack> Launchpad bug 1445089 in neutron "allowed-address-pairs broken with l2pop/arp responder and LinuxBridge/VXLAN" [Undecided,Confirmed] - Assigned to yalei wang (yalei-wang)
15:53:26 <uvirtbot> Launchpad bug 1445089 in neutron "allowed-address-pairs broken with l2pop/arp responder and LinuxBridge/VXLAN" [Undecided,Confirmed]
15:53:27 <uvirtbot> Launchpad bug 1445089 in neutron "allowed-address-pairs broken with l2pop/arp responder and LinuxBridge/VXLAN" [Undecided,Confirmed] https://launchpad.net/bugs/1445089
15:54:01 <janscheurich> I agree the automatic export of allowed address pairs as static routes in a VPN would be elegant, but I am a bit concerned because the Neutron Router doesn't seem to do that, and we would get very different behavior of the system depending on the whether the Router or Network association model is chosen.
15:54:52 <tmorin1> janscheurich: I understand your concern, but a the same time, we know we will have something different for netwokr associations that the Neutron router does not use...
15:55:39 <tmorin1> (and nothing prevents from proposing that Neutron routers leverage allowed_address_pairs additionally to static routes, by the way)
15:56:30 <janscheurich> What about allowed address pairs that specify also a MAC address?
15:56:31 <tmorin1> can we decide to not decide now ? ;)
15:56:55 <tmorin1> janscheurich: I guess we would only take into account the ones that specify an IP prefix
15:57:08 <tmorin1> well, for l3 bgpvpn at least
15:57:22 <tmorin1> l2 bgpvpn could leverage the MAC addresses
15:57:28 <janscheurich> Sure: Let's continue the discussion in the Etherpad. But I would at least like to sketch an additional alternative that avoid the re-interpretation of allowed_address_pairs
15:58:01 <tmorin1> janscheurich: agreed, but let's try not to do something that would be alien for the rest of Neutron...
15:58:12 <tmorin1> #topic API, VXLAN VNID
15:58:18 <tmorin1> not much time to discuss
15:58:29 <janscheurich> extra-routes on a BGPVPN should be acceptable, or not?
15:59:27 <tmorin1> I don't know, they could collide with the routes defined on a Router if a Router is associated to the BGPVPN
15:59:32 <tmorin1> maybe that is an issue to consider
15:59:37 <janscheurich> Sure
16:00:01 <tmorin1> I think that if we do something new, we should also try to make it reusable with other Neutron components
16:00:11 <tmorin1> VPNaaS could have a similar use for it
16:00:17 <tmorin1> ditto for service chaining stuff
16:00:25 <matrohon> janscheurich : you mean we should look at extra_routes defined for the associated router and export them in the attach bgpvpn
16:00:44 <tmorin1> which is why I'd rather use allowed_address_pairs, if that can work, as an initial first step
16:01:15 <janscheurich> Yes, that's for sure. I was suggesting to add a similar extra-routes attribute to the BGPVPN object itself
16:02:05 <tmorin1> janscheurich: but that would not be reusable by the rest of Neutron
16:02:42 <tmorin1> jansheurich: if we go for something new, I'd rather look at an option like a extension driver for aPort or Network
16:02:50 <tmorin1> s/aPort/Port
16:03:21 <tmorin1> ok, we are out of time
16:03:32 <tmorin1> let's pursue the discuss in the etherpad
16:03:40 <janscheurich> OK
16:03:54 <tmorin1> #topic other
16:04:17 <tmorin1> Just wanted to mention we are merging first contrib by svinota
16:04:25 <tmorin1> API change for RDs
16:04:28 <tmorin1> thanks svinota
16:04:33 <svinota> tmorin1, thanks
16:04:38 <tmorin1> I mean merging soon, not yet done :)
16:05:14 <svinota> :)
16:05:16 <tmorin1> I also updated jenkins jobs to avoid some breakage on dependencies
16:05:28 <tmorin1> ok, we should free the room I guess
16:05:52 <tmorin1> matrohon will drive the meetings the following weeks
16:06:00 <matrohon> ok
16:06:30 <tmorin1> ok, bye everyone !
16:06:33 <janscheurich> Bye then
16:06:36 <matrohon> bye
16:06:49 <tmorin1> #endmeeting