Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Segment Routing LSP Configuration

Enabling Distributed CSPF for Segment Routing LSPs

Prior to Junos OS Release 19.2R1S1, for traffic engineering of segment routing paths, you could either explicitly configure static paths, or use computed paths from an external controller. With the distributed Constrained Shortest Path First (CSPF) for segment routing LSP feature, you can compute a segment routing LSP locally on the ingress device according to the constraints you have configured. With this feature, the LSPs are optimized based on the configured constraints and metric type (traffic-engineering or IGP). The LSPs are computed to utilize the available ECMP paths to the destination with segment routing label stack compression enabled or disabled.

Distributed CSPF Computation Constraints

Segment routing LSP paths are computed when all the configured constraints are met.

The distributed CSPF computation feature supports the following subset of constraints specified in the Internet draft, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering:

  • Inclusion and exclusion of administrative groups.

  • Inclusion of loose or strict hop IP addresses.

    Note:

    You can specify only router IDs in the loose or strict hop constraints. Labels and other IP addresses cannot be specified as loose or strict hop constraints in Junos OS Release 19.2R1-S1.

  • Maximum number of segment IDs (SIDs) in the segment list.

  • Maximum number of segment lists per candidate segment routing path.

The distributed CSPF computation feature for segment routing LSPs does not support the following types of constraints and deployment scenarios:

  • IPV6 addresses.

  • Inter domain segment routing traffic engineering (SR-TE) LSPs.

  • Unnumbered interfaces.

  • Multiple protocols routing protocols such as, OSPF, ISIS, and BGP-LS, enabled at the same time.

  • Computation with prefixes or anycast addresses as destinations.

  • Including and excluding interface IP addresses as constraints.

Distributed CSPF Computation Algorithm

The distributed CSPF computation feature for segment routing LSPs uses the label stack compression algorithm with CSPF.

Label Stack Compression Enabled

A compressed label stack represents a set of paths from a source to a destination. It generally consists of node SIDs and adjacency SIDs. When label stack compression is enabled, the result of the computation is a set of paths that maximize ECMP to the destination, with minimum number of SIDs in the stack, while conforming to constraints.

Label Stack Compression Disabled

The multipath CSPF computation with label stack compression disabled finds up to N segment lists to destination, where:

  • The cost of all segment lists is equal to and the same as the shortest traffic-engineering metric to reach the destination.

  • Each segment list is comprised of adjacency SIDs.

  • The value of N is the maximum number of segment lists allowed for the candidate path by configuration.

  • No two segment lists are identical.

  • Each segment list satisfies all the configured constraints.

Distributed CSPF Computation Database

The database used for SR-TE computation has all links, nodes, prefixes and their characteristics irrespective of whether traffic-engineering is enabled in those advertising nodes. In other words, it is the union of the traffic-engineering database (TED) and the IGP link state database of all domains that the computing node has learnt from. As a result, for CSPF to work, you must include the igp-topology statement at the [edit protocols isis traffic-engineering] hierarchy level.

Configuring Distributed CSPF Computation Constraints

You can use a compute profile to logically group the computation constraints. These compute profiles are referenced by the segment routing paths for computing the primary and secondary segment routing LSPs.

To configure a compute profile, include the compute-profile statement at the [edit protocols source-packet-routing] hierarchy level.

The configuration for the supported computation constraints include:

  • Administrative groups

    You can configure admin-groups under the [edit protocols mpls] hierarchy level. Junos OS applies the administrative group configuration to the segment routing traffic-engineering (SR-TE) interfaces.

    To configure the computation constraints you can specify three categories for a set of administrative groups. The computation constraint configuration can be common to all candidate segment routing paths, or it can be under individual candidate paths.

    • include-any—Specifies that any link with at least one of the configured administrative groups in the list is acceptable for the path to traverse.

    • include-all—Specifies that any link with all of the configured administrative groups in the list is acceptable for the path to traverse.

    • exclude—Specifies that any link which does not have any of the configured administrative groups in the list is acceptable for the path to traverse.

  • Explicit path

    You can specify a series of router IDs in the compute profile as a constraint for computing the SR-TE candidate paths. Each hop has to be an IPv4 address and can be of type strict or loose. If the type of a hop is not configured, strict is used. You must include the compute option under the segment-list statement when specifying the explicit path constraint.

  • Maximum number of segment lists (ECMP paths)

    You can associate a candidate path with a number of dynamic segment-lists. The paths are ECMP paths, where each segment-list translates into a next hop gateway with active weight. These paths are a result of path computation with or without compression.

    You can configure this attribute using the maximum-computed-segment-lists maximum-computed-segment-lists option under the compute-profile configuration statement. This configuration determines the maximum number of such segment lists computed for a given primary and secondary LSP.

  • Maximum segment list depth

    The maximum segment list depth computation parameter ensures that amongst the ECMP paths that satisfy all other constraints such as administrative group, only the paths that have segment lists less than or equal to the maximum segment list depth are used. When you configure this parameter as a constraint under the compute-profile, it overrides the maximum-segment-list-depth configuration under the [edit protocols source-packet-routing] hierarchy level, if present.

    You can configure this attribute using the maximum-segment-list-depth maximum-segment-list-depth option under the compute-profile configuration statement.

  • Protected or unprotected adjacency SIDs

    You can configure protected or unprotected adjacency SID as a constraint under the compute-profile to avoid links with the specified SID type.

  • Metric type

    You can specify the type of metric on the link to be used for computation. By default, SR-TE LSPs use traffic-engineering metrics of the links for computation. The traffic-engineering metric for links is advertised by traffic-engineering extensions of IGP protocols. However, you may also choose to use the IGP-metric for computation by using the metric-type configuration in the compute profile.

    You can configure this attribute using the metric-type (igp | te) option under the compute-profile configuration statement.

