15:01:15 <tmorin> #startmeeting bgpvpn
15:01:16 <openstack> Meeting started Tue Dec 15 15:01:15 2015 UTC and is due to finish in 60 minutes.  The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:19 <openstack> The meeting name has been set to 'bgpvpn'
15:01:29 <matrohon> hi all
15:01:32 <Sam-I-Am> hi
15:01:39 <tmorin> hi matrohon doude enikher timirnich
15:01:45 <tmorin> hi Sam-I-Am
15:01:46 <enikher> hey
15:02:32 <Sam-I-Am> another meeting before coffee
15:02:36 <Sam-I-Am> living on the edge here
15:02:56 <matrohon> I've updated the agenda
15:03:09 <matrohon> https://wiki.openstack.org/wiki/Meetings/BGPVPN
15:03:30 <matrohon> We are very proud to annouce that the first release of bgpvpn is out
15:03:45 <matrohon> #link : https://pypi.python.org/pypi/networking-bgpvpn
15:04:00 <tmorin> tagged 3.0.0
15:04:32 <tmorin> we are very happy of all the work done together to achieve that !  :-D
15:05:43 <matrohon> let's start by the documentation topic so that Sam-I-Am can drink its coffee
15:05:47 <Sam-I-Am> hahaha
15:05:49 <Sam-I-Am> pleeeeeeze
15:06:01 <tmorin> go ahead :)
15:06:06 <tmorin> #topic documentation
15:06:12 <Sam-I-Am> thanks
15:06:29 <Sam-I-Am> short story - bgpvpn needs docs so people can deploy it in real environments
15:06:40 <tmorin> by the way: hi pcarver
15:06:41 <Sam-I-Am> its a fairly complex feature
15:06:47 <janscheurich> Hi
15:06:52 <matrohon> hi janscheurich
15:06:52 <tmorin> pcarver: the topic above is related to your suggestions
15:06:58 <tmorin> hi janscheurich
15:07:04 <Sam-I-Am> my suggestion would be implementing a deployment scenario in the networking guide
15:07:18 <matrohon> Sam-I-Am, +1
15:07:23 <pcarver> tmorin: sorry, on a voice conf call. will need to scroll back and read
15:07:24 <tmorin> (we've just announced that our release happened: https://pypi.python.org/pypi/networking-bgpvpn)
15:07:46 <tmorin> pcarver: nothing to scroll back yet, we are just starting
15:08:09 <Sam-I-Am> the most basic multi-node architecture on which someone can deploy bgpvpn, try it out, and determine how to deploy it in their specific environment
15:08:23 <tmorin> pcarver: Sam-I-Am suggestion is close to what you had proposed to do in Tokyo, right ? (if I recall correctly)
15:08:33 <Sam-I-Am> #link http://docs.openstack.org/networking-guide/deploy.html
15:08:35 <matrohon> Sam-I-Am, should we get inspired by guides for features such as VPNaas
15:08:51 <Sam-I-Am> matrohon: vpnaas needs docs too
15:09:06 <Sam-I-Am> theres lots of things without good docs and thats what keeps people from using them
15:09:18 <Sam-I-Am> neutron has seen a significant adoption after the networking guide scenarios
15:09:43 <Sam-I-Am> in the case of vpnaas, the guide would have something like "add vpnaas to these basic scenarios"
15:09:58 <pcarver> tmorin: I was going to revise the API documentation, but I got distracted by an ongoing effort of the documentation team to change how API docs are done. I hadn't talked about the networking guide, but that's absolutely a good idea. BGPVPN networking scenarios should be included in the networking guide.
15:09:58 <Sam-I-Am> so people can add features to something they're already familiar with
15:10:15 <tmorin> sam-i-am: would you have kickstarting info on where to doc the work (which repo to contribute to) and which tooling to use (e.g. anything particular for figures ?)
15:10:45 <Sam-I-Am> the repo is openstack-manuals and we use sphinx/rst
15:10:58 <pcarver> The issue with the API docs is that there's a migration effort going on that I don't completely understand. It seems to be about generating API docs from the code, but I don't quite understand the how.
15:11:08 <janscheurich> Would the example deployment be based on bagpipe reference driver?
15:11:24 <Sam-I-Am> i've done most of the diagrams in omnigraffle (because they look nice) but you can use whatever as long as its clear and i can convert them as time allows
15:11:26 <pcarver> The docs team is focussed on first migrating from their current format (which isn't RST, it's something else I forget)
15:11:38 <Sam-I-Am> janscheurich: yes, because OVS is in the ref arch
15:11:50 <Sam-I-Am> pcarver: docbook/xml is almost long gone
15:11:55 <tmorin> janscheurich: we have to cover the reference driver, but this does not exclude covering the other driver/backend options
15:11:57 <Sam-I-Am> the networking guide never used docbook
15:12:46 <pcarver> Sam-I-Am: agreed. separate issue
15:12:58 <Sam-I-Am> tmorin: right now the networking guide only support refarch stuff because we've found third-party stuff doesnt receive much love. in the case of ODL, the ODL documentation should include how to implement bgpvpn with ODL.
15:13:00 <pcarver> I hadn't talked about updating the networking guide, but agree it should be done
15:13:29 <Sam-I-Am> pcarver: its the place operators go for docs
15:13:36 <pcarver> I was talking about updating the API reference, which is currently RST for BGPVPN, but WADL for most of OpenStack
15:13:38 <Sam-I-Am> devref is scary and usually oriented toward devstack
15:13:46 <Sam-I-Am> pcarver: ohhhh, the api docs
15:13:59 <Sam-I-Am> pcarver: yeah... those are moving too, but at a slower pace
15:14:38 <matrohon> Sam-I-Am, so we should add a new bullet for our advanced service in the deployment scenario chapter?
15:14:41 <pcarver> The docs team is currently migrating WADL to something called Swagger and there seems to be something about generating API docs from code, but I don't think they've quite got it entirely figured out yet
15:15:26 <Sam-I-Am> matrohon: yeah, i think this belongs in advanced services and would include a deployment scenario that builds on one of the OVS scenarios if possible
15:15:45 <Sam-I-Am> pcarver: yeah thats it. i stay out of api docs, but they are pretty far out of date because of the complexity :/
15:16:09 <Sam-I-Am> matrohon: i'm guessing site-to-site vpn requires a few more components in the architecture
15:16:31 <matrohon> Sam-I-Am, let's start by population the "advanced srevices" section for bgpvpn
15:16:39 <pcarver> Sam-I-Am: It would be great if we could generate API docs direct from code, similar to how CLI help is generated from comments in code, but I don't think the instructions on how to do that have been written yet.
15:16:46 <Sam-I-Am> matrohon: is bgpvpn part of vpnaas?
15:17:05 <Sam-I-Am> pcarver: have you spoken to anne gentle? i think she's working on that
15:17:22 <matrohon> Sam-I-Am, for the moment it's a seperated effort
15:17:58 <Sam-I-Am> matrohon: same concept though?
15:18:10 <Sam-I-Am> one uses ipsec the other uses AS numbers?
15:18:40 <pcarver> Sam-I-Am: I exchanged a few emails and she shared a few links, but I couldn't quite figure it all out and it looked to me like the links she shared were in a pretty early state.
15:19:01 <Sam-I-Am> pcarver: bleh :/
15:19:03 <pcarver> She referenced a couple of tools that seemed to be very early development
15:19:10 <matrohon> Sam-I-Am, only the VPN word is similar, in the context of bgpvpn cloud admin and tenants can't create VPNs
15:19:10 <Sam-I-Am> well, someone needs to do the api doc updates
15:19:12 <Sam-I-Am> as much as it sucks
15:20:28 <pcarver> Sam-I-Am: I still have API doc updates for BGPVPN on my todo list.
15:20:31 <Sam-I-Am> matrohon: probably makes sense to write up some differences between the various vpn options
15:21:09 <pcarver> Sam-I-Am: I can just update RST if nothing else seems possible, but I was hoping that given a bit of time the OpenStack-wide strategy would become clearer.
15:21:24 <Sam-I-Am> matrohon: particularly catering to people who have used them in non-cloud scenarios (like ISPs)
15:21:43 <Sam-I-Am> for example, i've used bgp vpns at an isp, but need to know how they relate to cloud
15:22:04 <matrohon> Sam-I-Am, makes sense
15:23:07 <matrohon> Any volunteer to wirite a bgpvpn section in the networking guide?
15:23:11 <Sam-I-Am> matrohon: can this be entire self-contained or does it require an existing bgp vpn?
15:23:24 <matrohon> it requires existing bgpvpn
15:23:40 <Sam-I-Am> matrohon: hmm, makes it tough to test
15:23:44 <matrohon> the API is usefull to attach neutron components to an existing bgpvpn
15:24:27 <Sam-I-Am> hmm
15:24:40 <matrohon> Sam-I-Am, you need a bgp peer to talk to
15:25:24 <Sam-I-Am> matrohon: ok, so looks difficult for us to test
15:25:33 <Sam-I-Am> which is important...
15:26:31 <tmorin> Sam-I-Am: you can still do a bit of testing without a real router
15:26:32 <Sam-I-Am> matrohon: would it make sense to provide a way to simulate it enough to validate any scenario?
15:26:35 <matrohon> Sam-I-Am, the networking guide team is testing everything written in the guide?
15:26:40 <tmorin> Sam-I-Am: that's what we do for development
15:26:50 <tmorin> Sam-I-Am: we test VM-to-VM connectivity via a BGP VPN
15:26:59 <Sam-I-Am> matrohon: we try to... because it significantly reduces frustration for our audience
15:27:14 <matrohon> Sam-I-Am, great!
15:27:19 <tmorin> Sam-I-Am: this not the most illustrative way to describe the target use-case though....
15:27:51 <Sam-I-Am> well, we might need two things
15:28:04 <Sam-I-Am> one - "heres how you can get your brain around this in a lab"
15:28:11 <Sam-I-Am> two - "heres how you deploy this in real life"
15:28:22 <tmorin> Sam-I-Am: yes, that would make sense
15:28:40 <Sam-I-Am> networking is a pain point for most openstack operators
15:28:50 <Sam-I-Am> they want to do X, but the solutions for X are complex
15:29:01 <Sam-I-Am> sometimes they can't even find them (due to lack of docs)
15:29:12 <Sam-I-Am> most of the vpn stuff falls into this category
15:29:17 <Sam-I-Am> i'd like to fix that :)
15:29:59 <Sam-I-Am> tmorin: do you have docs for this test case arch?
15:30:48 <tmorin> Sam-I-Am: you mean for "(one)" ?   no...
15:30:58 <tmorin> Sam-I-Am: although this is rather short to expain
15:31:02 <janscheurich> If we want to go beyond intra-DC VM-VM communication, and there is no chance of having an external BGP speaker (DC Gw), could we have a back-to-back scenario between two DCs?
15:31:19 <Sam-I-Am> tmorin: yeah for (one)
15:33:55 <Sam-I-Am> hmmm
15:34:16 <Sam-I-Am> i've simulated bgp vpns using agents on linux/bsd. would doing any of this help people understand the use cases?
15:35:28 <matrohon> Sam-I-Am, this can also be done by bagpipe, and I think it helps understanding the use case
15:35:44 <Sam-I-Am> matrohon: oh, thats cool
15:35:57 <Sam-I-Am> i definitely think understanding the use case is good for the audience
15:36:04 <Sam-I-Am> networking is hard. :/
15:36:14 <tmorin> Sam-I-Am: to have a working test scenario for people to play with, bagpipe can be used as a bgpvpn implementation, but openbsd bgpd's can also do this I thikn
15:36:30 <matrohon> Sam-I-Am, expecially when we try to explain VPNs
15:36:35 <Sam-I-Am> tmorin: yeah i've used openbsd's stuff
15:36:44 <tmorin> Sam-I-Am: I know openbsd bgpd does the bgp routing part (I tested it), but I haven't played with openbsd mpls stack
15:37:24 <Sam-I-Am> tmorin: if nothing else, the scenario can do this -
15:37:39 <tmorin> Sam-I-Am: it would be nice to document how to test net-bgpvpn with bagpipe on compute nodes, and openbsd bgp/mpls on another box emulating a router with a few bgp/mpls VRFs
15:37:57 <Sam-I-Am> tell people "this example assumes your provider offers the following:" and then write the bgpvpn config to talk to that "something"
15:38:25 <Sam-I-Am> tmorin: yeah that would be nice
15:38:57 <Sam-I-Am> any way to make this easier is helpful... and providing a way to configure it that actually works
15:39:21 <tmorin> Sam-I-Am: in fact, that would rather be "this examples assumes you are a network operator supporting BGPVPNs and that openstack compute nodes peer with a BGP/MPLS router"
15:39:59 <Sam-I-Am> tmorin: sure. and bagpipe handles this on the compute nodes?
15:40:05 <tmorin> Sam-I-Am:yes
15:40:16 <Sam-I-Am> ok, i think we're getting somewhere here
15:40:25 <tmorin> Sam-I-Am: my point is that  it is very uncommon to have a DC/cloud operator allowed to exchange BGP VPN routes with its ISP
15:40:41 <Sam-I-Am> tmorin: makes sense
15:41:14 <Sam-I-Am> so even if the config example only includes the openstack bits, the diagrams and traffic flow can contain a example ISP components
15:41:30 <tmorin> Sam-I-Am: yes
15:41:35 <Sam-I-Am> lets go with that
15:41:49 <Sam-I-Am> whatever is the most common use-case
15:42:03 <Sam-I-Am> or if there's more than one
15:42:38 <matrohon> ok let's move on
15:42:46 <Sam-I-Am> tmorin: can you (or someone here) add a spec to docs-specs for this?
15:42:52 <Sam-I-Am> as an action item
15:44:05 <matrohon> #action : matrohon to create a spec in doc-specs to populate the networking-guide for bgpvpn use cases
15:44:19 <pcarver> tmorin: It may be uncommon, but it doesn't necessarily have to be. We have a whole service built around it and other providers could if they wanted to.
15:45:18 <tmorin> pcarver: yes, I can guess, and we have scenarios as well, but this is not the typical thing to document to help people get a clear picture of what they can expect from their ISP
15:45:22 <pcarver> We have a partnership with at least 4-5 different cloud providers to offer our MPLS VPN WAN to their customers via an API driven interface. It's just not an OpenStack standard mechanism.
15:47:16 <matrohon> topic : backport status?
15:47:34 <tmorin> pcarver: yes, but my point is that the documentation should say clearly upfront that in most cases, Internet ISPs don't provide this option, in which case what the BGVPN service plugin provide is probably not relevant to the cloud operator
15:48:20 <astupnikov> excuse me guys, just read your discussion and have a suggestion about use cases. Maybe it will be a good option for ISP to provide computing resources to his existing BGPVPN customers?
15:48:45 <pcarver> tmorin: sure, agreed. If someone isn't using an MPLS service provider directly (internal cloud) and isn't using a public cloud provider that offers MPLS as a service then BGPVPN project isn't relevant to them.
15:48:55 <matrohon> astupnikov, that's probably the main use case, right
15:49:16 <Sam-I-Am> tmorin: so who would be using these docs? the DC? ISP? seems like whomever deploys the compute nodes... but there's some interaction with openstack via the api.
15:49:24 <tmorin> astupnikov: yes, this is the most typical/simple use case, in this case the cloud operator is a BGPVPN operator as well
15:50:20 <pcarver> Sam-I-Am: I see the big use case as internal cloud, someone who is building their own OpenStack based cloud and also has a pre-existing MPLS provider for their pre-cloud WAN connectivity.
15:50:36 <tmorin> Sam-I-Am: the most typical users are (a) the cloud operators inside an ISP doing BGPVPNs and (b) a cloud operator working with an BGPVPN operator (like pcarver's company or ours)
15:50:59 <Sam-I-Am> pcarver tmorin so i'm playing the "dont have a clue" angle here... i'm someone who want to implement openstack, but have this bgpvpn service i'd like to leverage.
15:51:06 <tmorin> pcarver: agreed, internal cloud as well for an operator already having BGPVPNs (typical NFV use case)
15:51:49 <Sam-I-Am> i see that openstack supports bgpvpn... and need to figure out how to make it work with my environment.
15:52:03 <pcarver> Sam-I-Am: If someone doesn't already have an MPLS based WAN (either service provider or customer of an MPLS provider) then they probably don't care about this project
15:52:07 <tmorin> Sam-I-Am: if you "want to leverage it", it means you probably know the technology well, and the implications about who works on the BGP/MPLS router side, and essentially care about the Openstack side
15:52:15 <tmorin> pcarver: +1
15:52:34 <Sam-I-Am> pcarver: yeah, we'd assume they have one... and to tmorin's point... understand how it works
15:52:38 <Sam-I-Am> its just the openstack side
15:52:59 <Sam-I-Am> trying to convert openstack to conventional networking theory is difficult for many people
15:53:05 <Sam-I-Am> ovs, linuxbridge, iptables... its confusing for many
15:53:17 <Sam-I-Am> namespaces, oh my
15:54:47 <tmorin> so explaining that requires going into details specific depending on the driver/backend
15:55:12 <tmorin> for the bagpipe driver, working with the openvswitch mech driver, a good description is
15:55:31 <tmorin> ... the diagram at: http://docs.openstack.org/developer/networking-bgpvpn/bagpipe/index.html
15:57:16 <Sam-I-Am> ok
15:57:20 <Sam-I-Am> i'll do a bit of reading too
15:57:46 <Sam-I-Am> try to work on a docs spec that appeals to the people who would want this feature
15:57:51 <Sam-I-Am> sorry for consuming your meeting :/
15:58:03 <matrohon> 3 min left
15:58:06 <Sam-I-Am> things without docs dont launch well :/
15:58:06 <tmorin> Sam-I-Am: don't be, this is a useful discussion
15:58:07 <matrohon> 2 actually
15:58:16 <tmorin> #topic kilo backport
15:58:25 <tmorin> work is ongoing on the kilo backport
15:58:37 <tmorin> wdeclercq backported router-association support
15:58:45 <tmorin> I'm working on bagpipe driver backport
15:58:55 <tmorin> this one isn't merged yet
15:59:09 <tmorin> having it work will require a clean kilo branch for networking-bagpipe
15:59:19 <matrohon> this should be the last commit before a potential release?
15:59:26 <tmorin> I'd say so
15:59:31 <tmorin> assuming everything works
15:59:53 <matrohon> doude is currently working on juno backport
16:00:16 <tmorin> having a clean kilo branch for networking-bagpipe isn't trivial, because the branch had been named stable/kilo at the time, and each commit needs to go through folks in neutron-stable-maint
16:00:22 <matrohon> I think we should wait for the kilo release and then rebase changes on juno
16:00:33 <matrohon> ok
16:00:37 <matrohon> it's time
16:00:41 <tmorin> mestery has reviewed all of them today, but it seems we need someone else's +2
16:00:46 <tmorin> yes
16:00:50 <tmorin> thanks everyone !
16:00:56 <tmorin> #endmeeting