Re: sr - spring - what's the deal with 2 names
On 10/Sep/20 21:09, aar...@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.
RE: sr - spring - what's the deal with 2 names
>> 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. Cheers, Adrian
RE: sr - spring - what's the deal with 2 names
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
RE: sr - spring - what's the deal with 2 names
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 Sent: Thursday, September 10, 2020 3:41 AM To: aar...@gvtc.com Cc: NANOG 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, aar...@gvtc.com <mailto:aar...@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
RE: sr - spring - what's the deal with 2 names
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 0x501 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 - 0xe080
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 :::0.0.0.0 16 msec 7 msec 8 msec
2 :::0.0.0.0 6 msec 5 msec 6 msec
3 fc00:0:1:1::1 92 msec 86 msec 80 msec
-Aaron
Re: sr - spring - what's the deal with 2 names
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. Regards, Jeff > On Sep 10, 2020, at 12:35, Mark Tinka wrote: > > > >> On 10/Sep/20 10:40, Jeff Tantsura wrote: >> >> MPLS data plane could be instantiated over either IPv4 or IPv6 >> (similarly to LDP6), > > Be mindful of sketchy (or non-existent) IPv6 support in SR for IS-IS and > OSPF across all vendors. > > Mark.
Re: sr - spring - what's the deal with 2 names
On 10/Sep/20 10:40, Jeff Tantsura wrote: > MPLS data plane could be instantiated over either IPv4 or IPv6 > (similarly to LDP6), Be mindful of sketchy (or non-existent) IPv6 support in SR for IS-IS and OSPF across all vendors. Mark.
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, aar...@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 > >
Re: sr - spring - what's the deal with 2 names
On Thu, Sep 10, 2020, at 08:08, aar...@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?
RE: sr - spring - what's the deal with 2 names
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
Re: sr - spring - what's the deal with 2 names
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).
Re: sr - spring - what's the deal with 2 names
Aaron, 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). Regards, Jeff > On Sep 6, 2020, at 09:53, Saku Ytti via NANOG wrote: > > Hey, > > >> On Sun, 6 Sep 2020 at 04:26, Aaron Gould via NANOG 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
Re: sr - spring - what's the deal with 2 names
Hey, On Sun, 6 Sep 2020 at 04:26, Aaron Gould via NANOG 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
sr - spring - what's the deal with 2 names
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 aar...@gvtc.com
