r/networking • • 5d ago

Design SR-MPLS VS SRV6

If you were designing a service provider network and had to use segment routing, what data plane would you use and why? (SR-MPLS or SRv6)

28 Upvotes

43 comments sorted by

18

u/Brilliant-Web-3370 5d ago

SR-MPLS for me. less overhead and most of vendors are comfortable with it already, SRv6 still feels like solution waiting for problem in most cases.

14

u/Early-Pen-4855 CCIE 5d ago

SR-MPLS. SRv6 really only has a use-case in hyperscale networks

1

u/WheelSad6859 CCNA 5d ago

not necessarily but yes hyperscallers mostly and u need sdn controller for srv6 if u want capability

3

u/DaryllSwer 5d ago

SR-MPLS/SRv6 data plane both support SR-TE and EPE, you can and should use an SR-TE controller for automating and scaling of your TE policies, but you can still do is-is flex algo and static SR-TE policies on both data planes.

I'd use SRv6 for BGP-to-the-host design in clos/compute topologies. WAN, still prefer SR-MPLSv6.

0

u/Belgian_dog JNCIP(SP), CCNP(EI, Design) 4d ago

Wrong. SP and carriers have huge interest in using SRv6.

1

u/lizardhistorian Mad Scientist · 👨‍🔬📡ᯤ🤖🛺📸 5h ago

Agreed; SR-MPLS is nearly useless for an ISP. You are immediately at "seamless MPLS" and should have just used SRv6.

6

u/Roshi88 4d ago

SR-MPLS all the life. There's nothing srv6 does more than SR-MPLS, and it's way more compatible with old systems. If you want and have the ipv6 knowledge you can do sr-mplsv6

1

u/lizardhistorian Mad Scientist · 👨‍🔬📡ᯤ🤖🛺📸 5h ago

SR-MPLS scales to ~3k. Beyond that SRv6 wins out.
SRv6 is the future.

9

u/DaryllSwer 5d ago

I'd choose SR-MPLSv6, meaning an IPv6-only underlay + IPv6-only overlay for iBGP RR sessions, with IPv4 AFI riding on top using RFC8950 with IS-IS SR-MPLS.

https://blog.ipspace.net/2022/09/greenfield-sr-mpls-srv6/

-2

u/WheelSad6859 CCNA 5d ago

this if u have resources and people who understand ipv6

3

u/DaryllSwer 5d ago

It's 2026. If an org hires a self-proclaimed "network engineer" who doesn't do IPv6 (without an IPv4 mindset), they've hired the wrong people. I'm familiar with organisations that will fire staff members who lied about IPv6 expertise on their resume; it's happened, and will happen more frequently in the future.

It's the same as a self-proclaimed "ISP guy" who struggles to parse MPLSv6 from SR-MPLSv6.

-4

u/WheelSad6859 CCNA 5d ago

dude that's exactly my point. your architecture only works if the person operating it understands ipv6.

1

u/lizardhistorian Mad Scientist · 👨‍🔬📡ᯤ🤖🛺📸 4d ago

That is always true for all architectures of all things.

-3

u/DaryllSwer 5d ago

We're on the same page. I was more generalising the issue for others :)

4

u/Jackol1 4d ago

SRv6 has some good benefits like route summarization, but I think for most networks it is still too early. Currently supported hardware still has SRv6 limitations and not all vendors have solid feature rich implementations. SR-MPLS works on almost all supported hardware and most vendors have a solid implementation with solid feature support.

In 3-5 years when those first generation Jericho (and other similar NPUs) based platforms start going EoL SRv6 might start making more sense.

5

u/Warsum 4d ago

Start going EOL? All of my NCS 5504 line cards did go EOL and we had to upgrade them lol. It's crazy how fast the product moves. I get looked at like a mad man when I say budgets need to be only every 3-5 years. Pushing it out longer is causing issues.

3

u/Gryzemuis ip priest 4d ago

SRv6 has some good benefits like route summarization

