[openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

Mohan Kumar nmohankumar1011 at gmail.com
Thu Aug 10 12:27:23 UTC 2017


Hi Rajeev,

No , We haven't started any design .

Let me know If I can help you anywhere . We can collaborate on this :)

Thanks.,
Mohankumar.N



On Tue, Aug 8, 2017 at 12:15 PM, rajeev.satyanarayana at wipro.com <
rajeev.satyanarayana at wipro.com> wrote:

> Hi MohanKumar,
>
>
>
> Thanks for the reply.
>
>
>
> Is the design part for the “OAM Operation Manager for SFC” done? What is
> the approach being used to monitor the SFC? If the design is already done,
> I would like to contribute in implementing it. Please provide your comments.
>
>
>
> Thanks and Regards,
>
> Rajeev
>
>
>
> *From:* Mohan Kumar [mailto:nmohankumar1011 at gmail.com]
> *Sent:* Friday, July 28, 2017 1:32 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at lists.openstack.org>
> *Cc:* Rajeev Satyanarayana (MFG & Tech) <rajeev.satyanarayana at wipro.com>
> *Subject:* ** Newsletter/Marketing email** Re: [openstack-dev]
> [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC
>
>
>
> ** This mail has been sent from an external source. Treat hyperlinks and
> attachments in this email with caution**
>
> Hi Rajeev,
>
>
>
> The Chain Monitoring is the missing piece in networking-sfc . Vikram and
> myself were discussed to introduce "SFC Manager" [1] (basically OAM tool )
> few cycle before.
>
>
>
> It'll continuously monitor an existing SFC chain,  when any SF VM goes
> down or any packet drop. It'll trigger alert and capture corresponding logs
> . But we haven't started any implementation on this. Feel free to discuss
> with community, IMO  this feature will be great addition to networking-sfc
>
>
>
> [1]  https://bugs.launchpad.net/networking-sfc/+bug/1513368
>
> <https://clicktime.symantec.com/a/1/oyvdp2ozE_Pe2sKTM51_kVGy1ODcQYS_L50v9C-IyKo=?d=OZb6_jQ3JlDcR2AISJ1S1yWSl9wA-da9R6WweBZh8-1xFSm7MxSA9a4SYoOw7U5fTTE8TgbqfudjFvUJGjDkrnVR8mWytf4M3eN4AD71w1P20EuGgVBYqX2e4XU1RLCLPuDzEem8Pvb7DaVjt_oEU15hkt_CfSTEUKh58nKrnbrfyy9rDd5XIZscEY5gl3pbQ5CoXChMOmfq68AE2WCT9a01j26KThkBjxPJbv7zay4R1vkxAxl07G4VZ26lvhz-CLOS6io8hJGjhaWkAJN_i67NzGOXXjipBTRt860ew1Njxrns15bG_IJ58TV9RRw-EMQ0HNftqhXlA28RRbuLvqfjJmivRjKHrMXjeKah9B7TvU1XTn7fAwJvIbcHA8zejHC_MUDNNpDMJQ7RfC6A0v5hl8qhiG2UCM-axWeSN5erVE652SbORAGMTScANtK7PL02O8Da9-W30pJr9e8haxOIGYVgHA%3D%3D&u=https%3A%2F%2Fbugs.launchpad.net%2Fnetworking-sfc%2F%2Bbug%2F1513368>
>
>
>
> IRC: #networking-sfc
>
> Weekly Meeting:  https://wiki.openstack.org/wiki/Meetings/
> ServiceFunctionChainingMeeting
> <https://clicktime.symantec.com/a/1/6dNKaHpOkefxWGyCJEXAIE-cQCSPzu0gOs-V_OdWGO4=?d=OZb6_jQ3JlDcR2AISJ1S1yWSl9wA-da9R6WweBZh8-1xFSm7MxSA9a4SYoOw7U5fTTE8TgbqfudjFvUJGjDkrnVR8mWytf4M3eN4AD71w1P20EuGgVBYqX2e4XU1RLCLPuDzEem8Pvb7DaVjt_oEU15hkt_CfSTEUKh58nKrnbrfyy9rDd5XIZscEY5gl3pbQ5CoXChMOmfq68AE2WCT9a01j26KThkBjxPJbv7zay4R1vkxAxl07G4VZ26lvhz-CLOS6io8hJGjhaWkAJN_i67NzGOXXjipBTRt860ew1Njxrns15bG_IJ58TV9RRw-EMQ0HNftqhXlA28RRbuLvqfjJmivRjKHrMXjeKah9B7TvU1XTn7fAwJvIbcHA8zejHC_MUDNNpDMJQ7RfC6A0v5hl8qhiG2UCM-axWeSN5erVE652SbORAGMTScANtK7PL02O8Da9-W30pJr9e8haxOIGYVgHA%3D%3D&u=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FMeetings%2FServiceFunctionChainingMeeting>
>
>
>
> Thanks.,
>
> Mohankumar.N
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jul 27, 2017 at 11:30 AM, rajeev.satyanarayana at wipro.com <
> rajeev.satyanarayana at wipro.com> wrote:
>
> Hi Igor/Cathy/Gord,
>
>
>
> Sorry for the delay in replying.
>
>
>
> As part of monitoring the SFC, I think maintaining the details of “Number
> of flows assigned to a given SFC”, “Number of packets/bytes dropped/hit due
> to the policies at each Service Function entry/exit points or for the
> entire SFC” would be good to start with. I feel based on some of these
> details, an operator can know how much the virtual switch is loaded and
> take a call on whether to add a new SFC, or it could even help during
> debugging which service function has exactly caused the disruption to SFC.
>
> As a first step, I think it would be good to add meters to provide “number
> of packets/bytes hit due to policy at the ingress and egress of the entire
> SFC” and to realize that, we would need to add specific pollsters. We can
> use neutron_client API to fetch the ingress and egress port details and
> fetch the corresponding flows for those specific ports(also get flow_infos
> from flow_classifier and then use them to dump_flows matching those
> flow_infos) and fetch the no.of packets hit due to policy from them.
>
>
>
> I have just mentioned my idea on this. Can I please know your opinion on
> this and provide your comments?
>
>
>
> Thanks and Regards,
>
> Rajeev.
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <https://clicktime.symantec.com/a/1/CFW6mq6RP1Xg7VmIF0xf9GVWE7cWx9DoRuE2kC1iV4c=?d=OZb6_jQ3JlDcR2AISJ1S1yWSl9wA-da9R6WweBZh8-1xFSm7MxSA9a4SYoOw7U5fTTE8TgbqfudjFvUJGjDkrnVR8mWytf4M3eN4AD71w1P20EuGgVBYqX2e4XU1RLCLPuDzEem8Pvb7DaVjt_oEU15hkt_CfSTEUKh58nKrnbrfyy9rDd5XIZscEY5gl3pbQ5CoXChMOmfq68AE2WCT9a01j26KThkBjxPJbv7zay4R1vkxAxl07G4VZ26lvhz-CLOS6io8hJGjhaWkAJN_i67NzGOXXjipBTRt860ew1Njxrns15bG_IJ58TV9RRw-EMQ0HNftqhXlA28RRbuLvqfjJmivRjKHrMXjeKah9B7TvU1XTn7fAwJvIbcHA8zejHC_MUDNNpDMJQ7RfC6A0v5hl8qhiG2UCM-axWeSN5erVE652SbORAGMTScANtK7PL02O8Da9-W30pJr9e8haxOIGYVgHA%3D%3D&u=http%3A%2F%2FOpenStack-dev-request%40lists.openstack.org%3Fsubject%3Aunsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> <https://clicktime.symantec.com/a/1/xn9X1vSILl8BWLcQPzBsMQKCIAopQNCI4Y81WpGpdnk=?d=OZb6_jQ3JlDcR2AISJ1S1yWSl9wA-da9R6WweBZh8-1xFSm7MxSA9a4SYoOw7U5fTTE8TgbqfudjFvUJGjDkrnVR8mWytf4M3eN4AD71w1P20EuGgVBYqX2e4XU1RLCLPuDzEem8Pvb7DaVjt_oEU15hkt_CfSTEUKh58nKrnbrfyy9rDd5XIZscEY5gl3pbQ5CoXChMOmfq68AE2WCT9a01j26KThkBjxPJbv7zay4R1vkxAxl07G4VZ26lvhz-CLOS6io8hJGjhaWkAJN_i67NzGOXXjipBTRt860ew1Njxrns15bG_IJ58TV9RRw-EMQ0HNftqhXlA28RRbuLvqfjJmivRjKHrMXjeKah9B7TvU1XTn7fAwJvIbcHA8zejHC_MUDNNpDMJQ7RfC6A0v5hl8qhiG2UCM-axWeSN5erVE652SbORAGMTScANtK7PL02O8Da9-W30pJr9e8haxOIGYVgHA%3D%3D&u=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev>
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170810/312cf0a6/attachment.html>


More information about the OpenStack-dev mailing list