Distributed CSPF Computation

The SR-TE candidate paths are computed locally such that they satisfy the configured constraints. When label stack compression is disabled, the multi-path CSPF computation result is a set of adjacency SID stacks. When label stack compression is enabled, the result is a set of compressed label stacks (composed of adjacent SIDs and node SIDs).

When secondary paths are computed, the links, nodes and SRLGs taken by the primary paths are not avoided for computation. For more information on primary and secondary paths, see Configuring Primary and Secondary LSPs.

For any LSPs with unsuccessful computation result, the computation is retried as traffic-engineering database (TED) changes.

Interaction Between Distributed CSPF Computation and SR-TE Features

Weights Associated With Paths of an SR-TE Policy

You can configure weights against computed and static SR-TE paths, which contribute to the next hops of the route. However, a single path that has computation enabled can result in multiple segment lists. These computed segment lists are treated as ECMP amongst themselves. You can assign hierarchical ECMP weights to these segments, considering the weights assigned to each of the configured primaries.

BFD Liveliness Detection

You can configure BFD liveliness detection for the computed primary or secondary paths. Every computed primary or secondary path can result in multiple segment lists, as a result, the BFD parameters configured against the segment lists are applied to all the computed segment lists. If all the active primary paths go down, the pre-programmed secondary path (if provided) becomes active.

inherit-label-nexthops

You are not required to explicitly enable the inherit-label-nexthops configuration under the [edit protocols source-packet-routing segment-list segment-list-name] hierarchy for the computed primary or secondary paths, as it is a default behavior.

Auto-Translate Feature

You can configure the auto-translate feature on the segment lists, and the primary or secondary paths with the auto-translate feature reference these segment lists. On the other hand, the primary or secondary on which compute feature is enabled cannot reference any segment list. As a result, you cannot enable both the compute feature and the auto-translate feature for a given primary or secondary path. However, you could have an LSP configured with a primary path with compute type and another with auto-translate type.

Distributed CSPF Computation Sample Configurations

Example 1

In Example 1,

  • The non-computed primary path references a configured segment-list. In this example, the configured segment list static_sl1 is referenced, and it also serves as the name for this primary path.

  • A computed primary should have a name configured, and this name should not reference any configured segment list. In this example, compute_segment1 is not a configured segment list.

  • The compute_profile_red compute-profile is applied to the primary path with the name compute_segment1.

  • The compute_profile_red compute-profile includes a segment list of type compute, which is used to specify the explicit path constraint for the computation.

The weights for computed path next-hops and static next-hops are 2 and 3, respectively. Assuming the next-hops for computed paths are comp_nh1, comp_nh2, and comp_nh3, and the next-hop for static path is static_nh, the weights are applied as follows:

Next-Hop

Weight

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

Example 2

In Example 2, both the primary and secondary paths can be of compute type and can have their own compute-profiles.

Example 3

In Example 3, when compute is mentioned under a primary or secondary path, it results in local computation of a path to the destination without any constraints or other parameters for the computation.

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 destination-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 provide 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. Maximum segment-list binding to a LSP tunnel is increased from 8 to 128, with maximum 1000 tunnels per system. A maximum of 128 primary paths are supported per static segment routing LSP. 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.16.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.16.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.16.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:

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 address mode 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 128 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.

  • Maximum segment-list binding to a LSP tunnel is increased from 8 to 128, with maximum 1000 tunnels per system. A maximum of 128 primary paths are supported per static segment routing LSP. As a limitation, the maximum sensor support for LSP path is 32000 only.

  • 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:

If BGP service PNH is 10.22.44.0/24 with color community 123/124/125, then it uses SR-TE template sr_lsp1 to create tunnel. Any other color for same PNH prefix uses sr_lsp2 template due to color-any configuration.

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

  1. inetcolor.0 tunnel route: 10.22.44.0-0/24 --> RT_NH_TUNNEL

  2. inet6color.0 tunnel route: ffff::10.22.44.0-0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

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

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

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

  4. inetcolor.0 tunnel route:

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

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

  5. inet6color.0 tunnel route:

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

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

The color 101 tunnel (10.22.44.55:65:dt-srte-tunnel1) is created due to color-any configuration.

The IPv6 routes in inet6color.0 are due to mpls ipv6-tunneling configuration. It allows IPv6 routes with color community to be resolved over inet6color.0 table by converting SR-TE routes stored in the inetcolor.0 routing table to IPv4-mapped IPv6 addresses and then copying them into the inet6color.0 routing table.

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:

  1. inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL

  2. inet6.3 tunnel route: ffff::10.33.44.0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

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

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

  4. inet.3 tunnel route: 10.33.44.55/32 --> <next-hop>

  5. inet6.3 tunnel route: ffff::10.33.44.55/128 --> <next-hop>

