DC Fabric Segment Routing Use Case (2)

In the first post we covered a bit of the basics around segment routing in the data center. Let’s return to the first use case to see if we can figure out how we’d actually implement the type of traffic steering needed to segregate mouse and elephant flows. Let’s return to our fabric and traffic flows and think about how we could shape traffic using segment routing.

There are two obvious ways to shape traffic in this way—

IGP-Prefix segments

The first way would be to impose a label stack that forces traffic along a path that touches, or passes through, each of the devices along the path. In this case, that would mean imposing a path on the traffic originating behind the ToR at A so it must pass through [F,G,D,E]. The flow of traffic through the data center will look something like—

• Somehow classify the traffic as belonging to the flow that should be shaped to follow only the [F,G,D,E] path
• Impose the path as a label stack, so the SR header (really just a label stack in this situation, remember?) will contain [F,G,D,E]
• Forward the packet, with the label, to the next hop in the stack, namely F
• F receives the packet, pops the top label, examines the next label in the SR header (MPLS label stack)
• F uses local forwarding information to send the packet to G
• G receives the packet, pops the top label, examines the next label in the SR header (MPLS label stack)
• G uses local forwarding information to send the packet to D
• D receives the packet, pops the top label, examines the next label in the SR header (MPLS label stack)
• D uses local forwarding information to send the packet to E
• E pops the last label and forwards based on the destination address in the IP header

This is fairly typical operation, just what you might expect to guide the traffic through the fabric.

IGP-Adjacency Segments

This case is very similar to the first, only it adds an extra set of labels to the SR header (MPLS label stack) to forward the packets through the fabric. Let’s assume the inbound interface on each router in the fabric is assigned a letter/number combination (this would really just be another label in MPLS)—

• The inbound interface on F on the A->F link is labeled F1
• The inbound interface on G on the F->G link is labeled G1
• The inbound interface on D on the G->D link is labeled D1
• The inbound interface on E on the D->E link is labeled E1

Now when A imposes a label on packets being forwarded along this path, it will look like [F1,F,G1,G,D1,D,E1,E]. Notice the prefix segments are still in the SR stack; we’ve just added the interface labels along with the prefix segments. Processing this packet is a little different, as there are now specified interfaces along the path. Each switch is going to use the interface specified, rather than using locally calculated forwarding information.

• Somehow classify the traffic as belonging to the flow that should be shaped to follow only the [F1,F,G1,G,D1,D,E1,E] path
• Impose the path as a label stack, so the SR header (really just a label stack in this situation, remember?) will contain [F1,F,G1,G,D1,D,E1,E]
• Forward the packet out of the specified interface, F1, towards the next hop, which is F
• F will pop the inbound link label, F1, and its local label, F
• F will look up the outbound interface based on the next label, G1, and forward through that interface towards the next hop in the path, G

I’m not going to repeat the entire path here again, because it’s pretty much the same for each device in the path. Note the only difference between these two situations is the addition of the interface label. If it seems like the interface labels add complexity without adding value, you’re right—for this particular topology. The reason interface labels don’t add value here is because there is only one path between any pair of routers.

A later post will consider the value of interface labels

…continued…