Frequently asked questions
What does YCE stand for?
YCE is short for Your Configuration Engine. Current version is 5.4 and with version 6.0 to be released by the end of december ‘12. The company name is NetYCE.
What problem does YCE solve?
90% of all errors and network outages result from configuration changes, of which 80% is caused manually! (according to analyst groups such as EMA). This is what YCE resolves by using one application for managing and automating all network parameters, configurations and changes in a standardized and controlled way.
The essence of YCE?
Automating networks, the way You design it! With YCE you can design yourself how network changes and processes are enforced in a standardized way throughout the lifecycle of your network. YCE allows you to automate your network by standardizing all network parameters in combination with your golden configuration templates and generate “design driven configurations”. These can then be be activated in the network in fully controllable and manageable way.
How does YCE work?
The YCE platform allows designers, engineers and network operations to work together in an integrated way, enabling network changes to be fully coordinated, standardized and automated according to the user’s own specification.
What is the result?
Design driven configurations and full control of your change process. All configurations and changes are generated according to your own design rules and -principles and based on your own ‘golden configuration’ templates, using one consistent source of standardized information.
What are YCE’ USP’s?
What is modeling and network in a box?
The YCE modeling functionality turns a visio picture and a detailed network design into objects in the YCE database. These objects contain all the design parameters and relationships that build up your network topology, location, building blocks or service in a vendor agnostic way. Upon execution of the models, the objects generate a virtual network in the database that becomes the SOLL situation of your life network. Your complete network is therefore first build in the database before getting deployed. At this point, the ‘virtual network’ is still vendor independant. Once merged with the templates, the vendor specific configurations are generated that can be activated in the life network (IST situation). The modeling functionality also allows designers and engineers to define what options an operator gets when deploying new locations, services and tasks, pre-defining what he can and cannot do.
How can the YCE virtual network be used?
The virtual network in the YCE application is extremely useful for a variety of reasons. First, as all your “network” resides in the database and can be used for investigation, analysis and integrations by anybody, with right credentials, without touching the network. Secondly, it is very easy to migrate networks from one vendor to another or migrate from one type of network to another as you can prepare this in YCE first, put in your new vendor templates and have the system migrate your life network. Thirdly, the information in YCE can also be offered to external users, given them ‘access’ to part of their network for things like self service functionality. Fourth, actions can be prepared, scheduled and executed upon your own policies. Another way is to use the YCE northbound xml interface to integrate with external orchestration systems. For example a model gets executed upon receiving an xml request. A good example is the auto configuration of ports, vlan’s and ip-addresses upon the provisioning of a virtual machine by an external system.
Is it required to model your complete network?
No, you can define yourself how much and in what detail you model out certain processes. In some cases you want to give more choice and flexibility to operators, in other less. It is also possible to use the YCE application for certain processes that don’t need any modeling, such as automating (i)OS upgrades, doing configuration backups from your life network or run many simple batch jobs such as password updates etc.
What is meant by YCE’ top down approach?
Traditionally network changes are made by engineers and operations directly in the life network and mainly on the CLI (command line) of the individual devices. This is a ‘bottom up’ approach. YCE top down approach means that network configurations and changes are first prepared, generated and verified and then scheduled via the application to take effect in the network in a controlled and standardized way. YCE will make the config changes on the CLI as normally an engineer would.
What does this mean for engineers and their CLI?
The YCE application will do the same thing an engineer normally does on the CLI with the big difference that it uses all information, relationships, parameters and credentials stored in one place. The engineers and operator will use YCE to validate the configs, schedule them and see the outcome of the jobs. For an engineer, this means that the actual changes are not done directly on the CLI anymore but via the application. Engineers will still use the CLI for show commands regarding status information and verification.
How does YCE communicate with the devices?
There are several ways to do this. Most used is directly to the CLI of the device. YCE simply logs into the device using SSH or Telnet and issues the configuration. Another way is to hand over the config (or part of it) to the vendors element manager or other configuration management (NCCM) product who does the activation on the device. In this case YCE is used more as the orchestration and automation system and not for the push functionality. The third option is that YCE delivers the configs as xml type files that can be used by products that use market standards for configuration management, such as Netconf and Yang.
How easy is it to a support / add multiple vendors?
Multi vendor support means that YCE can issue the configuration on the CLI of the specific vendor. In order to do this, the only thing YCE needs, is to be able to log on the the device, activate the config and handle error messages. We are NOT dependent on vendor specific mib/snmp information or deal with specific OS dependencies as all that knowledge is put in the templates by the customer’s engineers themselves. So, YCE stores all the customer’s engineering and vendor specific knowledge in the templates and activates these on the devices. To support new vendors usually takes about two days for NetYCE to develop and test. Once developed NetYCE will support any future changes.
How about SDN support?
For YCE to become an SDN application for network configuration management, the only thing we need to do is develop a ‘vendor module’ on top of an openflow controller. In this way, networks can be standardized using YCE and programmed using SDN. This is on the roadmap for 2013.
How does YCE deal with multi technology?
YCE is based on the principle of “what you put in, you get out”, in an structured and automated way. The same goes for multi technology support. Users can use the templates to put in any type of configuration for any type of technology. By parameterizing and conditionalizing the templates YCE is able to automate the generation of multi technology templates.
Does the YCE platform support multi tenancy?
Yes, The YCE platform was build from day one to support multiple customers and multiple networks for different users. Based in your role, users can see or have access to certain networks and certain permissions in the application. This also allows the system to be used in variety of managed service and self service situations.
What is the difference between modeled and unmodeled nodes?
Modeled nodes are the nodes created upon execution of the YCE models and that make up the virtual network in the YCE database. All parameters are generated and managed by the YCE application. Non-modeled nodes can be anything from an import from your network or a list in an external cmdb that contains the node credentials for YCE to use or dummy devices in the YCE database. YCE can use non-modeled nodes for simple batch jobs or things like (i)OS upgrades. YCE does not manage the parameters of non-modeled nodes.
What are the YCE components?
The YCE platform has the following components: