Before you begin using Cisco Crosswork Optimization Engine, Cisco recommends that you complete the following planning and information-gathering steps:

• User Accounts : Cisco recommends as a best practice that you create separate accounts for all of your users, so that there is an audit record of user activity on the system. Prepare a list of the people who will use Cisco Crosswork Optimization Engine. Decide on their user names and preliminary passwords, and create user profiles for them (see Manage Users).

• User Roles: Cisco recommends that you use role-based access control to confine users to just the software functions needed to perform their job duties. By default, every new user you create has full administrative privileges. Unless you want to extend the same privileges to every user, you will need to plan a system of user roles, create them, and assign them to the user profiles you create (see Create User Roles).

• Credentials: Gather access credentials and supported protocols that you will use to monitor and manage your devices. For providers, this always includes user IDs, passwords, and connection protocols. For devices, it includes user IDs, passwords, and additional data such as the SNMP v2 read and write community strings, and SNMPv3 auth and privilege types. You will use these to create credential profiles.

  Credential profiles must be present in order for Cisco Crosswork Optimization Engineto access a device or to interact with a provider. Rather than entering credentials each time they are needed, you instead create credential profiles to securely store this information. The platform supports unique credentials for each type of access protocol, and allows you to bundle multiple protocols and their corresponding credentials in a single profile. Devices that use the same credentials can share a credential profile. For example, if all of your routers in a particular building share a single SSH user ID and password, you can create a single credential profile to allow Cisco Crosswork Optimization Engine to access and manage them

• Tags: Tags are simple text strings you can attach to objects to help group them. Cisco Crosswork Optimization Engine comes with a short list of ready-made tags used to group network devices. You can create your own tags and use them to identify, find, and group devices for a variety of purposes. Plan a preliminary list of custom tags to create when setting up the system, so that you can use them to group your devices when you first onboard them. For example, in addition to type and geolocation, you may want to identify and group them by their location in your network topology (Spine vs. Leaf), or the function they serve on your network (Provider vs. ProviderEdge). You need not have a complete list of tags at first, as you can always add more later, but please note that all the tags you do plan to use must be in place before you need them; you cannot create them "on the fly" (see Manage Tags).

• Providers: Cisco Crosswork Optimization Engine does not perform route segmentation or configuration changes directly. Instead, it relies on providers, such as SR-PCE and Cisco Crosswork Optimization Engine, to do the basic work of direct interaction with network devices. The provider family determines the type of service that provider supplies to Cisco Crosswork Optimization Engine, and the parameters unique to that service, which must be configured.

  Cisco Crosswork Optimization Engine requires you to have at least one SR-PCE configured as a provider to discover devices and to distribute policy configuration to devices. You can choose to have a backup SR-PCE for redundancy. Cisco recommends that you have an optional NSO server installed and configured as a provider in order to automate the configuration of devices to work with Cisco Crosswork Optimization Engine.

• Devices: Decide how you are going to onboard your devices:

  • Manually, via the UI or importing a CSV file

  • Automatically (with some manual edits), where the SR-PCE discover the devices and onboards them

  For more information, see About Adding Devices. To see an overview of each onboarding process, see High-Level Workflows.

• Data Destination(s): Decide which external data destination you are going to use and ensure it is set up to receive input from Cisco Crosswork Optimization Engine. By default, Cisco Crosswork Optimization Engineis configured as the data destination.

Note that you can capture the devices, credential profiles, tags, and providers lists in spreadsheet form, convert the spreadsheet to CSV format, and then upload them in bulk to Cisco Crosswork Optimization Engine. You do this using the Import feature.

You can access CSV templates for each of these lists by clicking the Import icon in the corresponding places in the user interface. Select the Download template link when prompted to choose an export destination path and file name.

These workflows describe the steps to quickly get started with Cisco Crosswork Optimization Engine. The main difference between the two workflows are the steps on how devices are added (see About Adding Devices). You will find that the general order of steps can be done out of the documented order as long as you keep the following in mind:

• An SR-PCE provider must be configured before devices are added.

• In order for data collection to occur, devices must be attached to a Cisco Crosswork Data Gateway instance.

• If you selected to use Cisco NSO for device management during Cisco Crosswork Optimization Engine installation, you must add NSO as a provider (see Cisco Crosswork Optimization Engine Installation Guide).

Resource Reservation Protocol (RSVP) is a protocol that you are most likely familiar with. It is a signaling protocol that enables systems to request resource reservations from the network. RSVP processes protocol messages from other systems, processes resource requests from local clients, and generates protocol messages. As a result, resources are reserved for data flows on behalf of local and remote clients. RSVP creates, maintains, and deletes these resource reservations. This section focuses on a high-level overview of Segment Routing (SR) which is gaining popularity in the networking routing area.

Segment routing is a method of forwarding packets on the network based on the source routing paradigm. The source chooses a path and encodes it in the packet header as an ordered list of segments. Segments are an identifier for any type of instruction. For example, topology segments identify the next hop toward a destination. Each segment is identified by the segment ID (SID) consisting of a flat unsigned 32-bit integer.

Segment Routing Policies

Segment routing for traffic engineering uses a “policy” to steer traffic through the network. An SR policy path is expressed as a list of segments that specifies the path, called a segment ID (SID) list. Each segment is an end-to-end path from the source to the destination, and instructs the routers in the network to follow the specified path instead of the shortest path calculated by the IGP. If a packet is steered into an SR policy, the SID list is pushed on the packet by the head-end. The rest of the network executes the instructions embedded in the SID list.

Note	Cisco Crosswork Optimization Engine discovers existing SR policies when devices are imported, but cannot manage them. SR policies can be managed only if they were provisioned using Cisco Crosswork Optimization Engine (see Create and Manage SR Policies).

There are two types of SR policies: dynamic and explicit.

Dynamic SR Policy

A dynamic path is based on an optimization objective and a set of constraints. The head-end computes a solution, resulting in a SID list or a set of SID lists. When the topology changes, a new path is computed. If the head-end does not have enough information about the topology, the head-end might delegate the computation to a path computation engine (PCE).

Explicit SR Policy

When you configure an explicit policy, you specify an explicit path which consists of a list of prefix or adjacency SIDs, each representing a node or link along on the path.

Disjointness

Cisco Crosswork Optimization Engine uses the disjoint policy to compute two lists of segments that steer traffic from two source nodes to two destination nodes along disjoint paths. The disjoint paths can originate from the same head-end or different head-ends. Disjoint level refers to the type of resources that should not be shared by the two computed paths. The following disjoint path computations are supported:

• Link – Specifies that links are not shared on the computed paths.

• Node – Specifies that nodes are not shared on the computed paths.

• SRLG – Specifies that links with the same Share Risk Link Group (SRLG) value are not shared on the computed paths.

• SRLG-node – Specifies that SRLG and nodes are not shared on the computed paths.

When the first request is received with a given disjoint-group ID, a list of segments is computed, encoding the shortest path from the first source to the first destination. When the second request is received with the same disjoint-group ID, information received in both requests is used to compute two disjoint paths: one path from the first source to the first destination, and another path from the second source to the second destination. Both paths are computed at the same time. The shortest lists of segments is calculated to steer traffic on the computed paths.

Note	Disjointness is supported for two policies with the same disjoint ID. Configuring affinity and disjointness at the same time is not supported.