Is there a guide out there to building a virtual topology for a service I created over multiple devices:
Currently I have the links hard coded and I choose the devices. I’m interested in how to take this service to the next step by using a virto model:
Solved! Go to Solution.
When will we ever get virto to a drag and drop icon model?
Keith and John
This is what I was discussing last Friday.
Let's add to the list of Vms short comings.
If I'm not mistaking, I think APIC-EM has this feature in there topology manager
Not to hijack the thread, but assuming that APIC-EM or some other platform has that information, couldn’t you have a NED talk to the API of that device and get the topology from it? I thought that was one of the reasons we are having NSO as the orchestrator in our high level ESP arch, as it can talk across platforms.
BU, have we gotten that far in the development to be able to pull topology from APIC-EM, WAE, etc.?
examples.ncs/service-provider/mpls-vpn is a more interesting example.
You can drag any device node to a different location.
This map is automatically built from the service model.
I’ve been studying this example and I have the following question:
If you have to specify the Topology connections per:
topology connection c0
endpoint-1 device ce0 interface GigabitEthernet0/8 ip-address 192.168.1.1/30
endpoint-2 device pe0 interface GigabitEthernet0/0/0/3 ip-address 192.168.1.2/30
topology connection c1
endpoint-1 device ce1 interface GigabitEthernet0/1 ip-address 192.168.1.5/30
endpoint-2 device pe1 interface GigabitEthernet0/0/0/3 ip-address 192.168.1.6/30
Does this topology connection actually configure the PE to CE BGP configuration automatically or is it expected that this link is already in place with BGP configured and we are just defining an existing link to the topology? Later in the readme it also shows adding in new CE topology connections.
If we get a tool to do the reverse in the future, i.e. use a topology builder to build a service topology and then the tool automatically generates the service model. Along with that if there is option to define all required parameters of devices/underlay so that the tool can also auto-generate a baseline fastmap/Java code that experts can review, validate and fine tune – then we are a few steps closer to “Nirvana” :-)
Feel free to kill me if this sounds too ambitious and smoky ;-)
The tool to “automatically build topologies” exists: Cisco WAE. There are some ideas to integrate NCS and WAE so that NCS could read topologies from NCS. WAE is L3 topologies only at this time. For L2 topologies discovery, we have an NCS add-on (not maintained) that can read CDP/LLDP but most L2 topologies are now going L3.
With regards to “automatically generated service model”, I do not understand you. Orchestration is way more than a service model, you need to have the right mapping. There are ontology tools that can analyse code and come back with high level contracts but that would be a very small piece of the work we do every day. Ontology is very interesting as a cross-borders research area.
The whole point here is – how do we achieve scale?
Today in every engagement we need a specialized person who has the necessary knowledge to write the service model and the FastMap code before we can show something to a customer. In my understanding, we don’t have many of such folks today across Cisco if you compare them to the number of accounts that we engage in the field.
Sure, with time this will improve. But if we can have some innovative way to achieve better scale in a faster timeframe, that will help everyone involved in this conversation.
Bear in mind that:
1. You can always use the demo/examples to “show something” to a customer - this works really well in my experience for first and exploratory meetings
2. The value proposition of the platform is to be more or less “assumption free”, meaning that it’s flexible enough to cater to customers that rapidly change their definition of what a service is defined to be (i.e. the service model) and has a multi-vendor network where the vendor base and versions of software changes over time
Because of (2), and because our customers are asking for a software-defined world, we will always need to engage software people that understands the tooling (YANG service models, fastmap, etc). Not only on the cisco-side of things, but also on the customer teams.
For the coming releases, we are spending on further improving tooling and APIs along the lines of how we understand software developers in our customer teams want to work. It is their satisfaction (and productivity) that is our main goal. So any innovation here is certainly of interest!
> On Jun 23, 2015, at 1:04 AM, Santanu Dasgupta (sadasgup) <firstname.lastname@example.org> wrote:
> The whole point here is – how do we achieve scale?
> Today in every engagement we need a specialized person who has the necessary knowledge to write the service model and the fastmap code before we can show something to a customer. In my understanding, we don’t have many of such folks today across Cisco if you compare them to the number of accounts that we engage in the field.
> Sure, with time this will improve. But if we can have some innovative way to achieve better scale in a faster timeframe, that will help everyone involved in this conversation.
This whole thing hinges upon whether we believe our customers will use an NSO-based GUI or not. So far the NCS customers do not, and the provisioning GUI (e.g. The L3VPN demo) is there for demo purposes only. Our experience with Prime Provisioning however is that the majority of customers use the GUI, but that is possibly due to lower tier customer base.
Also, there are multiple aspects of topology, so we need to be specific about the requirements: