cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
68
Views
0
Helpful
7
Replies
Cisco Employee

Redesign of customer configlets for integration with NCS

DT has a repository of almost atomic configlets that are stacked to produce a router configuration for service deployment.

These configlets contain actual router CLI including variables that are replaced.

We have 2 hierarchies of conditional config creation:

    1. Depending of service flavor configlet_A or configlet_B get loaded  (red dotted line in the diagram)

    1. Within a configlet, conditions may check for feature and HW support to select CLI_A vs. CLI_B.

Some configlets again call others per “include” statement (not shown in the picture).

Maintaining these configlets (there are 100+ per vendor) is a pain point currently.

I’d be interested in what could be the best design option to reduce the complexity for maintaining the configlets and represent it in NCS templates.

Optimally we find a way where

    • the service owner specifies only required features for a service flavour, e.g. ip-address, cdp, uRPF, qos-in, qos-out, instead of the actual CLI commands

    • NCS is able to find matching template(s)

    • NCS fills the template(s) with the information we receive Northbound or calculate in Java

Everyone's tags (6)
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Re: Redesign of customer configlets for integration with NCS

Let me come back to your original question on conflets.

This is a great question to receive from customers. It is really the tip of the iceberg when looking at the changes that installing NCS can produce in a SP  not in terms of technology but in their internal processes. It is also a challenging question as we need to be careful to not introducing too much risk and jeopardise the opportunity.

I received a similar request from Telefonica a month ago. The question something like “how can we make conflets pretty when moving to NCS” (they have a WIKI where they copy and paste configs).

See attached the slides that I presented to them. If you look at the transition from slide 1 to slide 2, you will see that what you want in the long run is that any intermediate product (such as conflets) to disappear. It may sound radical but it is about introducing the maximum agility by having modularity based on standard interfaces. A Wiki or any config repository outside of NCS needs to be maintained and introduces inter-dependencies that you want to avoid.  The idea is to substitute these products by some our great NCS features: “request service * check-sync/re-deploy/get-modifications”. Moreover, it is important that customers understand the need and value of test-cases, not as stand-alone product without maintenance but as integral part of the service development process. With test cases, you have a configuration output that lives with the same life-cycle as the service in itself.

That, I believe, should be our long-term vision. However, I needed to go back to “how do I make my configurations pretty” and you can see in slide 6 three different ways to express a device template in NCS compared with their original wiki.

View solution in original post

7 REPLIES 7
Highlighted
Cisco Employee

Re: Redesign of customer configlets for integration with NCS

We have a very similar situation at Vz. I'd like to hear the recommendations

Highlighted
Cisco Employee

Re: Redesign of customer configlets for integration with NCS

Don't be too distracted by DT's legacy approach to provisioning these services. Start first with applying service modularity to the portfolio, with service components designed in a way to minimize interdependencies.  This modular hierarchy then becomes the template for your YANG service model design. The details of what config changes get pushed to the devices will then fall out naturally and DT will have a truly modular service with reusable service components that are decoupled from the underlying infrastructure. This will maximize their service agility and the economic value delivered by the Platform. For more technical details, reach out to Roque Gagliano in our Tail-f sales team.

Highlighted
Cisco Employee

Re: Redesign of customer configlets for integration with NCS

I agree. Redesigning a service to let NCS shine would be the best approach, but is not always possible in beasts like DT to to complex and slow OSS change procedures.

E.g. we asked to get their attribute-based XML data changed to element-based input for NCS; DT responded this will take 2+ years or OSS integration.

I am wondering whether the attached drawing represents something in-line with NCS design principles.

    1. “Service In” represents the service data NCS receives Northbound from the OSS

    1. NCS would understand (by Java code), which service flavour we should deploy.

    1. NCS creates a service instance of the recognised flavour.

In my vision such solution potentially achieve the following:

    • Leave the NB interface untouched, avoid additional integration/insertion cost

    • The technical service owner could define the service flavours in a more abstract way than today’s CLI-based configlets

    • OSS may one day natively request the service flavours

I’m though wondering whether such an approach would not create a too huge indirection in the service provisioning process and scare the customer with the Service-Service mapping.

Highlighted
Cisco Employee

Re: Redesign of customer configlets for integration with NCS

Let me come back to your original question on conflets.

This is a great question to receive from customers. It is really the tip of the iceberg when looking at the changes that installing NCS can produce in a SP  not in terms of technology but in their internal processes. It is also a challenging question as we need to be careful to not introducing too much risk and jeopardise the opportunity.

I received a similar request from Telefonica a month ago. The question something like “how can we make conflets pretty when moving to NCS” (they have a WIKI where they copy and paste configs).

See attached the slides that I presented to them. If you look at the transition from slide 1 to slide 2, you will see that what you want in the long run is that any intermediate product (such as conflets) to disappear. It may sound radical but it is about introducing the maximum agility by having modularity based on standard interfaces. A Wiki or any config repository outside of NCS needs to be maintained and introduces inter-dependencies that you want to avoid.  The idea is to substitute these products by some our great NCS features: “request service * check-sync/re-deploy/get-modifications”. Moreover, it is important that customers understand the need and value of test-cases, not as stand-alone product without maintenance but as integral part of the service development process. With test cases, you have a configuration output that lives with the same life-cycle as the service in itself.

That, I believe, should be our long-term vision. However, I needed to go back to “how do I make my configurations pretty” and you can see in slide 6 three different ways to express a device template in NCS compared with their original wiki.

View solution in original post

Highlighted
Cisco Employee

Re: Redesign of customer configlets for integration with NCS

thanks for your input. Please excuse my late reply as I was on a customer meeting yesterday.

>> ... in the long run is that any intermediate product (such as conflets) to disappear.

I agree, but IMHO service templates or device templates are only a different representation of what we are substituting.

>> A Wiki or any config repository outside of NCS needs to be maintained and introduces inter-dependencies that you want to avoid.

This is exactly what we want to do and looking for a nice transition proposal. Only showing how we move from configlets to xml templates certainly will not get us far in DT.

The level of automation is already pretty high in the IP2 environment, so we’ll need to find additional motivations.

The value DT is expecting to reduce to work to maintain either configlets or templates.

Highlighted
Cisco Employee

Re: Redesign of customer configlets for integration with NCS

In reading below “reduce to work to maintain either configlets or templates”  -  can you also use the angle on services lifecycle and ability to redeploy with updates?

Highlighted
Cisco Employee

Re: Redesign of customer configlets for integration with NCS

Transactional automation of existing services brings a certain value, but due to the service modularity aspects of NCS (discussed earlier in this thread) the BIG benefit for DT will be the incremental investment they need to make in developing any future services and service features.  In other words, business agility.  This has two economic value drivers:  1) reduced service development investment, and 2) accelerated cash flows from future services being launched more quickly into the market.  The latter point especially can deliver a substantial net present value depending on the scope of the service.  This resonates especially with Product Management stakeholders in the SP (vs. Operations) as TTM is a major pain point for them.