I have what seems to be a good SRv6 test in my lab running XRv9k 7.0.2
But I’m wondering why the sniffer doesn’t show the much-spoken-of SRH (Segment Routing Header)…. But rather, shows my L3VPN v4 traffic riding v6 and that’s it. Let me know if I’m seeing an SRH and just don’t know it, LOL.
Ethernet – Type 0x86dd
Ipv6 – Next Header IPIP (4)
Ipv4 – icmp echo (my tests ce to ce end to end)
Those layers is all it shows. I’ve read a lot about SRv6 with SID’s inside extension headers or segment routing header, but I’m not seeing it.
Thanks Nick, I only see the following layers... I see no extension headers
behind the ipv6 header. I sent you the wireshark sniff directly so you can
see what I'm seeing.
Ethernet - Type 0x86dd
Ipv6 - Next Header IPIP (4)
Ipv4
Icmp
you should see extension headers if you're doing more complex stuff? E.g. if you run a ping / traceroute with the "use-srv6-op-sid" parameter, or create a segment list under "segment-routing srv6 traffic engineering", that should throw in some EHs.
Ethernet - 86dd
Ipv6 - DA fc00:0:0:4:40:: (cool, this is the active/top SID, and not the ping'ed DA)
- routing header for v6 (segment routing)
--- segments left: 1
--- address next segment: fc00:0:4:4::1
Icmpv6
Many people are buying hook, line and sinker on the narrative 'it is
just IP, nothing scary and complex like MPLS'. I think SRv6 is an
abomination, it is complex SW, and very complex HW, because it exists.
We pay the premium to add HW support for it.
For use cases it has, MPLSoUDP would do the same, fast, and it would
actually pass unmanaged IP domains, unlike SRv6, since many people
filter EH at edges.
And that is what the vendor(s) pushing this hope operators "realize"...
that SRv6 is a complex mess that needs some kind of centralized system
to manage. But wait, the centralized system is, itself, quite complex
that no operator would dare spend time installing, commissioning or
maintaining it themselves.
So what ever shall we do, as operators?
Simple, pay the vendor(s) to take care of all of it for you... planning,
design, spec'ing, bill of materials, deployment, operation and refresh
programs... lock that vendor top and bottom line in for them for the
next 10 years, while they find some other RFC to create in order to keep
the cycle going 11 years later.
Sorry guys, I'm not aware of much of what you mention as far as agenda, vendor motive, and hardware support, etc....
I'm still learning, but, It does seem interesting that the IP layer (v6) can now support vpn's without mpls. So one less layer of encapsulation seems cool. Don't get me wrong, I love all that mpls has done for us and offers, but, seems that SRx6 (x=v or m) is able to do it. Seems that the end to end label challenges with unified mpls, and all the csc and vpn type a,b,c might be better done with an IPv6 stack of headers and SIDs.
(wow, I'm not a prophet, but am I sensing another death of a labeling protocol ?! this would be interesting if like MPLS killed ATM.... SR kills MPLS !) (namely SRv6/SRm6)
And with this v6 SID being smartly divided into Locator:Function(Argument), I'm reading that this will carry with it much more functionality as well, like network programmability, application-to-network interaction or something like that.
Oh and I do agree that this SRv6 terminology and architecture does make your head hurt, lol, there is some very different/new stuff going on there.
You just move the encapsulation from in-order to inside-ip making
everything harder for SW and much harder for HW, the simplicity is a
lie.
Ultimately it is very simple, we need tunneling, then the question is
how much does it cost to look up those tunnel headers and how much
space they take on the wire (relevant for overspeed), everything else
is noise.
to quantify this, the tunneling header increased in size from a minimum of 4 octets to a minimum of 40 octets. If you want explicit path routing, you'll need to tack on a SRH which is another 8 octets + 16 octets per SID, so e.g. an mpls frame with 2-node ERO goes from 12 octets to 80 octets.
This comes at a cost. What was previously a simple lookup operation on a tightly optimised format is now up to 10x bloated with little extra functionality to show for it. It's true that these devices already do ipv6, but can they do ipv6 + complex decapsulation in a single pass? If you're using an NPU, probably yes. If an ASIC, maybe not. What if the decapsulated packet has a stash of ipv6 extension headers? This gets complicated quickly, and that complication can only be solved by adding complication to silicon, which is what you want not to do when the speed of your underlying forwarding plane is increasing by leaps and bounds. Good, cheap, fast. Choose two - or maybe one.
The control plane is byzantine. This also has a cost in terms of design, build and support / maintenance. As Mark points out, many companies have made their fortunes with a full stack product offering, from hardware and software to design, engineering and operations. It's not a bad business model as long as you realise that it's time-limited to the technology of the day. When it draws to a close, it's hard to turn companies around that have been used to a single-product or single-vertical cash trough which no longer exists. Some have done this successfully; others have floundered.