The uncolored tunnel (10.33.44.55:dt-srte-tunnel2) is created using dynamic-tunnel tunnel2 as it does not have color configured. The IPv6 routes in inet6.3 are due to mpls ipv6-tunneling configuration. It allows IPv6 routes to be resolved over an MPLS network by converting SR-TE routes stored in the inet.3 routing table to IPv4-mapped IPv6 addresses and then copying them into the inet6.3 routing table.

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:

  1. inetcolor.0 tunnel route: 10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  2. inet6color.0 tunnel route: ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::10.1.1.0 - 0 /24 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: R1(prefix) -> 10.33.44.55-124(PNH) Tunnel is not 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.

Color-Based Mapping of VPN Services

You can specify color as a protocol next hop constraint (in addition to the IPv4 or IPv6 address) for resolving transport tunnels over static colored and BGP segment routing traffic-engineered (SR-TE) LSPs. This is called the color-IP protocol next hop resolution, where you are required to configure a resolution-map and apply to the VPN services. With this feature, you can enable color-based traffic steering of Layer 2 and Layer 3 VPN services.

Junos OS supports colored SR-TE LSPs associated with a single color. The color-based mapping of VPN services feature is supported on static colored LSPs and BGP SR-TE LSPs.

VPN Service Coloring

In general, a VPN service may be assigned a color on the egress router where the VPN NLRI is advertised, or on an ingress router where the VPN NLRI is received and processed.

You can assign a color to the VPN services at different levels:

  • Per routing instance.

  • Per BGP group.

  • Per BGP neighbor.

  • Per prefix.

Once you assign a color, the color is attached to a VPN service in the form of BGP color extended community.

You can assign multiple colors to a VPN service, referred to as multi-color VPN services. In such cases, the last color attached is considered as the color of the VPN service, and all other colors are ignored.

Multiple colors are assigned by egress and/or ingress devices through multiple policies in the following order:

  • BGP export policy on the egress device.

  • BGP import policy on the ingress device.

  • VRF import policy on the ingress device.

The two modes of VPN service coloring are:

Egress Color Assignment

In this mode, the egress device (that is, the advertiser of the VPN NLRI) is responsible for coloring the VPN service. To enable this mode, you can define a routing policy, and apply it in the VPN service’s routing-instance vrf-export, group export, or group neighbor export at the [edit protocols bgp] hierarchy level. The VPN NLRI is advertised by BGP with the specified color extended community.

For example:

Or

Note:

When you apply the routing policy as an export policy of a BGP group or BGP neighbor, you must include the vpn-apply-export statement at the BGP, BGP group, or BGP neighbor level in order for the policy to take an effect on the VPN NLRI.

The routing policies are applied to Layer 3 VPN prefix NLRIs, Layer 2 VPN NRLIs, and EVPN NLRIs. The color extended community is inherited by all the VPN routes, imported, and installed in the target VRFs on one or multiple ingress devices.

Ingress Color Assignment

In this mode, the ingress device (that is, the receiver of the VPN NLRI) is responsible for coloring the VPN service. To enable this mode, you can define a routing policy, and apply it to the VPN service’s routing-instance vrf-import, group import, or group neighbor import at the [edit protocols bgp] hierarchy level. All the VPN routes matching the routing policy is attached with the specified color extended community.

For example:

Or

Specifying VPN Service Mapping Mode

To specify flexible VPN service mapping modes, you must define a policy using the resolution-map statement, and refer the policy in a VPN service’s routing-instance vrf-import, group import, or group neighbor import at the [edit protocols bgp] hierarchy level. All the VPN routes matching the routing policy are attached with the specified resolution-map.

For example:

You can apply import policy to the VPN service’s routing-instance.

You can also apply the import policy to a BGP group or BGP neighbor.

Note:

Each VPN service mapping mode should have a unique name defined in the resolution-map. Only a single entry of IP-color is supported in the resolution-map, where the VPN route(s) are resolved using a colored-IP protocol next hop in the form of ip-address:color.

Color-IP Protocol Next Hop Resolution

The protocol next hop resolution process is enhanced to support colored-IP protocol next hop resolution. For a colored VPN service, the protocol next hop resolution process takes a color and a resolution-map, builds a colored-IP protocol next hop in the form of IP-address:color, and resolves the protocol next hop in the inet6color.0 routing table.

You must configure a policy to support multipath resolution of colored Layer 2 VPN, Layer 3 VPN, or EVPN services over colored LSPs. The policy must then be applied with the relevant RIB table as the resolver import policy.

For example:

Fallback to IP Protocol Next Hop Resolution

If a colored VPN service does not have a resolution-map applied to it, the VPN service ignores its color and falls back to the IP protocol next hop resolution. Conversely, if a non-colored VPN service has a resolution-map applied to it, the resolution-map is ignored, and the VPN service uses the IP protocol next hop resolution.

The fallback is a simple process from colored SR-TE LSPs to LDP LSPs, by using a RIB group for LDP to install routes in inet{6}color.0 routing tables. A longest prefix match for a colored-IP protocol next hop ensures that if a colored SR-TE LSP route does not exist, an LDP route with a matching IP address should be returned.

