17:02:38 <LouisF> #startmeeting service-chaining
17:02:39 <openstack> Meeting started Thu Aug 13 17:02:38 2015 UTC and is due to finish in 60 minutes.  The chair is LouisF. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:44 <openstack> The meeting name has been set to 'service_chaining'
17:02:51 <johnsom> o/
17:02:58 <LouisF> hi all
17:03:02 <george__> hi
17:03:08 <Brian__> hi all
17:03:14 <max_klyus> hi there
17:03:22 <Mohankumar> hi
17:03:37 <abhisriatt> hi
17:03:37 <pcarver> hi
17:04:05 <LouisF> cathy will be joining shortly
17:05:01 <vikram_> hi
17:05:31 <LouisF> I posted an update to the API https://review.openstack.org/#/c/204695/
17:05:46 <LouisF> vikram_: hi
17:05:55 <xgerman> hi
17:06:41 <LouisF> vikram_: thanks for the review of the previous patch
17:06:57 <vikram_> ++
17:07:47 <cahty> hi everyone
17:07:51 <LouisF> cahty: hi
17:07:57 <cahty> sorry for my Internet conneciton issue
17:09:10 <cathy_> hi everyone
17:09:15 <LouisF> cathy_: hi
17:09:24 <cathy_> sorry for my Internet connection issue
17:09:44 <cathy_> let's start
17:10:01 <cathy_> #topic port pair
17:10:26 <cathy_> We are thinking about creating a separate resource for port pair.
17:10:34 <LouisF> i feel that having a separate port-pair resource is useful
17:10:50 <LouisF> as we have in the latest API spec
17:12:08 <cathy_> This is because: we would need to attach different attributes to the port. For example, to support Load distribution among a group of SFs, we need to attach a weight to the port pair
17:12:47 <pcarver> cathy_: That sounds like a reasonable use case
17:13:37 <cathy_> Also different SF could support different chain identification mechanism, such as chainID in the new chain header or VLAN. So we need the chain identification attribute attached to the port pair too.
17:14:02 <LouisF> +1
17:14:24 <cathy_> so that the vSwitch can forward the appropriate packet format to the SF VM
17:15:08 <pcarver> Is there any argument against having it as a separate resource? (I'm afraid I haven't read everyone's comments on every review in my backlog)
17:15:10 <cathy_> Another attribute needed is the " SF type" since the processing on the Switch is different for L2 Type SF and L3 type SF
17:16:01 <cathy_> pcarver: I don't think so, but vikram_ is asking whether we need it or not.
17:16:41 <vikram_> cathy_: i feel port group is sufficient to handle
17:17:12 <pcarver> I think we agree it's needed in the data model, but are questioning whether it needs to be directly manipulated by the API. Is that correct?
17:17:24 <pcarver> Or are we questioning whether it needs to be in the database at all?
17:18:19 <pcarver> Basically I'm asking whether this is an API discussion or a database normalization discussion or both
17:18:31 <LouisF> vikram_: i think that having it in the api makes it easier to be able to add  attributes to a port-pair resource if needed in the future
17:18:46 <cathy_> vikram_: If we need to attach additional attributes to the port pairs, it seems better to have a separate entity for port pair so that we cna extend the port pair without changing the port group. What do you think?
17:19:04 <cathy_> pcarver: both
17:19:14 <pcarver> The reason I'm asking, is because my followup question is: What's the harm in not exposing it in the API until we add something to the API that requires it?
17:19:20 <vikram> sorry got disconnected
17:19:39 <pcarver> If it's part of the DB model, but we don't need to manipulate it now via API we can always add to the API later
17:19:47 <max_klyus> I'm not sure if somebody saw my comments about tunnel redundancy/balancing across CNs. Does it make sense or such kind of things not in scope?
17:20:29 <vikram> cathy_: What I feel is too many CLI's will confuse user
17:20:51 <vikram> if we feel port-pair is necessary then we can remove port-group
17:21:06 <cathy_> pcarver: the harm is that we will make the port group API too complicated.
17:21:17 <pcarver> vikram: I agree, especially if the CLI (or API) exposes things that have no current function and are just part of a future use design
17:21:25 <LouisF> pcarver: if we have a port-pair resource then the chnages will be localized to the port-pair resource itself and  not affect the port group resource
17:21:38 <abhisriatt> vikram: I’m already confused :)
17:21:49 <vikram> :)
17:22:10 <cathy_> vikram: yes, I understand your concern. But having a port pair API is more modular in terms of API design and can be useful for other features
17:22:18 <pcarver> I think if we agree it belongs in the data model, the question is whether it needs to be exposed by API
17:22:30 <vikram> ++
17:22:41 <pcarver> If there's no current functionality that the user can do with it, we shouldn't expose it now
17:22:42 <xgerman> +1
17:22:52 <cathy_> pcarver: Actually It is needed now:-)
17:23:01 <pcarver> When we add the new capability to manipulate it in a useful way we can add it to the API
17:23:22 <abhisriatt> cathy_:what’s the use case?
17:23:23 <pcarver> cathy_: Can you give a user story?
17:23:55 <cathy_> Ok, let me describe it.
17:23:55 <pcarver> What would the end user of the CLI or API do with it, given the initial release of the SFC functionality?
17:25:38 <cathy_> Let's take the weight example. If there are multiple SF associated with a group, then we need the weight of each SF to be passed down for the Switch to choose which SF to use
17:25:40 <LouisF> each port-pair can potentially have a different encap mechanism such as nsh, or vlan, etc
17:26:06 <cathy_> what Louis gives is another usage example.
17:26:10 <pcarver> but are we supporting that now or are you future-proofing?
17:26:21 <cathy_> now
17:26:39 <LouisF> the weight can definitely be used right now
17:26:53 <cathy_> let's take the SF encap mechanism.
17:27:02 <abhisriatt> How is this use case different from load balancing?
17:27:16 <cathy_> We already know that different SF uses different encap mechansm
17:27:20 <LouisF> openflow support weights on buckets within a group
17:27:28 <pcarver> The SF encap mechanism is definitely future use, though isn't it? We said that NSH would be dependent on future support from OvS
17:28:37 <pcarver> I'm not really opposed to including it in the API as long as the knob does something.
17:28:56 <pcarver> But we shouldn't expect users to set a setting that can only be set one way
17:29:10 <LouisF> and the OF bucket weight can be used for load distribution for a port-group that consists of port-pairs having different weights
17:29:36 <cathy_> Even OVS does not support NSH, the OVS still needs to figure out the packet format when it sends the flow to the SF VM and that packet format depends on what format is supported by the VM SF. It could be VLAN or something else
17:30:01 <pcarver> Also, consider testing. The more knobs in the API the more scenarios that need test cases to make sure they all work and in all combinations.
17:30:37 <vikram_> pcarver: I agree... let's expose what really is really required
17:30:39 <cathy_> pcarver: yes, we will need to test them
17:31:10 <pcarver> Maybe, a slightly different topic, but are we expecting fully functioning implementation in Liberty timeframe?
17:31:32 <cathy_> abhisriatt: adding the weight is for the use case of load balancing.
17:31:44 <pcarver> I'd rather see a less featured implementation that is complete in Liberty timeframe then a more featured implementation that isn't finished
17:31:51 <cathy_> pcarver: Liberty is our goal.
17:32:45 <pcarver> cathy_: That's what I though, but with time running short that's why I'm questioning how many features, and equally importantly how many test cases can be delivered in that timeframe
17:32:58 <LouisF> pcarver: what features do you see as stretch features?
17:34:24 <xgerman> Liberty code freeze is in about two weeks - just a reminder
17:34:39 <pcarver> LouisF: I'm behind on reviewing all the code that's already up on Gerrit, so I can't quite judge. I'm just asking if this particular topic we're discussing is included.
17:34:50 <pcarver> And I don't mean just a required hop in the API
17:35:11 <cathy_> pcarver: we think the base features should include the load balancing among SFs which needs the weight, the format the OVS uses to forward to the SF which needs the specifcation of the SF encap format
17:35:28 <pcarver> I mean a knob in the API that you'd be able to use in multiple ways, and that there would be test coverage for all ways of using it.
17:35:41 <vikram_> LouisF, cathy_: why we can't remove port group.. it's just grouping port-pairs.
17:36:46 <vikram_> instead list of port-pairs could be passed directly
17:37:06 <vikram_> while creating chain
17:37:56 <mohankumar_> vikram_: i think  to achive  load balancing
17:38:02 <max_klyus> if port group will be removed load balancing will be impossible
17:38:40 <abhisriatt> And policies can also be easily applied on port groups rather on individual port-pairs.
17:38:42 <mohankumar_> port group will be the better way than passing directly
17:39:09 <LouisF> vikram_: that will cause work to remove port-groups and then test
17:39:32 <vikram_> LoiusF: ok
17:39:38 <cathy_> I think we should keep the port group for LB
17:40:51 <vikram_> i still don't understand why we can't achieve LB without port-group..
17:41:20 <pcarver> I'm ok with keeping it as long as it's an implemented, tested feature, not just extra work for the API user to always pass one legal value
17:41:22 <vikram_> may be i need to think more.. and lagging behind :(
17:45:35 <cathy_> So if we want to shoot for Liberty, we will probably not add these new attributes and we will keep existing APIs and CLIs. Please everyone go to the API patch to give your review and we need to merge this as soon as possible.
17:46:12 <cathy_> These APIs have been implemented and tested
17:46:28 <vikram_> cathy_: Once API is finalisied will correct CLI and horizon patch
17:46:41 <pcarver> cathy_: "These" meaning with or without the port group and load balancing feature?
17:46:45 <cathy_> vikram_: good. Thanks.
17:46:57 <vikram_> quit
17:47:09 <cathy_> pcarver: with port group and LB
17:47:14 <LouisF> yes
17:47:29 <pcarver> Ok, thanks
17:47:29 <abhisriatt> Have we finalized on the tunneling solution?
17:47:36 <cathy_> But we will do a very simple LB with out weight
17:47:50 <LouisF> abhisriatt: we should discuss that now
17:48:05 <abhisriatt> LouisF: sure.
17:48:08 <pcarver> cathy_: but that's what I meant, if we do it without weight, do we need the port group to do that?
17:48:38 <pcarver> Or is the user being asked to make the port group API call even though they can't actually configure it more than one way?
17:48:44 <LouisF> abhisriatt: what is your suggestion here?
17:49:02 <abhisriatt> LouisF: The approach that we used internally, actually uses MAC rewriting at each hop inside OVS to steer flows through SFs.
17:49:06 <cathy_> abhisriatt: we are thinking about using "raw packet+VXLAN" or "raw packet+ether header+VXLAN". Both are compliant with the IETF standard
17:49:23 <cathy_> abhisriatt: what's your thought?
17:49:42 <LouisF> abhisriatt: to rewrite the dst mac?
17:49:52 <abhisriatt> LouisF: Yes.
17:50:12 <cathy_> pcarver: we need port group since it specifies how many and what SFs belong to the same group for LB.
17:50:14 <abhisriatt> In the beginning, the packet will have src ip, port and dst ip, port.
17:50:48 <LouisF> when the packet returns from the SF what fields are used to re-classify?
17:51:06 <cathy_> pcarver: without weight, we cna just use round robin to choose the SF out of the group
17:51:07 <abhisriatt> however, at the source, the ovs replaces the dst mac with the first SF VM mac
17:51:34 <abhisriatt> cathy_: do we have a provision of learning in the load balancing.
17:52:04 <abhisriatt> cathy_: for security SFs, we need to maintain the session. Hence, the flows must travel to same set of SFs.
17:52:13 <max_klyus> weight parameter also will be useful for "smart" balancing potentially we could know the load of each SF at the moment
17:52:52 <LouisF> abhisriatt: right, but when the packet is reterned from the SF how is that packet identified as being part of a specific chain to steer it to the next hop SF?
17:53:06 <cathy_> max_klyus: yes, it is for that purpose. But given the time limit, we will add that in the next release
17:53:12 <LouisF> max_klyus: +1
17:53:20 <abhisriatt> LouisF: we can use flow classifers. For example: if we apply the SF on UDP traffic, our OVS rules look for UDP traffic. We can go very fine-grained at the port level too.
17:53:54 <LouisF> abhisriatt: ok so you use per-SF re-classification
17:54:29 <LouisF> this is assuming transparent SF that do not modify the packet n-tuple
17:54:36 <cathy_> abhisriatt: are you talking about the forwarding between the OVS and its connecting SF or the forwarding between two OVS on two Compute node?
17:54:48 <abhisriatt> LouisF:Yes, we assuming SFs as blackboxes.
17:55:08 <abhisriatt> cath_: forwarding between two OVS on two Compute node
17:55:15 <pcarver> I believe the MAC rewriting has a lot in common with how Contrail does it too, although with Contrail there's an additional L3 component.
17:55:37 <LouisF> abhisriatt: meaning they are transparent and do not modify the packet's header?
17:56:16 <pcarver> Contrail controls the sequence of hops by setting the L3 next hop vRouter (which as a side effect essentially changes the MAC too)
17:57:02 <cathy_> abhisriatt: pcarver there are two aspects we need to consider when forwarding between two OVSs. One is the inner packet destination associated with the destination SF VM and the other is the outer packet destination associated with the destination OVS.
17:57:10 <abhisriatt> LouisF: yes. even if they do, since our ovs rules remember the next hop for the packet. we can send them.
17:58:17 <cathy_> I guess we do not have time to finish this discussion in this meeting. We will need a diagram to show the data path format.
17:58:21 <LouisF> abhisriatt: we should discuss further
17:58:39 <abhisriatt> cathy_, LouisF:yes.
17:59:47 <cathy_> abhisriatt: could you write up the data path format which will be very helpful for our discussion? We can also write a datapath format option.
18:00:32 <cathy_> Ok, folks, time is up. Let's resume the discussion next week. abhisriatt could you post your data path format on the wiki page Paul created. We will do the same.
18:00:36 <abhisriatt> cathy_: sure.
18:00:45 <cathy_> Thanks everyone. bye for now.
18:00:48 <abhisriatt> bye
18:00:53 <Brian__> bye
18:00:53 <max_klyus> bye
18:00:56 <pcarver> bye
18:00:58 <mohankumar_> bye
18:00:58 <LouisF> bye
18:01:19 <LouisF> #endmeeting