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.

Related

6 Comments

Russ – F1 is missing in the stack:
“Now when A imposes a label on packets being forwarded along this path, it will look like [F,G1,G,D1,D,E1,E]. “

Russon 1 August 2016 at 6:47 am

Thanks! I’ve fixed it… 🙂

Jeff Tantsuraon 31 July 2016 at 5:07 pm

The topic of how to bind a FEC to a tunnel deserves separate discussion.
Russ – would be great to gain more insides into:
Hoe a FEC is identified, is there an abstraction to move away from IP addresses to identities, for example – all WEB to DB traffic should take a tunnel with those constraints?
How are you going to provision:
1. Tunnels
2. FEC’s and bindings?

In general – in any and all implementations I’m aware of when the RIB is asked for a labeled NH – it would return a best one, this is how any VPN would work, however if you want to subdivide traffic into smaller flows, you need to think how to bind them to a constrained tunnel

Russon 1 August 2016 at 6:59 am

Jeff — thanks for stopping by! I’ll add this to my list of things to talk about later in the series… 🙂

$iddhe$h Divekaron 2 August 2016 at 5:10 pm

Hi Russ,
It would be good to clarify that F1 is the adjacency label advertised by
router F for link AF to all other routers in the network.