Source Routing 2.0. Why Now, Why Again?

Source Routing 2.0. Why Now, Why Again?

Traditional source routing using IP header options was never widely deployed due to security concerns. Recent buzz around Segment Routing (a.k.a. SPRING) has re-invigorated interest in source routing technologies and their potential benefits. For many operators however, moving to SPRING represents a significant change in their operating practices, so in a more incremental approach they are implementing SPRING-inspired designs using current technologies with minor augmentations.

In this talk we will review SPRING/SR, but will mainly focus on using existing protocols for achieving similar benefits. We will discuss: - clever usage of static LSPs to achieve predictable label values in a data-center network - minor enhancements to BGP-LU for more resilient EPE (Egress Peer Engineering) - interoperability considerations between SPRING and non-SPRING domains

See more at: https://www.nanog.org/meetings/abstract?id=2585#sthash.kH6HJqky.dpuf

Traditional approach, putting source routed headers in packets. All deprecated in both v4 and v6. RFC5095 pretty much bans routing headers in packets.

If put into tunnel and source route the tunnel then people find that acceptable: MPLS TE with EROs.

New interest in "segment routing" to tunnel packets from src to dst by describing route in the header as a sequence of "segments."  Arises out of SDN / controller world view.

Appears to assume a closed universe whose endpoints are owned/operated by same entity. Example: VXLAN tunneling in DC environment.

Google created a mesh of RSVP LSPs that cover all paths, creating a lot of extra state in their network. Then they were able to analyze perf across all LSPs to monitor state of large complex mesh inter and intra Google DCs. This approach adopted by other big providers using static LSPs to avoid RSVP state overhead. Then use SPRING/source routing to push packets across specific paths for monitoring and analysis.

Could also use across MPLS paths in DC. He seems to think that using MPLS in the DC is controversial. Presumably because VMware thinks they own the space with VXLAN?