Visualize and Manage SR Policies

Cisco Crosswork Optimization Engine visualization provides the most value by giving you the ability to easily view and manage SR policies. By visually examining your network, the complexity of provisioning and managing SR policies is significantly reduced.

This section contains the following topics:

SR Policies Topology Map

To get to the topology map, choose Optimization Engine from the left navigation bar, and click SR Policies.

For information on topology issues, or using the map to get information about devices and links, see Network Topology Map and Troubleshoot Network Topology Map.

The following figure shows the topology map with SR policies highlighted. See the Visualize SR Policies Example for information on how to select SR policies so that they appear on the topology map/

Figure 1. SR Policies Topology Map
Topology Map
Callout No. Description

1

Click the appropriate check box to enable the following options:

  • Show Segment Hops—Displays segment hops for the selected explicit SR policies.

  • Show Participating Only—Displays only links that belong to selected SR policies. All other links and devices disappear.

2

SR Policy Origin and Destination: If both A and Z are displayed in a device cluster, at least one node in the cluster is a source and another is a destination. The A+ denotes that there is more than one policy that originates from a node. The Z+ denotes that the node is a destination for more than one policy.

3

SR Policies:

When SR policies are selected from the SR Policies Table, they show as purple directional lines on the map indicating source and destination.

An adjacency segment ID (SID) is shown as a green dot on a link along the path (adjacency SID).

4

A device or device cluster with a green outline (node_SID) indicates there is a node SID associated with that device or a device in the cluster.

5

Geographical Map: Click this icon to view the geographical map.

The geographical map shows single devices, device clusters, links, and SR policies, superimposed on a map of the world. Each device location on the map reflects the device's GPS coordinates (longitude and latitude) as defined in the device inventory.

6

Logical Map: Click this icon to toggle from the geographical map to the logical map. The logical map shows devices and their links, positioned according to an automatic layout algorithm, ignoring their geographical location. You can change the layout algorithm; see Change the Layout of a Logical Map.

The logical map displays up to 5000 devices and never displays devices in clusters.

If you drill down to the logical map from a geographical cluster at the maximum zoom level, the logical map shows devices that are located in the same location. See Identify the Members of a Cluster.

7

Expand/Collapse/Hide Side Panel: Expand or collapse the side panel to see the full and truncated versions of the right-side panel. Close the side panel to get a larger view of the topology map.

8

Zoom In: Click this icon to zoom in on the selected area; for example, to view clustered devices on the geographical map.

9

Zoom Out: Click this icon to zoom out from a selection area.

10

Zoom Fit: Lets you automatically scale the map to fit your zoom area.

11

Auto Zoom: Zooms in on selected SR policies. This option is selected by default. If you uncheck this option, navigate away from the map, and later return to the map; it will revert to the default option.

12

Bandwidth Utilization: Lets you enable or disable visualization of the bandwidth utilization for the mapped links. See Show Bandwidth Utilization for Links on the Map. This option is selected by default. If you uncheck this option, navigate away from the map, and later return to the map; it will revert to the default option.

13

Custom Map View: Lets you create a named custom view using the settings and layout for your current map, or display a custom view you have created previously. See Create Custom Map Views.

14

Metrics: Shows IGP, TE, or delay metrics for each link along the SR policy paths (see Show IGP, Delay, and Traffic Engineering Metrics).

SR Policies Table

To get to the SR Policies table, choose Optimization Engine from the left navigation bar, and click SR Policies. You will see the topology map and, to the right of the map, the SR Policies table.

Figure 2. SR Policies Table
SR Policies Table

The SR Policies table provides the following functions:

  • Displays a list of all SR Policies discovered from the network.

  • Configure new SR policies.

  • Edit SR policies created using Crosswork Optimization Engine (click on Details link).


    Note
    Only SR policies created from Crosswork Optimization Engine can be modified or deleted on the Crosswork Optimization Engine UI.

  • Highlight SR policies on the map when selected from the table.

  • View SR policy details (click on Details link). See Get More Information About an SR Policy).

  • Refresh () the table or policy details (if in the SR Policy Details table). You can also view the date and time as to when the last refresh occured.


    Note

    When creating or modifying SR policies, the refresh and auto-refresh functions are disabled in the tables.

The following information is available in the SR Policies table:


Note

Some fields may be blank depending on the SR policy type.
Table 1.

