Static Segment Routing Label Switched Path

 

The segment routing architecture enables the ingress devices in a core network to steer traffic through explicit paths. You can configure these paths using segment lists to define the paths that the incoming traffic should take. The incoming traffic may be labeled or IP traffic, causing the forwarding operation at the ingress device to be either a label swap, or a destination-based lookup.

Understanding Static Segment Routing LSP in MPLS Networks

Source packet routing or segment routing is a control-plane architecture that enables an ingress router to steer a packet through a specific set of nodes and links in the network without relying on the intermediate nodes in the network to determine the actual path it should take.

Introduction to Segment Routing LSPs

Segment routing leverages the source routing paradigm. A device steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to a segment routing node or to a global node within a segment routing domain. Segment routing enforces a flow through any topological path and service chain while maintaining per-flow state only at the ingress device to the segment routing domain. Segment routing can be directly applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.

Segment routing LSPs can either be dynamic or static in nature.

Dynamic segment routing LSPs—When a segment routing LSP is created either by an external controller and downloaded to an ingress device through Path Computation Element Protocol (PCEP) extensions, or from a BGP segment routing policy through BGP segment routing extensions, the LSP is dynamically provisioned. The segment list of the dynamic segment routing LSP is contained in the PCEP Explicit Route Object (ERO), or the BGP segment routing policy of the LSP.

Static segment routing LSPs—When a segment routing LSP is created on the ingress device through local configuration, the LSP is statically provisioned.

A static segment routing LSP can further be classified as colored and non-colored LSPs based on the configuration of the color statement at the [edit protocols source-packet-routing source-routing-path lsp-name] hierarchy level.

For example:

[edit protocols]
source-packet-routing {
source-routing-path lsp_name {
to destination_address;
color color_value;
binding-sid binding-label;
primary segment_list_1_name weight weight;
...
primary segment_list_n_name weight weight;
secondary segment_list_n_name;
sr-preference sr_preference_value;
}
}

Here, each primary and secondary statement refers to a segment list.

[edit protocols]
source-packet-routing {
segment-list segment_list_name {
hop_1_name label sid_label;
...
hop_n_name label sid_label;
}
}

Benefits of using Segment Routing LSPs

  • Static segment routing does not rely on per LSP forwarding state on transit routers. Hence, removing the need of provisioning and maintaining per LSP forwarding state in the core.

  • Provide higher scalability to MPLS networks.

Colored Static Segment Routing LSP

A static segment routing LSP configured with the color statement is called a colored LSP.

Understanding Colored Static Segment Routing LSPs

Similar to a BGP segment routing policy, the ingress route of the colored LSP is installed in the inetcolor.0 or inet6color.0 routing tables, with destincation-ip-address, color as key for mapping IP traffic.

A static colored segment routing LSP may have a binding SID, for which a route is installed in the mpls.0 routing table. This binding SID label is used to map labeled traffic to the segment routing LSP. The gateways of the route are derived from the segment list configurations under the primary and secondary paths.

Segment List of Colored Segment Routing LSPs

The colored static segment routing LSPs already provde support for first hop label mode of resolving an LSP. However, first hop IP mode is not supported for colored segment routing LSPs. Starting in Junos OS Release 19.1R1, a commit check feature is introduced to ensure that all the segment lists contributing to the colored routes have the minimum label present for all hops. If this requirement is not met, the commit is blocked.

Non-Colored Static Segment Routing LSP

A static segment routing LSP that is configured without the color statement is a non-colored LSP. Similar to PCEP segment routing tunnels, the ingress route is installed in the inet.3 or inet6.3 routing tables.

Junos OS supports non-colored static segment routing LSPs on ingress routers. You can provision non-colored static segment routing LSP by configuring one source routed path and one or more segment lists. These segment lists can be used by multiple non-colored segment routing LSPs.

Understanding Non-Colored Segment Routing LSPs

The non-colored segment routing LSP has a unique name and a destination IP address. An ingress route to the destination is installed in the inet.3 routing table with a default preference of 8 and a metric of 1. This route allows non-colored services to be mapped to the segment routing LSP pertaining to the destination. In case the non-colored segment routing LSP does not require an ingress route then the ingress route can be disabled. A non-colored segment routing LSP uses binding SID label to achieve segment routing LSP stitching. This label that can be used to model the segment routing LSP as a segment that may be further used to construct other segment routing LSPs in a hierarchical manner. The transit of the binding SID label, by default, has a preference of 8 and a metric of 1.

