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