Questions: Segment Routing and Source Routing

Question 1

A network operator wants to force a specific traffic flow through a particular physical link between routers A and B, even though normal shortest-path routing would avoid it. Which Segment Routing SID type is appropriate, and why?

• A. A prefix SID for router B — this directs traffic toward B via any path
• B. An adjacency SID for the A-B link — this explicitly identifies the specific link to traverse
• C. A new BGP route announcement redirecting traffic to B
• D. An OSPF cost adjustment to make the A-B link the shortest path

Answer: (B)

Prefix SIDs identify a destination node and let the network choose the path — they do not guarantee which specific link is used. Adjacency SIDs identify a specific directed link between two neighboring routers, so including an adjacency SID in a segment list forces traffic to traverse exactly that link. This is the precise traffic engineering use case for SR: encode the desired path as a sequence of adjacency (and prefix) SIDs so the ingress node dictates the route end-to-end.

Question 2

What is Segment Routing's most significant operational advantage over RSVP-TE for traffic engineering in MPLS networks?

• A. Segment Routing supports IPv6 while RSVP-TE is IPv4-only
• B. Segment Routing eliminates per-flow state in intermediate routers; intermediate nodes only need to know how to process SIDs
• C. Segment Routing computes shorter paths than RSVP-TE by leveraging global topology knowledge
• D. Segment Routing requires no changes to existing routing protocols

Answer: (B)

With RSVP-TE, every router along a traffic-engineered path must maintain signaling state for every tunnel — state that must be refreshed, is vulnerable to failures, and grows proportionally with the number of traffic-engineered flows. Segment Routing eliminates this entirely: intermediate routers just process SIDs locally and forward; all path intelligence lives at the ingress node (or a controller). This statelessness vastly improves scalability and reduces the operational burden of traffic engineering.

Question 3

In a Segment Routing network, each intermediate router along the segment list path should maintain per-flow state to correctly forward packets.

• T. True
• F. False

Answer: False

This is the key distinction between SR and older traffic engineering approaches. Intermediate routers in an SR network are stateless — they simply read the active SID, perform the corresponding action (forward to a node or via a specific link), pop that SID, and forward the packet. No per-flow state is stored or maintained. All path information is carried in the packet's segment list itself, which was encoded by the ingress node. This is what makes SR scalable to large numbers of traffic-engineered flows.

Question 4

SR-MPLS can be deployed on existing MPLS infrastructure with software upgrades because Segment IDs are carried as standard MPLS labels.

• T. True
• F. False

Answer: True

SR-MPLS maps each SID to an MPLS label value in the label stack, using the existing MPLS data plane without hardware changes. The segment list becomes a stack of MPLS labels — each SID is just a label, and the MPLS forwarding mechanism (push, swap, pop) already handles label stacks. This backward compatibility is a key deployment advantage: operators can adopt segment routing incrementally, adding SR capabilities via software upgrades to existing MPLS routers rather than replacing hardware.

Question 5

Explain why the statelessness of intermediate routers in Segment Routing matters operationally, particularly compared to RSVP-TE.

Model answer: In RSVP-TE, every router along a traffic-engineered path must store and maintain signaling state for every active tunnel — this state must be refreshed periodically, consumes memory, requires complex failure recovery, and grows with the number of engineered flows. In large networks with thousands of traffic-engineered tunnels, this becomes a significant operational burden. Segment Routing moves all path intelligence to the ingress node: the path is encoded in the packet's segment list, and intermediate routers simply execute SID instructions without storing anything per-flow. This means adding new traffic-engineered paths requires no coordination with or state changes in intermediate routers — only the ingress changes.

The practical consequence is dramatic scalability improvement: the number of traffic-engineered flows is limited only by the ingress node's compute capacity, not by memory across hundreds of intermediate routers. It also simplifies failure recovery, since there is no distributed state to synchronize when links or nodes fail.