05:04:53 <nati_ueno> #startmeeting neutron-advanced-routing
05:04:54 <pedro_r_marques> There was additional interest in the mailing list
05:04:54 <openstack> Meeting started Wed Nov 20 05:04:53 2013 UTC and is due to finish in 60 minutes.  The chair is nati_ueno. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:04:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:04:57 <openstack> The meeting name has been set to 'neutron_advanced_routing'
05:05:05 <nati_ueno> ok
05:05:24 <nati_ueno> https://etherpad.openstack.org/p/NeutronDynamicRoutingIceHouse
05:05:35 <nati_ueno> #info etherpad page https://etherpad.openstack.org/p/NeutronDynamicRoutingIceHouse
05:05:54 <nati_ueno> so one agenda is MPLS VPNs integration bp
05:06:10 <nati_ueno> If you guys have the other agenda, please add it on the etherpad
05:06:33 <nati_ueno> #topic MPLS VPNs integration
05:06:47 <nati_ueno> pedro_r_marques: could you paste the mpls bp on the etherpad and here?
05:07:12 <pedro_r_marques> Will do.
05:07:41 <nati_ueno> pedro_r_marques: Thanks
05:07:56 <pedro_r_marques> https://docs.google.com/document/d/1aVfYHiGrwL7XyE639_sCBkmALy7FKCJqPX8DqiHk7kY/edit
05:08:12 <pedro_r_marques> Can you please verify that the link is accessible.
05:08:36 <nati_ueno> thomas_morin: Actually, we have a discussion on the bp. We simplified existing bgp mpls bp
05:08:45 <nati_ueno> new bp is much more simpler and easy to manage
05:09:23 <nati_ueno> do you guys have feedback on this ?
05:09:47 <thomas_morin> the new bp is the googledocs just lnked by pedro ?
05:09:53 <nati_ueno> yes
05:09:53 <pedro_r_marques> The proposed doc is trying to capture the minimum set of objects necessary to extend a Neutron virtual-network to an L3VPN network
05:10:07 <thomas_morin> I think it's the right direction
05:10:30 <pedro_r_marques> The requirements are: implementation agnostic; admin should be able to manipulate the object independently of the tenant
05:10:30 <nati_ueno> thomas_morin: Thanks
05:10:31 <nati_ueno> OK, may be we should share this in the mailing list and get more feedback.
05:10:32 <thomas_morin> it's good to separate the properties of an external VPN network from the rest
05:10:54 <thomas_morin> one thing we may add, is the type of vpn:
05:10:57 <nati_ueno> "properties of an external VPN network " <-- which properties?
05:11:03 <pedro_r_marques> Nati: would you be willing to incorporate the new text in your BP ?
05:11:31 <thomas_morin> although the primary use of BGP/MPLS VPN today is IP VPNs, it woulc be nice to describe E-VPN as well
05:11:41 <nati_ueno> pedro_r_marques: I'll deprecate my old bp
05:12:08 <thomas_morin> no different properties for E-VPN: same set of properties than IP VPNs
05:12:23 <thomas_morin> nati_ueno: "properties" -> the attributes in the bp
05:12:25 <pedro_r_marques> It already has a set of subscribers. I would prefer to continue the work
05:12:46 <pedro_r_marques> Is it dificult to edit ?
05:12:56 <nati_ueno> E-VPN looks not L3VPN
05:13:05 <nati_ueno> pedro_r_marques: Which one?
05:13:25 <nati_ueno> so may be L3VPNConnection should be BGPVPNConnection ?
05:13:34 <pedro_r_marques> https://wiki.openstack.org/wiki/Neutron/BGP_MPLS_VPN
05:13:36 <thomas_morin> E-VPN protocol architecture is completely similar to the protocol architecture of BGP/MPLS
05:13:44 <nati_ueno> pedro_r_marques: It is easy to edit
05:13:49 <thomas_morin> nati: i think so yes
05:13:51 <nati_ueno> thomas_morin: yes.
05:14:06 <nati_ueno> pedro_r_marques: any thought for BGPVPNConnection?
05:14:07 <pedro_r_marques> thomas: do you have a strong preference to make it a single object ?
05:14:42 <thomas_morin> looks less verbose to have one object with a type, rather than two
05:14:49 <pedro_r_marques> It would be useful to be able to distinguish between l3vpn and evpn connections
05:14:51 <thomas_morin> but appart from that I don't care
05:15:16 <nati_ueno> it looks like easy to understand if we have l3vpn and evpn
05:15:20 <pedro_r_marques> one may want to connect one address family but not the other... e.g. evpn may not make sense beyound the DC
05:15:22 <thomas_morin> ok
05:15:55 <pedro_r_marques> for instance in the OpenContrail implementation inside the DC both l3vpn and evpn are turned on by default
05:16:04 <thomas_morin> ok for me : one resource for l3vpn and another one for evpn
05:16:06 <pedro_r_marques> but the user would probably not want to extend evpn
05:16:27 <nati_ueno> any way, let's have separate bp for evpn
05:16:27 <pedro_r_marques> OK. We can add two types that look the same...
05:16:37 <nati_ueno> let's have a small step
05:16:49 <thomas_morin> one question: what is the network-id field exactly ?
05:16:49 <pedro_r_marques> no objection.
05:16:59 <pedro_r_marques> The neutron network uuid
05:17:22 <pedro_r_marques> i.e. one attaches the connection object to the network to connect it...
05:17:52 <pedro_r_marques> Nachi's requirement is to be able to have different permissions on network and l3vpn-connection
05:18:05 <thomas_morin> what if you want to connect the L3VPn to more than one neutron network ?
05:18:28 <pedro_r_marques> You can add multiple connection with same route-target
05:18:29 <nati_ueno> thomas_morin: we can create multiple L3VPN with same route-target
05:18:40 <pedro_r_marques> perhaps as export-only
05:18:50 <nati_ueno> The other way is to use service-context
05:18:51 <thomas_morin> but who creates the connections ?
05:19:11 <nati_ueno> thomas_morin: it's depends on deployment
05:19:22 <thomas_morin> e.g. it wouldn't be good to require the admin to create a connection each time a tenant want to bind a neuton network to the external vpn
05:19:26 <nati_ueno> some carrier has OSS for L3VPN
05:19:26 <pedro_r_marques> The neutron apis would be l3vpn-connection-create/list
05:19:48 <nati_ueno> so we have a way to use service-insersion-context
05:19:56 <nati_ueno> in that we can specify multiple networks
05:20:02 <thomas_morin> binding a neutron network and external network could be done by a second resource
05:20:10 <pedro_r_marques> most likely the "connection-create" command would have to be either issued by admin or verified by it.
05:20:37 <nati_ueno> yes
05:20:44 <pedro_r_marques> thomas: the connection object's job is only to connect the network outside
05:20:57 <pedro_r_marques> the network could be an l3vpn inside (like contrail) or not
05:21:16 <thomas_morin> i would think it preferable to have an API letting the admin create an L3VPN object, give access to it to a tenant, and then let the tenant bind it to neutron networks later, as it wishes, as many times etc, through another API
05:21:31 <pedro_r_marques> A network implementation could be using a gateway to connect a neutron network implemented via other mechanism
05:21:47 <nati_ueno> thomas_morin: I agree. so we can hide route-target value, then let's tenant update network id
05:22:20 <pedro_r_marques> thomas: we can provide for that workflow... if admin creates a network called "External" with an l3vpn-connection that works
05:22:26 <thomas_morin> well, we would also need to let the tenant *add* network-ids
05:22:44 <pedro_r_marques> The tenant can later on connect its internal networks to that network... via network-policy or a VPC router
05:22:47 <nati_ueno> thomas_morin: good point
05:23:11 <nati_ueno> I'm start thinking to use service-insersion-context is right way
05:23:14 <pedro_r_marques> If the network already exists and tenant asks admin to connect it to a WAN network; the object also allows for that workflow
05:23:39 <thomas_morin> I link the idea of using service-insertion or the policy API to bind neutron network to external network
05:23:57 <pedro_r_marques> nati: can you provide link to service-insertion ?
05:24:23 <nati_ueno> pedro_r_marques: sure
05:24:37 <pedro_r_marques> thomas: in the OpenContrail implementation we do today deploy service VMs between internal networks and external networks.
05:24:59 <thomas_morin> pedro: your idea is not bad, but what if the tenant mistakenly delete the network that's bound to the external network ?
05:25:03 <pedro_r_marques> The external network is defined as a neutron network plus additional route target information
05:25:09 <nati_ueno> #link https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
05:25:16 <nati_ueno> you can access bp from the link
05:25:51 <pedro_r_marques> thomas: that is not an issue necessarily... the tenant is allowed to bring down its configuration
05:26:34 <thomas_morin> pedro: sure, but if the API let's the user shoot himself in the foot, it may be a sign we don't have the right API yet ;)
05:26:38 <pedro_r_marques> service-insertion is complementary to l3vpn
05:26:54 <pedro_r_marques> thomas: tenant can destroy a VPC for instance
05:27:04 <pedro_r_marques> That allows it to tear down all networks
05:27:22 <pedro_r_marques> l3vpn connection should not imho be tied to service-insertion
05:27:29 <thomas_morin> the issue is whether or not the tenant can rebuild the setup to access the external VPN network
05:27:33 <pedro_r_marques> service-insertion should work between networks.
05:28:09 <pedro_r_marques> thomas: one can fail a delete request if objects are still associated to it
05:28:24 <pedro_r_marques> e.g. network that has an l3vpn-connection can have its deletes refused
05:28:36 <pedro_r_marques> that would be the behaviour of for instance the contrail plugin
05:28:47 <pedro_r_marques> It doesn't let objects before orphan
05:29:37 <thomas_morin> if we can have a way to make "read-only" the neutron network associated to the L3VPn connection, then it's good
05:29:38 <pedro_r_marques> service-insertion is very useful; it is used without an l3vpn external network and vice-versa
05:30:02 <pedro_r_marques> thomas: the plugin implementation has a lot of latitude here...
05:31:13 <thomas_morin> pedro: agreed ; we could go a step furthet and make it a mandatory behavior
05:31:33 <nati_ueno> it looks like we should clearly usecase including admin workflow
05:32:10 <pedro_r_marques> we can modify the BP and add that... network delete should be rejected as long as there is a ref from l3vpn-connection
05:32:21 <thomas_morin> yes, the use case should describe what the admin does and what the tenant does
05:32:31 <pedro_r_marques> Nati: there are several potential workflows... i agree the more documentation the better
05:32:36 <thomas_morin> pedro: yes
05:33:05 <nati_ueno> then we can have concrete api discussion
05:33:12 <pedro_r_marques> My assumption would be that most carriers would not let the tenant configure the route target...
05:33:27 <nati_ueno> pedro_r_marques: yes
05:33:32 <thomas_morin> yes
05:33:52 <pedro_r_marques> but for instance the service-insertion would be controlled by the tenant
05:33:59 <nati_ueno> sorry going to offline 5min
05:34:13 <pedro_r_marques> example: blue_external is WAN connected network for tenant blue
05:34:39 <pedro_r_marques> This tenant may want to have direct access to this network by spawning VMs on it or using floating ip
05:35:00 <pedro_r_marques> Or may wish to deploy a NAT appliance between the DC's internal networks and this blue_external net
05:35:23 <thomas_morin> yes
05:35:32 <pedro_r_marques> it is also valid to have: admin creates blue_external; tenant creates blue external and asks admin to create connection
05:35:58 <thomas_morin> this would be valid, but possibly not interesting I would say
05:36:20 <pedro_r_marques> In general i feel pretty confident on the API; better use case documentation is needed
05:36:28 <pedro_r_marques> Nati: what are the action items ?
05:37:12 <nati_ueno> let's write down use cases
05:37:40 <pedro_r_marques> do you want me to take a stab at capturing some of these... ?
05:37:58 <nati_ueno> I'll add our usecase
05:38:01 <pedro_r_marques> Thomas do you have some i left out ?
05:38:04 <nati_ueno> thomas_morin: could you add yours?
05:38:16 <nati_ueno> pedro_r_marques: could you work on general one?
05:38:47 <pedro_r_marques> Action items: 1) Nati incorporate l3vpn-connection API into BP
05:39:00 <pedro_r_marques> 2) create EVPN blueprint (who ?)
05:39:01 <nati_ueno> #action Action items: 1) Nati incorporate l3vpn-connection API into BP
05:39:13 <nati_ueno> pedro_r_marques: EVPN could be future work
05:39:23 <pedro_r_marques> 3) use case text from nati, pedro, thomas...
05:39:27 <pedro_r_marques> ok then drop 2)
05:39:33 <nati_ueno> #action (2) use case text from nati, pedro, thomas...
05:39:33 <thomas_morin> sorry pedro, what did you already add to the bp ?
05:40:19 <pedro_r_marques> thomas: https://wiki.openstack.org/wiki/Neutron/BGP_MPLS_VPN is to be simplified with text from the google docs link
05:40:35 <thomas_morin> E-VPN can be future work, sure, but adding it is as easy as saying that the EVPNConnection resource has same properties as the L3VPNconnection
05:40:53 <pedro_r_marques> in addition there needs to be better description of use cases...
05:41:24 <pedro_r_marques> thomas: nati seems to be of the opinion that a separate document would be a more productive approach
05:41:31 <nati_ueno> action 1 is finished https://wiki.openstack.org/wiki/Neutron/BGP_MPLS_VPN
05:41:51 <nati_ueno> let's work on action2
05:41:58 <nati_ueno> Do you have any more agendas ?
05:42:18 <pedro_r_marques> nope.
05:42:33 <nati_ueno> OK let's continue discussion on the bp
05:42:46 <pedro_r_marques> ok.
05:43:03 <nati_ueno> #endmeeting