Starting in Junos OS Release 18.2R1, statically configured non-colored segment routing LSPs on the ingress device are reported to the Path Computation Element (PCE) through a Path Computation Element Protocol (PCEP) session. These non-colored segment routing LSPs may have binding service identifier (SID) labels associated with them. With this feature, the PCE can use this binding SID label in the label stack to provision PCE-initiated segment routing LSP paths.

A non-colored segment routing LSP can have a maximum of 8 primary paths. If there are multiple operational primary paths then the packet forwarding engine (PFE) distributes traffic over the paths based on the load balancing factors like the weight configured on the path. This is equal cost multi path (ECMP) if none of the paths have a weight configured on them or weighted ECMP if at least one of the paths has a non-zero weight configured on the paths. In both the cases, when one or some of the paths fail, the PFE rebalances the traffic over the remaining paths that automatically leads to achieving path protection. A non-colored segment routing LSP can have a secondary path for dedicated path protection. Upon failure of a primary path, the PFE rebalances the traffic to the remaining functional primary paths. Otherwise, the PFE switches the traffic to the backup path, hence achieving path protection. A non-colored segment routing LSP may specify a metric at [edit protocols source-packet-routing source-routing-path lsp-name] for its ingress and binding-SID routes. Multiple non-colored segment routing LSPs have the same destination address that contribute to the next hop of the ingress route.

Multiple non-colored segment routing LSPs have the same destination address that contribute to the next hop of the ingress route. Each path ,either primary or secondary, of each segment routing LSP is considered as a gateway candidate, if the path is functional and the segment routing LSP has the best preference of all these segment routing LSPs. However, the maximum number of gateways that the next-hop can hold cannot exceed the RPD multi-path limit, which is 128 by default. Extra paths are pruned, firstly secondary paths and then primary paths. A given segment list may be referred multiple times as primary or secondary paths by these segment routing LSPs. In this case, there are multiple gateways, each having a unique segment routing LSP tunnel ID. These gateways are distinct, although they have identical outgoing label stack and interface. A non-colored segment routing LSP and a colored segment routing LSP may also have the same destination address. However, they correspond to different destination addresses for ingress routes, as the colored segment routing LSP’s destination address is constructed with both its destination address and color.

Note

In the case where a static non-colored segment routing LSP and a PCEP-created segment routing LSP co-exist and have the same to address that contributes to the same ingress route, if they also have the same preference. Otherwise, the segment routing LSP with the best preference is installed for the route.

Segment List of Non-Colored Segment Routing LSPs

A segment list consists of a list of hops. These hops are based on the SID label or an IP address. The number of SID labels in the segment list should not exceed the maximum segment list limit. You can configure the maximum segment list limit at the [edit protocols source-packet-routing] hierarchy level.

Prior to Junos OS Release 19.1R1, for a non-colored static segment routing LSP to be usable, the first hop of the segment list had to be an IP address of an outgoing interface and the second to nth hops could be SID labels. Starting in Junos OS Release 19.1R1, this requirement does not apply, as the first hop of the non-colored static LSPs now provides support for SID labels, in addition to IP addresses. With the first hop label support, MPLS fast reroute (FRR) and weighted equal-cost multipath is enabled for resolving the static non-colored segment routing LSPs, similar to colored static LSPs.

For the first-hop label mode to take effect, you must include the inherit-label-nexthops statement globally or individually for a segment list, and the first hop of the segment list must include both IP address and label. If the first hop includes only IP address, the inherit-label-nexthops statement does not have any effect.

You can configure inherit-label-nexthops at any one of the following hierarchies. The inherit-label-nexthops statement takes effect only if the segment list first hop includes both IP address and label.

  • Segment list level—At the [edit protocols source-packet-routing segment-list segment-list-name] hierarchy level.

  • Globally—At the [edit protocols source-packet-routing] hierarchy level.

When the inherit-label-nexthops statement is configured globally, it takes precedence over the segment-list level configuration, and the inherit-label-nexthops configuration is applied to all the segment lists. When the inherit-label-nexthops statement is not configured globally, only segment lists with both labels and IP address present in the first hop, and configured with inherit-label-nexthops statement are resolved using SID labels.

