Showing results for 
Search instead for 
Did you mean: 
Cisco Employee

NSO GUI requirements


Hi there,



I keep seeing questions/requests around the NSO GUI. We have a very small GUI development team, and I would like to solicit input from this forum on how we can get maximum impact.



How do we think GUI impacts our sales? Our theory so far has been that our users don’t and wouldn’t use an NSO GUI for order entry. Can we validate that theory? Do we know of any NSO customers that don’t use some other system in front of NSO? How would such a customer be characterised? Certain size? Certain segment?



We could address our effort towards a number of audiences, e.g.



    1. Pre-sales, towards a buying audience:

      1. Cleaning up the current auto-generated GUI in order to enable demo/POC service models to be driven from a GUI (current top candidate)

      1. Example external GUI portal to enable the demo/POC developer to create a simple custom GUI for order entry (the problem with the current virtual MPLS demo is that the demo GUI is not an example of how we would advise our customers to create a GUI)

    1. Post-sales, for IT, for maintaining the NSO system

      1. Improving the admin GUI – how? Cleaning up GUI for users, credentials (internal/external), devices, device groups

    1. Post-sales, for operations

      1. Device management – device templates, policies, compliance?

      1. Cleaning up current auto-generated GUI? Unlikely that this would be used in operations

      1. Example external GUI portal? More likely candidate IMHO


IMHO, I don’t think a self-service portal should interface with NSO – this scenario would require order management functionality, but I’d be interested in your views on this.



Anything else?






Cisco Employee


Hi KJ,



We have a small SP in Israel that purchased NSO last year and, at least for the time being, intends to use it directly.


The current GUI cannot really be used, as some basic functionality is not really working (at least the last time I checked).



For example, the topic that was discussed few times here before: If you have a yang model with leafrefs to device names and ports on these devices – the list of interfaces according to the selected device is not being populated, so the user cannot see a drop-down list in a manner similar to ncs_cli.



I think similar issues exist with leaves/containers conditioned by when-statements, but am not sure about it.



Anyway, I think that some small customers might want to use the GUI – it doesn’t have to be pretty, but I think they might want it to be able to provide the basic stuff that ncs_cli provides for service activation.


I also think that during pre-sale / poc we should be cautious not to raise false hope that the provided gui can provide service-activation capabilities similar to the ones that the cli provides.







Cisco Employee


Telstra Ops and Cisco IT has requested a useful NSO Web UI for templates


*Real* users, hurray, not “just” Cisco sales



Daniels team put something together to get them through a POC:


Cisco Employee


Hi KJ,



In my opinion, the best return for investment would be to improve the auto-generated GUI. This will immensely help pre-sales. With pre-sales, there is a certain audience type that only see the value-proposition if it is communicated to them via some decent GUI.



It can also help post-sales admin/operators for small and/or initial installations - at times customers (network engineers) are looking for an out-of-box portal. That is after they finish building the service-packages, they would like to try it out in production on a small part of their network. Building just the service-packages is a steep learning curve for them and then having  to build a useable portal on top can be a big turn-off. Once they have successfully done initial deployment and want to expand, the organisation would be more willing to invest in a full blown portal solution.



I’m not convinced that “Example external GUI portal” would be of much value. There is a whole web-app industry out there, no point re-inventing the wheel.



Some of the line-items I’d like to be explored for improvement to the auto-generated GUI:


  1. The dynamic rendering of leafrefs based on user selection that Yftach points out below.
  2. Choice in terms of the landing page. For example, I’d like to land on a page with the services deployed in NSO.
  3. Ability to hide/unhide fields/tabs. At the moment actions/oper-data etc. all get rendered. Not very welcoming.
  4. Would be nice to be able to change style (CSS), placement of things across tabs, re-skinning etc.
  5. Ability to make the above customisation without having to do JavaScript. Perhaps as metadata/annotations in the service yang model itself.
  6. Some generic Graphing module which can be used to render things like topology, etc. Be able to click/drag and run “actions” on nodes.
  7. I’m sure I can come up with more items J






Cisco Employee





Agree with Bilal on auto-generated GUI being most impactful. Additional points to add:


    • For customers who are building a greenfield automation environment, they want to use some out-of-the-box GUI for an initial period while there is another team or project to build their GUI portal or other northbound system to consume the REST/API

    • Engineers want the auto-generated GUI to quickly check/validate and test their models

    • This is my opinion, and happy to be corrected - I feel a lot of middle management (those people with funding) feel better perceived value if they can see the outcomes through the auto-generated GUI than CLI-based interaction, even though this will be of interim use. In most cases, I feel Cisco’s scope might not include the northbound work order management or user portals as those always seem to cark us up.



If by “example external GUI portal” you mean a portal that is manually build to demonstrate one specific use case, this is certainly very useful to demonstrate that particular use case, but it might need to be modified to demonstrate other use cases.



Hope this helps.





Khay Kid


Cisco Employee


Hi Everyone,



I’ve been contemplating my response today. But no need as the ones below clearly capture our Advanced Services Mobility needs as well;



Working Gui to do POC, testing of new developed services, introduction of NSO to the customers without need for custom NB portal.





Cisco Employee





+1 for using GUI for POC’s and demo’s to customers who don’t have a NB portal.


It would be nice to have a stable GUI with enhanced look & feel and proper error handling with user-friendly messages.


Cisco Employee


I think it depends what you’re trying to sell. If you’re trying to sell NSO as a platform, then the generic operationally-focused GUI is fine. It’s a UI for NSO.



However, if you’re trying to sell (i.e. demonstrate or PoC) a very specific use case, then I think that a very lean and tailored UI is required. This will allow the customer to clearly see how NSO enables them to solve the specific operational issues or business outcomes they desire. Disclaimer: this is the approach that my team has taken in the construction of a PoC Web UI for NSO in APJ, so I am biased.



