SR-MPLS vs SRv6 MSD — Why Segment Depth Scales Differently
A technical analysis of Maximum SID Depth (MSD) architectural differences between SR-MPLS and SRv6 and their impact on network design.
MSD appears as a simple numeric capability, but its real meaning depends on the underlying forwarding architecture.
Understanding this distinction helps operators design segment routing policies that align with both silicon constraints and transport efficiency goals.
The MSD Design Parameter
As Segment Routing adoption expands across large service provider backbones and cloud-scale fabrics, Maximum SID Depth (MSD) is becoming a key design parameter — especially in environments using:
- 🔀 Hierarchical Traffic Engineering (TE)
- 🔗 Binding SID indirection
- ☁️ Service overlays
- 🍰 Network slicing constructs
At a high level, MSD simply indicates how many segments a node can process or impose. But in practice, MSD has very different architectural implications in SR-MPLS versus SRv6.
SR-MPLS: Label Stack Processing
In SR-MPLS, segments are encoded as a label stack at the packet front. Each hop processes labels sequentially, requiring multiple operations:
🔧 SR-MPLS Processing Requirements
- Parser Traversal: Extract and parse each label in the stack
- PHV Storage: Store parsed headers in Packet Header Vector
- Modification Operations: Execute pop/swap/push operations
- ECMP Visibility: Expose sufficient headers for load balancing
As stack depth grows, multiple pipeline resources are stressed simultaneously:
| Resource | Impact of Deep Stack |
|---|---|
| Parser Extraction Windows | Limited depth before parser exhaustion |
| Header Vector Space | PHV capacity consumed by label stack |
| Modification Stages | Multiple pipeline stages for push operations |
| ECMP Hash Engine | Payload headers may be obscured |
⚠️ SR-MPLS Scaling Challenges
This makes SR-MPLS MSD closely tied to forwarding silicon limits, and deep stacks can introduce:
- 🔴 ECMP Polarization: Suboptimal load distribution
- 🔴 Parser Limitations: Stack depth exceeding parser capability
- 🔴 Recirculation: Multiple pipeline passes in extreme cases
- 🔴 PHV Exhaustion: Hidden scaling factor
• Entropy Labels: Maintain ECMP visibility with deep stacks
• Programmable Hashing: Custom hash functions accessing payload
• Binding SIDs: Reduce stack depth through indirection
• Hierarchical SR: Limit per-domain segment depth
SRv6: Pointer-Based Forwarding
In contrast, SRv6 uses a pointer-based forwarding model where segments reside inside an IPv6 Segment Routing Header (SRH) and a segment pointer identifies the active segment.
🚀 SRv6 Processing Model
Key Difference: Forwarding typically advances the pointer rather than removing headers.
Because the full segment list does not need to be materialized into pipeline metadata, parser and modification complexity remain relatively stable as segment depth grows.
| Aspect | SR-MPLS | SRv6 |
|---|---|---|
| Segment Encoding | Label Stack (Front) | SRH (Extension Header) |
| Active Segment | Top of Stack | Pointer-Based |
| Forwarding Action | Pop/Swap/Push Labels | Advance Pointer |
| Parser Depth Impact | High | Low |
| PHV Pressure | Significant | Minimal |
| ECMP Visibility | Decreases with Depth | Consistent (IPv6) |
| Primary Constraint | Parser/Pipeline | Encapsulation/MTU |
✅ SRv6 Advantages for Deep Segment Lists
- Stable Parser Complexity: Segment depth doesn't stress parser
- Minimal PHV Impact: Only active segment needs metadata
- Consistent ECMP: IPv6 encapsulation always visible to hash engine
- Predictable Performance: No recirculation risk
The Fundamental Design Perspective
🎯 Key Insight
➡️ SR-MPLS scaling is primarily parser- and pipeline-constrained
➡️ SRv6 scaling is primarily encapsulation- and MTU-constrained
Operational Manifestations
This difference manifests in several operational ways:
| Operational Concern | SR-MPLS | SRv6 |
|---|---|---|
| ECMP Load Balancing | Deep stacks obscure payload headers; requires entropy labels | IPv6 encapsulation allows consistent hashing independent of depth |
| Silicon Dependency | Heavily dependent on ASIC parser/pipeline capabilities | More predictable across different silicon generations |
| Metadata Overhead | PHV resource pressure is hidden scaling factor | Segment depth has minimal metadata impact |
| MTU Considerations | 4-byte labels scale efficiently | 16-byte IPv6 addresses require MTU planning |
| Service Chaining | Limited by MSD and parser depth | More flexible for deep service chains |
Hybrid SR Architecture Strategy
As a result, many networks are adopting hybrid SR architectures — balancing efficiency with expressiveness:
🔄 Hybrid Architecture Model
SR-MPLS Use Cases
- ✅ Efficient core transport
- ✅ Label-optimized forwarding
- ✅ Simple TE paths
- ✅ Legacy interoperability
SRv6 Use Cases
- ✅ Flexible service programmability
- ✅ Deep service chains
- ✅ Network slicing
- ✅ Complex SFC scenarios
🎯 Design Principles for Hybrid Deployments
- Core Networks: Use SR-MPLS for transport efficiency and label stack optimization
- Edge/Service: Deploy SRv6 where service programmability and deep chaining are required
- Interworking: Implement SR-MPLS/SRv6 interworking at domain boundaries
- MSD Planning: Design segment depth budgets based on forwarding architecture
- ECMP Strategy: Use entropy labels (SR-MPLS) or native IPv6 hashing (SRv6)
Practical MSD Considerations
SR-MPLS MSD Planning
Typical SR-MPLS MSD Values:
- 🔸 Early Silicon: MSD = 6-10 (Limited by parser depth)
- 🔸 Modern ASICs: MSD = 10-15 (Improved parsers, PHV optimization)
- 🔸 High-End Platforms: MSD = 15-20+ (Deep buffers, recirculation support)
⚠️ Hidden Constraints: Advertised MSD may not account for PHV exhaustion, ECMP hash depth limits, or modification stage pressure.
SRv6 MSD Planning
Typical SRv6 MSD Values:
- 🔹 Standard Implementations: MSD = 8-16 segments
- 🔹 Deep Service Chains: MSD = 16-32+ segments
- 🔹 Constrained By: MTU limitations, not silicon capabilities
SRH Overhead = 8 bytes (SRH header) + (16 bytes × number of segments)
Example: 16 segments = 8 + (16 × 16) = 264 bytes overhead
Standard MTU (1500) - 264 = 1236 bytes payload capacity
Key Takeaways
💡 Summary Points
- MSD is Architecture-Dependent: The same numeric value has different meanings in SR-MPLS vs SRv6
- SR-MPLS Constraint: Parser and pipeline resources limit practical segment depth
- SRv6 Constraint: MTU and encapsulation overhead are primary limiters
- ECMP Behavior: SR-MPLS requires careful entropy management; SRv6 naturally consistent
- Hybrid Strategy: Leverage SR-MPLS for transport efficiency, SRv6 for service flexibility
- Design Alignment: Match segment routing policies to silicon constraints and efficiency goals
🤔 Question for the Community
While MSD appears as a simple numeric capability, its real meaning depends on the underlying forwarding architecture. Understanding this distinction helps operators design segment routing policies that align with both silicon constraints and transport efficiency goals.
Curious to hear how others are balancing SR-MPLS and SRv6 MSD considerations in large-scale deployments.
📚 Want more networking insights?
Explore advanced topics in Segment Routing, MPLS, and service provider architectures at RJS Cloud Academy
Written by RJS Expert | Network Architecture & Service Provider Expert