cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
94
Views
1
Helpful
11
Replies
Highlighted
Cisco Employee

Inventory data: Better inside or outside of NCS ?

Hello team,

next week we’re demo’ing NCS to DT Fixed Backbone as engine to deploy network services.

One question we anticipate is around constructing the correct device config based on SW and HW on the network element, i.e. sometimes a new HW generation requires an additional command or parameter.

From Hakan I learnt that the recent IOS-XR NED has a version branch that tracks the SW version running on the device.

Q:  Would it make sense to also keep track of inventory in NCS, e.g. to resolve those HW-dependencies, or is this something we should clearly keep outside of NCS, and rather pull the data from (likely) existing DB’s ?

How are other customers operating here?

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

Would be interesting to know more about “inventory data”.  What you describe (dependencies) are something that service modeling might handle – many inventory systems are lacking this (and it becomes a big reason why an Amdocs/Cramer or an Ericsson/Telcordia systems become expensive – they need coders to determine the impact for every minor change in a network element). 

The inventory systems also have information on the device that NCS doesn’t store natively – location information or financial/asset management (when purchased, what PO number, depreciation schedules, etc…).  NCS may be able to sync with inventory for this information.

11 REPLIES 11
Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

Would be interesting to know more about “inventory data”.  What you describe (dependencies) are something that service modeling might handle – many inventory systems are lacking this (and it becomes a big reason why an Amdocs/Cramer or an Ericsson/Telcordia systems become expensive – they need coders to determine the impact for every minor change in a network element). 

The inventory systems also have information on the device that NCS doesn’t store natively – location information or financial/asset management (when purchased, what PO number, depreciation schedules, etc…).  NCS may be able to sync with inventory for this information.

Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

Inventory is a hot topic in the IETF, a lot of drafts that you could leverage on your engagements:

https://tools.ietf.org/html/draft-dong-i2rs-network-inventory-00

This basically re-created the SNMP ENTITY-MIB

Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

I’ve on a service provider deployment in which inventory data was captured and stored within NCS to allow hardware dependent service activation. I am also working with another customer who will probably take a similar approach.

Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

Is this about recording, for each NCS device, exactly which model it is, and which hw it has ???

Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

Well, I've done some work where /ncs:/devices/device with operational data pulled from each device (Juniper). Once services are activated they consult the operational data to properly configure the service based on the operational data stored in the CDB. As I mentioned below, we have another customer likely to go in this direction as well as they have hardware specific services which would require something similar for Cisco devices.

Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

So, that's what I asked - and sure - this is absolutely an excellent idea.

As a matter of fact, all NEDs could just support this out of the box IMHO.

Would that be worthwhile, forcing all NEDs to be able to do that, and then we'd record this data in a std place under /device/device[name='foo']/model  ... or some such ?

By worthwhile - I mean - is it better to do this on a per project basis - or should we enhance the NED api to be able to report this data - always ?

Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

I think it would be great to auto-populate some of this information by the NEDS out-of-the-box. I do worry a bit that we have a very generic inventory model, such that it might not have the details really need for a service specific activation. But since everything is model based, perhaps this type of solution would be easy extended.

Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

The inventory data is considered as outside the boundaries of the Orchestration/Provisioning platform. Indeed tail-f is open and flexible but we need to decide if we are making it a “coding" project to develop functionality or focus on its main goal. Once you start looking at what Inventory means to customers you are entering a new area which does not start/end at polling physical inventory from a device, you’ll need to provide history keeping, reports, comparison and much more than the raw data.

Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

many thanks for the active discussion so far. I already expected this not to be a black/white topic.

I will have a sync with Dan on Monday to understand what he already implemented.

If DT expresses requirements on top I will share them with the team so we can converge to a common understanding.

Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

Looks like a long e-mail thread, this shows the importance of the subject.
Warning: look up the definition of words in all possible places. Cisco is nototious for bending definitions so it fits the device we produce.


What inventory are we talking about?  During a study I did 12-13 years ago we came up with 2 collections of data that make up the "technical" inventory. "technical" means we left out financial and logistics aspects (e.g. spare parts on shelf).

Collection#1: physical and logical inventory, which clould be simplified as the HW + the config files contents

Collection#2: subscriber-contract-service, those are the reasons why networks are built, without them networks only exist in research labs.

It happens that provisioning as it was called in those days is concerned with linking these 2 inventories together.

NCS/NSO as we know it today exclusively works on Collection#1.  From this point of view inventory is "inside".  Collection#2 is not touched nor modified at all, from the latter point of view inventory is "outside"

The study also highlighted that without ***common*** inventory systems fail or become very expensive, you can ask Cramer and Telcordia about that, they have tried all kinds of proxy and federation techniques.  To be common you need to have the same model on both sides. A human-readable model has advantages. A recursive, hierarchical modelling language is superior to linear ones (ask SNMP people)  All the abstraction verbiage serves to hide the absence of common models.

And finally the study highlighted that once you have common data the association between objects is much more important then the objects themselves.  NCS's fastmap and java packages that instantiate services do exactly that on Collection#1.

Conclusion: I am fundamentally opposed to the view of Gil; inventory MUST be used by orchestration-provisioning platforms, even Collection#2 because a change in inventory always influences how the network behaves.  Ignoring this will make your information-processing system irrelevant, which is not what we want for NCS.

Suppose the GLP of Cisco and Huawei inverses => al of a sudden lots of "services" will be orchestrated using the other model. NCS will need new java code, just like Cramer.

Suppose a hacker makes use of all kinds of networking gear => nobody pays for that useage, NCS should be able to eliminate the configurations from the config based on the fact that there is no customer-contract-service making use of that logical/physical inventory.

Suppose Cisco buys another tail-f or discovers the hidden features of RT-OSS => will there be 2 inventories? Synchronization is expensive (Cramer and Axiom know all about that)  one common logical inventory seems like a lot better.  Now NCS has the choice

    • consume inventory from some place = consume from the golden source

    • produce (a part of) the inventory to others = produce golden info

    • consume a part and produce another part = this seems the situation today

The choice for RT-OSS is the same, but the "parts" are different.

Wheter we like it or not "inventory" MUST be handled appropriately by NCS, starting by a clear definition of what data collections are consumed and what collections are produced.

Cisco Employee

Re: Inventory data: Better inside or outside of NCS ?

What you say about the necessity of using a single model for managing Collection#1 and #2 makes good sense, and I agree that this gap has been a major contributor to the cost of running networks for decades.

I'm surprised, however, when you say that NCS deals exclusively with Collection#1. As far as I understand the terms "subscriber", "contract" and "service", NCS is definitely dealing with that. In fact the term service, as in resource facing service, is at the heart of what NCS deals with. Most customers do not currently model customer facing services, customers and business contracts using YANG -- but this is possible, and some actually do model customers/tenants, customer facing services, SLA information, etc.

Every NCS deployment is subject to the requirements of the end customer, so the scope varies, but there is certainly nothing preventing Collection#2 use cases. We even provide ready made models for some of these things, e.g. customers, CFS, that some augment to add in their own specifics, like SLA references.

In projects where NCS has been used to implement service discovery, we do find those "rogue" services that are live in the network, but aren't connected back to any customer or contract.

Content for Community-Ad
August's Community Spotlight Awards