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