cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
358
Views
0
Helpful
26
Replies
khgrant
Cisco Employee

Service Assurance GTM models - probing for your expertise and market understanding on customer preferences

 

Team,

 

 

CVG, under leadership of Paola Arosio, Product Manager for Assurance, is looking to better understand what SP’s preferred GTM models would be for Service Assurance platforms.

 

 

Therefore we are reaching out to you, our field experts.

 

 

Could you be so kind to look at the attached and reply, within the next 5 days, to Paola and myself with your thoughts and understanding on this.

 

We will than convert this into a comprehensive report and share it back with you. Paola will use this as guidance for the further development of Cisco Service Assurance platform strategy.

 

If any question let us know and thanks in advance.

 

 

Regards,

 

Paola & Tony

 

26 REPLIES 26
khgrant
Cisco Employee

 

Hi Tony,

Could you please describe which are the target segments for the product? The answers will be different for each segment.

 

Roque

 

khgrant
Cisco Employee

 

Roque, thanks

 

All SP, cable, mobile, wireline, green and / or brownfield deployments. You can add this in the comment section. Thanks

 

Regards,

 

Tony

 

khgrant
Cisco Employee

 

Hi Roque,

 

An information about the segment is appreciate as well. Of course being part of the SP group my first target is SP indeed I believe there are differentiation also in the SP market depending on Tier 1, Tier 2 and Tier 3/4.

 

Paola

 

khgrant
Cisco Employee

 

Tony

 

 

From what we learn from our engagements, there will be variations case by by case.

 

 

Just like the VMS platform, there is higher interest in a consumption model (Cisco build and SP consume)

 

    • Faster time to market

    • SP does not want to deal with new complexity, or they feel they might not have the skills on day one

    • Cisco knows better how this should be deployed and managed

    • Economies of scale

    • etc

  However, just like VMS platform, there are several considerations for “as a Service" 

    • Data sovereignty – problem for Option 2

    • Legal and commercial – Cisco owned assets situated in the SP’s premises – problem for Option 1

    • Cost – TCO should not kill the business case of the service

    • SLA provided

  Additional comment on "pre-packaged" 

    • How is the capability to integrate with SP’s processes and current tools?

 

Hope this helps.

 

Regards

  Khay Kid Chow | Customer Solutions Architect, GSP ANZ

khgrant
Cisco Employee

 

Folks, people have been asking for the attached file, which was in the original email.

 

For your convenience please find it attached again. Don’t hesitate to provide your perspectives, we are getting some good inputs now. Thanks

 

Regards,

 

Tony

 

khgrant
Cisco Employee

 

Before discussing GTM model options, I would like to make sure if we are on a same page.

 

In my view, service assurance is a complementing system to service orchestration.

 

- Service orchestration : Fulfilment/provisioning/configuring, CRUD

 

- Service assurance : Event handling/correlation, Fault detection/prediction, RCA..

 

And I hope both are model-driven, and they can be integrated to create possible feedback loops.

 

Also, there could be some pre-requisites for the analytics. e.g. to determine what are necessary info to collect and use models to designate them, or to gather all available logs/events. In addition, I’d like to have a certain concrete data on how well the machine-learning-based-analytics solve real problems. This should be a big value proposition compared to legacy OSS based assurance solutions.

   

I know some works have been done for vMS. But this question is more generic, isn’t it?

 

Thanks!

Miya

 

khgrant
Cisco Employee

 

Hi Miya,

 

You are spelling this out correctly

 

- Service orchestration : Fulfilment/provisioning/configuring, CRUD

 

- Service assurance : Event handling/correlation, Fault detection/prediction, RCA..

 

Indeed as you are spelling this out it means that orchestration and assurance are completing the full service lifecycle but they stands equally, i.e. you cannot assure a service that has not been deployed and you cannot indeed deliver a service to your end customer without being able to monitor and meet customer SLA.

 

This does not means indeed that the insertion of service assurance is only limited to where orchestration is inserted, it is only one of the below 3 deployment models, i.e.:

 

1)      MANO and orchestration driven

 

2)      Infrastructure driven (I need to actually be able to monitor my infrastructure – we have multiple insertion of MOOG standalone in this case where there is need of fault analysis)

 

3)      SP Solution driven (i.e. VMS, Mobility etc.)

 

Each on is dependent one on the other but the two are actually standing on their own – of course closer integration between orchestration and assurance is required in the virtualized world.

 

 

Paola

 

 

khgrant
Cisco Employee

 

Hi!

 

mmmm, the below definition of service assurance is very much bottom-up, the classical view:

 

- lets collect traps, logs, and do a magic look-up/function to understand the service health

 

We have tried that for decades, google on research on service impact, alarm correlation etc and see the amount of attempts Big-data is no magic wand for bottom-up calculations, someone still needs to write the map reduce function

 

We must also look at top-down definitions of service assurance, measure *service KPIs*, I repeat *service KPIs*.

 

This is nearly impossible to do with device data as a starting point.

 

