Segment Routing - Do not use

Segment ID Labels

You can define the hops in an SR LSP tunnel path policy in the Path tab of the Add Tunnels or Modify Tunnels page. The hops specify the user-defined path policy for SR.

You specify the hops in the SR path policy by specifying the sequence of nodes, links and/or groups of nodes that you require the paths to traverse. The SID list that is generated to implement the path policy does not necessarily correspond to the exact hops that you specified. The paths satisfying your path policy also satisfy your other requirements such as delay, bandwidth, and so on. Therefore, the result of SR path computation is a list of SIDs that instruct the network to implement paths that satisfy your policy. But, the SID list may not align exactly with the hops specified in the path policy.

if both, a node SID and an anycast SID, are available for path computation, the PCS can implement the paths that satisfy your policy as follows to route traffic according to the path policy when PCEP or Netconf is used for the path computation request:

• Uses anycast SID instead of the node SID if PCEP is used.

• Uses node SID instead of anycast SID if Netconf is used.

Adjacency segment ID (SID) labels (associated with links) and node SID labels (associated with nodes) can be displayed on the topological map.

Note:

You can use either BGP-LS peering or IGP adjacency from the JunosVM to the network to acquire network topology. However, for SPRING information to be properly learned by NorthStar when using BGP-LS, the network should have RSVP enabled on the links and the TED database available in the network.

You can display adjacency SID labels on the map. On the right side of the topology window is a menu bar offering various topology settings. Click the Tools (gear-shaped) icon and select the Elements tab. Under Links, click the check box for Show Label and select SID A::Z from the corresponding drop-down menu. An example topology map showing adjacency SID labels is shown in Figure 1.

To view adjacency SID labels in the network information table, click the down arrow beside any column heading under the Link tab, and click Columns to display the full list of available columns. Click the check boxes beside SID A and SID Z.

When you display the detailed information for a specific link (by double clicking the link in the map or in the network information table), you see an attribute folder for both endA and endZ called SR. You can drill down to display attributes for each SID as shown in Figure 2. At present, only IPv4 SIDs are supported, and only one per interface.

Node SID labels are displayed a little differently because the value of the label depends on the perspective of the node assigning it. A node might be given different node SID labels based on the perspective of the assigning node. To display node SID labels on the topology map, specify the perspective by right-clicking on a node and selecting Node SIDs from selected node. The node SID labels are then assigned from the perspective of that selected node.

For example, Figure 3 shows a topology displaying the SID node labels from the perspective of node vmx101. Note that the node SID label for node vmx106 is 1106.

If you right-click on node vmx104 and select Node SIDs from selected node, the node SID labels on the topology change to reflect the perspective of node vmx104 as shown in Figure 4. Note that the node SID label for node vmx106 is now 4106.

The selected node does not display a node SID label for itself. Any other nodes in the topology map that do not display a node SID label do not have the segment routing protocol configured.

Note:

Node SID information is not available in the network information table.

SR LSPs

SR LSPs can be created using both adjacency SID and node SID labels. An SR LSP is a label stack that consists of a list of adjacency SID labels, node SID labels, or a mix of both.

To create an SR LSP:

1. Navigate to the Tunnel tab in the network information table and click Add at the bottom of the table to display the Provision LSP window, Properties tab.

2. From the Provisioning Method drop-down menu, select either PCEP or NETCONF.

   • PCEP SR LSPs are PCE-initiated and the associated configuration statements do not appear in the router configuration file. The advantage of PCEP is that LSP information is provided to NorthStar in real time, so changes in path or state are reflected in the NorthStar UI immediately.

   • NETCONF SR LSPs are statically provisioned and the associated configuration statements do appear in the router configuration file. While SR LSPs can be provisioned via NETCONF, they can be learned via either PCEP or NETCONF. In Junos OS Release 18.2 R1, PCEP reporting is limited. The alternative is to learn about the details of the NETCONF-provisioned SR LSPs by way of Device Collection configuration parsing in NorthStar.If you opt to use this method for SR LSP provisioning, be aware that because the primary path details come from device collection configuration parsing, updates are not provided to NorthStar in real time, and NorthStar reports the operation status for these LSPs as Unknown.

   • In order for the configuration statements to be included in the router configuration file, SR LSPs must be configured in NorthStar via NETCONF.

3. Complete the Name, Node A, and Node Z fields.

4. From the Provisioning Type drop-down menu, select SR.

5. For NETCONF SR LSP provisioning (not applicable to PCEP), you can also specify a binding SID label value in the Binding SID field on the Advanced tab. See the Binding SID section for more information.

6. On the Design tab, select the routing method from the drop-down menu, typically either routeByDevice (router computes some of the path) or default (NorthStar computes the path).

