15:18:22 <tmorin> #startmeeting bgpvpn
15:18:23 <openstack> Meeting started Tue May  2 15:18:22 2017 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:18:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:18:26 <openstack> The meeting name has been set to 'bgpvpn'
15:18:30 <pcarver> hi
15:18:33 <tmorin> hi pcarver
15:20:05 <tmorin> I'm not sure who else may come...
15:20:37 <tmorin> here are the topics I have in mind for today
15:20:52 <tmorin> a) status on feature evolution blueprints
15:20:57 <tmorin> b) rally tests
15:24:23 <pcarver> So on the topic of blueprints, I'm mostly only able to comment from the perspective of use cases that have been discussed in the context of Gluon.
15:24:52 <pcarver> The other features sound good, but I don't have any direct input that AT&T specifically needs them.
15:25:05 <pcarver> At least not at this time. Which is not to say I oppose them.
15:25:56 <tmorin> ok, good to know
15:26:08 <tmorin> I think I will try to progress this as-is
15:26:44 <tmorin> this may trigger more feedback, and if not then we will consider noone objects
15:27:28 <tmorin> I don't exactly know when I will find more cycles
15:27:50 <tmorin> on b) rally,  I simply wanted to mention that a base change has merged
15:28:05 <tmorin> and that another one providing more tests is in flight
15:28:28 <tmorin> https://review.openstack.org/#/c/386418/
15:28:39 <tmorin> and https://review.openstack.org/#/c/460465/
15:30:36 <tmorin> back on a) pcarver:  last week we had unclear conclusions on l3vpn gluon use cases, ni particular on the specific needs around hubnspoke and anycast
15:30:52 <tmorin> pcarver: would you have found out more since last week N
15:30:59 <tmorin> sorry s/N/?
15:32:24 <pcarver> tmorin: I think what I said was that the hub and spoke and anycast use cases have been discussed for quite a while in abstract and I don't know which specific VNFs need them.
15:32:42 <pcarver> I don't think it's that VNFs don't need them. I just don't happen to know which ones.
15:33:22 <pcarver> If I need to find out I can, but I've just been treating them as abstract use cases that one of our senior subject matter experts says are important.
15:34:03 <tmorin> ok
15:34:18 <tmorin> but do you have an idea what may be missing in our current bgpvpn API ?
15:36:44 <pcarver> actually yes, let me dig up the URLs
15:37:08 <pcarver> The OPNFV folks did a gap analysis where they called out the gaps they perceive
15:38:08 <tmorin> ah good
15:38:27 <pcarver> http://docs.opnfv.org/en/stable-danube/submodules/netready/docs/development/requirements/use_cases/l3vpn_ecmp.html#gaps-in-the-current-solution
15:38:39 <tmorin> what that in netready ?
15:38:43 <pcarver> http://docs.opnfv.org/en/stable-danube/submodules/netready/docs/development/requirements/use_cases/l3vpn_hub_and_spoke.html#derived-requirements
15:39:20 <tmorin> ok, interesting
15:39:21 <pcarver> Yes, they are using the OPNFV netready project as a sort of requirements gathering for the Gluon project
15:40:01 <tmorin> L3VPN-ECMP-GAP1 : "static routes" => true, but not related to ECMP/anycast strictly speaking
15:40:25 <pcarver> agreed, not specifically anycast
15:40:48 <tmorin> L3VPN-ECMP-GAP2: I don't think anything is missing, the behavior we get is the one dictated by the underlying routing protocols (said otherwise: we get ECMP/anycast for free)
15:41:26 <pcarver> I think so to, but it might be a case of needing testing to validate that it works as expected and document any edge cases
15:41:27 <tmorin> L3VPN-ECMP-GAP3: not a BGPVPN limitation at all, and also not required for ECMP/anycast
15:41:51 <tmorin> pcarver: on GAP2, yes, but this will be backend specific, not a problem on whether the API supports it or not
15:42:06 <pcarver> I think L3VPN-ECMP-GAP2 is basically saying that it may work but that the API semantics don't guarantee it
15:42:37 <tmorin> thanks for the pointer, that helps understand what is behind this discussion
15:42:48 <tmorin> will you be in Boston ?
15:43:07 <pcarver> L3VPN-ECMP-GAP3 is not a n8g-bgpvpn gap but a gap in the whole Neutron+extension
15:43:22 <tmorin> (I'll have to end this meeting in a few minutes, a bit earlier than the usual time)
15:43:31 <pcarver> If it were addressed in Neutron it could close the gap
15:43:40 <pcarver> Yes, I will be in Boston
15:44:58 <tmorin> GAP3: well yes... we get back to a discussion on whether a Neutron network is a L2/Ethernet network or not... if it is, then the effects of using the same IP twice can be problematic... whether this can be relaxed is a whole discussion in itself
15:45:01 <tmorin> ok
15:45:40 <tmorin> I will be in Boston as well
15:45:57 <tmorin> did I saw your name in the nirvana day agenda ?
15:46:20 <pcarver> tmorin: Yes, I believe we're co-presenting
15:46:27 <tmorin> :)
15:48:04 <tmorin> ok, of course... was out of my mind..; sorry
15:48:06 <tmorin> ok
15:48:15 <tmorin> see you in Boston then !
15:48:21 <tmorin> #endmeeting