Re: SRv6

[Nick Hilliard <nick () foobar org>]

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