SRv6 Capable NOS and Devices

Mailman List Mirror (Read Only)
1

I know the SRv6 is a fairly new technology. I am wondering which
vendors and network operating systems fully support SRv6 today? Has
anyone deployed this new technology?

If building a greenfield regional ISP network, would SRv6 be a requirement?

My understanding is that because it's using IPv6 in the dataplane, not
all devices have to have SRv6 enabled. The in-between core devices
just have to support IPv6, but not necessarily support SRv6. This is
much different than traditional MPLS networks today where all devices
have to support MPLS/LDP correct?

1 Like
2

❦ 11 January 2022 09:16 -06, Colton Conor:

I know the SRv6 is a fairly new technology. I am wondering which
vendors and network operating systems fully support SRv6 today? Has
anyone deployed this new technology?

Cisco on NCS devices have full support of SRv6 F1 (End, End.X, End.T,
End.DX4, End.DT4, End.DX6, End.DT6, End.DX2, with PSP/USD or USP,
H.Encaps.*), without any EVPN (so not End.DT2U AFAIK), from 7.2,
depending on hardware (Jericho 2-based platforms need 7.5). There may be
hardware restriction on the smaller NCS (NCS540). However, Cisco is
switching to SRv6 F3216, aka microsegments. The same behaviours are
supported. Beware there is a gap between being on the datasheet and not
running into various bugs. Staying close to what Cisco promotes will
help avoiding some bugs. With ISIS as an IGP, there is also support for
TI-LFA and FlexAlgo.

Juniper supports SRv6 F1 on MX, with the same feature set. Nokia
supports it too on the 7750 SR. No support from Arista yet.

Iliad deployed SRv6 in Italy (and partly in France), with Cisco.

If building a greenfield regional ISP network, would SRv6 be a
requirement?

Dunno. This is still super young and you restrict the number of vendors
you can select and interoperate with. Also note that SRv6 F3216 RFC is
not out yet and Cisco is already asking customers to move away from SRv6
F1. AFAIK, other vendors are still on F1. Starting with SRv6 now may be
a bit of a gamble because of that. Latest draft is here:

https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-12

My understanding is that because it's using IPv6 in the dataplane, not
all devices have to have SRv6 enabled. The in-between core devices
just have to support IPv6, but not necessarily support SRv6. This is
much different than traditional MPLS networks today where all devices
have to support MPLS/LDP correct?

That's correct.

1 Like
3

And you have this use-case? And you can't use MPLSoUDP?

SRv6 is pure snake oil, an easy marketing story to people with limited
knowledge. 'It is just IP bro, you already know it'. I'd like to to
continue 'like already widely used X', but I don't dare, considering
it's so established despite its obvious benefits only existing in
marketability.

4

My question is, why do you think you need Segment Routing at all? Is your network so enormously large and/or complex that IS-IS (and/or MPLS-TE) isn't capable of handling it?
So far, SR looks like a solution in search of a problem, at least to me.
I'm not saying you don't have a need for it, but I am questioning whether you do, or whether you're just being sucked in by all the latest sizzle (i.e. sales & marketing materials). (After all, that's what the sizzle is *designed* to do!)
-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson@merlin.mb.ca
www.merlin.mb.ca

5

  Has
anyone deployed this new technology?

I have heard of a network in Uganda that is running it.

The rest I've heard of are either in the lab, or some portions of their network under testing.

If building a greenfield regional ISP network, would SRv6 be a requirement?

Nope! It's a problem looking for a problem.

My understanding is that because it's using IPv6 in the dataplane, not
all devices have to have SRv6 enabled. The in-between core devices
just have to support IPv6, but not necessarily support SRv6. This is
much different than traditional MPLS networks today where all devices
have to support MPLS/LDP correct?

You'd be hard-pressed to find anything that will help you generate revenue that does not come with MPLS baked into the chip and code.

Do you want to take the chance of where and when SRv6 may or may not be needed?

SRv6 is Cisco trying to create a market for a problem that does not exist. In the process, all other vendors are forced to waste tons of money and time to stay in the game, when they could be fixing real problems and adding real value.

Don't fall for the trap. Vote with your wallet, and feet. We did.

Mark.

6

100%.

In a market where Cisco can no longer guarantee that operators will be spending US$50 million a year, minimum, they have to find a way to make it difficult for you to live without them.

Mark.

7

So SR-MPLS is different from SRv6.

I have refused to jump on the SR-MPLS train, but I AFAIK, it is not the monstrosity that SRv6 is. And while you still have to consider your hardware and software options for SR-MPLS, it is out there in the wild, working.

So if you had to choose, SR-MPLS is likely a better option than SRv6.

For me, MPLS + LDP works, and is mature. The vendors I am willing to invest in support LDPv6. The hardware we run is not going to fall over because of LDP state.

Leaves me time to focus on other, real problems.

Mark.

8

SR is terrific, SRv6 is snake-oil.

Everyone needs some type of tunnelling in most modern applications of
the network. maybe for pseudowires, repair, l3 vpns, traffic
engineering or just removing state and signalling from backbone.
Signalling labels via IGP is obviously better than via LDP.

9

I'm still growing in my understanding of SR-MPLS and SRv6.... but I can say that about everything... seems like the one constant in life, and particularly network technology... is change.