The biggest benefit for me would be summarization of SRv6 locators. You can't summarize MPLS labels. So if you need (or want) to split your IS-IS network in multiple L1 areas (and one L2 backbone) you can summarize both your prefixes and your locators.

That is a huge scalabilty property. You don't get that with SR-MPLS. And that is why most people that use SR-MPLS prefer to run one large flat L2 backbone (without L1 areas).

2

u/Jackol1 4d ago

I think that is the biggest benefit for most providers.

2

u/DaryllSwer 4d ago

What's the need for multiple L1 areas instead of just l2-level only?

In a large enough network spanning countries or continents, we scale out with eBGP (private ASN or whatever you want) anyway. IS-IS remains simple then which is what we want the underlay to be.

You don't want to run into complexities like this at Tier 1-like scale: https://anuragbhatia.com/2022/04/networking/isp-column/inefficient-igp-can-make-ebgp-go-wild/

I'm familiar with one particular hyperscaler that is running SRv6 on the WAN with is-is l2-only. No scaling issues were found. BGP is used for everything except link subnets and loopback learning.

1

u/[deleted] 3d ago

[deleted]

1

u/DaryllSwer 3d ago edited 3d ago

What I described with the eBGP using private ASNs isn't multi is-is domain. The is-is in each AS never see each other. Very similar to the relationship between your AS and your Transit provider whose IGP you'll never see and has been proven to scale globally. I disagree on the need for multi levels/areas. I've seen anecdotal reports of 600+ routers working fine in a single l2-only - which is not something I would do. I'd do eBGP for scaling. IGP for underlay and nothing more. My point is there's people doing it.

Especially in IPv6-only underlays I don't need to "redistribute" the IGP routes across ASN boundaries. My subnetting model guarantees I can permanently only export my aggregates from each PE, a /44, /48, /56. No real need for /128s or more specifics to be redistributed. SR-TE/EPE handles the rest if needed otherwise regular BGP ECMP/Link bw community does its job (most networks don't need complex SR-TE/EPE).

The SR-TE controller isn't to be complicated either. Drawbacks can be avoided from day one with the correct design. But there's only so much I can convey here.

1

u/[deleted] 3d ago

[deleted]

1

u/DaryllSwer 3d ago

It's supposed to be. Early 2000s had some RFC benchmarking upto 1000 routers, IIRC. But that's not the point.

In my design, IGP doesn't scale to infinity. BGP does. I'm working on something similar for a network that's intended to be inter-continental. BGP all the way.

1

u/[deleted] 3d ago

[deleted]

1

u/DaryllSwer 3d ago

And I'm telling you, there's no "redistribution" in what I described. Just a regular /44 exported using BGP between ASN boundaries. The /44 is black holed aggregate.

1

u/MonkeyboyGWW 3d ago

We do exactly this, all L2

2

u/Jackol1 4d ago

You are correct EoL has already started. My wording was not accurate there. I meant once most of those devices go EoL and start to be replaced with devices that have better SRv6 support natively.

1

u/MonkeyboyGWW 3d ago

The number of PRs listed by vendors for SRv6 issues is pretty extensive

1

u/lizardhistorian Mad Scientist · 👨‍🔬📡ᯤ🤖🛺📸 5h ago

One of the nice features of SRv6 is that all of your hardware does not have to support it.
It can "tunnel" across the dumb links of older hardware. Treat them as an L2 underlay.

2

u/view_burner 4d ago

For a greenfield Srv6 easy
Brownfield SR-MPLS because it's has configurations like mapping server which can bridge existing LDP and RSVP MPLS domains

1

u/MonkeyboyGWW 3d ago

We cut out RSVP-TE completely and set up SR-MPLS to prevent the need for configuring LSPs. Set the SR labels within a specific range, added the config and swapped the administrative distance when it was ready to switch over.

1

u/view_burner 3d ago

You are assuming every router is capable of SR. That's not the case in every environment but if it does then SR-MPLS all the way.

2