See:https://youtu.be/qS1v4JCVeYQ

 

And, some people get it wrong, collect device data, map that to NSO service topology.

 

Still does not help, what is the KPIs for a specific video-stream for a specific customer?

 

Old grumpy failed alarm guy

 

br Stefan

 

khgrant
Cisco Employee

 

Hi Stefan,

 

 

he required attribute of the next generation service assurance system have been defined and validated, you are pointing out an essential one but it is not the only one.

 

 

I suggest team to attend the session that was presented to the Cisco Knowledge Network on the 7th October that goes through the importance of each one of the required attributes so everyone is on the same page:

 

 

               (1) Open and modular, aligned with Big Data framework

                (2) Analytics based OSS functions applied across physical and virtual infrastructure

                (3) Service Model driven assurance

 

 

Paola

 

 

Paola Arosio

 

MANAGER.PRODUCT MANAGEMENT

 

khgrant
Cisco Employee

 

Hi!

 

Yes we agree, bottom-up *and* top-down is needed.

 

Just reminding people on this thread about the top-down and that we stick too much to the bottom-up thing which the industry has tried for decades (myself 10 years at HP) /s

 

/Stefan V

khgrant
Cisco Employee

 

Hi Paola,

 

 

Thanks for the video. I listened to the video and saw the presentation. I will fill your file today during my next trip.

 

 

Having worked in an RFP with Deepak I have some generic comments:

 

 

1- Push vs Pull relationship with NSO:

 

At the beginning of your presentation talks about “service discovery”  done by the AS system. I heard that already several team in discussions with your team. I want to make sure that we are in a push model where NSO needs to always be master and push the service-level changes to the AS system. This means that NSO configures the AS systems on what it needs to be collected and calculated and later on will be querying the AS system for reporting.

 

 

2- Non-NFV use cases:

 

We need to create a GTM that covers non-NFV use cases, which are the majority of NSO insertions. NSO is still competing against integrated solutions, particularly in areas such as mobile back-haul or metro-ethernet. I believe a simple orchestrated assurance solution performing simple service level performance and alarm management. There is always time to add modules to sell.

 

 

3- Brown-fields (existing Assurance stacks):

 

In a couple of projects that I was involved, the customer was only interested in simple assurance support. We basically needed to forward all performance, syslog and alarms to their existing systems with no processing needed. We should be extremely aggressive here. This point is essential as the assurance system is typically managed by a different team from the one managing the RFP/RFI.

 

 

Regards,

 

Roque

 

 

khgrant
Cisco Employee

 

In line. 

Paola

 

 

               1- Push vs Pull relationship with NSO:

 

                              At the beginning of your presentation talks about “service discovery”  done by the AS system. I heard that already several team in discussions with your team. I want to make sure that we are in a push model where NSO needs to always be master and push the service-level changes to the AS system. This means that NSO configures the AS systems on what it needs to be collected and calculated and later on will be querying the AS system for reporting.

 

[Paola] There is no service discovery done by the Assurance system – the Assurance System get the information around the service for the orchestration/fulfillment system.

 

For changes in the network, those are done by the orchestration/fulfillment system the AS can trigger the notification to the orchestration/fulfillment for changes required in the network/service.

 

 

               2- Non-NFV use cases:

 

                              We need to create a GTM that covers non-NFV use cases, which are the majority of NSO insertions. NSO is still competing against integrated solutions, particularly in areas such as mobile back-haul or metro-ethernet. I believe a simple orchestrated assurance solution performing simple service level performance and alarm management. There is always time to add modules to sell.

 

[Paola] Completely on board on this. Indeed we are positioning service assurance for both physical and virtual infrastructure. Moreover the positioning happen in the context of the NFV discussion since this is the initial topic that is discussed but the conversation shall bring up the fact that the system can be leveraged today for the existing physical infrastructure (i.e. this is the reason why we resell MOOG).

 

 

               3- Brown-fields (existing Assurance stacks):

 

                              In a couple of projects that I was involved, the customer was only interested in simple assurance support. We basically needed to forward all performance, syslog and alarms to their existing systems with no processing needed. We should be extremely aggressive here. This point is essential as the assurance system is typically managed by a different team from the one managing the RFP/RFI.

 

 

[Paola] Ideally in this situation customer need only the Domain Manager and ideally we provide the collection layer ONLY of the assurance stack and open API (i.e. RestFull) to be able to access the information collected.

 

 

khgrant
Cisco Employee

 

Definitely agree with Khay Kid.

 

We encounter both cases.

 

In many situations it would be dictated by service orchestration strategy as well as Operations vs. IT/OSS relationships.

 

My question is: why can’t solution do both?

 

If it’s truly modular and scalable it should be able to satisfy both cases, should it not?

 

 

Thanks,

Steven Smichok

khgrant
Cisco Employee

 

Hi Paola

 

Great video. Can you please send me a Powerpoint version of the slides?

 

Regards

  Khay Kid Chow

Create
Recognize Your Peers
Content for Community-Ad