How does SRv6 Work (Ⅲ) ? SRv6 BE vs. SRv6 TE: Key Differences Explained

Introduction

Building on the previous sections that explained what is SRv6, the role of SRH and TLV extensions in IGP and BGP, this section continues the third part of how SRv6 works. It focuses on SRv6 BE vs. SRv6 TE. It explains their forwarding behavior and highlights the key differences between them.

Before going deeper, it is useful to outline the two models. SRv6 BE (Best Effort) and SRv6 TE (Traffic Engineering) are two forwarding approaches in Segment Routing over IPv6 (SRv6) networks running on CX-M series.

What is SRv6 BE

In SRv6 BE vs. SRv6 TE comparison, SRv6 BE (Best Effort) provides simple, shortest-path forwarding based on IGP, such as IS-IS or OSPFv3. It follows a best-effort model and relies on SPF to compute the forwarding path.

In this mode, traffic is forwarded along the IGP shortest path. A single Service SID is used to steer the packet. There is no SRH carrying explicit path constraints. The packet format remains aligned with standard IPv6, and the data plane behavior is close to native IPv6 forwarding.

This design allows regular IPv6 nodes to process SRv6 BE packets. It ensures compatibility with existing IPv6 devices and enables deployment in standard IPv6 networks without changes to transit nodes.

Each SID represents a destination node or a service. The packet is forwarded hop by hop along the IGP shortest path toward the node associated with that SID.

• Working Principle: Forwarding follows the shortest path computed by the IGP, such as OSPFv3 or IS-IS.
• Encapsulation: The ingress node (PE) typically uses a single end-to-end Service SID. In many BE deployments, no SRH is required unless additional segments are needed.
• Use Case: Suitable for general VPN services, internet access, and scenarios without strict traffic steering requirements.
• Pros/Cons: Simple and scalable. No explicit path control or latency guarantee.

How SRv6 BE Forward Traffic

Assume three nodes: A, B, and C. Transit P nodes may exist, but are not essential here.

• A: 2001:db8:1::1
• B: 2001:db8:2::1
• C: 2001:db8:3::1

Each node advertises its SRv6 Locator:

• A Locator: fc00:a::/64
• B Locator: fc00:b::/64
• C Locator: fc00:c::/64

On node C, an End SID is defined:

• C End SID: fc00:c::10

SRv6 BE acts as the baseline transport model. It does not rely on an explicit path. Forwarding depends on SID reachability. The network routes packets toward the target SID using standard IPv6 routing.

In the control plane, PE nodes advertise Locator prefixes through IGP, such as IS-IS or OSPF. This builds reachability to each SID.

For example, when A sends traffic to C, it only needs C’s End SID fc00:c::10. A sets the IPv6 destination address to this SID. The network forwards the packet based on the route to fc00:c::/64. If the path goes through B, it is due to the IGP shortest path, not an explicit decision by A.

Each hop performs a standard IPv6 lookup. The packet is forwarded toward the Locator of the SID. When the packet reaches node C, the End SID fc00:c::10 is processed, and the corresponding function is executed.

This model is simple and efficient. It fits common VPN services and scenarios that require fast service provisioning.

What is SRv6 TE

In SRv6 BE vs SRv6 TE, SRv6 TE (Traffic Engineering) steers traffic along explicit, policy-driven paths. It targets specific performance goals, such as low latency or high bandwidth.

SRv6 TE, also known as SRv6-TE Policy, uses source routing. The ingress node selects a path that may differ from the IGP shortest path. The path is chosen to meet defined constraints.

The head-end node computes the path and encodes it as a SID list in the packet header. This list represents the exact sequence of segments the packet must traverse.

In terms of state, only the head-end maintains the policy. Transit nodes remain stateless. They simply execute the instructions carried in the SID list. This aligns with the Segment Routing design.

Key mechanisms include:

• SRv6-TE Policy: Traffic is steered based on the tuple (Head-end, Color, Endpoint). The Color identifies the intent or SLA requirement.
• Flexible Algorithm (Flex Algo): Extends IGP path computation. It allows path selection based on custom metrics, such as delay, instead of pure IGP cost. This is typically implemented with IS-IS or OSPF extensions.

