> On 14 Nov 2023, at 19:46, Michael Richardson <[email protected]> wrote: > > > Yoav Nir <[email protected]> wrote: >> - Although it is implied, it should be stated explicitly that >> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As >> some child SAs get deleted and perhaps not rekeyed if they’re idle, if >> traffic picks up again, new child SAs with these TS can be created >> until the peer again blocks you with a TS_MAX_QUEUE. > > Do you think it be better for each end to announce a maximum ahead of time? > (At negotiation of the first child SA)
I think so, but not completely sure. Suppose one peer is willing to go to 32 parallel SAs, while the other is going to stop at 8, because one has 32 cores and the other 8. So on the “big” gateway, all flows that fit the TS should be forwarded to one of 8 cores. If this was negotiated upfront, the big gateway can choose which 8. As it is, the first 8 cores that triggered the negotiation get SAs, while the rest have to forward after a short delay while trying and failing to negotiate an SA. Maybe it’s not an issue because SAs can be moved among cores. The draft mentions this possibility. Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