Column Heading

Description

Headend

Where the SR policy is instantiated.

Endpoint

The destination of the SR policy.

Color

A numerical value that distinguishes between two or more policies to the same node pairs (Headend – Endpoint). Every SR policy between a given headed and endpoint must have a unique color.

Path Name

Name of SR policy path.

Admin Status

Administrative status of the SR policy.This is the status defined by the user.

Oper Status

Operational status of the SR policy. This is the state of the policy as reported by the system. For example, the user can define the Admin status as Up. However, if the policy is operationally down due to some network issues, then the Oper Status will display as Down.

Binding SID

The binding segment is a local segment identifying an SR policy. Each SR policy is associated with a binding segment ID (BSID).

Utilization

Percentage of total bandwidth being used.

Disjoint Group

If applicable, the disjoint group the SR policy belongs in.

Last Update

Time when the most recent update for the policy was received from the network.

Actions

Click Details to Get More Information About an SR Policy.

SR Policy Configuration Sources

SR Policies discovered and reported by Cisco Crosswork Optimization Engine may have been configured from the following sources:

  • SR-PCE initiated—An SR policy that is configured directly on an SR-PCE device.

  • PCC initiated—An SR policy that is configured directly on a device.

  • Cisco Crosswork Optimization Engine PCE initiated—An SR policy that is configured using Cisco Crosswork Optimization Engine. This is the only type of SR policy that Cisco Crosswork Optimization Engine can modify or delete (see Create and Manage SR Policies).

Visualize SR Policies

This section describes the visualization features provided in the topology map for SR policies that have been discovered during the onboard of devices or provisioned using Cisco Crosswork Optimization Engine. To create and manage SR policies using Cisco Crosswork Optimization Engine see Create and Manage SR Policies.

This section contains the following topics:

Visualize SR Policies Example

Follow the steps in this example to quickly familiarize yourself with a number of SR policy visualization features that are available from the topology map.

In this example, we are using the following geographical map with devices and links that have SR policies configured. SR policies are not yet highlighted in the map.

Figure 3. Topology Map Example
Topology Map Example

Before you begin

In this example, we assume that devices and SR policies have already been added to Crosswork Optimization Engine (see Get Started).

Procedure

Step 1

From the SR Policies table, click the checkbox next to the SR policies you are interested in. In this example, there are four SR policies selected.

Figure 4. SR Policy Selection
SR Policies Selection
After SR selection, the map displays the following:

  • SR policies appear as purple links with arrows that indicate the path direction. Dashed links represent aggregated links.

  • XRV9k_1, XRV9k_2, and XRV9k_6 devices are origins for the selected policies. XRV9k_4, XRV9k_6, and devices in the device cluster are destinations for the selected policies. SR policy origin and destination are marked with A and Z, respectively. If both A and Z are displayed in a device cluster, at least one device in the cluster is a source and another is a destination. The A+ denotes that there is more than one policy that originates from a device. The Z+ denotes that the device is a destination for more than one policy.

  • Node ID indicates a device cluster composed of 2 devices within the same general location. This particular device cluster also has a node SID which is indicated by the green outline.

  • node_SID indicates XRV9k_4 and XRV9k_6 have node SIDs.

Step 2

Click on the device cluster to zoom in and see the individual devices (XRV9k_5 and XRV9k_1).

Figure 5. Device Cluster Zoom
Zoom in on Device Cluster
Step 3

From the SR Policies table, hover over one of the selected policy names. When you hover on one of the selected SR policy entries, the IGP path of that policy is highlighted on the topology view. In the case of ECMP (Equal Cost Multi-Path) all paths will be highlighted as shown in the example below.

Figure 6. Hover over an SR Policy
Hover over an SR Policy
Step 4

Check the Show Segment Hops check box. The segment hops for the selected SR policies are displayed, with curved arrows, instead of the IGP paths.

Figure 7. Segment Hops
Segment Hops
Step 5

Check the Show Participating Only check box. All non-participating links and devices disappear. Only participating policies are displayed.

Figure 8. Participating SR Policies
Participating SR Policies
Step 6

To view the IGP, TE or Delay metrics for each link along a policy's IGP path, select the Metric icon Metric icon and click the applicable check boxes. The metric details are displayed for each policy on the map.

Figure 9. IGP, Delay, and TE Metrics
IGP, Delay, and TE Metrics
Step 7