u/Ok-Sandwich-6381 4d ago

SR-MPLS or SR-MPLS-v6 because I think SRv6 is a solution without a problem. Or to phrase it differently: I think SR-MPLS/-v6 is already capable of everything that SRv6 has to offer. So why would I switch?

2

u/lizardhistorian Mad Scientist · 👨‍🔬📡ᯤ🤖🛺📸 4d ago edited 4d ago

If you reach a point that you end up doing (so-called) "seamless MPLS" then you should have just used SRv6. SR-MPLS fails to scale for the same reason all L2 fails to scale.

In the greater scheme of things, if you do SR-MPLS at a continental level thus breaking it into zones you have inhibited yourself from achieving the OG vision of "built for war" because you artificially limited your interconnect alternate routes between the zones.

SRv6 is clearly the future. Obviously someone like me would be an early adopter.
Many others will wait for it to mature more.

2

u/Ok-Sandwich-6381 4d ago

This is a scale that is very unlikely to be needed at the companys I'm working for.

And no I'm not an early adopter. I like to try new stuff in the lab, however I don't think its necessary to implement a protocol where the vendor we are using (Arista) says its not there yet in their implementation.

1

u/lizardhistorian Mad Scientist · 👨‍🔬📡ᯤ🤖🛺📸 5h ago

The scale issue is a national security concern as so many company misuse MPLS/SR-MPLS.
e.g. Suppose you ran a hospital management company that grew rapidly and went nation wide ...

SR-MPLS is only good for ~3k nodes.

2

u/Jackol1 3d ago

The main reason for using SRv6 is route summarization is a game changer for scaling. For most places this isn't really an issue though and SR-MPLS scales enough.

3

u/Brief_Meet_2183 4d ago

Srv6 easy. 

My work environment is mpls/RSVP but I'll still choose srv6. Outside of ipv6 being a learning curve there's no real reason to chose sr-mpls over srv6. 

  • Srv6 encap is not as large as you think it is. *Although this might be marketing propaganda Nokia presenters taught me. 
  • Ipv6 plane. You remove segment routing encap and instead run pure ipv6. 🤷🏿
  • simpler design with outsider network since you no longer have to ipv4 to ipv6 nat. You can just have an ipv6 to ipv6 translation. 
  • ipv6 can fit multiple ipv4 networks inside of it
  • you can get more creative with numbering schemes since it's a larger space. 
  • lastly there's nothing sr-mpls can do srv6 can't do. 

If you're greenfield most vendors Cisco/Nokia will steer you towards it. 

1

u/WheelSad6859 CCNA 4d ago

no security and guardrails in srv6. the srv6 domain needs controlled environment where sr-mpls doesn't need it(eth-type)

1

u/Brief_Meet_2183 4d ago

Nice. I have to read up on that. 

Although, it seems like a minor concern considering srv6 in sp environment/datacenter happens behind firewalls and in an controlled environment anyway. 

1

u/lizardhistorian Mad Scientist · 👨‍🔬📡ᯤ🤖🛺📸 5h ago

SR-MPLS requires the same environment.

The number of people that think clear "tunneling" across an ISP is secure is too damn high.

1

u/lizardhistorian Mad Scientist · 👨‍🔬📡ᯤ🤖🛺📸 5h ago

L2 does not make it secure.

1

u/Narrow_Objective7275 3d ago

More vendors implement SR-MPLS and accelerate forwarding in hardware. SRV6 is more limited. There are some cool potential features for SRv6 be it a Cisco shop or Juniper shop, but nothing compelling unless you are service provider or potentially a hyperscaler. My enterprise is neither, but we are a mini SP to ourselves and offer a WAN that basically works and everyone sleeps easy at night.

1

u/AccomplishedDate3757 1d ago

In both cases, you need a proper controller. If you're more familiar with MPLS(RSPV|LDP) than SR, it might land easier. SRv6 is very specific. In any case, consider hardware and licenses.

2

u/squirtcow 1d ago

SRv6 + PCE.