Like ytti (saku) mentioned, with SR/SPRING the IGP is finally carrying the Label/Sid, so we no longer need a label distribution mechanism running alongside the IGP (don't need LDP or RSVP). And for SRv6 vice SR-MPLS, the SID is now the IPv6 address, and not the MPLS Label. So we don't even need MPLS, but can accomplish network virtualization using a pure IPv6 core. Reminds me of Cell Mode MPLS vs Frame Mode MPLS... whereas the ATM Cell header VPI/VCI was repurposed as the MPLS label, until we went with straight MPLS shim headers.

In case you are interested, I put a video on my channel showing a quick look at SRv6. Using Cisco CML, IOS-XR 7.2.2, IS-IS, only using FE80 link local addressing. L3VPN to prove end to end Customer connectivity over SRv6.

The P node is quite interesting in it's ability to handle this with little to no additional protocols.

-Aaron

1 Like
10

No SRv6 is MPLS labeling where label is carried inside IP instead
before the IP header. Layering violation which increases complexity
and cost for no other purpose except dishonest marketing about 'it is
IP, you already understand it, MPLS is hard'.

1 Like
11

Hi,

No SRv6 is MPLS labeling where label is carried inside IP instead
before the IP header. Layering violation which increases complexity
and cost for no other purpose except dishonest marketing about 'it is
IP, you already understand it, MPLS is hard'.

What worries me more is the opportunity for adversaries to inject SRv6 packets. MPLS is not enabled by default on most router interfaces, so an adversary would have to have access to an interface where MPLS processing is explicitly enabled. IPv6 packet processing on the other hand… Unless an operator has airtight protection on every interface to block unwanted SRv6 headers I see some interesting opportunities to cause havoc :slight_smile:

Cheers,
Sander

12

Thus spake Sander Steffann (sander@steffann.nl) on Wed, Jan 12, 2022 at 06:21:25PM +0100:

Hi,

> No SRv6 is MPLS labeling where label is carried inside IP instead
> before the IP header. Layering violation which increases complexity
> and cost for no other purpose except dishonest marketing about 'it is
> IP, you already understand it, MPLS is hard'.

What worries me more is the opportunity for adversaries to inject SRv6 packets. MPLS is not enabled by default on most router interfaces, so an adversary would have to have access to an interface where MPLS processing is explicitly enabled. IPv6 packet processing on the other hand… Unless an operator has airtight protection on every interface to block unwanted SRv6 headers I see some interesting opportunities to cause havoc :slight_smile:

You are not alone, see for example the thread at
https://mailarchive.ietf.org/arch/msg/v6ops/GbWiie-bjQ_Bp1JKB1PlDh_fPdc/
this is more pronounced with respect to the various SRv6 compression scheme proposals.

Dale

13

What worries me more is the opportunity for adversaries to inject SRv6
packets. MPLS is not enabled by default on most router interfaces, so
an adversary would have to have access to an interface where MPLS
processing is explicitly enabled. IPv6 packet processing on the other
hand… Unless an operator has airtight protection on every interface to
block unwanted SRv6 headers I see some interesting opportunities to
cause havoc :slight_smile:

this is quite true, and a serious issue. but it has a good side. if
you run an ipv6 enebled network, you can deploy srv6 without enabling
srv6 everywhere, only at the marking encaps or embed) points. nice for
partial and/or incremental deployment.

randy, with no dog in this fight

14

I agree it seems like MPLS is still the gold standard, but ideally I
would only want to have costly, MPLS devices on the edge, only where
needed. The core and transport devices I would love to be able to use
generic IPv6 enabled switches, that don't need to support LDP. Low end
switches from premium vendors, like Juniper's EX2200 - EX3400 don't
support LDP for example.

MPLS switches are very expensive compared to enterprise switches.

15

Hi Randy,

this is quite true, and a serious issue. but it has a good side. if
you run an ipv6 enebled network, you can deploy srv6 without enabling
srv6 everywhere, only at the marking encaps or embed) points. nice for
partial and/or incremental deployment.

Yep, that's what I like about it! But I haven't figured out a way to mitigate the risks. Easy deployment == easy abuse it seems :frowning:

Cheers,
Sander

16

I would be surprised to find devices that support SR, and not MPLS/LDP.

Mark.

17

It is utter fallacy that MPLS is costly, MPLS is systematically and
fundamentally cheaper than IPv4 (and of course IPv6 costs more than
IPv4).

However if this doesn't reflect your day-to-day reality, then you can
always do MPLSoGRE, so that core does not need more than IP. So in no
scenario is this narrative justification for hiding MPLS headers
inside IP headers, which is expensive and complex, systematically and
fundamentally.

18

True, but in general MPLS is more costly. It's available on limited
devices, from limited vendors. Infact, many of these vendors, like
Extreme, charge you if you want to enable MPLS features on a box.

19

True, but in general MPLS is more costly. It's available on limited
devices, from limited vendors. Infact, many of these vendors, like
Extreme, charge you if you want to enable MPLS features on a box.

And in this discussion group, when MPLS is mentioned, does that include VPLS? Or do operators simply use MPLS and manually bang up the various required point-to-point links? Or is there a better way to do this?

For example, Free Range Routing can do do MPLS, but I don't think it has a construct for VPLS (joining more than two sites together).

20

Well, I don't entirely agree.

Pretty much all chips shipping now, either custom or merchant silicon, will support MPLS. Whether the vendor chooses to implement it in code or not is a whole other matter.

If you need MPLS, chances are you can afford it. If you don't, then you don't have to worry about it.

For Extreme, are you referring to before or after they picked up Brocade?

There is MPLS available in a number of cheap software suites. Even Mikrotik provides MPLS support. Whether it works or not, I can't tell you.

VyOS supports is too. Whether it works or not, I can't tell you.

But I think we are long past the days of "MPLS is expensive".

Mark.