BGP Labeled Unicast Color-based Mapping over SR-TE

Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve IPv4 or IPv6 routes over segment routing–traffic engineering (SR-TE) for both IPv4 and IPv6 address families. BGP-LU supports mapping a BGP community color and defining a resolution map for SR-TE. A colored protocol next hop is constructed and it is resolved on a colored SR-TE tunnel in the inetcolor.0 or inet6color.0 table. BGP uses inet.3 and inet6.3 tables for non-color based mapping. This enables you to advertise BGP-LU IPv6 and IPv4 prefixes with an IPv6 next-hop address in IPv6-only networks where routers do not have any IPv4 addresses configured. With this feature, Currently we support BGP IPv6 LU over SR-TE with IS-IS underlay.

In Figure 1, the controller configures 4 colored tunnels in an IPv6 core network configured with SR-TE. Each colored tunnel takes a different path to the destination router D depending on the defined resolution map. The controller configures a colored SR-TE tunnel to 2001:db8::3701:2d05 interface in router D . BGP imports policies to assign a color and resolution map to the received prefix 2001:db8::3700:6/128. Based on the assigned community color, BGP-LU resolves the colored next hop for BGP IPv6 LU prefix according to the assigned resolution map policy.

Figure 1: BGP IPv6 LU over colored IPv6 SR-TEBGP IPv6 LU over colored IPv6 SR-TE

BGP-LU supports the following scenarios:

  • BGP IPv4 LU over colored BGP IPv4 SR-TE, with ISIS/OSPF IPv4 SR extensions.​

  • BGP IPv4 LU over static colored and non-colored IPv4 SR-TE, with ISIS/OSPF IPv4 SR extensions.​

  • BGP IPv6 LU over colored BGP IPv6 SR-TE, with ISIS IPv6 SR extensions.

  • BGP IPv6 LU over static colored and non-colored IPv6 SR-TE, with ISIS IPv6 SR extensions.

  • IPv6 Layer 3 VPN services with IPv6 local address and IPv6 neighbor address.

  • IPv6 Layer 3 VPN services over BGP IPv6 SR-TE, with ISIS IPv6 SR extensions.

  • IPv6 Layer 3 VPN services over static-colored and non-colored IPv6 SR-TE, with ISIS IPv6 SR extensions.

Supported and Unsupported Features for Color-Based Mapping of VPN Services

The following features and functionality are supported with color-based mapping of VPN services:

  • BGP Layer 2 VPN (Kompella Layer 2 VPN)

  • BGP EVPN

  • Resolution-map with a single IP-color option.

  • Colored IPv4 and IPv6 protocol next hop resolution.

  • Routing information base (also known as routing table) group based fallback to LDP LSP in inetcolor.0 routing table.

  • Colored SR-TE LSP.

  • Virtual platforms.

  • 64-bit Junos OS.

  • Logical systems.

  • BGP labeled unicast.

The following features and functionality are not supported with color-based mapping of VPN services:

  • Colored MPLS LSPs, such as RSVP, LDP, BGP-LU, static.

  • Layer 2 circuit

  • FEC-129 BGP auto-discovered and LDP-signaled Layer 2 VPN.

  • VPLS

  • MVPN

  • IPv4 and IPv6 using resolution-map.

Tunnel Templates for PCE-Initiated Segment Routing LSPs

You can configure a tunnel template for PCE-initiated segment routing LSPs to pass down two additional parameters for these LSPs - Bidirectional forwarding detection (BFD) and LDP tunneling.

When a PCE-Initiated segment routing LSP is being created, the LSP is checked against policy statements (if any) and if there is a match, the policy applies the configured template for that LSP. The template configuration is inherited only if it is not provided by the LSP source (PCEP); for example, metric.

To configure a template:

  1. Include the source-routing-path-template statement at the [edit protocols source-packet-routing] hierarchy level. You can configure the additional BFD and LDP tunneling parameters here.

  2. Include the source-routing-path-template-map statement at the [edit protocols source-packet-routing] hierarchy level to list the policy statements against which the PCE-initiated LSP should be checked.

  3. Define a policy to list the LSPs on which the template should be applied.

    The from statement can include either the LSP name or LSP regular expression using the lsp and lsp-regex match conditions. These options are mutually exclusive, so you can specify only one option at a given point in time.

    The then statement must include the sr-te-template option with an accept action. This applies the template to the PCE-initiated LSP.

Take the following into consideration when configuring a template for PCE-initiated LSPs:

  • Template configuration is not applicable to staticalyy configured segment routing LSPs, or any other client’s segment routing LSP.

  • PCEP-provided configuration has precedence over template configuration.

  • PCEP LSP does not inherit template segment-list configuration.

Example: Configuring Static Segment Routing Label Switched Path

This example shows how to configure static segment routing label switched paths (LSPs) in MPLS networks. This configuration helps to bring higher scalability to MPLS networks.

Requirements

This example uses the following hardware and software components:

  • Seven MX Series 5G Universal Routing Platforms

  • Junos OS Release 18.1 or later running on all the routers

Before you begin, be sure you configure the device interfaces.

Overview