We have created a small, easily customised, Web UI framework written 100% in Java. All the HTML and JavaScript is generated server-side, so only the Java code needs to be changed in order to create a new use case. A new use case can be turned around in a couple of days. We have use cases for Layer 3 VPN, Layer 2 VPN, VNF management, and Zero Touch Provisioning for NSO with Autonomic Networking. The code is openly available for internal use and we encourage people to pull it and customise it for their own use:



Our approach was presented at the previous SEVT (at the 1:21 mark):



A video demonstration of our Layer 3 VPN use case portal for NSO:



We are currently working as part of the global Agile Development Team in GSP to create a common portal framework for GSP pre-sales PoC’s and demonstrations.



  .:|:.:|:.  Richard Wade






Thanks for the link and great work on a portal framework.



One important question: Why are you using the REST API and not JSON-RPC or NETCONF?  I worked with the EMEA innovation edge on a couple of project where we used NETCONF in Java (Tail-f open-sourced the client code) and it works great. With NETCONF you win transaction support and notifications. Notifications are a requirement when you use reactive fastmap.





Cisco Employee


Hi KJ,



My view is that we need to continue with the two side strategy:


- Best in class Self-rendered GUI with the target to be a tool for developers and operations (although the latest is a longer-term goal).


- Best in class JSON-RPC API for custom portals such as the Itential toolbox.



Now, I think the BU should think about a couple of areas:


1) We need to make usability a top priority. There are plenty of consulting firms that could help our developers to be way more user-friendly. I asked once, “why our GUI lands in the device-group page”? These sort of questions have very precise answers when you have a user-centric development strategy. Kalyan mentioned in an internal email that the new Juniper Orchestrator invested more than $1M in the GUI with a contract with a specialized user-experience company, that is the new competition we are against.



2) The issue with the examples' GUI is that it represents an “exception”. It is a modification of the NSO GUI that we cannot perform for other projects as we need an external portal to do so. As an exception, it is hard to set the correct expectations to the customer on what they can/cannot do.







Cisco Employee


I recently did a Proof of Concept for LG in which we automatically turned up internet and VPN services on ASR1k and ISR4k from a customer portal.


We used Itential Pronghorn as GUI on top of NSO.



It has auto-generated GUI (update yang wil automatically update the form) but can also federate information from multiple sources (IPAM, CPE shipping, Billing) before triggering NSO to orchestrate a service.


If information from multiple departments is required, it will also support workflow templates with work-queues in the operator portal.


The customer was very impressed and me as well.



We've captured the screens while executing the PoC and I'm working on creating a video showing the provisioning process end-2-end.


When it's done I plan to upload it internally.


Met vriendelijke groet / With kind regard,
Dirk-Jan van Helmond

Cisco Employee


Thanks everybody for your input – keep it coming.



Roque – see below




  1. KJ.



From: "Roque Gagliano (rogaglia)" <> Date: Wednesday, 7 September 2016 at 08:25 To: "Giri Venugopal (givenugo)" <>, "Julie Ann Connary (jconnary)" <>, "Khay Kid Chow (khchow)" <>, "Bilal Alam (balam)" <>, "Yftach Herzog (yfherzog)" <>, Kjetil Rossavik <>, "service_orchestration(mailer list)" <> Subject: Re: NSO GUI requirements


Cisco Employee


When the competition is a management system with a flashy interface, an auto generated UI will never be good enough. It’s cumbersome and easier to navigate those features through the CLI.



Given that a POC/demo is always focused around a particular use case, the UI needs to be tailored to that too. The current Virtual L3 VPN is a good example, but it’s too difficult to modify for other use cases unless you are an experienced Javascript and Dojo developer.



I would suggest we make it easier to build custom UIs by creating and documenting a framework and providing prebuilt widgets which can be reused an extended. Example widgets could be for topology, device views, VNFs, service chains, resource pools, alarms, rollbacks, plan view etc. In the same way we have a library of NEDs, we could have a library of widgets.



It would also be good to have something like the Ui Designer from Prime Fulfilment which is a graphical form designer. This means we can choose which items to display, in what order, the kind of input box to use etc. These forms are quick to build, and will always look better than something auto generated from the underlying yang model.



With this in place it gives us something credible to sell rather than saying it’s a throw away demo UI which has been built for a particular POC. We can say it’s a toolkit / library which can be bought and customised for production use. And where the customer is not interested in a UI, it will still enhance any demo where we say we are simulating / stubbing the system which would sit northbound of NSO i.e. portal / OSS / BSS.







Cisco Employee


In followup to this question of NSO API choice, could the NSO team comment as to what they would recommend as the “best API” to adopt given current NSO development roadmap? To be specific, this is for the development of a Web UI to present specific use cases based on NSO service models and workflow.



We currently use REST, but have hit some limitations when it comes to closer interaction with NSO for near real-time updates on device/config status. We have spoken with the EMEAR ADT who are using NETCONF, so are considering moving to that API. However, it would be good to get guidance from the NSO team with regard to future development plans, richness of the available APIs etc.






  .:|:.:|:.  Richard Wade

Cisco Employee


The simple answer is simplicity and it provides the capabilities we’ve needed so far. The team’s function is to provide rapid prototypes of applications or Web UI’s for demonstration or Proof of Concept to customers. Over time we may migrate to a different API, but at the moment a REST API provides us with a simple way of interacting with NSO which is independent of the language, libraries etc. that we develop in.


Content for Community-Ad
Cisco Community October 2020 Spotlight Award Winners
This widget could not be displayed.