On Fri, May 5, 2017 at 9:01 AM, Peltonen, Janne (Nokia - FI/Espoo) < [email protected]> wrote:
> There is perhaps some ambiguity now in the API on whether expired soft > lifetime means that a packet is not "successfully processed", which in > turn determines whether inline mode outbound packets get sent directly out. > > Having the life time expiration in the error field could be interpreted > to imply that soft life time expiration in inline output is not considered > successful processing, so an application can expect getting a result event > with successfully transformed packet but with one of the soft lifetime > error bits set. That works, but I do not think we want to drop out from > inline processing mode just because of soft lifetime (/bytes/packets) > Agree. which is why soft limits should be treated as separate events. These are essentially alerts to the control plane that it's time to start rekeying this SA as the current keys are nearing the end of their useful life. So in that case it's like the low fuel indicator on a car. That doesn't mean the car stops, just means that you need to consider filling up in the near future. Since as previously noted time based limits need to be treated as events anyway since they are not associated with any packet, it's simpler and more uniform to treat all such limit crossings the same. Adding side-information to the processing results for a given packet means that the application would need to check every packet for these rather than simply having the appropriate event handler waiting to receive these relatively rare notifications. > expiration. > > Janne > > > > -----Original Message----- > > From: lng-odp [mailto:[email protected]] On Behalf Of > Savolainen, Petri > > (Nokia - FI/Espoo) > > Sent: Friday, May 05, 2017 11:18 AM > > To: [email protected] > > Subject: Suspected SPAM - Re: [lng-odp] [PATCH API-NEXT v1 2/2] api: > ipsec: move soft > > limits expiration to flags, rather than errors > > > > > > > > > -----Original Message----- > > > From: lng-odp [mailto:[email protected]] On Behalf Of > > > Github ODP bot > > > Sent: Thursday, May 04, 2017 8:00 PM > > > To: [email protected] > > > Subject: [lng-odp] [PATCH API-NEXT v1 2/2] api: ipsec: move soft limits > > > expiration to flags, rather than errors > > > > > > From: Dmitry Eremin-Solenikov <[email protected]> > > > > > > Soft limit expiration isn't an error per se. It does not mean, that we > > > received invalid or unprocessed packet. They look more like flags, > > > noting that soft limit on this SA was expired. > > > > Advantage of keeping those among error flags, is the easy/fast check in > the common case: > > > > Only check (error.u64 == 0) to see that everything is OK vs. > > > > checking always both (error.u64 == 0 && (status.u64 == 0 || > (status.soft_exp_sec == 0 && > > status.soft_exp_bytes == 0 && status.soft_exp_packets == 0))) > > > > > > -Petri > >
