Hi Martin, > well said.
Thanks. > With this in mind I'd rather ask: Do we really need SID list compression at > all? A very fair question. > 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. :-) 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. Overhead counts. It comes straight off of the bottom line. Reducing it is very helpful. Even with a compressed header, SRv6 is asking the industry to pay a pretty penny in overhead and this will go directly against SRv6 adoption, especially by those who are knowledgeable and paying the bills. So yes compressing the SID list is beneficial for SRv6. It may well be the only real hope that SRv6 has for widespread adoption. > IMHO SRv6 is the one thing that really allows for full flexibility for > whatever use-cases may come up in the future. Any compression scheme has > drawbacks. That would be called the reserve parachute. :) Tony _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
