6. Segment Routing Policies

The concept of a segment routing policy is described by the IETF draft draft-filsfils-spring-segment-routing-policy. A segment routing policy specifies a source-routed path from a head-end router to some network endpoint, and it specifies the traffic flows that are steered into that source-routed path. A segment routing policy intended for use by a particular head-end router can be statically configured on that router or advertised to that router in the form of a BGP route.

The following terms are important to understanding the structure of a segment routing policy and the relationship between one policy and another.

  1. Segment-routing policy — a policy identified by the tuple of (head-end router, endpoint and color). Each segment routing policy is associated with a set of one or more candidate paths, one of which is selected to implement the segment routing policy and installed in the dataplane. Certain properties of the segment routing policy come from the currently selected path - for example, binding SID, segment list(s), and so on.
  2. Endpoint — the far-end router that is the destination of the source-routed path. The endpoint may be null (all-zero IP address) if no specific far-end router is targeted by the policy.
  3. Color — a property of a segment routing policy that determines the sets of traffic flows that are steered by the policy.
  4. Path — a set of one or more segment lists that are explicitly or statically configured or dynamically signaled. If a path becomes active then traffic matching the segment routing policy is load-balanced across the segment lists of the path in an equal, unequal, or weighted distribution. Each path is associated with:
    1. a protocol origin (BGP or static)
    2. a preference value
    3. a binding SID value
    4. a validation state (valid or invalid)
  5. Binding SID — a SID value that opaquely represents a segment routing policy (or more specifically, its selected path) to upstream routers. BSIDs provide isolation or decoupling between different source-routed domains and improve overall network scalability. Usually, all candidate paths of a segment routing policy are assigned the same BSID.
    These concepts are illustrated by the following example. Suppose there is a network of 7 nodes as shown in Figure 64 and there are two classes of traffic (blue and green) to be transported between node1 and node 7. There is a segment routing policy for the blue traffic between node1 and node7 and another segment routing policy for the green traffic between these same two nodes.
    Figure 64:  Network Example with 2 Segment Routing Policies 
    The two segment routing policies that are involved in this example and the associated relationships are depicted in Figure 65.
    Figure 65:  Relationship Between Segment Routing Policies and Paths 

6.1. Statically-Configured Segment Routing Policies

A segment routing policy is statically configured on the router using one of the supported management interfaces. In the Nokia data model, static policies are configured under config>router>segment-routing>sr-policies.

There are two types of static policies: local and non-local. A static policy is local when its head-end parameter is configured with the value local. This means that the policy is intended for use by the router where the static policy is configured. Local static policies are imported into the local segment routing database for further processing. If the local segment routing database chooses a local static policy as the best path for a particular (color, endpoint) then the associated path and its segment lists will be installed into the tunnel table (for next-hop resolution) and as a BSID-indexed MPLS label entry.

A static policy is non-local when its head-end parameter is set to any IPv4 address (even an IPv4 address that is associated with the local router, which is a configuration that should generally be avoided). A non-local policy is intended for use by a different router than the one where the policy is configured. Non-local policies are not installed in the local segment routing database and do not affect the forwarding state of the router where they are configured. In order to advertise non-local policies to the target router, either directly (over a single BGP session) or indirectly (using other intermediate routers, such as BGP route reflectors), the static non-local policies must be imported into the BGP RIB and then re-advertised as BGP routes. In order to import static non-local policies into BGP, you must configure the sr-policy-import command under config>router>bgp. In order to advertise BGP routes containing segment routing policies, you must add the sr-policy-ipv4 family to the configuration of a BGP neighbor or group (or the entire base router BGP instance) so that the capability is negotiated with other routers.

Local and non-local static policies have the same configurable attributes. The function and rules associated with each attribute are:

  1. shutdown — used to administratively enable or disable the static policy
  2. binding-sid — used to associate a binding SID with the static policy in the form of an MPLS label in the range 32 to 1048575. This is a mandatory parameter. The binding SID must be an available label in the reserved-label-block associated with segment routing policies, otherwise the policy cannot be activated.
  3. color — used to associate a color with the static policy. This is a mandatory parameter.
  4. distinguisher — used to uniquely identify a non-local static policy when it is a re-advertised as a BGP route. The value is copied into the BGP NLRI field. A unique distinguisher ensures that BGP does not suppress BGP routes for the same (color, endpoint) but targeted to different head-end routers. This is mandatory for non-local policies but optional in local policies.
  5. endpoint — used to identify the endpoint IPv4 address associated with the static policy. A value of 0.0.0.0 is permitted and interpreted as a null endpoint. This is a mandatory parameter.
  6. head-end — used to identify the router that is the targeted node for installing the policy. This is a mandatory parameter. The value local must be used when the target is the local router itself. Otherwise, any valid IPv4 address is allowed, and the policy is considered non-local. When a non-local static policy is re-advertised as a BGP route, the configured head-end address is embedded in an IPv4-address-specific route-target extended community that is automatically added to the BGP route.
  7. preference — used to indicate the degree of preference of the policy if the local segment routing database has other policies (static or BGP) for the same (color, endpoint). In order for a path to be selected as the active path for a (color, endpoint), it must have the highest preference value amongst all the candidate paths.

