17:03:13 <cathy_> #startmeeting service_chaining
17:03:13 <openstack> Meeting started Thu Aug 20 17:03:13 2015 UTC and is due to finish in 60 minutes.  The chair is cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:17 <openstack> The meeting name has been set to 'service_chaining'
17:03:26 <georgewang> hi
17:03:28 <cathy_> hi everyone
17:03:29 <LouisF> hi
17:03:31 <pcarver> hi
17:03:34 <mohankumar_> Hi Everyone !
17:03:36 <Swami> hi
17:03:38 <Brian___> hi
17:03:39 <maxklyus> hi
17:03:45 <abhisriatt> hi
17:04:09 <vikram_> hi
17:04:12 <johnsom_> o/
17:04:29 <cathy_> today I have two topics to discuss. one is the review of the spec and codes including the insertion type. the other is the encap format
17:04:36 <cathy_> any other topic?
17:05:07 <cathy_> ok let's start with the first topic
17:05:19 <cathy_> #topic review of the spec and codes
17:05:38 <cathy_> Here is the link to review
17:05:49 <cathy_> #link https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc+branch:master+topic:networking-sfc,n,z
17:07:08 <cathy_> The API spec has been ope for review for over 4 weeks. Now let's discuss the insertion/network type and reach consensus. Then I think it is ready for merge.
17:07:47 <cathy_> I see Vikram and Paul's comment.
17:08:13 <cathy_> The network type is per SF. That is, different SF could have different network types.
17:08:33 <pcarver> within the same chain?
17:08:38 <cathy_> We cna not predict what types of SFs a chain will have
17:09:06 <cathy_> pcarver: yes.
17:09:10 <pcarver> ok
17:09:11 <LouisF> pcarver: the may  be a mix of SFs in the same chain
17:10:08 <cathy_> So we need to associate this network type with a SF's port pair, not with a chain
17:11:14 <cathy_> This network type is a attribute of a SF. SF could be provided by different vendors and could be of different types.
17:11:18 <vikram_> can it have a default value?
17:11:58 <cathy_> we do not know the default value since it is decided by the design/funcitonality provided by the SF vendor of the SF
17:12:09 <cathy_> we do not know the default value since it is decided by the design/funcitonality provided by the SF vendor
17:12:19 <abhisriatt> what does “networy type” mean here? any example?
17:13:07 <cathy_> abhisriatt: network type means whether it is a L2 or L3 type SF or bump in the wire type
17:13:27 <abhisriatt> cathy_: Got it.
17:13:35 <cathy_> The Switch's behavior will be different when forwarding the flow packet to different types of SF
17:14:24 <cathy_> We have gone through these exercise in the data plane and found out that we need this network type specification in order for the data plane work properly
17:14:59 <cathy_> So does everyone agree with adding this attribute to the port pair?
17:15:04 <LouisF> +1
17:15:38 <Brian___> +1
17:15:45 <LouisF> i will change the name from insertion_type to network_type in the API doc
17:15:46 <georgewang> +1
17:15:46 <pcarver> +1
17:15:52 <abhisriatt> +1
17:16:13 <mohankumar_> cathy_ : +1.. if we dont other way to handle it !
17:16:31 <cathy_> #agree add network_type attribute to the port pair in the API
17:18:13 <s3wong> sorry, late. 101N was terrible
17:18:13 <cathy_> Could everyone go to the review links for all the spec and codes and either give your +1 or your comments. I am going to ask the Neutron PTL to approve it if no more major comments? They have been open for review for quite some time.
17:18:32 <cathy_> s3wong: No. Thanks for joining
17:18:53 <cathy_> Now let's go to second topic
17:19:17 <cathy_> #topic data path encap format
17:20:11 <cathy_> Here is the link to the encap format which abhisriatt and I have put. Let's walk through them and see if any questions
17:20:17 <cathy_> #link https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
17:21:25 <cathy_> abhisriatt: I see that you change the destination mac at the source VM's OVS. right?
17:21:58 <abhisriatt> cathy_:right.
17:22:35 <cathy_> What type of SF are you assume is running on VM2?
17:22:39 <abhisriatt> cathy_:we have open flow rules on that host’s ovs to modify the destination mac.
17:23:23 <cathy_> abhisriatt: Yes, I understand that. My question is whether we need to modify the destination mac.
17:24:16 <cathy_> If the SF is L2 type, then there seems no need to modify the destination mac, but if it is L3, then yes we need to modify the destination mac otherwise the L3 SF will drop the packet
17:25:29 <cathy_> For L2 type, the SF itself has L2 capability and can figure out how to forward the packet properly based on mac learning. Just think about when forwarding a packet to a L2 Switch, we would not need to modify the destination mac to be the switch's mac
17:25:41 <abhisriatt> cathy_: we modified the mac to make sure that the packet is steered to the SF node, instead of going to the destination.
17:26:05 <abhisriatt> we didn’t assume anything as far as SFs are concerned.
17:26:38 <abhisriatt> We are still using Openstack’s GRE tunnels without creating any additional tunnels.
17:27:28 <cathy_> OK, I see. Let me go through your flow again
17:27:47 <LouisF> abhisriatt:   so in step 4 in your diagram you set DMAC to M4 when sending packet to VM2
17:28:31 <abhisriatt> LouisF: DMAC is set to M4 at step 2.
17:29:00 <abhisriatt> step 4 is just carrying the same packet. At step 4, GRE tunnels will be stripped at br-tun, and the packet is delivered to VM2.
17:30:00 <cathy_> abhisriatt: OK, I think your flow format is good. But I will go through it after the meeting.
17:30:32 <LouisF> abhisriatt: that means flow on node 1 must be aware of MAC on node 2?
17:31:24 <abhisriatt> LouisF: Yes. we build that information graph as soon as we receive the SF request.
17:31:30 <cathy_> I guess other people might need more time to go through it and we can continue reviewing the flow format after the meeting.
17:31:40 <LouisF> abhisriatt: since you set DMAC = M4 on node 1
17:31:41 <abhisriatt> cathy_ : sure.
17:32:39 <cathy_> Another option is to change the destination mac on OVS 2 instead of OVS1. What do you think?
17:33:22 <abhisriatt> cathy_: Yes. But how would packet be routed to OVS2 to make that happen. If mac is not modified, the packet would have gone to OVS3.
17:33:23 <cathy_> Since the OVS is programmed by OVS driver, we can choose how to program it.
17:33:41 <cathy_> The outer header will make it to OVS2
17:34:12 <abhisriatt> cathy_: The underlying GRE tunnels do the MAC learning. In that case, you have to flush the existing rules and create handcrafted rules.
17:34:44 <abhisriatt> cathy_: that would also affect the routing of other flows classes not part of SF.
17:35:17 <cathy_> abhisriatt: I think you are right.
17:36:00 <abhisriatt> cathy_: with this approach, we can rely on the underlying openstack networking to do all the work.
17:36:46 <cathy_> abhisriatt: let me think about this more and we can discuss this further in next meeting. And other folks could have time to think about it and bring their input/comments
17:37:02 <abhisriatt> cathy_: sounds good.
17:37:04 <cathy_> abhisriatt: Agree
17:37:13 <abhisriatt> cathy_:yes.
17:37:29 <mohankumar_> cathy_: okay
17:39:15 <s3wong> cathy_: need to digest the diagram first
17:39:19 <cathy_> abhisriatt: My original thought is same as yours and the diagram I sent you has the same flow format as yours. But later I feel some problem. Now I need to think about this again.
17:39:26 <cathy_> s3wong: sure
17:39:39 <cathy_> Any other topic ?
17:39:45 <pcarver> I have a topic
17:40:04 <cathy_> pcarver:OK
17:40:29 <abhisriatt> cathy_:”But later I feel some problem” — which encapsulation method are referring to?
17:40:59 <pcarver> Do we know what the expectation is for packaging and deployment? I mean we're making some changes to existing components such as the OvS agent and neutronclient. How would we expect that this gets deployed?
17:41:12 <cathy_> The one you posted. But now I think yours is correct. Let me think about it after the meeting and get back to you
17:41:39 <cathy_> pcarver: god question
17:41:56 <pcarver> Does this have to get merged back into Neutron before it's practically available?
17:41:57 <abhisriatt> cathy_:sure. sounds good.
17:42:20 <pcarver> Or do we have some notion of how someone would deploy Neutron and then additionally deploy networking-sfc
17:42:22 <cathy_> We will follow similar mechanism done for DVR or other Neutron approved sub-project
17:42:58 <Swami> cathy_: DVR was part of neutron
17:43:17 <cathy_> I need to do some investigation or ask Kyle/Armando or other core member on this.
17:43:35 <s3wong> how is it done for l2gw?
17:43:37 <pcarver> this big tent thing is new
17:43:54 <cathy_> pcarver: yes, it is new. Let me ask Kyle on that
17:44:00 <pcarver> I was going to post to the mailing list to see if there's a general view on how it should work
17:44:06 <cathy_> s3wong: yes, L2GW is an example
17:44:22 <cathy_> or dragonflow sub-project
17:44:39 <cathy_> AFAIK dragonflow will be release in Liberty
17:45:17 <cathy_> Swami: welcome back! do you know how other sub-project is packaged and released, deployed?
17:45:38 <Swami> Swami: no I don't know
17:46:09 <pcarver> It seems to me that somehow there has to be a code merge
17:46:34 <pcarver> If we're making copies of existing Neutron components into the networking-sfc repo
17:46:52 <pcarver> If we only used inheritance or APIs then it would be different
17:46:53 <s3wong> l2gw seems to be using ovsdb instead of extending existing ovs agent; nevermind
17:47:25 <pcarver> but I believe we're actually making changes to specific Python files that would be pre-existing from Neutron packages
17:48:20 <pcarver> And a deployer wouldn't want to overwrite Liberty Neutron packages with files from networking-sfc if we haven't merged in all non-sfc Liberty Neutron development
17:48:21 <s3wong> dragonfly seems to also has its own agent instead of extending Neutron OVS agent...
17:48:35 <s3wong> * dragonflow (damn auto-correct)
17:48:59 <pcarver> That's part of the reason that the AT&T SFC that abhisriatt worked on in R&D was built as a standalone thing
17:49:02 <s3wong> we may have to do that as well --- have our own OVS-sfc agent
17:49:19 <LouisF> s3wong: yes that may be a solution
17:49:23 <abhisriatt> pcarver: I was going to give the same reason :)
17:49:36 <pcarver> It was built to interact with public Neutron APIs and it manipulates OvS directly rather than modifying Neutron's OvS agent
17:50:08 <s3wong> pcarver: seems like that is the approach for the other subprojects that are using OVS as well
17:50:33 <pcarver> It does make sense to integrate it long term, but I'm not clear on how it will work in the big tent model
17:50:44 <cathy_> pcarver: you raised a very criitical question. We need to get a clear answer on this.
17:50:51 <abhisriatt> s3wong: can we not adopt the same external approach?
17:51:10 <s3wong> pcarver: yeah... for stuff like dragonflow, I am not sure if it would ever be merged into Neutron core repo
17:51:39 <cathy_> pcarver: s3wong would you like to take this action item together with me?
17:51:48 <s3wong> abhisriatt: what is the alternative? Refactor OVS agent to make it extensible?
17:52:10 <pcarver> s3wong: now that might not be a bad idea to think about
17:52:14 <s3wong> cathy_: sure... I meant to investigate this actually. It was a good thing pcarver brought it up
17:52:28 <pcarver> Alterntively, how clear are you on super()?
17:52:56 <abhisriatt> s3wong: having a separate SFC agent to talk to ovs switches.
17:53:01 <pcarver> I've watched Raymond Hettinger's PyCon talk on Super considered super and I'm wondering if we might leverage that approach
17:53:33 <s3wong> pcarver: so SFC would implement a child class of ova agent class?
17:54:00 <cathy_> AFAIK, modifying existing OVS agent is the way some other projects use
17:54:12 <pcarver> I haven't thought through all the details here, but wondering if would be possible to alter the components in Neutron to inherit functions from SFC classes
17:54:21 <cathy_> I mean extending OVS agent
17:54:27 <s3wong> abhisriatt: that was what we've been talking about so far, right? Have our own agent that runs (hopefully never in conflict with) in conjunction with the Neutron OVS agent?
17:54:38 <LouisF> s3wong: yes can have a child class of ovs agent
17:54:47 <abhisriatt> s3wong: yes.
17:55:45 <pcarver> I think the two options are to write totally independent components (for API, DB and agent) or to find a way to dynamically (at runtime) inherit functionality
17:56:08 <cathy_> OK, let's take the action item and find out how we should proceed with the packaging, release, and coding
17:56:14 <pcarver> What I don't think will work well is to have a Neutron version of a given .py file and a networking-sfc version of the same .py file
17:57:08 <s3wong> pcarver: in generally, SFC library has a dependency on Neutron package --- so we can have Neutron ovs agent inheriting from SFC OVS agent class to adopt functionality
17:57:12 <s3wong> * in general
17:57:25 <cathy_> s3wong: +1
17:57:33 <cathy_> Time is up. Let's warp up.
17:57:33 <s3wong> * can't
17:57:44 <s3wong> (sorry)
17:57:44 <pcarver> The direction of the inheritance is what I haven't figured out yet. The obvious approach would be to strictly inherit from Neutron into our own classes. But Hettinger's talk about replacing suppliers at runtime got me thinking of maybe doing it the other way around.
17:58:06 <s3wong> pcarver: obviously I am not a Python expert :-)
17:58:35 <s3wong> cathy_: let's put that investigation as an #action
17:58:36 <pcarver> In that case I highly recommend the talk. It's on Youtube. I'm not a Python guru either but I found it enlightening.
17:58:46 <s3wong> pcarver: sure
17:58:56 <pcarver> https://www.youtube.com/watch?v=EiOglTERPEo
17:59:02 <mohankumar_> for client code , we inherit neutronclient code and using it as extension API
17:59:06 <cathy_> pcarver: thanks for the link
17:59:17 <s3wong> mohankumar_: yes, that direction makes sense
17:59:55 <cathy_> Ok, everyone, let's sync up next meeting. Please go to the links to give your final review.
18:00:01 <cathy_> bye for now
18:00:09 <s3wong> mohankumar_: though now we are thinking about having installed and loaded an agent on host, then dynamically load a library on top... don't know if it has been done before yet
18:00:35 <s3wong> Thanks guys!
18:00:38 <Brian___> bye
18:00:39 <LouisF> bye
18:00:45 <abhisriatt> bye
18:00:52 <cathy_> #endmeeting