Click the logical map icon (Logical View icon).

Figure 10. Logical Map
Logical Map
You are able to see the same information (aside from geographical location) that is available on the geographical topology map. You also have the ability to move devices and links on the map to make it easier to view.
Step 8

To view SR policy details such as disjoint groups, metric type, segment hop information, and so on, click Details... from the table.

Figure 11. SR Policy Detail Link
SR Policy Detail Link
The SR Policy Details page is displayed in the side panel (see Get More Information About an SR Policy). Note that only the selected policy is now highlighted on the topology map.
Figure 12. SR Policy Details
SR Policy Details Page

Note

To return to the SR Policies table, close (Close icon) the current view.

What to do next

Provision and manage SR policies. See Visualize and Manage SR Policies.

Highlight an SR Policy on the Map

When many SR policies are displayed on the map, it may be difficult to view a particular SR policy path. To highlight a particular SR policy path on the map, navigate to Optimization Engine > SR Policies > SR Policies table, and hover over the SR policy.

Hover over an SR Policy

Identify Segment Hops

To view segment hops for selected policies, do the following:

Procedure

Step 1

From the SR Policies table, select the SR policies you are interested in.

Step 2

From the top left box in the topology map, check the Show Segment Hops check box. The segment hops for the selected SR policies are displayed, with curved arrows, instead of the IGP paths.

Show Participating Nodes and Links

To view only the nodes and links that are part of selected SR policies, do the following:

Procedure

Step 1

From the SR Policies window, select the SR policies you are interested in.

Step 2

From the top left box in the topology map, check the Show Participating Only check box.

Show IGP, Delay, and Traffic Engineering Metrics

Each link is assigned a metric value. The distance between two nodes is the sum of all the metric values of links along a path. To view IGP, Delay, or Traffic Engineering (TE) metrics on the topology map:

Procedure

Step 1

From the SR Policies table, check the checkboxes next to the SR policies you are interested in. The SR policies are highlighted in the topology map.

Step 2

From the topology map, select the Metric icon Metric icon and click the applicable check boxes. The metric details are displayed for each policy on the map.

What to do next

To configure a dynamic SR policy based on one of these metrics, see Create Dynamic Path SR Policies.

Create and Manage SR Policies

This section describes how to provision and manage SR policies using the Cisco Crosswork Optimization Engine UI. The Cisco Crosswork Optimization Engine UI gives you the capability of provisioning SR policies in a variety of methods (explicit, dynamic, and bandwidth constraint driven). As you provision an SR policy, you can select nodes on the topology map and also preview the path before deployment. This greatly reduces the complexity of SR policy management. Before provisioning SR policies, you should understand some basic segment routing configuration concepts (see Segment Routing).

Configure Affinity Mapping

Affinity of an SR policy is used to specify the link attributes for which the policy has affinity for. It determines which links are suitable to form a path for the policy. It is a 32-bit value, with each bit position (0 - 31) representing a link attribute. Affinity mapping is used to map each bit position or attribute to a color. This makes it easier to refer to link attributes.


Note

The affinity mapping name is only used for visualization in Cisco Crosswork Optimization Engine. Affinities defined on devices are not collected by Cisco Crosswork Optimization Engine. Define affinity mapping in Cisco Crosswork Optimization Engine with the same name and bits that are used on the device interface. Cisco Crosswork Optimization Enginewill only send bit information to SR-PCE during provisioning.

Procedure

Step 1

From the main menu choose Optimization Engine > Affinity Mapping. You can also define affinities while creating a policy (Create Dynamic Path SR Policies) by clicking Manage Mapping.

Step 2

To add a new affinity mapping, click Create Mapping.

  1. Enter the name (color) and the bit it will be assigned to.

  2. Click Save icon to save the mapping.

Step 3

To edit an affinity mapping, click Edit icon.

  1. Make the necessary changes. If you want to cancel your changes, click Close icon.

  2. Click Save icon to save the changes.

Step 4

To delete an affinity mapping, click Delete icon

Note 

You should remove the policy before removing the affinity to avoid orphan policies. If you have removed an affinity associated to an SR policy, the affinity is shown as "UNKNOWN" in the SR Policy Details window.

What to do next

After defining affinities, you can Create Dynamic Path SR Policies.

Create Explicit Path SR Policies