SRv6 TE provides precise path control and better resource utilization. It supports strict SLA enforcement. The trade-off is higher control plane complexity and the need for policy distribution.

When integrated with SDN, SRv6 TE enables end-to-end service orchestration. It fits service-driven networks and is widely considered the recommended SRv6 deployment model.

How SRv6 TE Forward Traffic

In SRv6 BE vs SRv6 TE, SRv6 TE forwarding behavior can be illustrated as follows. Assume three nodes: A, B, and C. Transit P nodes may exist, but are omitted for clarity.

• A: 2001:db8:1::1
• B: 2001:db8:2::1
• C: 2001:db8:3::1

Each node advertises its SRv6 Locator:

• A Locator: fc00:a::/64
• B Locator: fc00:b::/64
• C Locator: fc00:c::/64

Define the following SIDs:

• C End SID: fc00:c::10
• B Transit SID: fc00:b::20

The core idea of SRv6 TE is that the ingress node encodes the full path into the SRH Segment List. The network follows this list strictly, instead of relying on the IGP shortest path.

SRv6-TE Policy selects a candidate path and enforces it by encapsulating the packet with an SRH.

For example, to enforce the path A → B → C, the Segment List can be: [fc00:c::10, fc00:b::20]

In SRv6, the Segment List is stored in reverse order. The active segment is placed in the IPv6 destination address.

The forwarding process is as follows:

1. A receives traffic destined for C.
2. A matches the traffic against an SRv6 TE Policy.
3. A encapsulates the packet with an IPv6 header and SRH. The Segment List includes B and C SIDs.
4. The IPv6 destination is set to fc00:b::20. The packet is forwarded to B based on standard IPv6 routing.
5. At B, the SID is processed. The SRH is updated, and the destination address is switched to fc00:c::10.
6. The packet is forwarded to C.
7. At C, the End SID is executed. The packet is decapsulated and delivered to the upper-layer service.

Transit nodes do not perform path computation. They only execute the instructions carried in the SRH. The path is fully defined at the ingress.

This model provides deterministic forwarding and strict path control. It is independent of the IGP shortest path, which may still run using IS-IS or OSPF for reachability.

SRv6 BE vs. SRv6 TE: Key Differences Explained

SRv6 BE and SRv6 TE differ fundamentally in design goals and forwarding behavior.

SRv6 BE relies on the IGP shortest path computed by SPF, typically using IS-IS or OSPF. It usually applies a single Service SID and does not require a controller. As long as routing reachability is in place, services can be delivered. This model is often used to replace traditional MPLS for simple and fast service provisioning.

SRv6 TE, in contrast, encodes an explicit path using a SID list (Segment List). The path is computed and distributed by a controller or policy. Traffic is typically matched using Color and next-hop. This enables fine-grained traffic control. It can avoid congested links, optimize path selection, and provide latency guarantees. It is designed for scenarios with strict performance requirements.

The table below highlights the key differences:

Aspect	SRv6 BE	SRv6 TE
Path Selection	IGP shortest path (SPF)	Explicit path via policy
Encapsulation	Single Service SID	SID list (Segment List)
SRH Usage	Usually not required	Required
Control Plane	IGP only	Controller or policy-driven
Trigger	Route reachability	Color + next-hop
Path Control	None	Fine-grained, deterministic
Use Case	Basic VPN, Internet access	SLA-driven services, TE scenarios
Deployment	Simple, fast	More complex

Summary

In SRv6 BE vs SRv6 TE, key differences explained helps clarify how to choose the appropriate forwarding model based on the deployment scenario.

In SRv6 BE vs. SRv6 TE, the forwarding mode can be selected according to different network requirements and service objectives.

• BE mode: Focuses on fast deployment and simplified operations. It is suitable for standard VPN services and general-purpose traffic without strict performance constraints.
• TE mode: Focuses on explicit path control and SLA guarantees. It is suitable for service-driven networks where latency, bandwidth, and deterministic forwarding are critical.

With these two models, SRv6 provides both flexibility and programmability. At the same time, it supports diverse network requirements, enabling efficient and intelligent IPv6-based service transport.