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