Prestaging Workflow in Connectivity Services Director
Prestaging of devices using the Services Activation Director GUI comprises the process of discovering capabilities of devices in the network. Certain classifications are made, depending on the result of the device prestaging process. Service provisioning is made possible on the device based on the discovered capabilities and classification. The devices that do not confirm to an expected configuration are not made available for selection, when you attempt to provision services. These capability discoveries of devices are prone to errors on certain occasions. A second level of control for the user to classify the device above the prestaging classification is implemented in Connectivity Services Director. This additional level of segregation and selection enables you to choose to override the capabilities discovered by the prestaging workflow. The information discovered by the prestaging workflow serves as a tip for you to modify the device-capability classification accordingly. Device prestaging using the Services Activation Director GUI is a manual process in which you need to prestage the device, before you can configure services on the device. Design enhancements have been made to automate this process using the automated prestaging mechanism, where the devices are prestaged automatically when concerned events occur on the device, in the Junos Space Platform database, or the deployment of the Connectivity Services Director application. Using this effective and streamlined automated prestaging methodology, the devices are always prestaged with latest configuration when you attempt to configure services on them.
The device prestaging workflow in Services Activation Director is slightly redundant and also error-prone. An additional step of prestaging the devices before a service can be configured on them is also not transparent and beneficial. As a result of this redundant implementation, the service configuration on a particular device is impacted. The service capabilities discovered for a service can be erroneous, owing to anomalies with device prestaging. Additionally, the process of confirming a role discovered by the prestaging workflow is regarded as an unnecessary step and is discarded in the redesigned and optimized workflow. In Services Activation Director, the changes that affect the service capability of the device are not automatically discovered. In Connectivity Services Director, the devices are always prestaged services are configured on them to enable the latest configuration to be synchronized between the device and the application. Auto-discovering the devices, based on changes occurring on the device and Junos Space Platform is highly efficient and user-friendly.
Auto-Discovery and Auto Prestaging of Devices
The process of automatically synchronizing device configuration and service capability discovery, based on the configuration setting changes made on the device and using the Junos Space Platform software application, is called device automatic prestaging. The auto prestaging mechanism is triggered based on events occurring on the device and the Junos Space Platform software. Certain events that occur on the devices are identified as conditions for triggering the auto prestaging workflow. The following are some of the events that impact the capability of the device to enable Network Services to function:
Device addition and deletion using the Junos Space Platform GUI
Interface status alternating between up and down
Loopback address change
Interface addition and deletion
Service type-related configuration (in scenarios when additional configuration such as BGP or LDP changes are made, which updates the service capability (L2, L3) of the device)
Management IP address or hostname change
Changes to the interface family
Changes in the interface encapulation type
Parallel Prestaging Jobs
Because auto prestaging is an automated process triggered by the change events from the device and platform, there can be multiple parallel prestaging jobs from a single device and from multiple devices. These jobs updates the corresponding device information on completion. Service creation and deployment is not impacted by the prestaging jobs and picks up the available configuration at the given point of time. In the older version of Services Activation Director, only one prestaging job can run at any point of time, which is valid with only manual prestaging because the prestaging job scans the whole device inventory and prestages device which are not already been assigned a role. Having a second job run in parallel does not result in any advantage. With the introduction of auto device prestaging feature, the scenario is different because auto-prestaging is mostly per-device, and therefore, it is essential to have parallel prestaging jobs running for different devices.
Auto Prestaging Jobs When a Manual Prestaging Job is Running
Manual prestaging process prestages the entire device inventory and auto assign device roles to them. Therefore, having a per-device auto prestaging job running in parallel might be redundant for the functionality because the concerned device could most likely be taken care by the manual prestaging job. However, possibilities arise in which the concerned device is prestaged before the new event and the latest configuration is not synced. To avoid such race condition, the auto prestaging job has to run after the manual job completes. For this sequencing of the types of prestaging jobs, auto prestaging event request is stored in a memory queue against a particular device ID and is run by the scheduler after the manual prestaging job completes.
Manual Prestaging Jobs When an Auto Prestaging Job is Running.
Manual prestaging jobs are queued if there are auto prestaging jobs currently running. The manual prestaging job for a particular device is discarded if an auto prestaging job is already in progress.
Multiple Auto Prestaging Jobs for a Device
In cases where there are multiple events generated for a single device the event are queued for execution, a validation is performed to determine if there are current jobs in execution for the particular device and queue the request in which case. There can only be one prestaging request per device in queue at any point in time.
Multiple Auto Prestaging Jobs for a Device
In this case, all the prestaging jobs has to run in parallel. With Services Activation Director (only manual re-sync), the prestaging data in overwritten when a new prestage jobs runs, until the role is assigned. However, with the latest changes, the role assignment happens as part of manual or auto prestaging, and enhancements are made to support parallel processing.
Scenarios With a Clustered Environment
There are possibilities of race conditions in a clustered Junos Space appliance environment where there can be parallel prestaging jobs queued up for the same type of devices as the jobs because the queue context is local to each instance in the cluster. These scenarios are prevented by using a cluster-level context for the queues is present.
Types of Prestaging
Because of scenarios where the manual and auto prestaging has to be identified specifically, the support for distinguishing both the types needs to be added. Instead of the handling of the auto prestaging and manual prestaging jobs by a single job API in which the job data does not contain any information regarding the nature of the job being manual or auto prestaging, the distinction is achieved by comparing the device ID against null from the database job data and by running two separate jobs, one for manual prestaging and the other for auto prestaging.
Prestaging takes the devices already under Junos Space management and prepares them for service activation. The prestaging process discovers network provider edge (N-PE) devices in the Junos Space database and assigns roles to those devices and their interfaces. In Connectivity Services Director, device discovery and prestaging done automatically whenever a device is added or updated.