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
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
