Segment Routing Traffic Engineering at BGP Ingress Peer Overview

 

This feature enables BGP to support a segment routing policy for traffic engineering at ingress routers. The controller can specify a segment routing policy consisting of multiple paths to steer labeled or IP traffic. The segment routing policy adds an ordered list of segments to the header of a packet for traffic steering. BGP installs the candidate routes of the segment routing policy into routing tables bgp.inetcolor.0 or bgp.inet6color.0. BGP selects one route from the candidate routes for a particular segment routing traffic engineering policy, and installs it in the new routing tables inetcolor.0 or inet6color.0. This feature supports both statically configured as well as BGP-installed segment routing traffic engineering policies in the forwarding table at ingress routers.

Understanding Segment Routing Policies

In segment routing the controller allows the ingress nodes in a core network to steer traffic through explicit paths while eliminating the state for the explicit paths in intermediate nodes. An ordered list of segments associated with the segment routing policy is added to the header of a data packet. These segment lists or lists of segment identifiers (SIDs) represent paths in the network, which are the best candidate paths selected from multiple candidate paths learned from various sources. An ordered list of segments is encoded as a stack of labels. This feature enables steering a packet toward a specific path depending on the network or customer requirements. The traffic can be labeled or IP traffic and is steered with a label swap or a destination-based lookup toward these segment routing traffic engineering paths. You can configure static policies at ingress routers to steer traffic even when the link to the controller fails. Static segment routing policies are useful to ensure traffic steering when the controller is down or unreachable.

BGP’s Role in Route Selection from a Segment Routing Policy

When BGP receives an update for segment routing traffic engineering subsequent address family identifier (SAFI) from the controller, BGP performs some basic checks and validation on these updates. Segments that are not MPLS labels are considered invalid. If the updates are valid then BGP installs the segment routing traffic engineering policy in the routing tables bgp.inetcolor.0 and bgp.inet6color.0 and these are subsequently installed in the routing tables inetcolor.0 or inet6color.0. These routing tables use attributes such as distinguisher, endpoint address, and color as the key.

The policy action color: color-mode:color-value is configured at the [edit policy-options community name members] hierarchy level to attach color communities when exporting prefixes from inet-unicast and inet6-unicast address families.

To enable BGP IPv4 segment routing traffic engineering capability for an address family, include the segment-routing-te statement at the [edit protocols bgp family inet] hierarchy level.

To enable BGP IPv6 segment routing traffic engineering capability for an address family include the segment-routing-te statement at the [edit protocols bgp family inet6] hierarchy level.

Note

Starting in Release 18.3R1, Junos OS supports collection of traffic statistics for both ingress IP and transit MPLS traffic in a network configured with segment routing traffic engineering policy. To enable collection of traffic statistics include the telemetry statement at the [edit protocols source-packet-routing] hierarchy level.

Statically Configured Segment Routing Policies

Static policies can be configured at ingress routers to allow routing of traffic even when the link to the controller fails. Configure sr-preference at the [edit protocols source-packet-routing] hierarchy level to choose a statically configured segment routing traffic engineering policy forwarding entry over a BGP-signaled segment routing traffic engineering forwarding entry. The top label of the segment identifier label stack is swapped with the interior gateway protocol (IGP) top label for resolution.

A static segment routing traffic engineering policy can contain multiple paths with or without weighted ECMP. If IGP configuration has weighted ECMP configured, then the forwarding path provides hierarchical weighted equal-cost multipath (ECMP). However, if weighted ECMP is not configured, equal balance is applied to all the segment routing traffic engineering paths.

Supported and Unsupported Features

Junos OS supports the following features with BGP segment routing traffic engineering:

  • For PTX Series, this feature is supported for FPC-PTX-P1-A with enhanced chassis mode.

  • Weighted ECMP and hierarchical weighted ECMP.

  • MPLS fast reroute (FRR) is supported for the paths in segment routing traffic engineering policies. IGP backup paths corresponding to the top label are installed to the routing table when available for segment routing traffic engineering policy paths.

The following limitations apply to BGP segment routing traffic engineering::

  • BGP and static segment routing traffic engineering policies are only supported for the master instance.

  • The static segment routing traffic engineering paths that are explicitly configured or learned through BGP are limited to lists of segment identifiers that represent absolute MPLS labels only.

  • A maximum of eight segment lists are supported for both BGP and static segment routing traffic engineering policies.

  • The BGP segment routing traffic engineering SAFI is not supported for peers in routing instances.

  • The BGP segment routing traffic engineering network layer reachability information (NLRI) cannot be imported to other routing tables using routing information base (RIB) groups (RIBs are also known as routing tables).

  • Traffic statistics are not supported for traffic traversing the segment routing policy.

  • The processing of time-to-live (TTL) MPLS label segment identifiers is not supported.

  • Nonstop active routing is not supported.

  • Class-of-service (CoS) policies work on the top label.

  • Only non-VPN CoS rewrite CLI commands are supported; for example, EXP rewrite for the top label is supported.

  • For an ingress packet, a maximum of eight labels can be parsed, and Layer 2 or Layer 3 MPLS payload fields are used in the load-balancing hash calculation. If label depth in the ingress packet is more than eight labels, then MPLS payload is not parsed and Layer 2 and Layer 3 MPLS payload fields are not used in the load-balancing hash calculation.

  • The maximum label stack depth support is five. You must configure maximum-segment-list-depth to limit the label depth of segment routing traffic engineering policies. If maximum-segment-list-depth is not configured, meaningful defaults apply that restrict the maximum label depth to five.

  • The color attribute must be specified in segment routing traffic engineering LSP configuration. Hence the ingress routes are downloaded to inetcolor{6}.0 tables.

  • When there are multiple static segment routing traffic engineering policies with the same Endpoint, color preference but different binding segment identifiers are present, the route corresponding to the lesser binding segment identifier is installed in the mpls.0 table.

  • Mixed segment identifiers are not supported: the segment identifiers in the segment routing traffic engineering segment list must be exclusively IPv4 or IPv6.

  • You must explicitly configure MPLS maximum transmission unit (MTU) on an interface to accommodate more than five labels; otherwise more than five labels might result in packet drops.

  • The limits of the supported parameters are listed below in Table 1:

    Table 1: Supported Parameters for Segment Routing Traffic Engineering

    Parameter

    Limit

    Maximum number of labels supported

    5

    Maximum number of paths in segment routing traffic engineering policy

    8

    Number of BGP segment routing traffic engineering policies

    32,000

    Number of static segment routing traffic engineering policies

    32,000

Release History Table
Release
Description
Starting in Release 18.3R1, Junos OS supports collection of traffic statistics for both ingress IP and transit MPLS traffic in a network configured with segment routing traffic engineering policy. To enable collection of traffic statistics include the telemetry statement at the [edit protocols source-packet-routing] hierarchy level.