Hi Jeff, Please see inline. Jason From: Jeffrey Haas <[email protected]> Sent: Thursday, April 13, 2023 4:03 PM To: Jason Sterne (Nokia) <[email protected]> Cc: [email protected] Subject: Re: Unknown bits - backwards compatibility
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Jason, On Apr 12, 2023, at 5:26 PM, Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>> wrote: It just occurred to me that to avoid the NBC change we could also consider just calling this new typedef “raw-bits” and always outputting all the bits in the second leaf (whether they are known or not)? I suspect this was already considered though… It was and part of the discussion. As I mentioned to Andy, consistent advice for modeling the raw stuff might be helpful. However, for bit fields I find the likely options to be annoying and probably not good ease of use for the end-user. More below From: netmod <[email protected]<mailto:[email protected]>> On Behalf Of Jason Sterne (Nokia) One topic that came up during the IETF 116 NETMOD meeting was backwards compatibility. From what I understand, a leaf (e.g. unknown-flags) that uses the unknown-bits typedef would never change its definition in YANG. It would always be defined as unknown-bits with all 64 bit definitions even as more and more bits become “known”. *But* the system would suddenly stop reporting bit-0, then bit-1 in that unknown-flags leaf as those bits become known. That's the current proposal, yes. Strictly speaking, that should probably be considered an NBC change although it is a bit of a grey zone - the NBC rules for state are fuzzy (theoretically they are defined by RFC7950 but it is clear those rules were focused on config, and the same goes for all our new versioning work). But I could imagine an implementation that was previously seeing bit-0 returned and suddenly stops seeing that bit-0 returned (which could cause different interpretation/behavior). So in some ways the semantics of the unknown-flags leaf has changed. It may be better to just flag this as an NBC change so a user would be drawn to look at it, and make a decision that they do or don’t have to update their handling/use of it? I'm not following the versioning discussions enough to know the full semantics you're implying. [>>JTS:] It is basically the fact that the “old” server returned bit-1 in a specific scenario and now the new server doesn’t return bit-1 in that same scenario. Strictly speaking that’s NBC (as you mention below, a client/app may have been checking for bit-1). That said, you hit the relevant point next: The known flags leaf would only go through backwards compatible changes though (since we’d always be additive in adding bits) – assuming bit positions don’t change in the protocol. Exactly. Unknown became known. The need to "see" the unknown has gone away. Thinking on this slightly more, I think I see where our thinking diverges somewhat. From one perspective (illustrated by your point above), bit-1 has "gone away". This is a change. My perspective is that the semantics of the node in question is there to model "unknown". The change is thus "expected" when things are assigned.[>>JTS:] Yeah – I see that perspective. But a client using the old API/contract gets new/different behavior for the unknown-flags leaf from a new server. Hence NBC – unless we decide in the end to somehow make this specific case/typedef an exception but I’m not sure about that yet. The typedef and behavior you are describing there may still be useful as-is even if we decide to still officially consider the change to unknown-flags behavior as NBC (i.e. in new the version of the module that changes a bit from unknown to known). Where things are potentially problematic for end users from a state perspective is that if you're testing on the unknown bit, its change is HIGHLY problematic. My use case is for debugging rather than daily operations. [>>JTS:] OK but when we report NBC vs BC for a new version of a module, we can’t really define that based on some use cases and not others. It is based on rules purely related to how the API & behavior has changed. This doesn’t make the proposed behavior bad – I’m just thinking that we should probably still consider it NBC. In circumstances where you wanted to always know the contents of the bit vector in a constant fashion, a "raw" output is preferable. However, this reverts to the headache discussed in other sub-threads. I wish to point you and others concerned on these points to the BGP YANG modeling for Extended Communities, which will have these problems in a different flavor: Known communities will render via the typedefs, unknown will render using the prefix 'raw'. (See typedef bgp-ext-community-type.) This headache is already a consideration in every BGP implementation that deals with extended communities in changing meaning. [>>JTS:] Can you point me to a repository or RFC where I can see this? I’m not familiar with where this YANG work is being done. To address that point and needs for stable representation, see leaf-list "ext-community-raw". Netmod's deep scrutiny on this topic is heartily invited. :-) I expect a lot of heartburn over what current implementations do with this stuff. It would probably help to show an example of what a YANG module looks like for step 1 and then step 2 (an unknown becomes known), and also what is returned in NETCONF in step 1 and step 2. You partially have that in section 3.2 although the YANG model isn’t shown and it might be good to explicitly mention that <unknown-flags> isn’t returned (note it may also be valid to return <unknown-flags></unknown-flags>). Figure 4 in draft version -02 shows how the type gets modified to add the new bit. The model doesn't change between step 1/ step 2 beyond this. [>>JTS:] Sure – maybe just mention explicitly that the model for unknown-flags stays unchanged. If you'd find it helpful, I could add to the text covering Figure 8 "after assignment, bit-1 is no longer returned in unknown-flags". Is that what you're looking for?[>>JTS:] Yes – that would probably help. -- Jeff
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
