Re: [spring] SRv6 compression

[Martin Horneffer <[e-mail]>]

Hi Tony,

>> If silicon sooner or later get's tailored for SRv6, can't it be made to simply parse big enough headers?
> 
> My understanding of SRv6 is that the SID list is effectively unbounded. It’s hard to grow silicon to keep up with unbounded. :-)

true, but also true for any factor x by which you reduce the header size!

In practice I think it's the operator's responsibility to think wisely 
about which header or segments they really need to add, and to account 
for them. And so far I do not see any use case that really would need 
more than a few segments.
Traffic Engineering can achieve almost the full optential with "2-SR" 
optimizations in all real-world topologies we could get hold of. And I 
doubt that service chaining with tens of steps will ever be really useful.

> The size of the SID list also affects MTU.  Every byte that you send in a SID list is one byte less of payload that fits.  This is perhaps less of a concern right now, but over time, as more folks move to larger MTUs, this will become more problematic.
> 
> The real killer is the cost in bandwidth. Please remember that every byte of SID list costs us because we have to transport it. And there’s no ‘revenue’ associated with this, it’s pure overhead.
> 
> I’m old enough to remember another link layer with a high overhead: ATM. Adaptation layers, cells, the whole nine yards. The net overhead was painful. So painful that it was uncompetitive. So uncompetitive that ISPs simply turned it off and replaced it with packet over SONET. And for lower overhead, just straight Ethernet over fiber.

This argument might be valid, but personally I don't share it.

Neither for the current situation.
Even though I am with an operator who actually is the one who pays for 
the overhead. I do not consider a few % overhead as critical for chosing 
a technology. What counts much more is whether a new technology is 
available, solves an acxtually existing problem, and _robustly_ works 
and interoperates.

Nor for the historic assessment of ATM.
I have been there, too. Using STM-4/OC12 with LAN Emulation when 
Gigabit-Ethernet didn't yet exist. In my personal perception, the main 
reasons to let ATM die were:
  - Overall the idea to segment packets for transport didn't seem to pay 
off at all. Is simply wasn't well suited for packet transport. And there 
were no real use cases for services besides IP.
  - AAL5 was a pain and there were no reassembly-chips for speeds higher 
than STM-4.
  - Getting EPD was an issue, but essential for reliable and effective 
IP transport.
  - Stateful LAN Emulation caused a lot of operational problems.

IMHO the limited transport overhead was a negligible problem compared to 
those.

Best rergards,
Martin