>> However, due to the combinatorial explosion, these blocks of SAs may easily >> become pretty >> large, ie. with a reservation for multicast senders and QoS groups SPIs may >> be a little short. > > Wow, what architecture are you implementing? After all, 2^32 SPIs by 2^32 > packets per SPI are more than the estimated number of silicon atoms! > > When I originally designed PIPE and reserved v6, that initial draft > eliminated the IP ToS field. I've never seen the need, and believe that > history has validated my view. Since then, "integrated services" and > "differentiated services" and other efforts have long been marketing points > to extract money from naive customers, but have had little practical effect. > > As some folks know, once upon a time I founded one of the first ISPs in 1994. > In more than a decade, I'd never had a customer who needed QoS. > > CoDel did far more for active queue management than QoS. (I was involved in > the CeroWRT bufferbloat project, too.) > > IMnsHO, those who want to shoot themselves in the foot with QoS deserve the > complexity and overhead. > > Still, I've no idea how you'd run out of SPIs.
Unfortunately I develop systems for a customer who uses DS for some (maybe non-technical) reason. The issue I am struggling with: If there are multiple “reasons” to allocate blocks of SAs we’ll have a lot of unused SPI space. Coming back to my example data center scenario: Customer with 10,000 VMs doing multicast + QoS + having multiple cores (say AMD with 64). We would require 14 bits to encode all possible senders, 6 bit to encode possible DSCP values and 6 bit to encode the cores. That is 26 bits of our 32 bits in total. We only can build up very few of these SAs (<32 if we want rekeying with make-before-break). The key issue is that we had to preallocate all these SPIs even if few of them are ever used. Maybe I am seeing this all a little pessimistic, but I would not want solutions that exclude each other, i.e. multicast SAs that do not scale over CPUs, etc. One way out is Tero’s suggestion to add the sender IP address to the SA lookup. I have thought about this option over the last days, but I am coming more and more to the conclusion that this is left out of the lookup for a couple of reasons: Most prominently there maybe issues with IPv6 renumbering and multiple/non-unique sender IP addresses. Furthermore, the IP addresses of the senders would required to be known in advance. All of this will cause a lot of control plane overhead and possible race conditions in the interworking between control and data plane.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
