I've got a couple of changes to the ipsec API that I'd like to upstream to match the vpp "kernel" code I'm going try and upstream to strongswan.
1) Add: Add an ip_route_lookup/reply pair (semver minor++) 2) Fix: Add IS_INBOUND flag (value 0x40) to ipsec_sad_flags (semver patch++) optional) Fix: possibly add the other missing flags to ipsec_sad_flags so they can be properly returned on queries. I think submitting these for release branches is OK after reading https://wiki.fd.io/view/VPP/API_Versioning I'm coding to 19.08 right now, if I'd like to have those changes in that branch I would imagine I'd need to also submit changes for 20.01 and master? I admit to being confused about the CRC stuff, and the warnings in the 19.08.1 release notes and what those warnings imply. Is it safe to assume the CRC stuff can be ignored and external clients will still work (given no semver major change) even if a CRC chagnes? Side Note: from the API link: "If a new message type is added, the old message type must be maintained for at least one release. The change must be included in the release notes, and it would be helpful if the message could be tagged as deprecated in the API language and a logging message given to the user." Given there are 3 releases per year, only maintaining an old compatible function for 1 release seems rather aggressive. It does say "at least" though. :) Thanks, Chris.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15521): https://lists.fd.io/g/vpp-dev/message/15521 Mute This Topic: https://lists.fd.io/mt/71535081/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-