Junos OS a set of explicit segment routing paths are configured on the ingress router of a non-colored static segment routing tunnel by configuring the segment-list statement at the [edit protocols source-packet-routing] hierarchy level. You can configure segment routing tunnel by configuring the source-routing-path statement at [edit protocols source-packet-routing] hierarchy level. The segment routing tunnel has a destination address and one or more primary paths and optionally secondary paths that refer to the segment list. Each segment list consists of a sequence of hops. For non-colored static segment routing tunnel, the first hop of the segment list specifies an immediate next hop IP address and the second to Nth hop specifies the segment identifies (SID) labels corresponding to the link or node which the path traverses. The route to the destination of the segment routing tunnel is installed in inet.3 table.

Topology

In this example, configure layer 3 VPN on the provider edge routers PE1 and PE5. Configure the MPLS protocol on all the routers. The segment routing tunnel is configured from router PE1 to router PE5 with a primary path configured on router PE1 and router PE5 . Router PE1 is also configured with secondary path for path protection. The transit routers PE2 to PE4 are configured with adjacency SID labels with label pop and an outgoing interface.

Figure 2: Static Segment Routing Label Switched PathStatic Segment Routing Label Switched Path

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

PE1

PE2

PE3

PE4

PE5

CE1

CE2

Configuring Device PE1
Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device PE1:

  1. Configure the interfaces.

  2. Configure autonomous system number and options to control packet forwarding routing options.

  3. Configure the interfaces with the MPLS protocol and configure the MPLS label range.

  4. Configure the type of peer group, local address, protocol family for NLRIs in updates, and IP address of a neighbor for the peer group.

  5. Configure the protocol area interfaces.

  6. Configure the IPv4 address and labels of primary and secondary paths for source routing-traffic engineering (TE) policies of protocol source packet routing (SPRING).

  7. Configure destination IPv4 address, binding SID label, primary, and secondary source routing path for protocol SPRING.

  8. Configure policy options.

  9. Configure BGP community information.

  10. Configure routing instance VRF1 with instance type, interface, router distinguisher, VRF import, export and table label. Configure export policy and interface of area for protocol OSPF.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE2
Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

  1. Configure the interfaces.

  2. Configure the static LSP for protocol MPLS.

  3. Configure interfaces and static label range for protocol MPLS.

  4. Configure interfaces for protocol OSPF.

Results

From configuration mode on router PE2, confirm your configuration by entering the show interfaces and show protocols commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Verifying Route Entry of Routing Table inet.3 of Router PE1
Purpose

Verify the route entry of routing table inet.3 of router PE1.

Action

From operational mode, enter the show route table inet.3 command.

Meaning

The output displays the ingress routes of segment routing tunnels.

Verifying Route Table Entries of Routing Table mpls.0 of Router PE1
Purpose

Verify the route entries of routing table mpls.0

Action

From operational mode, enter the show route table mpls.0 command.

Meaning

The output displays the SID labels of segment routing tunnels.

Verifying SPRING Traffic Engineered LSP of Router PE1
Purpose

Verify SPRING traffic engineered LSPs on the ingress routers.

Action

From operational mode, enter the show spring-traffic-engineering overview command.

Meaning

The output displays the overview of SPRING traffic engineered LSPs on the ingress router.

Verifying SPRING Traffic Engineered LSPs on the Ingress Router of Router PE1
Purpose

Verify SPRING traffic engineered LSPs on the ingress router.

Action

From operational mode, enter the show spring-traffic-engineering lsp detail command.

Meaning

The output displays details of SPRING traffic engineered LSPs on the ingress router

Verifying the Routing Table Entries of Routing Table mpls.0 of Router PE2
Purpose

Verify the routing table entries of routing table mpls.0 of router PE2.

Action

From operational mode, enter the show route table mpls.0 command.

Verifying the Status of Static MPLS LSP Segments of Router PE2
Purpose

Verify the status of MPLS LSP segments of router PE2.

Action

From operational mode, enter the show mpls static-lsp command.

Meaning

The output displays the status of static MPLS LSP segments of router PE2.

Routing Engine-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution

You can run seamless Bidirectional Forwarding Detection (S-BFD) over non-colored and colored label-switched paths (LSPs) with first-hop label resolution, using S-BFD as a fast mechanism to detect path failures.

Understanding RE-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution

S-BFD Static Segment-Routing Tunnels for First-Hop Labels

Segment-routing architecture enables ingress nodes in a core network to steer traffic through explicit paths through the network. The segment-routing traffic engineering (TE) next hop is a list or lists of segment identifiers (SIDs). These segment lists represent paths in the network that you want incoming traffic to take. The incoming traffic may be labeled or IP traffic and the forwarding operation at the ingress node may be a label swap or a destination-based lookup to steer the traffic onto these segment-routing TE paths in the forwarding path.

You can run seamless BFD (S-BFD) over non-colored and colored static segment-routing LSPs with first-hop label resolution and use S-BFD as a fast mechanism to detect path failures and to trigger global convergence. S-BFD requires fewer state changes than BFD requires, thus speeding up the reporting of path failures.

Given a segment-routing tunnel with one or multiple primary LSPs and optionally a secondary LSP, you can enable S-BFD on any of those LSPs. If an S-BFD session goes down, the software updates the segment-routing tunnel’s route by deleting the next hops of the failed LSPs. If the first-hop label of the LSP points to more than one immediate next hop, the kernel continues to send S-BFD packets if at least one next hop is available (underlying next-hop reachability failure detection must be faster than the duration of the S-BFD detection timer).