The following are configuration rules related to the previously described attributes:

  1. Every static local policy must have a unique combination of color, endpoint, and preference.
  2. Every static non-local policy must have a unique distinguisher.

Each static policy (local and non-local) must include, in its configuration, at least one segment-list containing at least one segment. Each static-policy can have up to 32 segment-lists, each containing up to 11 segments. Each segment-list can be assigned a weight to influence the share of traffic that it carries compared to other segment-lists of the same policy. The default weight is 1.

The segment routing policy draft standard allows a segment-list to be configured (and signaled) with a mix of different segment types. When the head-end router attempts to install such a segment routing policy, it must resolve all of the segments into a stack of MPLS labels. In the current SR OS implementation this complexity is avoided by requiring that all (configured and signaled) segments must already be provided in the form of MPLS label values. In terms of the draft standard, this means that only type-1 segments are supported.

6.2. BGP Signaled Segment Routing Policies

The base router BGP instance is configured to send and receive BGP routes containing segment routing policies. In order to exchange routes belonging to the AFI=1, SAFI=73 address family with a particular base router BGP neighbor, the family configuration that applies to that neighbor must include the sr-policy-ipv4 keyword.

When BGP receives an sr-policy-ipv4 route (AFI=1, SAFI=73) from a peer, it runs its standard BGP best path selection algorithm to choose the best path for each NLRI combination of distinguisher, endpoint, and color. If the best path is targeted to this router as head-end, BGP extracts the segment routing policy details into the local segment routing database. A BGP segment routing policy route is deemed to be targeted to this router as the head-end if either:

  1. it has no route-target extended community and a NO-ADVERTISE standard community
  2. it has an IPv4 address-specific route-target extended community with an IPv4 address matching the system IPv4 address of this router

An sr-policy-ipv4 route can be received from either an IBGP or EBGP peer but it is never propagated to an EBGP peer. An sr-policy-ipv4 route can be reflected to route reflector clients if this is allowed (a NO_ADVERTISE community is not attached) and the router does not consider itself the head-end of the policy.

Note:

A BGP segment routing policy route is considered malformed, and triggers error-handling procedures such as session reset or treat-as-withdraw, if it does not have at least one segment-list TLV with at least one segment TLV.

6.3. Segment Routing Policy Path Selection and Tie-Breaking

Segment Routing policies (static and BGP) for which the local router is head-end are processed by the local segment routing database. For each (color, endpoint) combination, the database must validate each candidate path and choose one to be the active path. The steps of this process are outlined in Table 54.

Table 54:   Segment Routing Policy Validation and Selection Process 

Step

Logic

1

Is the path missing a binding SID in the form of an MPLS label?

Yes: This path is invalid and cannot be used.

No: Go to next step

2

Does the path have any segment-list containing a segment type not equal to 1 (an MPLS label)?

Yes: This path is invalid and cannot be used.

No: Go to next step

3

Are all segment-lists of the path invalid? A segment-list is invalid if it is empty, if the first SID cannot be resolved to a set of one or more next-hops, or if the weight is 0.

Yes: This path is invalid and cannot be used.

No: Go to next step

4

Is the binding-SID an available label in the reserved-label-block range?

Yes: Go to next step.

No: This path is invalid and cannot be used.

5

Is there another path that has reached this step that has a higher preference value?

Yes: This path loses the tie-break and cannot be used.

No: Go to next step.

6

Is there a static path?

Yes: Select the static path as the active path because the protocol-origin value associated with static paths (30) is higher than the protocol-origin value associated with BGP learned paths (20).

No: Go to next step.

7

Is there a BGP path with a lower originator value? The originator is a 160-bit numerical value formed by the concatenation of a 32-bit ASN and a 128-bit peer address (with IPv4 addresses encoded in the lowest 32 bits.)

Yes: This path loses the tie-break and cannot be used.

8

Is there another BGP path with a higher distinguisher value?

Yes: Select the BGP path with the highest distinguisher value.

At step 3 of Table 54, the router attempts to resolve the first segment of each segment-list to a set of one or more next-hops and outgoing labels. It does so by looking for a matching SID in the segment routing module, which must correspond to one of the following:

  1. SR-ISIS or SR-OSPF node SID
  2. SR-IS or SR-OSPF adjacency SID
  3. SR-IS or SR-OSPF adjacency-set SID (parallel or non-parallel set)
Note:

