09:00:25 <oanson> #startmeeting Dragonflow
09:00:26 <openstack> Meeting started Mon Dec 26 09:00:25 2016 UTC and is due to finish in 60 minutes.  The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:30 <openstack> The meeting name has been set to 'dragonflow'
09:00:38 <oanson> Hello, everyone. Welcome to the weekly Dragonflow meeting.
09:00:45 <dimak> Good morning
09:00:48 <xiaohhui> Hi
09:00:50 <lihi> Hi
09:00:52 <oanson> Raise you hands, say yeah! (If you're here)
09:00:52 <ishafran> Hi
09:01:27 <oanson> #info lihi xiaohhui ishafran in meeting
09:01:34 <oanson> #info dimak is also here
09:01:47 <oanson> yuli_s, nick-ma_, you guys in?
09:02:14 <oanson> All right, let;s get this show on the road.
09:02:18 <oanson> #topic Ocata Roadmap
09:02:23 <oanson> lihi, any updates?
09:02:48 <oanson> (IPv6, that is)
09:02:54 <lihi> I'm still working on the router discovery
09:03:49 <lihi> I have a suspicion that ovs doesn't support it properly. But I'm still checking it
09:04:33 <oanson> If there is an OVS bug, you can report it, or better yet, we can try working on a fix :)
09:04:55 <lihi> OK :)
09:05:09 <lihi> However more comments on the neighbor discovery would be nice :)
09:05:20 <oanson> I also see the Neighbor Advertiser is coming along nicely. Link: http://review.openstack.org/#/c/412337/
09:05:44 <oanson> Next up, NB API refactor
09:06:02 <oanson> dimak had some interesting ideas on the spec. I am still trying to construct something readable of it
09:06:09 <oanson> I hope that will be done today.
09:06:38 <oanson> I understand that dimak already started working on the implementation with jsontools. So that would be interesting to see too.
09:06:45 <dimak> oanson, I think we should have some kind of group discussion once the spec is updated
09:07:19 <dimak> The info is too scattered at the moments
09:07:21 <oanson> If its all right with everyone, lets schedule it for tomorrow, 8:30 UTC? (That's half an hour before this meeting)
09:07:29 <oanson> (If I got my timings correct (: )
09:07:43 <nick-ma_> hi
09:07:52 <dimak> oanson, I have some basic implementation for the proposed idea, I'll upload it as a patch today hopefully
09:08:07 <oanson> #info nick-ma_ is also in meeting
09:08:09 <oanson> nick-ma_, hi :)
09:08:10 <dimak> so anyone interested can examine and play with it
09:08:37 <oanson> irenab, ^^^^ (if you're here)
09:09:14 <dimak> we should try to come up with the order of work items as well, so we can merge the refactor gradually
09:09:15 <oanson> I'll ask her offline later
09:09:47 <oanson> There is a list of work items on the spec. If it's not granular enough, we can try breaking it up further
09:10:31 <dimak> So lets discuss it more in depth tomorrow
09:10:38 <oanson> Sounds good.
09:10:53 <oanson> Anything open on SFC?
09:11:36 <oanson> dimak, ?
09:11:38 <dimak> Have some issues with the MPLS labeling scheme
09:11:55 <oanson> You want to share and consult?
09:12:17 <dimak> Namely, mapping locations in SFC graphs to actual labels
09:12:40 <oanson> What's the issue?
09:13:14 <dimak> The way we though of doing it originally, was using NSH which has fields for chain, hop# and metadata to store some extra info (e.g. what initial classifier we had, to restore port regs/metadata)
09:13:53 <dimak> But with MPLS we have to introduce a mapping Chain#, Hop#, Flow classifier# <=> Label
09:14:20 <dimak> Which means that each change we have to query some extra table and look for vacant labels
09:14:53 <dimak> I am not sure this suits key value stores well
09:15:22 <oanson> That last one doesn't sound too bad. Changes are made on the Neutron Server nodes. And we have an unique key infrastructure we can use
09:15:40 <dimak> Its auto-increment
09:15:53 <dimak> But labels are limited to 20 (+3) bits
09:15:54 <oanson> Is that a problem (for a first implementation)?
09:16:11 <xiaohhui> We can make that to be a allocation-pool
09:16:14 <dimak> We can just ignore it for the moment
09:16:15 <oanson> And labels have to be unique per destination port
09:16:17 <xiaohhui> I meant the unique key
09:16:34 <dimak> oanson, what do you mean?
09:16:36 <oanson> We could, but I don't think we need that now.
09:16:53 <oanson> dimak, the label is used by the destination port on the SF / SFF to decide what to do with the packet.
09:17:17 <oanson> So if we have the same label on different ports, that belong to different SFFs, there shouldn't be a problem
09:17:20 <oanson> Am I right?
09:17:35 <dimak> The key has to be SFF agnostic because ports can move around
09:17:46 <oanson> From one SFF to another?
09:17:55 <dimak> and I don't think we'd like to reallocate labels if ports move
09:17:56 <dimak> yes
09:18:00 <dimak> A vm migrates
09:18:01 <xiaohhui> The unique key for lport might use allocation-pool, as it has the possibility to run out of unique key, if the system runs for a long time.
09:18:33 <oanson> xiaohhui, yes. That's true. We will also want an allocation pool for sNAT addresses
09:19:16 <oanson> dimak, an SFF is also a VM? It's not planned to be done as flows?
09:19:29 <xiaohhui> oanson, that will be my plan in next step to refactor the unique key.
09:19:36 <dimak> SFF is not a vm, its our ovs bridge
09:19:40 <oanson> xiaohhui, very cool!
09:19:51 <dimak> but an SF is a VM
09:20:01 <dimak> so its dest ports can move around
09:20:42 <oanson> dimak, I see
09:21:24 <dimak> oanson, I'll try to resolve it this week
09:21:42 <dimak> Maybe for a first release we'll just ignore 23 bit overflow
09:21:43 <oanson> dimak, sure.
09:22:02 <dimak> then introduce some smart mapping and allocation mechanism
09:22:16 <dimak> Or switch to NSH :)
09:22:18 <oanson> dimak, sounds good. We can cross that bridge when we get to it.
09:22:43 <dimak> (I meant add support along with MPLS :)
09:23:18 <dimak> I hope to upload some initial patches this week although they are still based on the old refactor code
09:23:32 <oanson> The mapping to labels itself can be handled by the db, e.g. a tables 'union(<keys>) <=> label' with cached reverse lookup
09:23:34 <dimak> Hope we can have refactoring done quickly so I can base on it
09:23:39 <yuli_s> For TAPasaService Iren also advised me not to use segment id for tapService from neutron segment pool, but to use other ids,
09:23:43 <oanson> dimak, that's the plan
09:24:04 <oanson> yuli_s, sure. We'll get to that in a minute. Let's finish with SFC first
09:24:04 <yuli_s> if we have a general allocation pool mechanizm I can also reuse it for tap-as-a-service
09:24:28 <oanson> Anything else for SFC?
09:25:01 <dimak> Not for now
09:25:07 <oanson> Great. Tap as a Service
09:25:09 <oanson> yuli_s, now go
09:25:17 <yuli_s> thanks
09:25:18 <yuli_s> For TAPasaService Iren also advised me not to use segment id for tapService from neutron segment pool, but to use other ids,
09:25:21 <xiaohhui> yuli_s, how would you avoid conflict the vni number with tenant network?
09:25:24 <yuli_s> IMHO if we have a general allocation pool mechanizm I can also reuse it for tap-as-a-service
09:25:33 <oanson> yuli_s, why?
09:25:45 <oanson> Why avoid Neutron's segment ID allocation?
09:25:59 <oanson> And if we do, how do we avoid the issue xiaohhui just raised?
09:26:00 <hujie> what about use unique_key for tapService??
09:26:21 <yuli_s> neutron segment pool is used for networks
09:26:22 <oanson> hujie, we may have a conflict with existing VNI's and segment IDs
09:26:36 <oanson> yuli_s, yes.
09:26:59 <hujie> as each tapService refers to a lport, and each lport has its owner unique key
09:27:08 <yuli_s> xiaohhui, it can be done if we assign range that does not coinside with the one used in neutron
09:27:42 <oanson> yuli_s, 1. How do you verify that? 2. I still don't understand why?
09:27:51 <yuli_s> oanson, I suppose this can be done during the stack.sh script
09:28:02 <xiaohhui> Then the configuration should be carefully taken.
09:28:08 <xiaohhui> taken care
09:28:23 <oanson> I don't remember seeing anything like that. Do you have a reference?
09:28:23 <yuli_s> it will assign specific range that will be different that currently used by neutron
09:28:35 <oanson> And it sounds very error prone, and devstack specific
09:29:18 <oanson> yuli_s, please first answer why, then we can discuss how.
09:29:19 <yuli_s> hm
09:29:22 <yuli_s> [ml2_type_geneve]
09:29:22 <yuli_s> vni_ranges = 1:1000
09:29:33 <yuli_s> that what I can in /etc/neutron/plugins/ml2/ml2_conf.ini file
09:29:48 <yuli_s> that what I have in /etc/neutron/plugins/ml2/ml2_conf.ini file
09:30:10 <oanson> Cool.
09:30:16 <oanson> I would still like to know why?
09:30:34 <dimak> is there any metadata we can add to geneve headers to mark this as tap traffic?
09:31:16 <oanson> dimak, IIRC, encapsulation protocols only give you a VNI field to identify the traffic. geneve specifically is variable-width, but e.g. VxLAN is fixed width on (IIRC) 24 bits
09:31:20 <yuli_s> according to Iren network segment pool should be used only for networks
09:31:59 <yuli_s> to distinguish networks
09:32:13 <oanson> irenab, irenab_ , you here to comment?
09:32:28 <yuli_s> and not to distinguish TapServices
09:32:40 <yuli_s> because we can have a lot of TapServices
09:32:40 <xiaohhui> segment means the L2 segment, I don't think it has to be only used for neutron network.
09:32:41 <oanson> yuli_s, we can see a TapService as a (tap) network
09:32:42 <irenab> oanson, sorry, I was at the meeting; was not following the discussion
09:32:59 <dimak> oanson, vxlan gbp also lets you use 16 bit for group policy id
09:33:27 <oanson> irenab, we're discussing why not use Neutron's segment ID allocation for TapService VNI allocation?
09:33:48 <yuli_s> when we have a lot of TapServices it will "eat" resources assigned to networks
09:33:51 <oanson> dimak, but we want to support regular VxLAN too (or am I confused and it's the same protocol?)
09:34:05 <oanson> yuli_s, those VNIs have to come from somewhere anyway
09:34:05 <dimak> oanson, its an extension
09:34:23 <dimak> oanson, it conflicts with vxlan gpe though :(
09:34:29 <irenab> oanson, I raised this concern on the spec.
09:35:03 <dimak> irenab, yuli_s oanson maybe we can allocate a single vni then?
09:35:25 <dimak> and encode the tap id elsewhere?
09:35:26 <oanson> dimak, I don't think so. If you have multiple TapService on the same remote compute node, you will have a collisionb
09:35:55 <yuli_s> single vni is not good from security point of view.
09:36:15 <oanson> irenab, not sure I understand yet why they need to be separate?
09:36:17 <yuli_s> we do not want to mix traffic from different clients / tenants
09:36:18 <dimak> maybe we can use source mac and put it back in the destination
09:36:33 <dimak> if there are several, encode its index too
09:36:45 <dimak> we have 2 extra bytes
09:37:00 <oanson> dimak, we raised the possibly of using src IP last week. But it's... less elegant
09:37:01 <dimak> that 64k macs per source port
09:37:26 <irenab> oanson, admin setups network vnis and expects number of network to be supported
09:37:28 <dimak> oh, sorry, I didn't follow that discussion
09:38:02 <oanson> yuli_s, how is it solved in TAPaaS reference implementation?
09:38:07 <irenab> if we get Tap Service vnis from the same pool, the number of networks will decrease
09:38:20 <yuli_s> oanson, I will check
09:38:41 <oanson> irenab, won't separating them cause a deployment and configuration overhead? Including more pain points?
09:38:54 <xiaohhui> irenab, the segment is associated with network, one network might have multiple segments, so they don't have to be same number
09:39:21 <irenab> oanson, Tap is service, it maybe enabled or not, it can come with its own configuration
09:40:18 <oanson> irenab, yes. But then it is possible there are no free segment IDs for it. All were taken for networks
09:40:50 <irenab> oanson, if its separate pool, this will not happen
09:40:51 <oanson> I guess we could support both options. But that makes things worse :)
09:41:10 <oanson> irenab, I mean the network segment ID pool takes up the entire e.g. 24 bits
09:41:33 <irenab> another question is how the Virtual Topology will look like
09:41:56 <oanson> irenab, what do you mean?
09:42:08 <irenab> oanson,  in ML2 VXLAN driver, admin specifies the ranges to allocate from
09:42:59 <irenab> oanson, TAP Service is port on some neutron network, but it gets another network segment
09:43:00 <oanson> irenab, yes. But he can specify the whole range. He has to know about it TaaS needing VNIs, or modify the range later
09:43:53 <irenab> oanson, tap can fallback to neutron range if there is not dedicated one
09:44:17 <oanson> irenab, that sounds good
09:44:35 <oanson> That's what I mean when I said support both options.
09:44:59 <oanson> Is this acceptable by everyone?
09:45:12 <irenab> oanson, yuli_s But I still do not quite see how Tap Service is prefented in Virtual Topology
09:45:22 <irenab> we can discuss it over spec
09:45:39 <oanson> irenab, I'm sorry, I'm not sure I understand 'Virtual Topology'. What is it?
09:46:06 <irenab> think of Topology view in Horizon
09:46:46 <oanson> I'll admit, I don't remember the last time I was in horizon :)
09:46:59 <irenab> lets take it offline :-)
09:47:00 <oanson> But that sounds like something with the Neutron API, not Dragonflow.
09:47:05 <oanson> irenab, sure
09:47:20 <oanson> Everyone happy with the segment IDs solution?
09:47:51 <oanson> Great. yuli_s, please verify what TAPaaS reference implementation did so that we have a basis for comparison.
09:48:05 <yuli_s> sure
09:48:15 <oanson> Thanks
09:48:27 <oanson> sNAT - ishafran, anything to update?
09:48:41 <ishafran> I am working on POC
09:48:50 <yamamoto> irenab: https://review.openstack.org/#/c/396022/
09:49:01 <ishafran> Facing problem with NAT implementation in OVS
09:49:27 <oanson> yamamoto, thanks
09:49:54 <ishafran> I am going to ask in OVS discuss group regarding this issue
09:50:01 <oanson> ishafran, sounds good.
09:50:41 <oanson> Anything else for roadmap?
09:51:09 <oanson> #topic Open Issues
09:51:14 <oanson> The floor is for the taking
09:51:24 <oanson> Just bring it back when you're done :)
09:51:43 <xiaohhui> I want to present this solution for multi-tenants in topology
09:51:44 <xiaohhui> https://review.openstack.org/#/c/414697/
09:51:56 <xiaohhui> I meant selective topology distribution
09:52:26 <dimak> I'll go over it today
09:52:31 <xiaohhui> There are 2 options, I want to hear your opinions
09:52:37 <xiaohhui> thanks dimak
09:52:42 <oanson> xiaohhui, I'll go over it too
09:52:54 <xiaohhui> thank you too oanson
09:52:58 <oanson> :)
09:53:22 <oanson> Anything else?
09:53:33 <xiaohhui> Nothing from me
09:53:50 <oanson> It's a grade A floor. Only drawback is that it's virtual.
09:54:18 <oanson> All right. Thanks everyone.
09:54:38 <dimak> Good bye!
09:54:44 <yuli_s> thanks !
09:54:44 <oanson> Don't forget tomorrow 8:30 for the NB refactor discussion if you want to join
09:54:53 <oanson> #endmeeting