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.
The process in essence looks like this. Network designers define the architectural rules and choices that are to be given (and allowed) to the operator and design how to standardize the required network parameters. This is done via the YCE’ modeling functionality. For example, the design-, service- and hardware options an operator gets when deploying a new service. The models then defines what can be chosen by an operator, while at the same time generating the relevant parameters upon execution of the model.
The network engineer puts his golden configs in the application’s templates and uses YCE’ smart templating language to ‘parameterize’ and ‘conditionalize ’ them. Upon execution, the templates are automatically filled with the rights parameters coming from the database (generated by the models) and the configuration, or part of them are created.
Network operations use the application to populate new sites and services, verify the generated configs, schedule jobs for executions and do all their operational tasks. The application will log in to all the devices and issue all changes. Important to notice is that operations is still fully in control of what happens when to the network, but all is done in a standardized, integrated and controlled way using one single standardized source of information.

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.
And as all topology, relationships and parameters are explicitly known in the application, meaning the the application is fully service and topology aware, it is now very easy to start managing and automating network changes instead of changes on individual devices.

What are YCE’ USP’s?

  • Network modeling; automation the way you design it
  • Network in a box concept
  • Integration of People, Process and Technology across teams
  • Top down approach to change management
  • Collaboration between different teams to ensure consistency
  • Enforce standardization and design policies
  • Multi vendor support
  • Multi technology support
  • Multi tenancy

 

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:

  1. Network & service modeling; to standardize your designs, building block and services and formalize the changes process between groups
  2. IPAM modeling; for registration, standardization and allocation of all you ip addresses
  3. Templates; This is where you put all your vendor specific configurations in different templates, that can be reused over and over with the parameters from the database and personalize conditioning
  4. Scenarios; to define yourself how certain jobs and changes should be handled, such as auto roll back procedures etc.. A scenario is used in combination with jobs.
  5. Scheduler & Push server; this can be integrated on one system with the database server or on (multiple) separate server(s) and can be tuned depending on the type of jobs. E.g. small jobs (1-2 second each) or large scale IOS upgrades with 30 sec to 2 minutes each.
  6. Vendor modules; These allow CLI communication with the specific vendors (e.g. all cisco’s, juniper, avaya, hp, etc.)
  7. (i)OS upgrades; This module is dedicated to perform large scale (i)OS upgrades for different types of vendors. It can be used stand alone with e.g. a customer’s cmdb, containing all the device credentials or based on the modeled and non-modeled devices in the YCE platform
  8. Pre and post compliancy; This function guarantees that what you roll out to your network is according to your own design requirements and design rules.
  9. Delta reporting; This function guarantees that in case changes to the life network have been made outside the YCE system, the operator is notified that there is a difference between the SOLL and the IST situation. Depending on your scenarios these can be handled automatically.
  10. Job and user control; Users in the YCE application can get different roles depending on their permission levels. This ranges from browser, operator, modeler, engineer, manager and system admin. This can be assigned per (type of) network. With job control you can define things like manager’s approval for certain changes.
  11. Logging; All activity in the system is logged and can be traced for compliance reasons
  12. Reporting; YCE comes with basic reporting functionality. As the database is mySQL, customers can make their own specific reports with external tools.
  13. Integrations: As the YCE database has read access integrations with external systems is easy. NeYCE has done many integrations with external systems such as Infoblox, QiP, IBM Netcool, HP service desk, HPOV, Concord. For these api’s already exist.
  14. Xml / north bound interface; This is the interface that can be used with external systems for automation and orchestration. E.g. an xml message can initiate a specific model to execute without human intervention.