7. On the Path tab, you can specify any specific hops you want in the path, including private forwarding adjacency links generated by the provisioning of binding SID SR LSP pairs. See the Binding SID section for more information.

8. Click Submit. The provisioning request then enters the Work Order Management process.

   • For both PCEP and NETCONF provisioned SR LSPs, once the work order is activated, the new path is highlighted in the topology map.

   • For NETCONF provisioned SR LSPs, once the work order is activated, the corresponding configuration statements appear in the router configuration file.

Viewing the Path

There are multiple ways to view the details of the path:

• The IP address and the SID are the two parts of the explicit route. The IP address part is displayed in the ERO column in the network information table, Tunnel tab. The SID part is displayed in the Record Route column.

• Double-click on the tunnel row in the network information table and drill down into the liveProperties to see the details of the ERO.

• Use Junos OS show commands on the router. Some examples are:

  • show spring-traffic-engineering lsp name lsp-name detail to display the LSP status and SID labels.

  • show route table inet.3 to display the mapping of traffic destinations with SPRING LSPs.

If a link in a path is used in both directions, it is highlighted in a different color in the topology, and does not have arrowheads to indicate direction. Figure 5 shows an example in which the link between vmx105 and vmx106 is used in both directions.

Binding SID

When you provision a pair of binding SID SR LSPs (one going from A to Z and one for the return path from Z to A), a private forwarding adjacency is automatically generated. These adjacencies are named with a specific format, with three sections, separated by colons. For example, binding:0110.0000.0105:privatefa57.

• The names all start with “binding” followed by a colon.

• The center section is the name of the originating node, followed by a colon (0110.0000.0105: in this example).

• The last section is the name you specified for the binding SID SR LSP in the Name field on the Properties tab of the Provision LSP window (privatefa57 in this example). This name must be the same for the binding SID SR LSPs in both directions, to ensure they can be properly matched, creating the corresponding private forwarding adjacency link.

In the topology map, you can opt to display private forwarding adjacency links or not. In the left pane drop-down menu, select Types and then select or deselect the check box for privateForwardingAdjacency under Link Types as shown in Figure 6. When selected, the adjacencies display as dotted lines on the topology map as shown in Figure 7.

You can tunnel a non-binding SID SR LSP over a binding SID SR LSP, thereby reducing the number of labels in the label stack (private forwarding adjacency labels can represent multiple hops in the path). An example is shown in Figure 8.

Note:

Tunneling a binding SID SR LSP over another binding SID SR LSP is not supported.

In this display, you can see the logical path (traced in amber) of the SR LSP as it goes from vmx101 to vmx105, to vmx107 by way of a private forwarding adjacency link, and finally to vmx103. You can also see (traced in pink) the path of the private forwarding adjacency link of the binding SID SR LSP. The Record Route column in the network information tunnel shows a label stack with three labels. The second label of the three is the private forwarding adjacency link. Without that adjacency link, the label stack would have required six labels to define the same path.

Note:

Path highlighting for an SR LSP in a network that has two adjacency SIDs per interface is not supported.

To provision a pair of binding SID SR LSPs, use the procedure for NETCONF SR LSP provisioning, plus:

1. On the Provision LSP window Advanced tab, populate the Binding SID field with a numerical binding SID label value of your choice from the static label range of 1000000 to 1048575. This value then becomes the label that represents the path defined by the hops you specify on the Path tab (the hops that make up the private forwarding adjacency link).

   Note:

   At this time, NorthStar does not support binding SID label allocation nor collision detection. Note that Junos OS has built-in collision detection, so that if the binding SID label specified is outside the allowed range of 1000000 to 1048575, the router does not allow the configuration to commit. Correspondingly, the Controller Status in the Tunnel tab of the network information table shows the usual indication of FAILED(NS_ERR_INVALID_CONFIG).

2. On the Design tab, select the routing method, default for example.

3. On the Path tab, select the hops in the path.

4. Provision a second binding SID SR LSP in the opposite direction, using the same LSP name as the first LSP in the pair. The binding SID label value can also be the same as in the first LSP in the pair, but it is not required that it be the same.

When the binding SID SR LSP pair is provisioned, the private forwarding adjacency link is automatically created, and can then be selected as a destination when you designate hops for a non-binding SID SR LSP. Use show commands on the router to confirm that the LSP pair has been pushed to the router configuration.

Maximum SID Depth (MSD)

To avoid encountering an equipment limitation on the maximum SID depth (MSD), you can use the Routing Method drop-down menu in the Provision LSP window (Design tab) to select routeByDevice as shown in Figure 9. This option allows the router to control part of the routing, so fewer labels need to be explicitly specified.