Note:

This model is supported for auto-translate-derived LSPs.
LSP-level S-BFD

An S-BFD session is created for each unique label-stack+address-family combination. You can configure identical segment lists and enable S-BFD for all of them. The segment lists that have identical label-stack+address-family combinations share the same S-BFD session. The source address for the S-BFD session is set to the least configured loopback address (except the special addresses) under the main instance.

Note:

Ensure that the chosen source address is routable.

The address family of an LSP is derived based on the address family of the “to” address in the segment-routing TE tunnel. The state of the LSP with S-BFD configured also depends on whether BFD is up—if S-BFD is configured for an LSP, the LSP route isn’t calculated until S-BFD reports the path is alive.

S-BFD Parameters

The following S-BFD parameters are supported for segment-routing TE paths:

  • Remote discriminator

  • Minimum interval

  • Multiplier

  • No router alert option

In S-BFD, each responder may have multiple discriminators. The discriminators may be advertised by IGP to other routers, or they may be statically configured on these routers. On an initiator, a particular discriminator is chosen as the remote discriminator for an S-BFD session by static configuration, based on the decision or resolution made by you or by a central controller. When multiple LSPs are created with the same key label stack and S-BFD is enabled on each of them with different parameters, the aggressive value of each parameter is used in the shared S-BFD session. For the discriminator parameter, the lowest value is considered as most aggressive. Similarly for the router alert option, if one of the configurations no router alert is configured, the derived S-BFD parameter will have no router alert option.

Limitations

  • Prior to Junos OS Release 23.2R1, only global repair is supported. Starting in Junos OS Release 23.2R1, local repair is supported for MX Series devices.

  • Even though S-BFD detects failures depending on the configured timer values, convergence time depends on the global repair time (seconds).

Auto Derivation of Remote Discriminator (RD) for S-BFD Session

Starting in Junos OS Release 22.4R1, you can use the auto-derived remote discriminator for S-BFD sessions for the SR-TE paths. With this feature, you need not configure a remote-discriminator in the S-BFD configuration on the ingress or transit device and a matching local-discriminator on its respective endpoint. Instead, the egress PE device will now accept IP addresses as its local discriminator. To allow IP address as local-discriminator in BFD, use the set protocols bfd sbfd local-discriminator-ip configuration.

You can also use a common S-BFD template with the S-BFD configurations on multiple controller provisioned SR-TE policies. In these S-BFD sessions, Junos OS automatically derives the remote discriminator from the tunnel endpoint for matching SR-TE policies.

Note:

  • We support auto derivation of RD only for IPv4 endpoints, not for IPv6 endpoints.

  • We do not support auto derivation of RD for color-only tunnels. If RD is not configured (by auto derivation of RD) for statically configured SR-TE color-only tunnels, the system will display a commit error. If RD is not configured (by auto derivation of RD) for dynamic color-only tunnels by using SR-TE template configuration, Junos OS skips the sbfd configuration for that tunnel.

S-BFD for SRv6 TE Paths

Starting in Junos OS Release 24.4R1, you can run S-BFD over SRv6 TE paths to quickly detect path failures. Each path configured with S-BFD within a SRv6 TE tunnel can send probes to the destination of the path. These probes follow the SIDs of the TE path and report failures for any SIDs within the path. When failues are detected, the corresponding SRv6 TE tunnel path will be brought down so traffic can be distributed onto backup paths.

S-BFD for SRv6 is supported in distributed mode on ingress routers and distributed mode on egress routers.

To configure S-BFD for a SRv6 TE path on an ingress router, you must configure a local discriminator with the sbfd local-discriminator number configuration statement at the [edit protocols bfd] hierarchy level. You also need to configure a remote discriminator with the sbfd remote-discriminator number configuration statement at the [edit protocols source-packet-routing source-routing-path name primary name bfd-liveness-detection] hierarchy level.

To configure S-BFD for SRv6 TE paths on an egress router, you must configure the sbfd local-discriminator number local-ipv6-address address configuration statement at the [edit protocols bfd] hierachy level. The loca-discriminator at the responder must match the remote-discriminator configured on the SRv6 TE path at the ingress router

For S-BFD responders that only supports IPv6 local host address, you can enforce the use of an IPv6 local host address by using the bfd-liveness-detection sbfd destination-ipv6-local-host configuration statement at the [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] hierarchy level.

Configuring RE-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution

To enable LSP-level S-BFD for a segment list, you configure the bfd-liveness-detection configuration statement at the [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] hierarchy and the [edit protocols source-packet-routing source-routing-path lsp-path-name secondary segment-list-name] hierarchy.

