Segment Routing with BGP

Segment routing allows a router, potentially by action of an SDN controller, to source route a packet by prepending a segment router header containing an ordered list of segment identifiers (SIDs). Each SID can be viewed as some sort of topological or service-based instruction. A SID can have a local meaning to one particular node or it can have a global meaning within the SR domain, such as the instruction to forward the packet on the ECMP-aware shortest path to reach some prefix P. With SR-MPLS each SID is an MPLS label and the complete SID list is a stack of labels in the MPLS header.

For all the routers in a network domain to have a common understanding of the meaning of a topology SID, the association of the SID with an IP prefix must be propagated by a routing protocol. Traditionally this is done by an IGP protocol, however, in some cases the meaning of a SID may need to be carried across network boundaries that extend beyond IGP protocol boundaries. For these cases, it is possible for BGP to carry the association of an SR-MPLS SID with an IP prefix. This is possible by attaching a prefix-SID BGP path attribute to an IP route belonging to a labeled-unicast address family. The prefix SID attribute attached to a labeled-unicast route for prefix P advertises a SID corresponding to the network-wide instruction to forward the packet along the ECMP-aware BGP-computed best path or paths to reach P. The prefix-SID attribute is an optional, transitive BGP path attribute with type code 40. This attribute encodes a 32-bit label-index (into the SRGB space) and may also provide details about the SRGB space of the originating router. The encoding of this BGP path attribute and its semantics are further described in draft-ietf-idr-bgp-prefix-sid.

An SR OS router with upgraded software that understands the prefix SID attribute can prevent it from propagating outside the segment routing domain where it is applicable, using the block-prefix-sid command. This BGP command removes the prefix SID attribute from all routes sent and received to and from the IBGP and EBGP peers included in the scope of the command. By default, the attribute propagates without restriction.

SR OS attaches a meaning to a prefix SID attribute only when it is attached to routes belonging to the labeled-unicast IPv4 and labeled-unicast IPv6 address families. It has no meaning when attached to other types of routes. When attached to routes of unsupported address families the prefix SID attribute is ignored but still propagated, as with any other optional transitive attribute.

Segment routing must be administratively enabled under BGP using the following command: config>router>bgp>segment-routing>no shutdown for any of the following to be possible:

To enable BGP segment routing, the base router BGP instance must be associated with a prefix-sid-range. This command tells BGP which SRGB label block it is allowed to use (for example, to allocate labels from) and to advertise in the Originator SRGB TLV of the prefix SID attribute. The global parameter value indicates that BGP should use the SRGB as configured under config>router>mpls-labels>sr-labels. The start-label and max-index parameters are used to restrict the BGP prefix SID label range to a subset of the global SRGB.

Note: The start-label and max-index must reside within the global SRGB or the command fails.

This is useful in cases where partitioning of the SRGB into non-overlapping subranges dedicated to different IGP/BGP protocol instances is desired. Segment routing under BGP must be shutdown before any changes can be made to the prefix-sid-range command.

A unique label-index value should be assigned to each different IPv4 or IPv6 prefix that is advertised with a BGP prefix SID. If label-index N1 is assigned to a BGP-advertised prefix P1, and N1 plus the SRGB start-label creates a label value that conflicts with another SR programmed LFIB entry, then the conflict situation is addressed as follows:

  1. If the conflict is with another BGP route for prefix P2 that was advertised with a prefix SID attribute, all the conflicting BGP routes (for P1 and P2) are advertised with a normal BGP-LU label from the dynamic label range.

  2. If the conflict is with an IGP route, and BGP is not trying to redistribute that IGP route as a label-ipv4 or label-ipv6 route with a route-table-import policy action that uses the prefer-igp keyword in the sr-label-index command, the BGP route loses to the IGP route and it is advertised with a normal BGP-LU label from the dynamic label range.

  3. If the conflict is with an IGP route, and BGP is trying to redistribute that IGP route as a label-ipv4 or label-ipv6 route with a route-table-import policy action that uses the prefer-igp keyword in the sr-label-index command, this is not considered a conflict and BGP uses the IGP-signaled label-index to derive its advertised label. This has the effect of stitching the BGP segment routing tunnel to the IGP segment routing tunnel.

    Note: This use of the prefer-igp option is only possible when BGP segment routing is configured with the prefix-sid-range global command.

Any /32 label-ipv4 or /128 label-ipv6 BGP routes containing a prefix SID attribute are resolvable and usable in the same way as /32 label-ipv4 or /128 label-ipv6 routes without a prefix SID attribute. In other words, these routes are installed in the route table and tunnel-table (unless disable-route-table-install or selective-label-ipv4-install are in effect), and they can have ECMP next hops or FRR backup next hops and be used as transport tunnels for any service that supports BGP-LU transport.

It should be noted that receiving a /32 label-ipv4 or /128 label-ipv6 route with a prefix-SID attribute does not create a tunnel in the segment-routing database; it only creates a label swap entry when the route is re-advertised with a new next hop. This means that the first SID in any SID-list of an SR policy should not be based on a BGP prefix SID; if this advice is not followed, then the SID-list may appear to be valid but the datapath is not programmed correctly. However, it is fine to use a BGP prefix SID as a non-first SID in any SR policy.