For dynamic non-colored static LSPs, that is the PCEP-driven segment routing LSPs, the inherit-label-nexthops statement must be enabled globally, as the segment-level configuration is not applied.

Table 1 describes the mode of segment routing LSP resolution based on the first hop specification.

Table 1: Non-Colored Static LSP Resolution Based on First Hop Specification

First Hop Specification

Mode of LSP Resolution

IP address only

For example:

segment-list path-1 {
hop-1 ip-address 172.0.12.2;
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}

The segment list is resolved using the IP address.

SID only

For example:

segment-list path-2 {
hop-1 label 1000011;
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}

The segment list is resolved using SID labels.

IP address and SID (without the inherit-label-nexthops configuration)

For example:

segment-list path-3 {
hop1 {
label 801006;
ip-address 172.24.1.2;
}
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}

By default, the segment list is resolved using IP address.

IP address and SID (with the inherit-label-nexthops configuration)

For example:

segment-list path-3 {
inherit-label-nexthops;
hop1 {
label 801006;
ip-address 172.24.1.2;
}
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}

The segment list is resolved using SID labels.

You can use the show route ip-address protocol spring-te active-path table inet.3 command to view the non-colored segment routing traffic-engineered LSPs having multiple segment lists installed in the inet.3 routing table.

For example:

user@host> show route 7.7.7.7 protocol spring-te active-path table inet.3
Note

The first hop type of segment lists of a static segment routing LSP can cause a commit to fail, if:

  • Different segment lists of a tunnel have different first hop resolution types. This is applicable to both colored and non-colored static segment routing LSPs. However, this does not apply for PCEP-driven LSPs; a system log message is generated for the mismatch in the first hop resolution type at the time of computing the path.

    For example:

    The commit of tunnel lsp1 fails, as path-1 is of IP addressmode and path-2 is of label mode.

  • The binding SID is enabled for the static non-colored LSP whose segment list type is SID label.

    For example:

    Configuring binding SID over label segment list is supported only for colored static LSPs and not for no-colored static LSPs.

Static Segment Routing LSP Provisioning

Segment provisioning is performed on per-router basis. For a given segment on a router, a unique service identifier (SID) label is allocated from a desired label pool which may be from the dynamic label pool for an adjacency SID label or from the segment routing global block (SRGB) for a prefix SID or node SID. The adjacency SID label can be dynamically allocated, which is the default behavior, or be allocated from a local static label pool (SRLB). A route for the SID label is then installed in the mpls.0 table.

Junos OS allows static segment routing LSPs by configuring the segment statement at the [edit protocols mpls static-label-switched-path static-label-switched-path] hierarchy level. A static segment LSP is identified by a unique SID label that falls under Junos OS static label pool. You can configure the Junos OS static label pool by configuring the static-label-range static-label-range statement at the [edit protocols mpls label-range] hierarchy level.

Static Segment Routing LSP Limitations

  • Junos OS currently has a limitation that the next hop cannot be built to push more than the maximum segment list depth labels. So, a segment list with more than the maximum SID labels (excluding the SID label of the first hop which is used to resolve forwarding next-hop) is not usable for colored or non-colored segment routing LSPs. Also, the actual number allowed for a given segment routing LSP may be even lower than the maximum limit, if an MPLS service is on the segment routing LSP or the segment routing LSP is on a link or a node protection path. In all cases, the total number of service labels, SID labels, and link or node protection labels must not exceed the maximum segment list depth. You can configure the maximum segment list limit at [edit protocols source-packet-routing] hierarchy level. Multiple non-colored segment routing LSPs with less than or equal to the maximum SID labels can be stitched together to construct a longer segment routing LSP. This is called segment routing LSP stitching. It can be achieved using binding-SID label.

  • The segment routing LSP stitching is actually performed at path level. If a non-colored segment routing LSP has multiple paths that is multiple segment lists, each path can be independently stitched to another non-colored segment routing LSP at a stitching point. A non-colored segment routing LSP which is dedicated to stitching may disable ingress route installation by configuring no-ingress statement at [edit protocols source-packet-routing source-routing-path lsp-name] hierarchy level.

  • A maximum of 8 primary paths and 1 secondary path are supported per non-colored static segment routing LSP. If there is a violation in configuration, commit check fails with an error.

  • If any segment-list is configured with more labels than the maximum segment list depth, the configuration commit check fails with an error.

