Please forgive if this has already been spoken to… if so, you can simply send the link to old mail list entries and that will suffice… otherwise…
Does anyone know the scope on why we have 2 names for this ? Seriously, was it one of those things where a vendor started doing it first (pre-standard) as sr, and then ietf started standardizing it as spring ? …or was it always being standardized pre-vendor implementation and there was a disagreement within ietf or elsewhere ? or… was there a conscious decision amongst the inventors to actually call it both sr and spring ? or is their actually something different about each one and I’m wrong in thinking they are 2 names for the same technology.
I’m taking stabs at this and presenting multiple choice just as I sit back and wonder why the 2 names
I mean there must be a reason why someone thought that we should call this 2 different names.
I would think within this NANOG maillist, someone will have the answer or at least some pretty good insights into why the 2 names.
Out of curiosity - if you are interested in SR, where are you getting your information from if not IETF (SPRING)?
As for history - we (at Redback) have published 1st draft describing SR-MPLS data plane in 2003 (LDP control plane).
Much beloved vendor claims support for "SPRINGv4" feature for a certain family of products (I personally expect something like SR, SR-MPLS or SRv6, definitely not SPRING).
Very big WTF, especially that that term is only found on 2 public pages : product family datasheet (PDF and HTML versions).
SR could be instantiated with 2 data planes, MPLS and IPv6 - SR-MPLS and SRv6 respectively.
MPLS data plane could be instantiated over either IPv4 or IPv6 (similarly to LDP6), MPLSoUDP->SRoUDP allows transport of SR-MPLS over IP/UDP(RFC8663) and could be used to build innovative, end2end architectures, e.g. draft-bookham-rtgwg-nfix-arch.
There is SFC related work, draft-ietf-spring-nsh-sr.
I have described what SR is, not what vendors (for variety of reasons) do with it, hence “could”
As a side note - SRoUDP works seamlessly over either v4 or v6.
Thanks for the heads up Mark... I see docs showing SRv6 not supported until XR 6.6, I put XR7 in my lab to start testing it...
I have what seems to be a good test for vpnv4 mpls l3vpn over SRv6 IS-IS in core
This is my first go at this so still learning. Srv6 has a strange locator thing with it. Here's a PE with a CEF entry showing the remote l3vpn subnet. Interesting about the SRv6 T.Encaps.Red thing
RP/0/RP0/CPU0:r1#sh cef vrf one 1.1.1.0/30
Thu Sep 10 18:57:04.082 UTC
1.1.1.0/30, version 3, SRv6 Transit, internal 0x5000001 0x0 (ptr 0xe208f5c) [1], 0x0 (0xe3d45a8), 0x0 (0xf1ce1a8)
Updated Sep 10 18:47:58.416
Prefix Len 30, traffic index 0, precedence n/a, priority 3
via fc00:0:0:4::/128, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xd905574 0x0]
next hop VRF - 'default', table - 0xe0800000
next hop fc00:0:0:4::/128 via fc00:0:0:4::/64
SRv6 T.Encaps.Red SID-list {fc00:0:0:4:41::}
I only used link local default fe80 on the transit core interfaces...
Only added a rfc4193 fc00 address to each loopback to get bgp session to come up. Works
Ce to ce can ping
Interesting looking trace from pe lo0 to pe lo0
RP/0/RP0/CPU0:r4#traceroute fc00:0:1:1::1 source fc00:0:4:4::1
Thu Sep 10 19:02:55.211 UTC
Type escape sequence to abort.
Tracing the route to fc00:0:1:1::1
Thanks Jeff, this is pretty trippy… I mean the fact that VPNV4 L3VPN works over SRv6 !
I’m so accustomed to seeing L3VPN being an MPLS thing, and now, no labels, no mpls. Wow
The wireshark sniff shows…
Ethernet
Ipv6
Ipv4
That’s it. No double mpls tags like I’ve so familiar with.
I wanted to look at the MP-iBGP update to see what was in there, but apparently this is so new, it seems that my wireshark decode doesn’t show everything. I see “BGP Prefix-SID” and then an Unknown 37 bytes under that. I wonder if I could enable the SR Wireshark decode. I have had to do that for other protocols in the past.
I found these threads about BGP Prefix-SID decoded needed for Wireshark. Anyone know what wireshark version fixes this ? I just installed 3.2.6 and that doesn’t seem to do it
Does anyone know the scope on why we have 2 names for this ?
SPRING is the IETF working group name - Source Packet Routing in Networking
Segment Routing is under SPRING
Yeah, sorry, this was my fault. Gotta have a catchy name.
As to "SPRINGv4" as others have said, this is not a recognised term in the IETF. I can think of it meaning a number of things (ranging from a private invention of SRv4, up to RFC 8663). You're going to have to check with the vendor using the term to find out what they mean, and possibly why they are using a new term instead of an existing one.
