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. Aaron aaron1@gvtc.com
Hey, On Sun, 6 Sep 2020 at 04:26, Aaron Gould via NANOG <nanog@nanog.org> wrote:
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.
If you don't like the names, I have others. SPRING is the IETF working group name - Source Packet Routing in Networking Segment Routing is under SPRING -- ++ytti
On Sun, Sep 6, 2020, at 10:14, Jeff Tantsura via NANOG wrote:
Out of curiosity - if you are interested in SR, where are you getting your information from if not IETF (SPRING)?
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).
Interesting... I've never heard of SPRINGv4 https://www.juniper.net/us/en/products-services/routing/ptx-series/datasheet s/1000538.page I found it in the bottom section I wonder if SPRINGv4 is like SRv6, meaning, SPRING(SR) over IPv4 dataplane? Or, am I reading way too much into that SPRINGv4 acronym? -Aaron
On Thu, Sep 10, 2020, at 08:08, aaron1@gvtc.com wrote:
Interesting... I've never heard of SPRINGv4
Neither did I until a few days ago.
I wonder if SPRINGv4 is like SRv6, meaning, SPRING(SR) over IPv4 dataplane? Or, am I reading way too much into that SPRINGv4 acronym?
Like SR-VXLAN ? Does it even make any sense?
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. And there’s whole SRv6 thingy... Let me know if I can help in any way. Cheers, Jeff
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 1 ::ffff:0.0.0.0 16 msec 7 msec 8 msec 2 ::ffff:0.0.0.0 6 msec 5 msec 6 msec 3 fc00:0:1:1::1 92 msec 86 msec 80 msec -Aaron
On 10/Sep/20 21:09, aaron1@gvtc.com wrote:
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 wasn't talking about SRv6... I am talking about SR-MPLS, signaled via and supported for IPv6, in the IGP. Mark.
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. 05 00 22 00 01 00 1e 00 fc 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 ff ff 00 01 00 06 28 18 10 00 10 40 -Aaron From: Jeff Tantsura <jefftant.ietf@gmail.com> Sent: Thursday, September 10, 2020 3:41 AM To: aaron1@gvtc.com Cc: NANOG <nanog@nanog.org> Subject: Re: sr - spring - what's the deal with 2 names 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. And there’s whole SRv6 thingy... Let me know if I can help in any way. Cheers, Jeff On Sep 10, 2020, at 08:10, aaron1@gvtc.com <mailto:aaron1@gvtc.com> wrote: Interesting... I've never heard of SPRINGv4 https://www.juniper.net/us/en/products-services/routing/ptx-series/datasheet s/1000538.page I found it in the bottom section I wonder if SPRINGv4 is like SRv6, meaning, SPRING(SR) over IPv4 dataplane? Or, am I reading way too much into that SPRINGv4 acronym? -Aaron
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 https://www.wireshark.org/lists/wireshark-bugs/201603/msg00621.html https://www.wireshark.org/lists/wireshark-bugs/201603/msg00623.html -Aaron
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. Cheers, Adrian
participants (6)
-
aaron1@gvtc.com
-
Adrian Farrel
-
Jeff Tantsura
-
Mark Tinka
-
Radu-Adrian Feurdean
-
Saku Ytti