Dynamic Creation of Segment Routing LSPs

In segment routing networks that have each provider edge (PE) device connected to every other PE device, a large amount of configuration is required for setting up the segment routing label-switched paths (LSPs), although only a few segment routing traffic-engineered (SR-TE) paths may be used. You can enable BGP-trigerred dynamic creation of these LSPs to reduce the amount of configuration in such deployments.

Configuring Dynamic Segment Routing LSP Template

To configure the template for enabling dynamic creation of segment routing LSPs, you must include the spring-te statement at the [edit routing-options dynamic-tunnels] hierarchy.

  • The following is a sample configuration for color dynamic segment routing LSP template:

  • The following is a sample configuration for non-color dynamic segment routing LSP template:

Resolving Dynamic Segment Routing LSPs

Resolving Colored Dynamic Segment Routing LSP

When the BGP prefixes are assigned with color community, they initially get resolved over the catch-all-route-for-that–particular-color policy, and in turn, the SR-TE template on which the BGP prefix should be resolved onto is identified. The destinations SID is then derived from the BGP payload prefix next-hop attribute. For example, if the next hop of the BGP payload prefix is an IP address that belongs to Device A, then the node-SID of Device A is taken and a corresponding label is prepared and pushed to the bottom of the stack. The BGP payload prefix is resolved in a color-only mode, where the node-SID of Device A is at the bottom of the final label stack, and the SR-TE path labels are on top.

The final LSP template name is a combination of prefix, color, and tunnel name; for example, <prefix>:<color>:dt-srte-<tunnel-name>. The color in the LSP name is displayed in hexadecimal format, and the format of the tunnel name is similar to that o RSVP-triggered tunnel LSP names.

To successfully resolve a colored destination network, the color should have a valid template mapping, either to a specific color, or through the color-any template. Without a valid mapping, the tunnel is not created and the BGP route requesting for resolution remains unresolved.

Resolving Uncolored Dynamic Segment Routing LSPs

The catch-all routes for non-colored LSPs are added to the inet.3 routing table. The non-colored tunnel destination must be configured in a different spring-te configuration with only one template name in the mapping list. This template name is used for all the tunnel routes matching any of the destination networks configured under the same spring-te configuration. These tunnels are similar to RSVP tunnels in functionality.

The final LSP template name is a combination of prefix and tunnel name; for example, <prefix>:dt-srte-<tunnel-name>.

Dynamic Segment Routing LSP Sample Configuration

The dynamic segment routing LSP template always carries a partial path. The last hop node SID is derived automatically at the tunnel creation time depending on the protocol next-hop address (PNH) node SID. The same template can be used by multiple tunnels to different destinations. In such cases, the partial path remains the same, and only the last hop changes depending on the PNH. Dynamic segment routing LSP templates are not common to a single tunnel, as a result a full path cannot be carried on it. You can use a segment list if a full path is to be used.

Colored Dynamic Segment Routing LSPs

Sample configuration for colored dynamic segment routing LSPs:

For the above-mentioned sample configuration, the route entries are as follows:

  • inetcolor.0 tunnel route: 22.33.44.0-0/24 --> RT_NH_TUNNEL

  • inetcolor6.0 tunnel route: ffff::22.33.44.0-0/120 --> RT_NH_TUNNEL

  • BGP prefix to tunnel mapping:

    R1(prefix) -> 22.33.44.55-101(PNH) LSP tunnel name = 22.33.44.55:65:dt-srte-tunnel1

    R1(prefix) -> ffff::22.33.44.55-101(PNH) LSP tunnel name = 22.33.44.55:65:dt-srte-tunnel1

    R1(prefix) -> ffff::22.33.44.55-124(PNH) LSP tunnel name = 22.33.44.55:7c:dt-srte-tunnel1

  • inetcolor.0 tunnel route:

    22.33.44.55-101/64 --> <next-hop>

    22.33.44.55-124/64 --> <next-hop>

  • inetcolor6.0 tunnel route:

    ffff::22.33.44.55-101/160 --> <next-hop>

    ffff::22.33.44.55-124/160 --> <next-hop>