This task creates an SR policy using an explicit path (segments) that you define.

Procedure

Step 1

From the main menu, choose Optimization Engine > SR Policies.

Step 2

From the SR Policies table, click + Create.

Figure 13. Create SR Policy
Create SR Policy
Step 3

Enter the following SR policy values:

  1. Required fields:

    • Headend—Where the SR policy is instantiated. Note: You can either select a node (from the map or drop-down list) or enter part of the node name to filter the headend and endpoint node entries.

    • Endpoint—The destination of the SR policy.

    • IP Address—After the endpoint is selected, the SID list is populated and you can select the loopback IP address.

    • Color—A numerical value that distinguishes between two or more policies to the same node pairs (Headend – Endpoint). Every SR policy between a given headed and endpoint must have a unique color. The bit value must match the value that is configured on the device.

    • Path Name—Enter a name for this SR policy path. SR policy paths from the same headend must be unique. Policy path names are not case sensitive.

  2. Optional values:

    • Description—Enter details or a description of this policy.

    • Explicit Binding SID—The binding segment is a local segment identifying an SR policy. Each SR policy is associated with a binding segment ID (BSID). The BSID is a local label that is automatically allocated for each SR policy when the policy is instantiated. If you wish to use a specific segment ID, rather than the default one that is automatically assigned, then enter it here.

    • Profile ID—Identification used to associate an SR policy with a set of features applied to the policy by the headend. It should correspond with a profile configured on the headend.

Step 4

Under Policy Path, click Explicit Path.

Step 5

Add segments that are part of the SR policy path.

  1. You can either select a node from the drop-down list or enter part of the node name to filter the node list. After a node is selected, the Select SID drop-down list is populated with associated prefix and adjacency segment IDs.

  2. Select a segment ID from the Select SID drop-down list. The drop-down list contains all available segments. The segment names indicate the associated node and whether it is a prefix or an adjacency segment. The name also includes whether the segment is protected (P) or unprotected (U).

  3. Click Add. The segment appears in the table with segment values.

  4. Repeat for each segment you want to add to the SR policy path. To reorder the segment hops, click and drag Reorder iconnext to the segment hop you want to move.

    Note 

    The segments must be in order or the path will not be created.
Figure 14. Explicit SR Policy Example
Explicit SR Policy Example
Step 6

Click Preview. The path is highlighted on the map and policy details are displayed on the right.

Figure 15. Explicit SR Policy Example
Preview SR Policy
Step 7

If you are satisfied with the policy path, click Provision.

Step 8

When the policy is provisioned successfully, a window appears with the following options:

  • View SR Policy List—Displays the SR Policies table that lists all SR policies including the one that was just created.

  • Create New—Allows you to create another SR policy.

Note 

The newly provisioned SR policy may take some time, depending on network size and performance, to appear in the SR Policies table. The SR Policies table is refreshed every 30 seconds.

Create Dynamic Path SR Policies

This task creates an SR policy with a dynamic path. SR-PCE computes a path for the policy based on metrics and path constraints (affinity or disjointness) defined by the user. A user can select from three available metrics to minimize in path computation: IGP, TE, or delay. SR-PCE may also automatically re-optimize the path as necessary based on topology changes.

Procedure

Step 1

From the main menu, choose Optimization Engine > SR Policies.

Step 2

From the SR Policies table, click + Create.

Figure 16. Create SR Policy
Create SR Policy
Step 3

Enter the following SR policy values:

  1. Required fields:

    • Headend—Where the SR policy is instantiated. Note: You can either select a node (from the map or drop-down list) or enter part of the node name to filter the headend and endpoint node entries.

    • Endpoint—The destination of the SR policy.

    • IP Address—After the endpoint is selected, the SID list is populated and you can select the loopback IP address.

    • Color—A numerical value that distinguishes between two or more policies to the same node pairs (Headend – Endpoint). Every SR policy between a given headed and endpoint must have a unique color.

    • Path Name—Enter a name for this SR policy path. SR policy paths from the same headend must be unique. Policy path names are not case sensitive.

  2. Optional values:

    • Description—Enter details or a description of this policy.

    • Explicit Binding SID—The binding segment is a local segment identifying an SR policy. Each SR policy is associated with a binding segment ID (BSID). The BSID is a local label that is automatically allocated for each SR policy when the policy is instantiated. If you wish to use a specific segment ID, rather than the default one that is automatically assigned, then enter it here.

    • Profile ID—Identification used to associate an SR policy with a set of features applied to the policy by the headend. It should correspond with a profile configured on the headend.