The label value in the first segment of the segment-list is matched against ILM label values that the local router has assigned to node-SIDs, adjacency-SIDs, and adjacency-set SIDs. The matched ILM entry may not program a swap to the same label value encoded in the segment routing policy - for example, in the case of an adjacency SID, or a node-SID reachable through a next-hop using a different SRGB base.

6.4. Resolving BGP Routes to Segment Routing Policy Tunnels

When a statically configured or BGP signaled segment routing policy is selected to be the active path for a (color, endpoint) combination, the corresponding path and its segment lists are programmed into the tunnel table of the router. The resulting tunnel entries can be used to resolve the following types of BGP routes:

  1. Unlabeled IPv4 routes
  2. Unlabeled IPv6 routes
  3. Label-unicast IPv4 routes
  4. Label-unicast IPv6 (6PE) routes

6.4.1. Resolving Unlabeled IPv4 BGP Routes to Segment Routing Policy Tunnels

For an unlabeled IPv4 BGP route to be resolved by an segment routing policy:

  1. A color extended community must be attached to the IPv4 route
  2. The base instance BGP next-hop-resolution configuration of shortcut-tunnel>family ipv4 must allow sr-policy tunnels

Suppose that under these conditions there is an IPv4 route with a color extended community (value C) and BGP next-hop address N. The order of resolution is as follows:

  1. If there is a segment routing policy for which endpoint = N and color = C, then use this tunnel to resolve the BGP next-hop.
  2. If no segment routing policy is found in the previous step and the color extended community has its color-only bits set to '01' or '10', then try to find a segment routing policy for which endpoint = null (0.0.0.0) and color = C. If there is such a policy, use it to resolve the BGP next-hop.
  3. Otherwise, fall back to other resolution methods, based on factors such as TTM preference, admin-tag-policy, and the disallow-igp option.

6.4.2. Resolving Unlabeled IPv6 BGP Routes to Segment Routing Policy Tunnels

For an unlabeled IPv6 BGP route to be resolved by an segment routing policy:

  1. A color extended community must be attached to the IPv6 route.
  2. The base instance BGP next-hop-resolution configuration of shortcut-tunnel>family ipv6 must allow sr-policy tunnels.

Suppose that under these conditions there is an IPv6 route with a color extended community (value C) and BGP next-hop address N. The order of resolution is as follows:

  1. If the color extended community has its color-only bits set to '01' or '10' and there is a segment routing policy for which endpoint = null (0.0.0.0) and color = C, then use this tunnel to resolve the BGP next hop.
  2. Otherwise, fall back to other resolution methods, based on factors such as TTM preference, admin-tag-policy, and the disallow-igp option.

6.4.3. Resolving Label-IPv4 BGP Routes to Segment Routing Policy Tunnels

For a label-unicast IPv4 BGP route to be resolved by a segment routing policy:

  1. A color extended community must be attached to the label-IPv4 route.
  2. The base instance BGP next-hop-resolution configuration of labeled-routes>transport-tunnel>family label-ipv4 must allow sr-policy tunnels.

Suppose that under these conditions there is a label-IPv4 route with a color extended community (value C) and BGP next-hop address N. The order of resolution is as follows:

  1. If there is an interface route that can resolve the BGP next hop, then use the direct route to resolve the BGP next hop.
  2. If allow-static is configured and there is a static route that can resolve the BGP next hop, then use the static route to resolve the BGP next hop.
  3. If there is a segment routing policy for which endpoint = N and color = C, then use this tunnel to resolve the BGP next hop.
  4. If no segment routing policy is found in the previous step and the color extended community has its color-only bits set to '01' or '10', then try to find a segment routing policy for which endpoint = null (0.0.0.0) and color = C. If there is such a policy, use it to resolve the BGP next hop.
  5. Otherwise, fall back to other resolution methods, based on factors such as TTM preference and admin-tag-policy.

6.4.4. Resolving Label-IPv6 BGP Routes to Segment Routing Policy Tunnels

For a label-unicast IPv6 BGP route to be resolved by an segment routing policy:

  1. A color extended community must be attached to the label-IPv6 route.
  2. The base instance BGP next-hop-resolution configuration of labeled-routes>transport-tunnel>family label-ipv6 must allow sr-policy tunnels.

Suppose that under these conditions there is a label-IPv6 route with a color extended community (value C) and BGP next-hop address N. The order of resolution is as follows:

  1. If there is an interface route that can resolve the BGP next hop, then use the direct route to resolve the BGP next hop.
  2. If allow-static is configured and there is a static route that can resolve the BGP next hop, then use the static route to resolve the BGP next hop.
  3. If the color extended community has its color-only bits set to '01' or '10' and there is a segment routing policy for which endpoint = null (0.0.0.0) and color = C, then use this tunnel to resolve the BGP next-hop.
  4. Otherwise fall back to other resolution methods, based on factors such as TTM preference and admin-tag-policy.