Non-Colored Dynamic Segment Routing LSPs

Sample configuration for non-colored dynamic segment routing LSPs:

For the above-mentioned sample configuration, the route entries are as follows:

  • inet.3 tunnel route: 22.33.44.0/24 --> RT_NH_TUNNEL

  • inet6.3 tunnel route: ffff::22.33.44.0/120 --> RT_NH_TUNNEL

  • BGP prefix to tunnel mapping:

    R1(prefix) -> 22.33.44.55(PNH) LSP template name = LSP1 --- 22.33.44.55:dt-srte-tunnel2

    R1(prefix) -> ffff::22.33.44.55(PNH) LSP template name = LSP1 --- 22.33.44.55:dt-srte-tunnel2

  • inet.3 tunnel route: 22.33.44.55/32 --> <next-hop>

  • inet6.3 tunnel route: ffff::22.33.44.55/128 --> <next-hop>

Unresolved Dynamic Segment Routing LSP

Sample configuration for unresolved dynamic segment routing LSPs:

For the above-mentioned sample configuration, the route entries are as follows:

  • inetcolor.0 tunnel route: 22.33.44.0 - 0/24 --> RT_NH_TUNNEL 1.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  • inetcolor6.0 tunnel route: ffff::22.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::1.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  • BGP prefix to tunnel mapping: R1(prefix) -> 22.33.44.55-124(PNH) Tunnel will not be created. (Template not found for the color).

Considerations for Configuring Dynamic Creation of Segment Routing LSPs

When configuring the dynamic creation of segment routing LSPs, take the following into consideration:

  • A template can be assigned with a color object. When the dynamic tunnel spring-te configuration includes a template with a color object, you must configure all other templates with color objects as well. All destinations are assumed to be colored within that configuration.

  • A template can have a list of colors defined on it, or can be configured with the color-any option. Both these options can coexist in the same spring-te configuration. In such cases, templates assigned with specific colors have a higher preference.

  • In a spring-te configuration, only one template can be defined with the color-any option.

  • The color-to-template mapping is done on a one-to-one basis. One color cannot map to multiple templates.

  • The template name should be configured in the spring-te statement under the [edit protocols] hierarchy, and should have the primary option enabled.

  • Colored and non-colored destinations cannot co-exist in the same spring-te configuration.

  • You cannot configure same destination networks, with or without color, under different spring-te configuration statements.

  • In non-colored spring-te configuration, only one template can be configured without color object.

Services Supported over Dynamic Segment Routing LSPs

The following services are supported over colored dynamic segment routing LSPs:

  • Layer 3 VPN

  • BGP EVPN

  • Export policy services

The following services are supported over non-colored dynamic segment routing LSPs:

  • Layer 3 VPN

  • Layer 2 VPN

  • Multipath configurations

Behavior With Multiple Tunnel Sources in Segment Routing

When two sources download routes to the same destination from segment routing (for example static and dynamic sourced tunnels), then the segment routing preference is used for choosing the active route entry. A higher value has greater preference. In case the preference remains the same, then the tunnel source is used to determine the route entry.

Dynamic Segment Routing LSPs Limitations

The dynamic SR-TE LSPs do not support the following features and functionalities:

  • IPv6 segment routing tunnels.

  • Static tunnels.

  • 6PE is not supported.

  • Distributed CSPF.

  • sBFD and LDP tunnelling is not supported for dynamic SR-TE LSPs and in a template.

  • Install and B-SID routes in a template.

Release History Table
Release
Description
Starting in Junos OS Release 19.1R1, a commit check feature is introduced to ensure that all the segment lists contributing to the colored routes have the minimum label present for all hops.
Starting in Junos OS Release 19.1R1, this requirement does not apply, as the first hop of the non-colored static LSPs now provides support for SID labels, in addition to IP addresses. With the first hop label support, MPLS fast reroute (FRR) and weighted equal-cost multipath is enabled for resolving the static non-colored segment routing LSPs, similar to colored static LSPs.
Starting in Junos OS Release 18.2R1, statically configured non-colored segment routing LSPs on the ingress device are reported to the Path Computation Element (PCE) through a Path Computation Element Protocol (PCEP) session.