Step 4

Under Policy Path, click Dynamic Path.

Step 5

Under Optimization Objective, select one of the following:

  • Interior Gateway Protocol (IGP) Metric—Minimizes total path IGP metric.

  • Traffic Engineering (TE) Metric—Minimize total path TE metric.

  • Latency—Minimize total path latency.

Step 6

Define affinities:

Note 

Affinity constraints and disjointness cannot be configured on the same SR policy.

  • Exclude Any—Does not traverse interfaces that have any of the specified affinities.

  • Include Any—Includes only interfaces that have any of the specified affinities.

  • Include All—Include only interfaces that have all of the specified affinities.

  • Select or Create Mapping

    • If affinity mappings have been defined, select the applicable value.

    • To create an affinity mapping, click Create Mapping.

    Note 

    For more information, see Configure Affinity Mapping.

  • Add Another—Click this link to add more affinity rules.

Step 7

(Optional) Define disjointness. For more information on how Cisco Crosswork Optimization Engine handles disjoint policies and what options are supported, see the "Disjointness" section in Segment Routing). Enter the disjoint group ID and subgroup ID. If there are existing SR policies belonging to a disjoint group that you define here, all SR policies that belong to that same disjoint group are shown during Preview.

Note 

There cannot be more than two SR policies in the same disjoint group or subgroup.
Step 8

Under Segments, select one of the following:

  • Protected (Preference)—Creates an SR policy that will use protected segments (provides a backup path) when available.

  • Unprotected Only—Creates an SR policy that will only use unprotected segments. This option cannot be used when affinity constraints are defined.

Step 9

Click Preview. The path is highlighted on the map. Note in the following example that all policies belonging to the same disjoint group are displayed.

Figure 17. Dynamic SR Policy and Disjoint Group Policy Preview
Dynamic SR Policy Example
Step 10

If you are satisfied with the policy path, click Provision.

Step 11

When the policy is provisioned successfully, a window appears with the following options:

  • View SR Policy List—Displays the SR Policies table that lists all SR policies including the one that was just created.

  • Create New—Allows you to create another SR policy.

See the following topics:

Preview Disjoint Policies

The following example shows how the SR policy provisioning preview feature can be used for disjoint SR policies. Two SR policies will be provisioned with link disjointness. After the first one is provisioned, the preview of the second will show both policies in the map view and how the path of the first would be re-optimized by SR-PCE to make them link disjoint from each other.


Note

There cannot be more than 2 disjoint policies in the same disjoint group or subgroup

Below is a provisioned dynamic policy (DisjA) belonging to disjoint link group 200. The SR policy has a path that ECMP splits between XRV9k_4 and XRV9k_1 as shown in the following figure.

Figure 18. Example: DisjA SR Policy
DisjA SR Policy

A second policy (DisjB) is now configured in the same disjoint group as the first. When we preview this policy you see both DisjA and DisjB are displayed. You also see the path of DisjA has been reoptimized to ensure both policies are link disjoint. This path change to the existing policy DisjA will be made by SR-PCE if DisjB is provisioned.

Figure 19. Example: Preview Disjoint SR Policies
Preview Disjoint SR Policies

After DisjB is provisioned, we select View SR Policy List and check the checkbox next to the DisjA policy to confirm that the path for DisjA has been rerouted.

Figure 20. Example: DisjA SR Policy Rerouted
SR Policy Rerouted

From the SR Policies table, check the checkbox next to DisjB, and delete it.

Figure 21. Example: Delete DisjB SR Policy
Delete SR Policy

After a few seconds, display DisjA again. You will see that it has reset itself and shows two paths from XR.

Figure 22. Example: DisjA SR Policy Reset
SR Policy Reset

View SR Policies Belonging to a Disjoint Group

From the SR Policy Details window, click the Disjoint Group ID number to view all SR policies that use that disjoint group.

Figure 23. Disjoint Group
Disjoint Group

To go back to the SR Policy Details window, click Previous Screen icon.

Modify SR Policies

To modify an SR policy:

Procedure

Step 1

From the main menu, choose Optimization Engine > SR Policies.

