Traffic Steering into an SRv6 TE Policy

Color-based Traffic Steering

SRv6 TE Policies support color-based traffic steering where traffic is steered into an SRv6 TE Policy through route recursion based on the color value and destination address in the route. Figure 1 shows the color-based traffic steering process.

Figure 1 Color-based traffic steering

The process of color-based traffic steering is as follows:

1. Use a controller to deliver an SRv6 TE Policy to headend device A. The color value for the SRv6 TE Policy is 123 and the endpoint is 2001:DB8:1::1 (device B).

2. Configure a BGP or VPN export policy on device B (or a BGP or VPN import policy on device A), and set the color value to 123 for route prefix 2001:DB8:90::/80 and the next hop to 2001:DB8:1::1 (device B). Then, configure device B to send routing information to device A through a BGP peer relationship.

3. Configure a tunnel policy on device A. After receiving the BGP route 2001:DB8:90::/80, device A recurses the route to the SRv6 TE Policy based on the color value 123 and the next hop 2001:DB8:1::1. Before forwarding a packet destined for 2001:DB8:90::/80, device A adds a specific SID list <C, E, G, B> to the packet.

DSCP-based Traffic Steering

In DSCP-based traffic steering, the headend recurses traffic based on the next hop of the corresponding route in compliance with the configured tunnel policy. If traffic recursion to an SRv6 TE flow group is configured, the headend matches the traffic with an SRv6 mapping policy that has the same color value as the route. If such an SRv6 mapping policy exists, the headend dynamically generates an SRv6 TE flow group that contains multiple SRv6 TE Policies with the same endpoint but different color values.

If there is no such SRv6 mapping policy, the headend does not dynamically create an SRv6 TE flow group.

If multiple flows with the same color value but different next-hop addresses need to recurse to SRv6 TE flow groups, multiple dynamic SRv6 TE flow groups with different endpoints are created based on the configuration of the matching SRv6 mapping policy.

Figure 2 shows the DSCP-based traffic steering process.

Figure 2 DSCP-based traffic steering

In an SRv6 mapping policy, you can configure a separate color-DSCP mapping rule for both the IPv4 address family traffic and IPv6 address family traffic. In the same address family (IPv4 or IPv6), each DSCP value can be mapped to only one color value. Furthermore, such a mapping rule can be configured for an SRv6 TE Policy only if this policy is up.

When IPv4/IPv6 packets with DSCP values enter an SRv6 TE flow group, they are matched against the following rules in sequence to achieve forwarding:

1. The packets are first strictly matched against the SRv6 TE Policy-specific or native IP link-specific rule configured with specified DSCP values in the corresponding address family.
2. If the matching fails, the packets are matched against the SRv6 TE Policy-specific or native IP link-specific rule configured with the default priority in the local address family.
3. If the matching fails, the packets are matched against the SRv6 TE Policy-specific or native IP link-specific rule configured with the smallest DSCP value in the local address family.
4. If the matching fails, the packets are matched against the SRv6 TE Policy-specific or native IP link-specific rule configured with the default priority in the other address family.
5. If the matching fails, the packets are matched against the SRv6 TE Policy-specific or native IP link-specific rule configured with the smallest DSCP value in the other address family.

Service Class-based Traffic Steering

In service class-based traffic steering, the headend recurses traffic based on the next hop of the corresponding route in compliance with the configured tunnel policy. If traffic recursion to an SRv6 TE flow group is configured, the headend matches the traffic with an SRv6 mapping policy that has the same color value as the route. If such an SRv6 mapping policy exists, the headend dynamically generates an SRv6 TE flow group that contains multiple SRv6 TE Policies with the same endpoint but different color values.

If there is no such SRv6 mapping policy, the headend does not dynamically create an SRv6 TE flow group.

If multiple flows with the same color value but different next-hop addresses need to recurse to SRv6 TE flow groups, multiple dynamic SRv6 TE flow groups with different endpoints are created based on the configuration of the matching SRv6 mapping policy.

Figure 3 shows the service class-based traffic steering process.

Figure 3 Service class-based traffic steering

In an SRv6 mapping policy, you can specify a rule for the mapping between the color values of SRv6 TE Policies and the service class values of packets or for the mapping between native IP links and the service class values of packets. Each service class value can be associated with only one SRv6 TE Policy or native IP link. Furthermore, such a mapping rule can be configured for an SRv6 TE Policy only if this policy is up.

When packets with service class values enter an SRv6 TE Policy group, they are matched against the following rules in sequence to achieve forwarding:

1. The packets are first strictly matched against the SRv6 TE Policy-specific or native IP link-specific rule configured with the corresponding service class value.

2. If the matching fails, the packets are matched against the SRv6 TE Policy-specific or native IP link-specific rule configured with the default priority.

3. If the rule configured with the default priority does not exist or it fails to go up, the packets are matched against the SRv6 mapping policy rule that is configured with the smallest index and remains up. As such, it is recommended that low-priority service classes (BE < AF1 < AF2 < AF3 < AF4 < EF < CS6 < CS7) be specified in the SRv6 mapping policy rule with a small index. This ensures that unmatched traffic preferentially preempts the low-priority bandwidth instead of the high-priority bandwidth.