SRv6 Capable NOS and Devices

Wed Jan 12 16:20:08 UTC 2022

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.
https://www.youtube.com/watch?v=SrryHbjpnAc

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

-Aaron

-----Original Message-----
From: NANOG <nanog-bounces+aaron1=gvtc.com at nanog.org> On Behalf Of Saku Ytti
Sent: Wednesday, January 12, 2022 2:35 AM
To: Adam Thompson <athompson at merlin.mb.ca>
Cc: NANOG <nanog at nanog.org>
Subject: Re: SRv6 Capable NOS and Devices

On Wed, 12 Jan 2022 at 00:00, Adam Thompson <athompson at merlin.mb.ca> wrote:

> 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.

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.

--
  ++ytti