The following steps give the basic configuration and then operation of S-BFD with first-hop label resolution:

  • The steps immediately below describe the outlines of the basic configuration:

    1. On an ingress router, you configure one or more segment lists with first-hop labels for a static segment-routing tunnel to use as primary and secondary paths.

    2. On the ingress router, you configure the static segment-routing tunnel, with either multiple primary paths (for load balancing), or one primary path and one secondary path (for path protection). Each primary or secondary path (LSP) refers to one of the segment lists you configured already, creating routes using the next hops derived from the first-hop labels from contributing LSPs.

    3. On the ingress router, you enable per-packet load-balancing so that routes resolving over ingress routes and the binding-SID route (which all have first-hop labels) install all active paths in the Packet Forwarding Engine. An S-BFD session under an LSP protects all routes that use that LSP.

    4. On the egress router of the segment-routing tunnel, you configure S-BFD responder mode with a local discriminator D, creating a distributed S-BFD listener session for D on each FPC.

    5. On the ingress router, you configure S-BFD for any LSP for which you want to see path-failure detection. You specify a remote-discriminator D to match the local S-BFD discriminator of the egress router. An S-BFD initiator session is created with the LSP label-stack+address-family combination as the key, if an initiator session doesn’t already exist for the current LSP key. The S-BFD parameters in the case of a matching BFD session are reevaluated with the new shared LSPs taken into consideration. When the S-BFD parameters are derived, the aggressive value of each parameter is chosen.

    The steps immediately below describe basic operation :

    1. The S-BFD initiator session runs in a centralized mode on the Routing Engine. The software tracks S-BFD session up and down states.

    2. When the S-BFD state moves to UP, the LSP is considered for the relevant routes.

    3. On the ingress router, if the software detects an S-BFD session DOWN, a session-down notification is sent to the routing daemon (RPD), and RPD deletes the next hop of the failed LSPs from the segment-routing tunnel’s route.

    4. The total traffic loss in the procedure is bound to the S-BFD failure detection time and the global repair time. The S-BFD failure detection time is determined by the S-BFD minimum-interval and multiplier parameters. The global repair time depends on the segment-routing TE process time and the redownload of the routes to forwarding.

    LSP label stacks are changed as follows:

    1. The particular LSP is detached from the existing S-BFD session. If the existing S-BFD session has at least one LSP referring to it, the old BFD session is preserved, but the S-BFD parameters are re-evaluated so that the aggressive parameter values among the existing LSP sessions is chosen. Also, the name of the S-BFD session is updated to the least one if there is a change. If the old S-BFD session has no more LSPs attached to it, that S-BFD session is removed.

    2. The software attempts to find an existing BFD session that matches the new-label-stack+address-family combination value; if such a match exists, the LSP refers to that existing S-BFD session. The S-BFD session is re-evaluated for any change in parameters or session name similarly to the re-evaluations in step 1.

    3. If there is no matching BFD session in the system, a new BFD session is created, and the S-BFD parameters are derived from this LSP.

    Note:

    An S-BFD session’s minimum interval and multiplier determine the failure detection time for the session. The repair time additionally depends on the global repair time.

The following output shows configuration statements you would use for a colored LSP with primary LSPs:

At the responder side, you must configure the correct discriminator:

By default, router alerts are configured for S-BFD packets. When the MPLS header is removed at the responder end, the packet is sent to the host for processing without a destination address lookup for the packet. If you enable the no-router-alert option on the ingress router, the router-alert option is removed from the IP options and hence from the egress side. You must configure the destination address explicitly in lo0; otherwise the packet is discarded, and S-BFD remains down.

You can use a new trace flag, bfd, to trace BFD activities:

Example

The following configuration is an example of a non-colored static segment-routing tunnel with LSP protection.

Verify That LSPs Are Configured for Static Segment-Routing Tunnels and That S-BFD Session Status Is Visible

Purpose

Use the show spring-traffic-engineering lsp detail command to show LSPs for static segment-routing tunnels, with S-BFD session status.

Action

Because many LSPs can share the same BFD session, when the first LSP with a unique label-stack+address-family combination comes up, the name of the S-BFD session uses address-family+lsp-name. If more LSPs later share the same session, the name of the session can change to address-family+least-lsp-name, without affecting the state of the S-BFD session. The name of the S-BFD session appears in output from the show bfd session extensive command as well. Output for each LSP shows the S-BFD status as well as the S-BFD name it is referring to as shown in the preceding example as BFD status: Up BFD name: V4-sl2. Because there might not be one S-BFD session per LSP, the LSP-level S-BFD counters are not displayed.

Verify the Segment-Routing Tunnel Route with a Primary Next Hop and a Secondary Next Hop

Purpose

On the Routing Engine of the ingress router, verify the segment-routing tunnel route with a primary next hop and a secondary next hop.

Action

Verify the S-BFD Session of the Primary Path

Purpose

On the Routing Engine of the ingress router, verify the S-BFD session of the primary path.

Action

Note:

On the Routing Engine of the ingress router, verify the S-BFD session of the secondary path also similarly.

Computing Delay Optimized Intradomain and Interdomain Segment Routing Paths

Delay-based Metrics for Traffic Engineered Paths Overview

Leveraging dynamic delay-based metrics is becoming a desirable attribute in modern networks. Delay-based metrics is essential for a Path Computation Element (PCE) to compute traffic engineered paths. You can use delay-based metrics to steer packets on the least latency paths, or the least delay path. To do this, you need to measure the delay on every link and advertise it using a suitable routing protocol (IGP or BGP-LS), so that the ingress has the per link delay properties in its TED.

To understand how to advertise the delay on each link, or turn on link measurements, see How to Enable Link Delay Measurement and Advertising in ISIS.