Note:

routeByDevice is to be used when you want to create an SR LSP with Node SID.

Note:

When provisioning via PCEP, a symptom of encountering the MSD limitation when you are not using routeByDevice is that although a row for the new LSP is added to the network information table, the Op Status is listed as Unknown and the Controller Status is listed as Reschedule in x minutes.

Provisioning of an SR LSP can include hop information that somewhat influences the routing. In the Provision LSP window, select the Path tab. There, you can select hops up to the MSD hop limitation that is imposed on the ingress router, and specify Strict or Loose adherence.

PCEP RoutebyDevice Example

In Figure 10, the routing paths highlighted are the equal cost paths for the t2 LSP.

For t2 in this example:

• Node A is vmx101 and Node Z is vmx104.

• The provisioning type is SR, designated in the Properties tab of the Provision LSP window.

• The routing method is routeByDevice, designated in the Design tab of the Provision LSP window. The highlighting of the equal cost paths can only be viewed in the topology if the routing is being done by the PCC.

The mandatory transit router can be part of the generated ERO using the adjacency SID passing through that transit router. However, specifying a mandatory transit router usually increases the label stack depth, violating the MSD. In that case, you can try using the routeByDevice method. To specify a mandatory transit router using Node SID, select the routing method as routeByDevice (Design tab), and specify the loopback of the mandatory transit router as loose hop (Path tab).

A possible downside to using routeByDevice is that other constraints you impose on the LSP links (bandwidth, coloring, and so on) cannot be guaranteed. The NorthStar Controller does not provision the LSP if it sees that the constraints cannot be met. But if the information available indicates that the constraints can be met, the NorthStar Controller provisions the LSP even though those constraints are not guaranteed. Turning on the path optimization timer enables NorthStar to periodically check the constraints.

If the NorthStar Controller later learns (during the execution of an optimization request, for example) that the constraints are no longer being met, it will try to reroute the tunnel by changing the first hop outgoing interface if a specific one was not configured. If that is not possible, the LSP remains in the network, even though constraints have been violated.

The Role of NETCONF Device Collection

SR LSPs provisioned using NETCONF can be learned either by PCEP or by device collection. When learned by device collection, the information is pulled in a non-real-time fashion only when collection tasks are run.

Note:

When you create your NETCONF device collection tasks, be sure you select the check box to collect configuration data. This is necessary for NorthStar to collect and parse the statements in the router configuration file, including those related to SR LSPs. See Figure 11.

Figure 11: Select the Check Box to Collect Configuration

Automatic NETCONF collection is also performed every time an SR LSP is provisioned using NETCONF in the NorthStar UI.

Rerouting and Reprovisioning

For PCEP-provisioned SR LSPs, the router is only able to report on the operational status (Op Status in the network information table) of the first hop. After the first hop, the NorthStar Controller takes responsibility for monitoring the SID labels, and reporting on the operational status. If the labels change or disappear from the network, the NorthStar Controller tries to reroute and re-provision the LSPs that are in a non-operational state.

If NorthStar is not able to find an alternative routing path that complies with the constraints, the LSP is deleted from the network. These LSPs are not, however, deleted from the data model (they are deleted from the network, and persist in the data storage mechanism). The goal is to minimize traffic loss from non-viable SR LSPs (black holes) by deleting them from the network. Op Status is listed as Unknown when an SR LSP is deleted, and the Controller Status is listed as No path found or Reschedule in x minutes.

You can mitigate the risk of traffic loss by creating a secondary path for the LSP with fewer or more relaxed constraints. If the NorthStar Controller learns that the original constraints are not being met, it first tries to reroute using the secondary path.

Note:

Although NorthStar permits adding a secondary path to an SR LSP, it is not provisioned as a secondary path to the PCC because the SR LSP protocol itself does not support secondary paths.

If you are creating an LSP (both PCEP-provisioned or Netconf-provisioned) by using REST APIs, you can set the rerouting behavior of an SR LSP to noRerouting, wherein, the SR PCS brings down the SR LSP if topology changes cause traffic in the LSP to deviate from the original path it was provisioned on. If noRerouting is not specified (that is rerouting is allowed), the PCS computes a new path that complies with the user-defined path policy when the network topology changes.

When the PCS has an option to use both node SIDs and anycast SIDs for implementing a path policy, the PCS uses SIDs as follows:

• If noRerouting is specified, node SIDs are used for implementing the path policy.

• If rerouting is allowed, anycast SIDs are used for implementing the path policy. This is because when the topology changes, the existing SID list can still implement a path policy by shifting the LSP from one node in the anycast group to another node in the anycast group.