cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

445
Views
0
Helpful
1
Replies
khgrant
Cisco Employee

ConfD and NCS

I believe NCS is only supported for IOS, IOS XR and NX OS, right? What is the plan to support IOS XE platforms like (ASR920,902,903 etc.)? To whom I need to work with to bring XE platform Support?

2.How can we enable Confd support on ME1200 (Linux based platform) and ME4600? What is the procedure? Who is the PM? Is there any Roadmap Slides which you can share with us?

3.What is the advantage of using Native NETCONF/YANG vs Confd? What are the Memory and CPU requirement? ME1200 is NID very small and cheap platform so just wanted to see how we can bring support on that platform.

4.How do I check What are the service packages/features already available in NED? Do we supported EVC configuration? How hard to build a new feature support? What is procedure again to add feature support in NED XR/NED IOS? What is the timeline? Who will do the development? Tail-f team will provide support to add features or BU needs to work on it?

5.Can I use NCS with any platform Today?

1 ACCEPTED SOLUTION

Accepted Solutions
khgrant
Cisco Employee

NCS can interwork with IOS XE today (e.g. There is NED support)

2.Adding Conf D to a platform (such as ME1200 or ME4600) is a engineering effort for the platform team rather than a Conf D engineering effort. Conf D is essentially a SW product which the product team integrates their code with via API´s. Decision to leverage Conf D is therefore a PM / Engineering decision on the platform team (e.g. Build vs. Buy)

3.Conf D is a proven technology (75+ customers), comes with built in characteristics that saves development time and effort + offer operational predictability (transactions, rollback, automation, feature consistency by virtue of auto rendered northbound interfaces etc.). In your case it sounds like your starting point is to analyse Conf D as a vehicle to get Netconf/YANG support on two already shipping products. In such a case you essentially have to decide whether you are better off rewriting the existing code to work with Conf D (giving access to the Conf D goodies) or whether you are better of adding Netconf/YANG natively.

4.The way to determine whether your use case is supported is by taking your config file (sh running or equivalent) and comparing it with the NCS YANG representation of your product. We have customers doing a variety Carrier Ethernet wire services but I would recommend an analysis of your desired config file. Adding features and functionality to a NED supported platform is typically not that complicated, it is predominantly a matter of engineering resource prioritisation. The process for getting things done is customer driven and thus you need to engage with the NCS overlay sales team to register your opportunity. Similar to Tony, the NCS sales team reports to Hal Gurley. While NED work is in some cases performed by 3rd parties such as product teams it is done in concert with Tail-f engineering (following Tail-f quality assurance process) to ensure the quality of implementation and integrity of the orchestration system.

5.NCS supports a broad set of platforms and we have yet to find a networking platform that we can not support using the NED approach. That said, can you be a bit more specific?

View solution in original post

1 REPLY 1
khgrant
Cisco Employee

NCS can interwork with IOS XE today (e.g. There is NED support)

2.Adding Conf D to a platform (such as ME1200 or ME4600) is a engineering effort for the platform team rather than a Conf D engineering effort. Conf D is essentially a SW product which the product team integrates their code with via API´s. Decision to leverage Conf D is therefore a PM / Engineering decision on the platform team (e.g. Build vs. Buy)

3.Conf D is a proven technology (75+ customers), comes with built in characteristics that saves development time and effort + offer operational predictability (transactions, rollback, automation, feature consistency by virtue of auto rendered northbound interfaces etc.). In your case it sounds like your starting point is to analyse Conf D as a vehicle to get Netconf/YANG support on two already shipping products. In such a case you essentially have to decide whether you are better off rewriting the existing code to work with Conf D (giving access to the Conf D goodies) or whether you are better of adding Netconf/YANG natively.

4.The way to determine whether your use case is supported is by taking your config file (sh running or equivalent) and comparing it with the NCS YANG representation of your product. We have customers doing a variety Carrier Ethernet wire services but I would recommend an analysis of your desired config file. Adding features and functionality to a NED supported platform is typically not that complicated, it is predominantly a matter of engineering resource prioritisation. The process for getting things done is customer driven and thus you need to engage with the NCS overlay sales team to register your opportunity. Similar to Tony, the NCS sales team reports to Hal Gurley. While NED work is in some cases performed by 3rd parties such as product teams it is done in concert with Tail-f engineering (following Tail-f quality assurance process) to ensure the quality of implementation and integrity of the orchestration system.

5.NCS supports a broad set of platforms and we have yet to find a networking platform that we can not support using the NED approach. That said, can you be a bit more specific?

Create
Recognize Your Peers
Content for Community-Ad