Jon, [...]
> Which is all pretty much fine... Except that it continues to use a > field named "is_inside", and when passed _back_ to the Client in a > DUMP/DETAIL, > message, it is a tri-state value: > is_inside == 0 <==> "outside" > is_inside == 1 <==> "inside" > is_inside == 2 <==> "both" > > Which is where the unannounced, yet visible API change took place. I reviewed that change (too briefly, you might argue) and concluded mistakenly that it was backwards compatible. Sorry for that. [...] > Call me a old grumpy whiner, but can we please post something to > the list about these sorts of changes? That should clearly have been done. > And can we please rename that field away from "is_inside" to something > more descriptive and *less* misleading now? > > I understand that this quad-state is really a combination of "on a list or > not" > and "one of three states if it is on a list", but it really would be much > clearer > if the flags field was used as a real 4-state (2-bit) flag field and the > INSIDE and OUTSIDE bits were clearly declared as such using 0x1 and 0x2 > and 0x3 was used at the API to indicate both IN and OUT. > > Blah. > > jdl > > PS -- Yes, I can write that patch if it would be accepted... A patch would be very welcome. I believe you are one of the main users of the NAT component. Would you have time to sit down on the phone next week (after the IETF) and talk over NAT evolution / roadmap, how you use it etc? Best regards, Ole
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
