17:00:12 <Cathy__> #startmeeting service_chaining
17:00:14 <vikram> hi
17:00:17 <openstack> Meeting started Thu Apr  7 17:00:12 2016 UTC and is due to finish in 60 minutes.  The chair is Cathy__. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:21 <openstack> The meeting name has been set to 'service_chaining'
17:00:29 <pcarver> Hello
17:00:33 <georgewang> hello
17:00:38 <Cathy__> hi everyone
17:01:10 <s3wong> hello
17:01:11 <scsnow> hi
17:01:16 <LouisF> hi
17:01:21 <Cathy__> s3wong: scsnow LouisF hi
17:01:34 <Cathy__> let's start
17:01:40 <s3wong> Cathy__: your nic keeps on changing :-)
17:01:44 <doonhammer> Hi
17:01:51 <Cathy__> doonhammer: hi
17:02:02 <LouisF> doonhammer: hi
17:02:05 <mohankumar__> hi
17:02:10 <Cathy__> s3wong: really? I don't know why
17:02:24 <vikram> Cathy__: register a nick for you
17:02:32 <raofei> hi everyone
17:03:00 <Cathy__> vikram: OK, will do
17:03:04 <Cathy__> hi raofei
17:03:12 <Cathy__> #topic Source port specification in the FC
17:04:08 <Cathy__> Let me try to explain why we need the source port in the SFC FC specification
17:04:18 <Cathy__> hi iyamahat vishnoianil
17:04:29 <vishnoianil> Cathy__, hi
17:05:41 <Cathy__> With the source port specified, we know where to instantiate the FC
17:06:04 <iyamahat> Cathy__, hi
17:06:25 <vikram> Cathy__: Why we can't put it as a part of the chain
17:06:25 <Cathy__> That will enhance the performance
17:06:41 <vikram> Cathy__: I mean in service_chain_param
17:07:04 <Cathy__> vikram: I guess we can consider that
17:07:25 <vikram> Cathy__: Doing so we can keep FC generic
17:07:41 <LouisF> vikram: it is used to select traffic entering the chain so the FC is the right place to have  it
17:08:21 <vikram> LouisF: Agreed.. but this kills generic design for FC
17:08:34 <mohankumar__> vikram: +1
17:08:37 <vishnoianil> SFC spec do have source port as a match attribute for classifier, isn't it?
17:08:40 <Cathy__> raofei: pcarver s3wong what's your thought?
17:08:42 <LouisF> the FC will evolve and have other parameters such as DSCP, vlan-id etc
17:08:51 <Cathy__> vishnoianil: yes
17:09:07 <vikram> LouisF: The problem here is we are making Src port as mandatory
17:09:18 <pcarver> Cathy__: I'm definitely concerned about putting SFC specific info in the FC because we would like the FC to be generic across things other than SFC
17:09:22 <s3wong> Cathy__: source port as in Neutron port? I don't even know FC has a networking location association...
17:09:25 <Cathy__> In current way, the user can specify that all traffic coming from a source port will go through the chain
17:09:32 <LouisF> there was discussion on a common FC some months ago but that work has not progressed
17:10:39 <trozet> stupid question, does FC == Flow Classifier?
17:10:41 <LouisF> pcarver: a port is not really SFC specific - is likely can be  used by other features such as qos
17:10:43 <pcarver> Also, we need to maintain a clean separation between the abstract design of the API and the particular needs of one implementation. So we should ask whether the source port is required for all SFC drivers or just the OvS agent based one.
17:10:47 <s3wong> trozet: yes :-)
17:10:49 <vikram> trozet:bingo
17:10:50 <vishnoianil> Cathy__, sorry i missed the initial context, are we talking about source port (L4 ) or "Ingress Port" ?
17:11:06 <vikram> source port
17:11:07 <Cathy__> since the source port can be used as a FC rule to classify the traffic, I am not sure if it is appropriate to move it out of the FC
17:11:15 <s3wong> vishnoianil: yeah, that was my question as well :-)
17:11:22 <pcarver> I have the same question as vishnoianil
17:11:32 <LouisF> vishnoianil: neutron src port
17:11:33 <Cathy__> vishnoianil: s3wong source port in the FC
17:11:36 <pcarver> I'm assuming we're talking Neutron port where VM attaches
17:11:45 <pcarver> not TCP/UDP port
17:11:46 <vikram> pcarver: +1
17:11:51 <LouisF> pcarver: yes
17:11:57 <s3wong> pcarver: yes, that's what I was thinking
17:12:22 <vikram> Cathy__: I didn't get your reasoning
17:12:37 <trozet> I think the issue is when you want to SFC to operate at a service/admin role, you want to be able to classify based on traffic from specific neutron networks or ports
17:12:37 <pcarver> I understand that for the OvS based implementation we need to know where to put the flow rules, but I'm not sure that's a generic SFC API requirement
17:12:41 <Cathy__> pcarver: yes, but it is not the source port of a SF VM, it is a source port to identify traffic coming to the chain
17:12:49 <s3wong> Cathy__: wound't ingress network port part of FC?
17:12:54 <vikram> Cathy__: since the source port can be used as a FC rule to classify the traffic, I am not sure if it is appropriate to move it out of the FC : My proposal is not to mandate this field
17:12:56 <s3wong> * wouldn't
17:12:57 <vishnoianil> i think with that, it gets bit vague, because "ingress port" basically considered as a L0 match criteria
17:12:57 <Cathy__> trozet: yes
17:13:20 <trozet> Cathy__: so with RBAC, doesn't that enable this type of behavior?
17:13:38 <pcarver> Thinking in terms of physical switches and firewalls for a moment. Normally an ACL or ruleset is defined and then it is applied to one or more (physical) ports
17:13:50 <LouisF> vishnoianil: yes it is a match on packet metadata not packet contents
17:13:58 <Cathy__> s3wong: it is the ingress network port of a traffic flow which is currently part of the FC.
17:14:09 <s3wong> vikram: as you said, given that ingress Neutron port should be part of classification, shouldn't it be part of FC? Why would you opposed to including it as part of FC?
17:14:43 <mohankumar__> i believe src port made mandatory to check does traffic coming from same compute host or not
17:14:53 <LouisF> there are use cases where all traffic to/from a VM port must be steered into a SFC
17:14:56 <vikram> s3wong: classification can be done for a stream of traffic coming from / to a neutron src
17:15:10 <trozet> shouldn't we also include neutron network? and not just VM port here?
17:15:21 <Cathy__> vishnoianil: our matching criteria is very large, can be up to L7
17:15:45 <vikram> trozet: initial design is chaining ports
17:16:04 <trozet> there are cases where a service operator wants all tenant traffic from a specific network to go through an admin chain before going to an external network, it makes sense to define one chain there in the admin space and not for every tenant
17:16:08 <vishnoianil> Cathy__, then in my opinion it make sense to me, i don' think it's breaking generic nature of the API
17:16:12 <vikram> trozet: which address all the scenarios
17:16:14 <trozet> vikram: i'm not talking about chaining, im talking about classification
17:16:53 <vikram> trozet: Ok.. so you mean adding a param net in the FC?
17:17:06 <trozet> vikram: yeah network and ports both in FC
17:17:26 <LouisF> trozet: ports already exist in the FC
17:17:28 <Cathy__> trozet: I understand your point. Yes that is a use case we need to cover. Could one or a group of source ports represent that network whose traffic go through the chain?
17:17:42 <vikram> trozet: anyways it can be done.. if we already support ports.. at the end nets are collection of ports
17:17:43 <trozet> vikram: of course one would only be able ot match on network/ports outside of his tenant if he had proper admin rights given by RBAC I think
17:17:46 <vishnoianil> Cathy__, LouisF i think classification in general should provide all the attribute on which you can steer the traffic, except it enforces which attribute to be made mandatory or enforces any dependency between the matching attributes
17:17:58 <s3wong> trozet: I got to be honest, on the plumbing side, I don't know how to render 'network' into something like OVS flow table... subnet? VLAN?
17:18:19 <Cathy__> trozet: If we can use existing way to cover other scenarios, I would rather not add more and more primitives in the FC
17:18:23 <LouisF> s3wong: +1
17:18:31 <trozet> s3wong: in ODL its matched on in flows
17:18:34 <trozet> s3wong: in OVS
17:18:47 <vikram> vishnoianil, I am not suggesting to remove the src port attribute
17:18:54 <vishnoianil> s3wong, ideally it should be associated subnet, because it's lower level construct then network
17:19:04 <trozet> s3wong: i think its part of hte tunnel ID for vxlan, but need to confirm
17:19:08 <vishnoianil> network has one to many associativity with subnet
17:19:09 <vikram> vishnoianil, Just not to mandate it
17:19:14 <Cathy__> s3wong: good point
17:19:46 <s3wong> Cathy__, vikram. LouisF: how about this then? If a source port is specified in the FC, we know where to put it; if not, all traffic is subjected to classification and matching?
17:19:53 <vishnoianil> vikram, okay, i think mandating it might create a problem
17:20:19 <Cathy__> s3wong: that is existing way:-)
17:20:34 <Cathy__> OK, so now the issue is "mandatory" or not
17:20:36 <vikram> vishnoianil, Yup..
17:20:50 <vikram> Cathy__: +1
17:20:50 <s3wong> Cathy__: I see --- how the discussion is much more clear :-)
17:20:54 <s3wong> * now
17:21:03 <vishnoianil> Cathy__, "ingress port" actually scope your traffic to the specific port, so any classification you will specify after specify ingress port, will be scoped to that ingress port only
17:21:07 <LouisF> it can made optional in the FC with the caveat that in certain implementations there may be performance impact
17:21:10 <Cathy__> raofei: I remember you have some point on this.
17:21:43 <vikram> LouisF: For this one can provide this info using service_chainparam
17:21:46 <s3wong> Cathy__: in that context, I actually side with vikram here... we want the FC to be flexible enough to be specified as "all traffic from all port should be matched against this"
17:21:54 <vikram> LouisF: For this one can provide this info using service_chain_parameter
17:22:21 <vishnoianil> so if make ingress port mandatory, to specify classification at switch level you will have to cater traffic each port basis and that can lead to flow explosion at the device level :)
17:22:43 <s3wong> LouisF: +1, exactly!
17:22:50 <trozet> so from reading this discussion, matching on port is already supported, the discussion is whether to make it mandatory or not?
17:23:03 <Cathy__> trozet: yes
17:23:06 <LouisF> trozet: correct
17:23:15 <vikram> trozet: +1000
17:23:23 <s3wong> trozet: yep, my understanding as well (finally, after some long discussions) :-)
17:23:31 <vikram> :(
17:23:33 <trozet> why would you want to make it mandatory?
17:23:38 <trozet> that doesn't make much sense to me
17:23:46 <vishnoianil> trozet, In my personal opinion, that's not good idea
17:23:47 <Cathy__> there is a reason we later made it mandatory. I am still thinking about why.
17:24:14 <vikram> Cathy__: IIRC, it was for identifying the flow on the other compute node
17:24:17 <trozet> Cathy__: was that simply because then you know where to place the classifier flow?
17:24:30 <Cathy__> trozet: no
17:24:56 <LouisF> it is currently mandatory, if it is made optional then the OVS rules for matching must be installed on all OVS switches
17:25:00 <Cathy__> vikram: yes, something like that. I remember I described the scenario in one of our previous IRC meeting.
17:25:04 <vikram> Cathy__: If the chain span across multiple nodes then we need to identify th flow
17:25:14 <LouisF> trozet: +1
17:25:27 <mohankumar__> Cathy__ , i remember , to find Compute node belongs to same tenent nw or different tenent (or OVS rather )
17:25:29 <vikram> coming from chain / it's normal packet
17:25:47 <trozet> LouisF: yeah they should be on every OVS if not specific to a port
17:25:57 <LouisF> trozet: yep
17:26:12 <s3wong> LouisF: which probably is the user intent in this context (that the flow rules should be matched on all OVS switches)
17:26:48 <LouisF> s3wong: yes
17:27:17 <Cathy__> So if the same flow comes back to SF VMs which happen to run on the same computer node, we need a way to distinguish this since depending on where the flow comes, the next hop is different.
17:27:18 <trozet> so I guess the question is, who in the room wants to keep it mandatory?
17:27:36 <vikram> trozet: +1000.. and where to mandate this
17:29:00 <vikram> My proposal is we can pass the src port info "[--chain-parameters <chain-parameter>]" here, if needed
17:29:02 <Cathy__> If I remember correctly, we decided to use the source port as a way to distinguish the traffic entering the chain from the traffic that loop back to the compute node
17:30:28 <s3wong> Cathy__: I think it is perfectly fine if we happen to render the chain / FC into flow rules with source port context --- so that is something we (drivers) can do, without subjecting users to specify a source port
17:31:31 <vikram> s3wong: I didn't get you
17:31:42 <trozet> Cathy__: yeah if you have to specify port in classifier so you know that a return packet to OVS shouldnt be reclassified and is still part of the chain--that seems to me like you are fixing a chain problem by restricting the classifier
17:32:05 <trozet> Cathy__: the chain flows should know where the packet is in the chain, and not restrict the classifier IMO
17:32:14 <s3wong> vikram, Cathy__: in your example, say SF1->SF2->SF3, a FC matches traffic to SF1
17:32:51 <Cathy__> trozet: could you calrify what you mean by "chain flows should know where the packet is in the chain"?
17:33:43 <s3wong> vikram, Cathy__: if say SF3 happens to be in the same node as SF1, we can render a source port on the return traffic from SF2 -> SF3 with the same flow rules
17:34:03 <LouisF> trozet: return packets from the egress port of SF are re-classified on the current design
17:34:22 <raofei> yes, s3wrong, for one scenario, service path is sf1->sf2->sf1->sf3, if we don't assign the source port,  it's difficult to distinguish the return the traffic.
17:34:28 <Cathy__> trozet: when the flow loops back to the same vSwitch that the traffic originally enters the chain, how does the vSwitch determine the different next hop?
17:34:49 <trozet> Cathy__: well NSH solves that problem
17:34:49 <LouisF> the ovs driver/agent acts like a sfc proxy device
17:35:05 <Cathy__> trozet: yes
17:35:11 <vishnoianil> Cathy__, LouisF trozet , are we talking of this specific problem, when we don't use NSH encap?
17:35:18 <vikram> trozet: ;) Reality is tough
17:35:19 <Cathy__> trozet: if we use NSH, we can use the service_index to solve it
17:35:22 <trozet> Cathy__: I'm not as familiar with how you are doing SFC in networking-sfc
17:35:36 <s3wong> vishnoianil: technically OVS has no NSH support
17:35:47 <vikram> vishnoianil: yes
17:35:50 <s3wong> vishnoianil: independently of what ODL SFC is using :-)
17:35:53 <mohankumar__> vishnoianil , its not included to ovs officially
17:36:01 <vishnoianil> s3wong, agree, but in ODL we do run OVS with NSH (that's not official version)
17:36:07 <Cathy__> trozet: when we proposed the SCH spec which merged with NSH, we considered this case and service_index can be used for solving it
17:36:20 <LouisF> raofei: but the driver/agent matches on the egress port so is can distinguish return traffic from that originating from the source port
17:36:23 <trozet> s3wong: :) let's not go down that road... it will be in a few months
17:36:29 <vishnoianil> s3wong, vishnoianil mohankumar__ agree
17:36:52 <s3wong> raofei: in that case, how would user specify source port for SF1->SF2 vs SF1->SF3?
17:36:58 <LouisF> vishnoianil: does odl support nsh-aware SFs?
17:37:02 <vikram> Time is really draining fast ;)
17:37:33 <trozet> Cathy__: so in current networking-sfc implementation, how do you distinguish a packet that is part of a chain versus regular tenant traffic?
17:37:33 <vishnoianil> LouisF, ODL can support NSH, but having SF NSH aware is kind of out of scope for ODL
17:38:01 <vikram> trozet: https://github.com/openstack/networking-sfc/blob/master/doc/source/ovs_driver_and_agent_workflow.rst
17:38:03 <Cathy__> trozet: through the FC. Not sure if I understand your question properly
17:38:22 <s3wong> vikram: the beauty of explaining things via IRC ... a whiteboard session would have explained the problem in 10 minutes :-)
17:38:24 <LouisF> vishnoianil: so the odl driver for sfc must do re-classification of packets returned from each SF
17:38:27 <Cathy__> If OVS officially supports NSH, then we do not need this "mandatory".
17:38:49 <vikram> s3wong :)
17:39:11 <vishnoianil> s3wong, Cathy__ trozet LouisF , i think won't it be good if we take this topic to mailing list, probably that will bring us to conclusion faster :), just an opinion
17:39:20 <LouisF> Cathy__: it depends on  whether the SF is nsh-aware and the need to do reclassifcation on return traffic
17:39:32 <Cathy__> trozet: Do you mean that OVS will officially support NSH in a few months? About what time will NSH be merged into OVS officially?
17:39:46 <vishnoianil> Cathy__, Yes, 2.6 should have support for NSH
17:39:54 <vikram> Cathy__: My opinion is  we should resolve the issue by disturbing a generic API
17:40:13 <Cathy__> vishnoianil: great! when is that?
17:40:15 <s3wong> vishnoianil: really? was it finally merged? I've seen the outstanding patch there forever...
17:40:22 <raofei> agree with Louis
17:40:24 <LouisF> vikram: not sure what you mean
17:40:46 <vishnoianil> vikram, do you mean "by NOT disturbing" ?
17:41:03 <LouisF> vishnoianil: who is doing that work?
17:41:27 <vikram> vishnoianil, LouisF: Not imposing a restriction on a generic API
17:41:49 <Cathy__> Maybe we can put this in the back burner for now and if we can get NSH support soon, then we will remove the "mandatory" at that "soon" time.
17:41:49 <vikram> what we are having today by making the src port as a mandatory field
17:41:52 <trozet> Cathy__: ok now I see you are using the MPLS header to track if its part of the chain
17:42:07 <LouisF> vikram: you mean by making the src port mandatory in the FC?
17:42:11 <vikram> trozet: You are fast :)
17:42:13 <Cathy__> trozet: yes, that is a place holder for future NSH header
17:42:17 <trozet> Cathy__: so then what loop packet are we talking about that gets accidentally reclassified?
17:42:30 <trozet> Cathy__: egress from the chain?
17:42:39 <vikram> LouisF: I am half sleepy now.. ;) I mean not to make it mandatory
17:42:53 <vikram> LouisF: It's time to bed :(
17:43:12 <LouisF> vikram: thanks for joining
17:43:54 <Cathy__> trozet: not egress from the chain. Think about if all SF VM runs on the same Computer Node (vSwitch)
17:43:58 <mohankumar__> Cathy__ : i agree , to remove mandatory once we ve NSH suppport
17:43:58 <vikram> LouisF: Please forgive if I sound stupid today .. Tiering day
17:44:12 <Cathy__> mohankumar__: Ok, good.
17:44:27 <Cathy__> vikram: mohankumar__ thanks for joining at your mid night!
17:44:30 <vikram> Cathy__: Does ODL has any issues ?
17:44:33 <LouisF> trozet: the end-of-chain case is ok because the ovs driver/agent reclassifies on the egress port of the last SF
17:44:45 <Cathy__> raofei: Thanks to you too at your 1am time !!!
17:45:05 <vikram> Cathy__: Does ODL has any issues if we continu src port as mandatory in the FC API?
17:45:07 <trozet> Cathy__: yeah so if you have multiple SF on the same node, when the packet from SF1-->OVS-->SF2 that is where you are worried about a reclassification problem if you dont specify a port?
17:45:12 <LouisF> raofei: +1000
17:45:26 <Cathy__> vikram: not that I am aware of
17:45:47 <vikram> trozet, vishnoianil, any inputs?
17:46:17 <trozet> vikram: yeah it's not good
17:46:34 <LouisF> vikram: is it an issue for the onos driver?
17:46:38 <vikram> i don't remeber for ONOS
17:46:41 <Cathy__> so SourcePort->OVS->SF1->OVS->SF2
17:47:04 <vikram> but I remember we were able to do it without src port as well
17:47:10 <trozet> virkam: then if you want to match on tcp port 80 traffic, you have to create N number of classifiers for every port, or you just ignore any match port criteria from networking-sfc in the ODL driver
17:47:30 <Cathy__> If no source port, then FC rules with no SourcePort->OVS->SF1->OVS->SF2
17:48:01 <trozet> Cathy__: so your ingress packet from SF1, dont you have flows tha match ont eh MPLS header to decide if the packet is still part of the chain?
17:48:41 <vikram> trozet: Agreed.. but frankly speaking classifier should be deployed a separate node and all the traffic should pass through it
17:49:27 <Cathy__> how about this? I will send out a diagram describing this scenario. We have spent enough time on this discussion:-) I think a diagram will explain the problem easier.
17:49:46 <LouisF> vikram: that depends on the usage scenario - for mobile Gi LAN that would be correct, but the DC is different
17:50:00 <s3wong> trozet: yes, exactly what I was thinking... the match from unencapulated packet to SF1 and the second time it hits SF1 should be different
17:50:04 <vikram> LouisF: Yes.. I realized
17:50:06 <pcarver> vikram: Can't assume traffic will be small enough to all pass through a single node
17:50:30 <vikram> pcarver: make sense..
17:50:33 <vishnoianil> trozet, SF on same SFF problem, why we can't solve that problem using NXM-REG?
17:50:40 <vikram> Really learning SFC now ;)
17:51:02 <trozet> Cathy__: so the issue is you dont encap the tunnel header if you are on the same OVS node, so you don't know the packet is part of the chain?
17:51:35 <vikram> trozet: for your question, yes ONOS currently installs flow for N ports separately
17:51:38 <Cathy__> trozet: yes, no need for tunnel header since it will not go through the tunnel
17:51:42 <LouisF> vishnoianil: for multiple SFs on the same SFF (OVS) it is not a problem beacuse the rules will match on the egress port of each SF
17:52:00 <vishnoianil> LouisF, okay
17:52:19 <vishnoianil> LouisF, reading trough chat with your max speed,sometime confuses you :P
17:52:53 <trozet> vishnoianil: yeah maybe im sure shague would have a good fix for this
17:53:21 <vishnoianil> trozet, yeah
17:53:29 <Cathy__> vishnoianil: it will match on the egress port of each SF, so we need a source port to distinguish traffic on the source port from traffic on the egress port of each SF
17:53:50 <LouisF> trozet: it would be good to find out how odl handles the non-nsh-aware SF
17:54:15 <Cathy__> with NSH support, this issue is gone.
17:54:39 <LouisF> Cathy__: agree, for nsh-aware SFs
17:54:50 <trozet> Cathy__: so cant you match on ingress port for the chain, rather than ingress port with the classifier?
17:55:13 <trozet> Cathy__: if you just make the chain rule match on SF1 in_port
17:55:33 <trozet> Cathy__: but then what if that VNF is part of multiple chains, how do you know what is the next hop?
17:55:39 <trozet> since you have no header
17:55:40 <LouisF> trozet: the "ingress port" for the chain is the ingress port of the FC
17:55:55 <trozet> LouisF: i mean in_port from the previous VNF in the chain
17:56:38 <s3wong> trozet: even if we have to reclassify, that is OK --- as long as the rules are replicated with the ingress port added ... I still think driver is a right place to do this, as opposed to having user specify a port
17:57:02 <Cathy__> trozet: we still need to distinguish the traffic on the source port which is before the SF1, from the traffic on SF1 in_port
17:57:04 <trozet> s3wong: yeah thats a good point
17:57:13 <LouisF> trozet: by egress port from a SF port-pair would be the OVS in_port
17:57:15 <trozet> s3wong: just making the OVS networking-sfc driver apply the classifier to each port
17:57:39 <Cathy__> trozet: since all the traffic is handled by the same Compute Node and vSwitch
17:58:32 <s3wong> Cathy__: traffic into chain is FC, traffic to SF1 is in_port SF1 + FC, which the driver needs to be smart enough to add... does that work?
17:59:02 <LouisF> trozet: the VNF re-classify will discriminate the chains when multiple chains use that VNF
17:59:10 <Cathy__> s3wong: that seems a good way. let me think about it more
17:59:21 <Cathy__> Hi folks, time is up.
17:59:40 <scsnow> I have a question regarding currect SFC implemenation in OVS driver. Where can I ask it?
17:59:40 <vikram> :)
17:59:41 <s3wong> good discussion!
17:59:44 <Cathy__> Let's continue the discussion in next meeting. We only cover one topic today:-)
17:59:52 <LouisF> scsnow: here
17:59:55 <vikram> scsnow: Mailing List
17:59:59 <Cathy__> scsnow: could you send your Q via email
18:00:09 <Cathy__> Ok, by everyone
18:00:12 <vikram> bye
18:00:14 <s3wong> bye
18:00:15 <mohankumar__> bye
18:00:16 <scsnow> I was waiting for open discussion topic here )
18:00:24 <Cathy__> scsnow: :-)
18:00:25 <vikram> scsnow :)
18:00:26 <doonhammer> bye
18:00:36 <Cathy__> #endmeeting