cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
96
Views
2
Helpful
20
Replies
Cisco Employee

Reducing the OSS integration by inserting NSO

We have started an internal discussion with the CVG BU regarding inserting NSO between the OSS layer and the multi-vendor EMS layer in order to provide seamless management across multi-vendor network and reduce complexity, reduce IT integration, having at the end less touch points.

What we have heard back is that NSO must talk directly to the network devices and not to the EMS’s as it will break the transactional manner of how tail-f works and therefore we will not benefit from having it.

Can I get your view on this? We sell the ALU 5620 NED, so therefore we can achieve this transnational functionality with 3rd party vendor but not with our own Cisco NMS tools?

OSS Integration by inserting NSO.png

Everyone's tags (6)
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

I believe the answer I'm seeing through the thread is that we do not mandate replacement of EMS systems for the purpose of NSO to function, in fact this is really our differentiator, being able to orchestrate in a multi-vendor dynamic environment. If you need next level technical details, I suggest you call a meeting with Carl/Urban/Stefan.

I can help with any positioning questions you may have.

View solution in original post

20 REPLIES 20
Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

I also heard the rumour that NSO must talk direct to a device. There are certainly some advantages in doing that but having NSO talking to an EMS or a controller (like APIC) for that matter works fine as well. In some cases you have to talk through an EMS as the device does not have an open interface for NSO to access. In a multi vendor network you could end up in a mixed scenario where NSO talk directly to some devices and through an EMS for other devices.

In many cases there is an advantage when it comes to configuration and provisioning to have NSO talking direct to a device. NSO also has a very powerful concept in how we support device mediation, typically order of magnitude better than what you find in an EMS.

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

The way we position the horizontal NSO offering is in a modular fashion with strong focus on what our orchestrator does really well. The target market for this are the customers that need the freedom build solutions by picking and choosing across their target architecture. Some of the moving parts will be from cisco, other parts will be legacy in-house or from other vendors.

Cisco also builds integrated products to your point above. We have three in the development pipeline as far as I know: vMS, Mobility and multi-layer. These are distinctly different from NSO in that they target very specific challenges and they are (at least at this point) cisco-only solutions top to botton. This is in contrast with NSO which assumes nothing about the services and expects multi-vendor and integration with surrounding systems.

“””

So what I believe we should be thinking about is this: should we have an orchestrator that is independent of the existence of any EMS layer for provisioning and activation or should we mandate/push for EMSes as a mandatory part of our value proposition?

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

I believe that having the mixed option of direct to the device OR through an EMS is considered our solution strength.

Again, what I am worried about is the comment from CVG that says : going through the EMS means loosing functionality, are we jeopardizing the service?

In the past we had Cisco provisioning tools who were capable of provisioning a network ONLY if their were the sole entity configuring it, if someone used CLI in parallel, the provisioning system could have caused the service to break and an outage. Are we there with NSO?

My understanding is NO, can you help me to clarify that?

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

We have built NEDs that provision through the CLI and upload via the EMS (or vice versa). 

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

I am fully aware of that, but my question remains the same, what are we loosing if we go thorough EMS NED vs through a device NED?

OR maybe the answer is already here, we need to develop a Cisco NMS NED to preserve the NSO functionality.

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

I guess there is no single answer to this as there is no one size fits all. Following parameters will play a role:

  • Simplicity of the overall EMS <-> NMS <-> OSS stack.

  • Functional capabilities and API’s of the xMS’s over the NE.

  • Implementation / development efforts and cost (BC), required business process optimization.

  • Project phasing, NE interaction first, xMS in 2nd phase?

These are just a few.

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

We can all agree that having a single line in the drawing going from OSS/BSS to NSO will ease the total integration work and I assume cost associated with it.

Can I be safe by saying that it does not matter if the user configures a service trough the EMS/CLI/tail-f the service will not break?

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

if it’s done in a proper way the service should not break / fail but each approach has its own level of complexity and risk for inserting human error.

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

Of course human’s make mistakes but this is exactly why we need this software.

Since I have started this thread I have received many responses but not yet got an answer to my question.

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

What we have heard back is that NSO must talk directly to the network devices and not to the EMS’s as it will break the transactional manner of how tail-f works and therefore we will not benefit from having it.

If the question is, what will break if we go through an EMS instead of directly to a device? Then the answer is, it depends :).

Everything depends on what the EMS can do, if the EMS does network wide transactions then we will not loose that. If it does not well then we can only guarantee that the config NSO wrote is on the EMS, we can’t promise its on the devices.

Other than that it does not matter for NSO if its an EMS or another device. The EMS will be just another device (at least that is how we have done all EMS NEDs so far).

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

Thank you all for the feedback.

I will close this thread as at this stage I believe that I got what I was looking for.

In the next few days I will share with you the summary of things.

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

First,  it is clear that your sentence “NCS MUST talk directly to the network devices and not to the EM” is inaccurate and whoever is making such an assertion should be alerted.

Personally, I pitch NCS to talk directly to devices as first option. This is basically to enable a better modularity between the different orchestration parts. EMS typically introduce a number of interdependencies that reduces agility for the customer. Typical examples are features that are exposed by the devices APIs and not by the EMSes APIs. Additionally, with the (hopeful) raise of NETCONF as the configuration protocols for devices, we can have native transactions. Waiting for NETCONF in EMS would not be a good idea. In general the customer’s response is very positive on by-passing the EMS systems.

With regards to Cisco’s NMS, I believe it enters in our NED development process: if there is a paying customer that require us to do it, we will. Today, that is the case for UCSM.

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

I’m not sure where you picked this sentence from, it was never the message.

Looks to me that we need to provide our customers a choice of Cisco NMS NED (EPN M ND) in order to get to the same level of simplicity we offer with the 5620 SAM NED.

Thanks for your feedback.

Highlighted
Cisco Employee

Re: Reducing the OSS integration by inserting NSO

I believe the answer I'm seeing through the thread is that we do not mandate replacement of EMS systems for the purpose of NSO to function, in fact this is really our differentiator, being able to orchestrate in a multi-vendor dynamic environment. If you need next level technical details, I suggest you call a meeting with Carl/Urban/Stefan.

I can help with any positioning questions you may have.

View solution in original post