Hi Matt/vpp-dev, I’m reaching out after discussion with Andrew regarding an upcoming change in behaviour of an API. Currently, when nat44_ed_add_del_static_mapping[_v2] is called, the supplied u8 protocol value is taken and silently converted into NAT_PROTOCOL_(TCP|UDP|ICMP|OTHER). Part of upcoming change is to drop this internal enum and treat static mappings (SM) same way as dynamic mappings - to store IANA IP protocol value in SM instead of said nat_protocol_t. This however causes a behaviour change.
For TCP, UDP and ICMP there is NO change. For everything else the change is: Old: nat44_ed_add_del_static_mapping (is_add=1, protocol=101) is treated as "nat44_ed_add_del_static_mapping (protocol=other)", so this creates a catch-almost-all SM, which then translates also all other protocols except tcp, udp and icmp. Calling nat44_ed_add_del_static_mapping (is_add=1, protocol=102) would then return VNET_API_ERROR_VALUE_EXIST (because it’s internally translated to the same “other” thingie). New: protocol is stored in (and matched by) static mapping exactly as it’s supplied. To get old behaviour a user would have to create 252 static mappings (with all protocol values except tcp, udp, icmp). New feature with this is ability to translate only some of non-tcp/udp/icmp protocols as it isn’t a catch-almost-all logic anymore. Question is whether there is a real need to do the usual deprecate old api and keep its behaviour (which would now internally add/del 252 mappings) while introducing a new api with new behaviour routine or it’s okay to change it under the hood keeping apis intact. The apis are already accepting ip protocol value, so there is no change required in api signature. Would you be so kind to share your thoughts on this topic? Thanks, Klement
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20218): https://lists.fd.io/g/vpp-dev/message/20218 Mute This Topic: https://lists.fd.io/mt/85921424/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