The following sequence of events happen when you measure, advertise, and compute the detection of changes in the network and calculate traffic engineered path with shortest latency:

  • Detect changes in the network by measuring the latency, with synthetic probes, router-to-router.
  • Flood the results to ingress nodes through IGP extended TE-metric extensions.
  • Advertise the results to centralized controllers with corresponding BGP-LS extensions.
  • Compute IGP-based shortest cumulative latency metric paths (Flex-algo).
  • Compute traffic-engineered explicit paths (source to destination) with shortest cumulative latency or delay metrics (SR-TE).

Benefits of Delay-based Metrics for Path Computation

  • Deploy value-added services based on the lowest latency throughout the network.
  • Measure per path latency (minimum, maximum, average) using delay-based metrics.
  • Steer delay sensitive services (such as VPN or 5G services) on ultra-low latency SR optimized paths.

DCSPF-based Computation with Delay Metrics for SR Path Overview

Using the distributed Constrained Shortest Path First (CSPF) for segment routing LSP feature, you can compute a segment routing LSP locally on the ingress device according to the constraints you have configured. With this feature, the LSPs are optimized based on the configured constraints and metric type (traffic-engineering or IGP). The LSPs are computed to utilize the available ECMP paths to the destination with segment routing label stack compression enabled or disabled.

You can configure distributed CSFP to run on multiple headends and do path computation independently on each headend. You can apply compute profile on the source path (source packet routing path). If you have configured compute profile optimized for delay average, you can also additionally apply a constraint called the delay-variation-threshold. When you configure a value for delay-variation-threshold, any link exceeding the threshold value would be excluded from path computation.

To configure delay metrics for DCSPF-based computation for SR path, you need to enable the delay configuration statement at the [edit protocols source-packet-routing compute-profile profile-name metric-type delay] hierarchy level. You can configure the delay metrics such as minimum, maximum, average, and delay variation threshold for path calculation.

  • minimum—Minimum delay metric value from TED for cumulative lowest latency path calculation.
  • average—Average delay metric value from TED for cumulative lowest latency path calculation.
  • maximum—Maximum delay metric value from TED for cumulative lowest latency path calculation.
  • delay-variation-threshold—Link delay variation threshold (1..16777215). Any link exceeding the delay variation threshold would be excluded from path calculation. The delay variation threshold is independent of whether you are doing optimization for minimum, maximum, or average. The delay-variation-threshold configuration statement appears at these hierarchy levels:

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay]

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay minimum]

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay maximum]

    • [edit protocols source-packet-routing compute-profile profile-name metric-type delay average]

You can configure delay metrics at the following CLI hierarchy:

Delay Metrics for Interdomain and Intradomain Use Case Overview

For the intra-domain case (path resides within a single domain), the link delay is taken into consideration when doing path computation. Delay metrics for segment routing path computation is supported on both compressed SIDs and uncompressed SIDs. If you have uncompressed SIDs, then adjacency segments for segment lists is used to produce multiple segment lists if there are equal costs. You can configure uncompressed SIDs using the no-label-stack-compression configuration statement at the [edit protocols source-packet-routing compute-profile profile-name] hierarchy level. This provides a fully expanded path using adjacency SIDs. See compute-profile for more information.

The following is a sample configuration for delay metrics:

Note:

For optical path computation, it is recommended to use the delay metrics as minimum. Minimum is the default configuration.

For interdomain (multi-domain) use case, where there are multiple autonomous systems, you can use express segments to configure link delays for path computation. Express segments are links that connect border nodes or ASBRs. See Express Segment LSP Configuration to learn about express segments. You can configure the delay or inherit the delay of the underlying LSP in the express segment. You can configure delay at the [edit protocols express-segments segment-template template-name metric] hierarchy level and set the values for minimum, maximum, and average delays.

You can configure delay metrics in an express segment at the following CLI hierarchy:

For interdomain path computation, you can assign delay metrics on BGP EPE links. You can configure a value for delay-metric at the [edit protocols bgp group group-name neighbor ip address egress-te-adj-segment segment-name egress-te-link attribute] hierarchy level as shown below:

Delay Metrics in Optical Networks Use Case

The following topologies depict an example of an optical use case. Optical protection and restoration solutions result in the underlying physical attributes, mainly path length, changing due to link failures and subsequent DWDM network optimization.

In figure, the link between A and C is through the optical nodes O1 and O3 and has a latency of 10 microseconds. In figure, you can see a link failure between optical nodes O1 and O3 and that the actual optical connection is rerouted through the optical node O2. This increases the latency of 15 microseconds. The metric for the link that connects A and B changes dynamically between time=0 and time=1.

When a change in the per link delay is detected by the ingress, the ingress triggers recomputation of the delay optimized path and the headend router reroutes the path over the next available least latency path. The change in the link delay may result in the ingress choosing another set of links that has the least latency path. In figure B, you can see there is a change in the link between the path A and C and the headend router reroutes and selects the path A-B-C as shown in the topology.

Related Documentation

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
20.2R1
Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve IPv4 or IPv6 routes over segment routing–traffic engineering (SR-TE) for both IPv4 and IPv6 address families.
19.4R1
You can configure a tunnel template for PCE-initiated segment routing LSPs to pass down two additional parameters for these LSPs - Bidirectional forwarding detection (BFD) and LDP tunneling.
19.1R1
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.
19.1R1
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.
18.2R1
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.