18:00:54 #startmeeting networking_policy 18:00:55 Meeting started Thu Aug 11 18:00:54 2016 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:58 The meeting name has been set to 'networking_policy' 18:01:12 #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#Aug_11th.2C_4th.2C_July_21st_2016 18:02:01 #topic Quality of Service support via NSPs 18:02:10 amitbose: hi 18:02:14 igordcard: there? 18:02:15 hemanthravi: hi 18:02:19 hi 18:02:22 hi 18:02:42 just wanted to quickly address any pending issues that igordcard might be having with his patch (in case he is around) 18:03:20 probably not 18:03:26 i have commented on his patch 18:03:28 moving on 18:03:52 patch btw is #link https://review.openstack.org/#/c/301701 18:04:12 #topic L3-Policy mapping to Address Scope & Subnetpool 18:04:18 #link https://review.openstack.org/#/c/343929 18:04:36 rkukura: thanks for the review comments, (and amitbose thanks for your review earlier as well) 18:05:05 rkukura: i saw your main comment earlier in the morning, and then noticed a few more comments just a few minutes back 18:05:33 one main issue, and several minor ones 18:05:37 rkukura: i think your more recent comments are mostly aligned with your main comment L181 18:05:43 right 18:05:48 rkukura: yeah so lets go over that 18:06:03 others, please do chime in 18:06:15 the main issue is with the 1-to-mainy mapping to subnetpools 18:06:22 rkukura: right 18:06:40 rkukura: so the requirement there is not purely for prefix scaling purposes 18:06:41 It doesn’t seem necessary, and might add signficiant complexity 18:06:54 rkukura: i agree it adds complexity 18:07:35 rkukura: but there are use cases where you would need to associate explicitly associate subnetpools (as opposed to modifying existing subnetpools) 18:07:37 in particular, I’m worried about how this plays with neutron’s requirement that all subnets on a network come from the same subnetpool, if any of them are from a subnetpool 18:08:22 rkukura: so the requirement is to be able to associate one or more subnetpool resources, and not just add prefixes 18:08:34 rkukura: isn't the requirement that they come from the same address scope? 18:08:39 I’m not sure I see why adding a new subnetpool is ever preferable to adding a prefix to an existing subnetpool 18:08:48 rkukura: does it have to be the same subnetpool? that's odd 18:09:00 On a network, it has to be the same subetpool 18:09:13 rkukura: i believe you are only looking at the scaling use case 18:09:13 I’m not sure about on a router, but I expect that to be based on address_scope 18:09:36 I am not sure what other use cases apply 18:09:45 scaling being needing more subnets, I think 18:09:50 I guess visibility is another concern 18:10:08 rkukura: however, the user might be explicitly creating the subnetpool 18:10:22 ivar-lazzaro: yeah, the l3p sharing use case 18:10:32 Sure, the user can explicitly create a subnetpool and use it to create an L3P 18:10:33 amitbose was pointing out that earlier as well 18:11:04 the l3p is shared and each tenant creates its own subnetpool and associates with the l3p 18:11:09 with a single shared VRF, you still might want to limit the subnets for each tenant 18:11:13 I vaguely recall some use cases being mentioned in discussion, which I didn’t quite undertand at the time, but I don’t see any of this in the spec 18:11:45 So why is it necessary to share an L3P but not share the subnetpool? 18:11:49 rkukura: okay, i will add a sentence on that use case to clarify 18:11:52 which could be accomplished by looking at the subnetpool ownership/sharing 18:12:16 rkukura: ^^ 18:12:30 Do we really need that complexity? 18:12:37 rkukura: why would you force the subnetpool to be shared? 18:12:48 I think that is the use case, whether or not it can really be accomplished is to be evaluated 18:12:51 If you need to share it, share the L3P 18:12:59 If you don’t need to share it, don’t share the L3P 18:13:09 doesn't seem really complex does it? You have a space of non overlapping IPs between your tenants 18:13:25 pretty much like having overlapping_ips set to false 18:13:40 but you still need each tenant to use the assigned subnet 18:14:04 In Neutron you would do that by having a shared AS 18:14:13 and private SP 18:14:16 First, if we do need multiple subnetpools in an L3P, they would have to have the same AS, and therefore no overlap 18:14:17 does it make sense? 18:14:20 I'm not convinced if having multiple subnetpools is adding too much complexity, but it does allow us to address more use-cases 18:14:44 rkukura: right, they would have to be the same AS 18:14:47 Why not just have each tenant have a non-shared L3P, with all of these sharing an AS? 18:15:10 rkukura: you might want to run cross-tenant traffic without NAT 18:15:17 at least that's my guess 18:15:42 in any case, I think we should at least be able to accomodate these use cases 18:15:52 meaning that we could still have a list of subnetpools 18:15:58 but limit to 1 for now 18:16:16 rkukura: the requirement is to be able to share the construct at the GBP resource level 18:16:20 so that we can remove the constraint once we see fit without breaking compatibility 18:16:24 rkukura: i am referring to the l3p 18:16:41 Maybe some of the semantics we have on L3P should be moved to AS 18:16:46 (but I agree with the _v4 _v6 comment) 18:17:11 rkukura: for somebody purely driving the GBP workflow, the fact that AS is shared is not even visible, unless the L3P is shared 18:17:31 ivar-lazzaro: v4 and v6 separation is also not that big of a deal 18:17:42 ivar-lazzaro: it probably looks more cleaner 18:17:58 ivar-lazzaro: but there is hardly any extra computation cost if its a single list 18:18:04 The _v4, _v6 thing is a more minor issue 18:18:14 we will be filtering based on the address_scope id 18:18:30 SumitNaiksatam: yeah, that's the kind of thing that becomes easily incompatible once you release the driver... So we probably want to make sure we take the right decision right away 18:18:35 rkukura: but i can make that change if it looks more cleaner from an API perspective 18:19:09 What really bothers me is that we will require some set of SPs to have the same AS, but neutron allows the SP->AS association to be mutated at will 18:19:27 rkukura: that is separate issue 18:19:31 And we will also require the L3P to be associated with that same AS 18:19:38 which needs to be addressed, regardless of subnetpool list or no 18:19:45 *not 18:20:10 If we have a single SP we theoretically don't care about the AS 18:20:18 for SPs already associated with an L3P we will have to in some way disallow update of AS 18:20:21 It just seems much cleaner to me to say that an L3P has exctly one SP for each family, and 18:20:22 but I'm very nervous about taking this route and be burned later 18:20:33 the AS is whatever that SP points to 18:20:36 I'd rather get the model right, and maybe limit the length of that list to 1 18:21:37 rkukura: at the neutron model level that is the only change, but it will not be as trivial for the backend because things will have to be rewired to change the AS mapping 18:21:38 I’m just not (yet) convinced that a list of SPs is the right model 18:21:45 rkukura: which may or may not be possible 18:22:03 rkukura: how would you solve the use case we discussed above with the current model? 18:22:12 We need to handle updates to a SP’s AS for neutron 18:22:19 rkukura: so when the update to the SP happens, GBP would have to interpose anyway 18:22:48 we might say we won't support those, but it seems a bit risky considering we already have users that have a big single shared VRF 18:22:49 Is the use case that you somehow want multiple tenants to have different SPs but share an L3P/AS? 18:23:04 rkukura: right 18:23:21 So why do the different tenants need their own SPs? 18:23:25 Each tenant has different subnets assigned. But they are in the same VRF to allow cross traffic when needed 18:23:58 I agree if they are sharing the L3P/AS, they will be sharing the VRF 18:24:10 I’d just like to understand why they can’t also share the SP? 18:24:28 rkukura: because he who design the network is not the same as who run the applications 18:24:51 also, address space separation is good to avoid a tenant to be too noisy 18:24:58 Why would ether of thee care which SP some tenant uses? 18:24:59 rkukura: so that one tenant does not use the other tenants IPs? 18:25:03 without necesserely enforcing quotas 18:25:30 the SPs do enforce quotes, based on individual IPs for v4 and based on /64 spaces for v6 18:25:49 SumitNaiksatam: that is already enforced by using the same shared VRF 18:26:04 I see two main advantages: 18:26:26 ivar-lazzaro: how is it enforced by using the same shared VRF?? 18:26:28 - 1) Accounting traffic by IP 18:26:48 SumitNaiksatam: using the same VRF you can't have overlapping IPs. even if you have one single shared SP 18:27:01 ivar-lazzaro: i am not talking about overlapping IPs 18:27:10 2) slice the subnets to prevent a tenant from growing too much 18:27:32 ivar-lazzaro: my question to rkukura was more rhetorical 18:28:02 Oh ok, I misinterpreted 18:28:38 I guess rkukura question is more like "why would anyone care about which tenant uses which subnet" 18:28:58 given a shared routing domain 18:29:17 ivar-lazzaro: good points 18:29:19 basically the summary is that we want to be able to cleanly separate the applications (and the subnets they use) in a shared address space 18:29:25 Regarding ivar-lazzaro’s 2), I’m not sure I understand this. If the tenant owns any SP, they can always add new prefixed to it. Only quotas prevent them from doing that. 18:29:51 rkukura: can they? even if created by an admin? 18:29:51 I’m not even sure the quote prevents them from adding the prefix, just from allocatiing subnets 18:30:04 but even if they can, other tenants won't run out of IPs 18:30:12 and to support the range of use cases that fall under this category, association to a list of SPs seems like the right thing to model 18:30:14 If the admin creates it using the tenant’s tenant_id, its the same as if the tenant created it 18:30:20 because they already have their allocated slice 18:30:35 So what about the fact that SPs cannot be mixed on a network? 18:30:38 so you would be able to grow, but not to "invade" 18:31:05 ivar-lazzaro: i like the use of “invade” ;-) 18:31:06 How is the user supposed to know which of this list of SPs is even being used for the L2P they want to use? 18:31:38 rkukura: that is a good point 18:31:44 rkukura: isn't that covered via resource visibility? 18:32:09 ivar-lazzaro: in this case the user would see the other SPs as well 18:32:16 ivar-lazzaro: but wont be able to use them 18:32:21 If the SPs are not marked as shared, doing a "show" on the L3P would only list the ones you can have access to 18:32:25 Do we even know whether neutron prevents the prefixes within one SP from overlapping with the prefixes in another SP when the two SPs share an AS? I suspect the enforcement is at subnet allocation instead, but could be wrong. 18:32:27 how? 18:32:52 Every non-admin query is filtered by ownership or shareability 18:33:02 AFAIR 18:33:05 ivar-lazzaro: because there is no resource visibility being enforced on the SPs’ list attribute when you do a show on the L3P 18:33:46 So each user of the shared L3P sees different results for the same attribute? I’d think they would see the IDs, but not be able to show the resource the ID identifies. 18:33:48 SumitNaiksatam: I see what you mean, that's because those values are loaded by the L3P join 18:34:05 rkukura: it does prevent it by spec 18:34:12 rkukura: not sure if it's actually implemented 18:34:33 ivar-lazzaro: Prevent prefix overlap within an AS? 18:34:37 rkukura: yeah 18:34:42 ivar-lazzaro: i dont know of a way to enforce that with the current policy.json mechanism 18:34:58 That's why I believe we should limit the list to 1 right now 18:35:03 we know there are valid use cases 18:35:13 but we need to get the implementation right 18:35:30 except that the implementation can be changed later, the model is a bit trickier 18:35:32 ivar-lazzaro: you are probably suggesting that this filtering can be done in the “make_dict”? 18:35:56 Given the flexibility, I’m sure we’d find use cases that can take advantage of the flexibiltiy. But the question I have is whether these same use cases can be solved better by other means. 18:36:29 rkukura: if that is an open ended question, i think we have to go with an approach that readily solves those use cases 18:36:56 rkukura: how would you address those cases with a single SP? 18:37:31 rkukura: I'm ok even with just having a plan, ad long as we know that we won't need to come back and break the model compatibility 18:37:33 I’d use quotes to address hording 18:37:57 what about accounting? 18:38:04 rkukura: “hording”? 18:38:10 I’m not sure if subnetpool prefixes are ever really the best/only solution for accounting, but maybe 18:38:12 even though that's not the right word 18:38:27 "accounting"... It's more like IP identity 18:38:46 oh you mean “quotas to address hoarding”…nevermind 18:38:58 We can certainly map the individual ports to tenants 18:39:02 hoarding is what I meant 18:39:17 accounting is more of a commercial term I guess, what I mean is for an operator to be able to know the identity of the traffic by looking at the IP 18:39:40 rkukura: ivar-lazzaro: i would prefer to not rat hole into the quotas/hoarding/invading/accounting discussion 18:39:44 (with IPv6, sometimes they even do that by host) 18:39:58 since the separation of concerns seems like a more prominent use case to me 18:40:09 the accounting aspects are probably implementation specific 18:40:19 some support might be currently available and some might not be 18:40:46 but that discussion side steps the sharding paradigm concerns 18:40:57 I think I just misused the word accounting 18:41:15 sharding -> sharing 18:41:40 but what I meant is that the operator can identify the tenant generating traffic by just looking at the source IP 18:41:45 I’m not going to -2 the spec based on this one-to-many mapping to SPs. I’m not comfortable with it, and would rather start simple if possible, but if you guys are confident it is implementable and useful, I’m don’t have any evidence to prove you wrong 18:42:19 rkukura: isn't limiting the list to "1" simple enough to start? 18:42:29 rkukura: 1-1 is restrictive and leads to a incompatible change down the line 18:42:42 we stay on the safe side as far as the model is concerned, but we keep the implementation simple 18:42:51 1-many is less restrictive though we dont have to implement from get-go (stating the obvious) 18:42:55 I think it's a win-win 18:43:58 To me, the key thing is that we don’t introduce potential inconsistencies that we then have to figure out how to enforce. Even just storing both the AS and a single SP in the DB leads to those potential inconsistencies. 18:45:04 rkukura: I thought that wasn't too hard to enforce for a single SP, but I might be wrong 18:45:06 rkukura: i will make it explicit in the spec that for a SP associated with a L3P, you should not be changing the AS association 18:45:06 If we were really confident a single SP per address family per L3P would suffice, then I’d argue we don’t store the AS explicitly, and don’t have to worry about maintaining consistency. 18:45:30 rkukura: we will try to enforce this as well, but the details of that wont be part of this spec 18:45:32 In neutron, you are allowed to change the SP/AS association. 18:45:58 rkukura: but you can validate this using a gbp mechanism driver 18:46:12 which will probably be needed down the line anyways 18:46:14 rkukura: yes you are, and you can change the association for SPs not associated with an L3P 18:46:42 I’d prefer that we just live with that and have the L3P reference a single SP per AF, and use that SP’s AS (if there is one). But clearly we don’t have concensus on this. 18:47:18 rkukura: but i feel you are leaning to towards 1-many :-P 18:47:33 the model rkukura is proposing is definitively easier to manage and implement... But I'm really worried about the lack of flexibility 18:47:44 I’ve convinced myself I’m not going to convince either of you ;) 18:48:04 yes, its easier to implement with one SP 18:48:30 what does everyone feel about modeling separate lists for v4 and v6 SPs? 18:48:44 versus just having one list? 18:48:47 would that be possible to not include the AS as long as we limit the SPs to 1? 18:49:13 once the request arise, would that be even possible to change the current model to add the AS id? 18:49:27 probably not, it would require special migration for the existing AS 18:49:40 I’d suggest we define the AS attribute in the API, but not store it in the DB 18:49:54 ivar-lazzaro: i believe there is a requirement up front to be able to create L3P with an explicit AS (everything else is implicitly created) 18:50:13 So you can create an L3P passing in an existing AS and a prefix, et.c 18:50:14 etc. 18:51:01 SumitNaiksatam: yeah but we could read that dynamically. However, the moment we need to manage multiple SPs we would need to "fix" that attribute 18:52:23 rkukura: you cannot lazily create SPs unless you store the AS in the DB (at least in the explicit AS case) 18:53:31 ivar-lazzaro: i am saying, the user provides an explicit AS and not SP 18:54:05 Do we plan to create the SPs lazily? Assuming a shared AS that enforces non-overlap between prefixes, it would seem we would need to create the SP immediately to validate it. 18:54:45 rkukura: right 18:54:50 rkukura: i havent completely thought through, but by not persisting the AS, we completely take away that option 18:55:16 rkukura: also what happens if the last SP is deleted 18:56:05 time check - we have 5 mins 18:56:09 We are running short on time, and I’ve said my piece, so I am happy to leave it up to SumitNaiksatam to decide which approach to take, and I will support that. 18:56:38 my earlier question - “: what does everyone feel about modeling separate lists for v4 and v6 SPs?” 18:56:50 SumitNaiksatam: +1 for that 18:56:53 +1 18:57:12 okay so separate lists 18:57:45 so i will respin a new version of the spec in line with the discussion here and address rkukura’s other comments 18:57:50 man that was quick 18:57:57 sounds good 18:58:16 rkukura: ivar-lazzaro amitbose thanks for the passionate engagement on this! ;-P 18:58:18 covered the whole agenda ;) 18:58:30 #topic Open Discussion 18:58:40 I'm here now 18:58:45 we havent had open discussion for a while 18:58:51 ah igordcard right on cue 18:59:07 igordcard: let me know if you have furhter problems with your patch, we can touch base offline 18:59:08 yeah I arrived a few mins ago but wasn't waiting for the open 18:59:30 there was some other issue with the exercise but I'm now on vacation 18:59:41 I will further look into it in a couple weeks is that okay? 18:59:53 igordcard: sure np, enjoy your vacation 19:00:03 thanks 19:00:03 alrighty thanks everyone for joining today! 19:00:10 bye! 19:00:13 adieu! 19:00:22 bye bye 19:00:24 thanks SumitNaiksatam 19:00:25 bye 19:00:27 #endmeeting