Step 2

Expand the SR Policies table. You will see a list of SR policies and various information such as source, destination, Admin status, operating status, and so on.

Step 3

Locate the SR policy you are interested in and click the Details... link (under the Actions column). You may need to expand the SR Policies table to view the Actions column.

Step 4

From the top-right corner of the SR Policy Details window, click Edit Policy icon.

Note 

If the icon is grayed out, the policy cannot be modified for one of the following reasons:

  • The policy was not created using the Crosswork Optimization Engine (SR Policies table > Create).

  • The policy was created using the Bandwidth Optimization function pack.
Step 5

Click Edit.

Step 6

In the Policy Path area, modify the values you want to change.

Step 7

(Optional) Click Preview to view visible updates on the topology map.

Step 8

Click Update.

Step 9

When the policy is updated successfully, a window appears with the following options:

  • View SR Policy List—Displays the SR Policies table that lists all SR policies including the one that was just updated.

  • Create New—Allows you to create a new SR policy.

Get More Information About an SR Policy

From the SR Policies table, locate the SR policy you are interested in and click the Details... link (under the Actions column). You may need to expand the SR Policies table to view the Actions column. The SR Policy Details window appears, where you can view more detailed information about the policy and its associated paths. See the following table for field descriptions.
Figure 24. SR Policy Details
SR Policy Details
Table 2. SR Policy Details Fields
Field Description

Headend

Where the SR policy is instantiated (source).
Endpoint

The destination of the SR policy.

Color

A numerical value that distinguishes between two or more policies to the same node pairs (Headend – Endpoint). Every SR policy between a given headed and endpoint must have a unique color.

Description

(Optional) If provisioned using the Cisco Crosswork Optimization Engine UI, it is the description entered by the user. This may be blank if the user did not enter a description.

Path Name

The name of the current active candidate path of the SR policy. For SR policies created using the Cisco Crosswork Optimization Engine UI, it will be the name provided by the user during configuration. For SR policies created through configuration on the headend router, the Path Name will be the base name configured for the policy on the CLI with "cfg_" appended to the beginning and the candidate path preference appended to the end.

Path Type

Indicates whether an SR policy created through Cisco Crosswork Optimization Engine is explicit or dynamic.

Admin State

Administrative state is dictated by the user.

For example, the user creates an SR policy and does not intentionally shut it down. The Admin State will be UP.

Oper State

Operational state received by the system.

For example, the user has configured a policy and so the Admin State is UP. However, due to network issues it is operationally down. In this case, Oper State will display DOWN and Admin State will remain as UP.

Binding SID

The binding segment is a local segment identifying an SR policy. Each SR policy is associated with a binding segment ID (BSID). The BSID is a local label that is automatically allocated (or explicitly entered during manual provisioning) for each SR policy when the policy is instantiated.

Profile ID

Identification used to associate an SR policy with a set of features applied to the policy by the headend. It should correspond with a profile configured on the headend.

Utilization (Mbps)

The measured traffic on the SR policy.

BWOD Policy Bandwidth (Mbps)

The bandwidth constraint associated with a policy created through the Bandwidth on Demand function pack.

Metric Type

The metric type can be of type TE, IGP, or latency.

Accumulated Metric

Total metric calculation of the SR policy.

Disjoint Group

If applicable, displays disjointness information.

PCE Initiated

If the policy was initiated and provisioned by a PCE, the value is True.

Source Application

Indicates which application created this SR policy. It can be one of the following:

  • Optimization Engine—The policy was provisioned using the Cisco Crosswork Optimization Engine UI.

  • Bandwidth Optimization—This is a tactical SR policy that was created by the Bandwidth Optimization function pack to remediate traffic congestion. It will be removed when the congestion goes below the configured threshold.

If it is blank, the SR policy was PCC instantiated.

Delegated PCE

The SR policy is delegated to this PCE IP address.

Non Delegated PCEs

PCEs reporting the policy, but not currently delegated.

Affinity

Lists any affinity constraints belonging to this policy.

Segment

Lists whether a dynamic path policy should prefer protected or require unprotected SIDSs

PCE Computed Time

Time when PCE computed the path currently in effect.

Last Update

The last time the policy was updated.

Path

Lists segments that are part of the policy. It gives the following segment information: segment type, label, IP address, associated node, interface, and SID type (Protected or Unprotected).