Simple node SID TE with either SRv6 or SR-MPLS
Hi, folks. I’m activating the NANOG brain trust here because I’ve exhausted (and am exhausted from) efforts so far to seal the deal on what is probably simple stuff to y’all. TL;DR: I think I’m missing some specific glue to make my backbone data plane forward CE IPv4 traffic into a simple PE-to-PE node SID path. I’ve tried both SRv6 steering IPv4 encap in IPv6 GRE (due to lack of End.DX4 or End.DT4) and SR-MPLS. Anonymized and scrubbed topologies and configurations attached — Plan E for SRv6, Plan F* for SR-MPLS. Using Junos 23.4R2-S5.6, looking for the magic “you forgot this part” for either way (though SRv6 + IPv6 GRE preferred). Details: I have a video partner with CEs at two sites on my internal WAN using SMPTE 2022-7 to generate two identical video streams. I receive those on physically diverse links from his CEs to my PEs, then ideally carry them over diverse paths, which I need TE to do. A path of node SIDs satisfies (for now) proof that I can do this (adjacency SIDs later). Everything I’m doing passes Junos CLI syntax checking and “commit check” semantics, but when the change is complete, neither I nor my partner sees this work doing ... anything. I should see his video test patterns having a significant bump in the “blue” path transcontinental end-to-end latency because I’m heading towards Canada then heading towards Mexico on my way between coasts. The “red” path is almost a straight shot. My PEs do not run BGP, so I need to do all of this entirely within IS-IS. I believe my use of “color” in these configurations is a distraction that sounds like it should work but is misguided being a BGP knob. I believe I’ve identified that IPv6 GRE on Junos will only use inet6.0 and will not get steered by the SID path in other tables despite my trying mechanisms like resolution-ribs. I prefer to have this work with SRv6 because I’m greenfield and it’s kind of a moonshot. But at this point I’ll defer to something more tried-and-true like SR-MPLS just to get things working. Direct responses are great, public responses are cool if there are helpful learnings for others where my self-esteem in this space is fragile but sacrificial :-) -dp * Yes, “F” now stands for what you think it does
Finally found the missing glue: [edit routing-options static route 10.10.2.0/24] - next-hop 10.255.0.6; - color 200; + spring-te-lsp-next-hop { + BLUE-TE; + lsp-source { + static; + } + } [edit protocols source-packet-routing] + tunnel-tracking; -dp From: David Zimmerman <dzimmerman@linkedin.com> Date: Saturday, December 13, 2025 at 2:49 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Subject: Simple node SID TE with either SRv6 or SR-MPLS Hi, folks. I’m activating the NANOG brain trust here because I’ve exhausted (and am exhausted from) efforts so far to seal the deal on what is probably simple stuff to y’all. TL;DR: I think I’m missing some specific glue to make my backbone data plane forward CE IPv4 traffic into a simple PE-to-PE node SID path. I’ve tried both SRv6 steering IPv4 encap in IPv6 GRE (due to lack of End.DX4 or End.DT4) and SR-MPLS. Anonymized and scrubbed topologies and configurations attached — Plan E for SRv6, Plan F* for SR-MPLS. Using Junos 23.4R2-S5.6, looking for the magic “you forgot this part” for either way (though SRv6 + IPv6 GRE preferred). Details: I have a video partner with CEs at two sites on my internal WAN using SMPTE 2022-7 to generate two identical video streams. I receive those on physically diverse links from his CEs to my PEs, then ideally carry them over diverse paths, which I need TE to do. A path of node SIDs satisfies (for now) proof that I can do this (adjacency SIDs later). Everything I’m doing passes Junos CLI syntax checking and “commit check” semantics, but when the change is complete, neither I nor my partner sees this work doing ... anything. I should see his video test patterns having a significant bump in the “blue” path transcontinental end-to-end latency because I’m heading towards Canada then heading towards Mexico on my way between coasts. The “red” path is almost a straight shot. My PEs do not run BGP, so I need to do all of this entirely within IS-IS. I believe my use of “color” in these configurations is a distraction that sounds like it should work but is misguided being a BGP knob. I believe I’ve identified that IPv6 GRE on Junos will only use inet6.0 and will not get steered by the SID path in other tables despite my trying mechanisms like resolution-ribs. I prefer to have this work with SRv6 because I’m greenfield and it’s kind of a moonshot. But at this point I’ll defer to something more tried-and-true like SR-MPLS just to get things working. Direct responses are great, public responses are cool if there are helpful learnings for others where my self-esteem in this space is fragile but sacrificial :-) -dp * Yes, “F” now stands for what you think it does
participants (1)
-
David Zimmerman