SRv6
Nick Hilliard
nick at foobar.org
Tue Sep 15 19:07:18 UTC 2020
Saku Ytti wrote on 15/09/2020 18:05:
> 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.
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.
Nick
More information about the NANOG
mailing list