Hi, I think that we need to be careful here. In summary, I agree with a lot of the concerns flagged by Jan, both in ensuring that we don't break existing NETCONF*/YANG configuration paradigms (*, by NETCONF, I mean NETCONF or RESTCONF), but also the approach of considering the best long-term solution to each of the specific requirements.
Fundamentally, I generally interpret this draft as saying: NETCONF/YANG doesn't really match the existing management model/API in 3GPP and hence we want to make non-backwards compatible changes to NETCONF/YANG to match the 3GPP semantics. Currently in the network management space, this is a strong desire for configuration to be intent driven, where it should be possible, in a single external transaction to move from any one valid configuration to another valid configuration. E.g., some clients always make any configuration change as a full commit replace and leave it to the device to calculate the actual configuration change delta that needs to be processed (including deleting and recreating objects if that is needed). E.g., some of our customers really dislike it whenever we force them to split a config-updates into two separate transactions because it increases the complexity of the orchestration - we end up getting bug reports for these sorts of issues and aim to remove them. So, I think that I am fairly strongly opposed to adding an annotation to YANG that would mandate this transaction breaking behaviour - it seems to be going in the wrong direction of travel for automation. In terms of a liaison response, I would suggest that we acknowledge the request from 3GPP and indicate that we are investigating approaches to address the requirements raised, but we need to determine if there are ways that these requirements can be met without breaking the core tenets of the NETCONF/YANG configuration architecture. E.g., some parts of the approach described here will mean that existing management clients, that are compatible with NETCONF/YANG, will not directly work with servers implementing this change. Similarly, some of the language is effectively forcing breaking changes onto NETCONF/YANG service implementations (e.g., text in the document like "When present, it indicates that data nodes based on the parent statement are not allowed to be added, removed or updated except according to the exceptions argument. Any such write attempt will be rejected by the server."). Further, I wonder if there are enough issues here to warrant having a dedicated interim to discuss this. I seem to recall the NETMOD chairs suggesting an interim on one topic in the recent NETMOD session, but don't recall whether it was for this one - sorry! A few thoughts on the current draft: - Handling of capabilities is an important topic, and has comes up recently in several places, this topic alone might be worth some time being spent on it. Having an annotation to indicate capabilities information may be useful, but possibly this should be an entirely separate annotation to indicate what it is, or perhaps putting capabilities are put under a /capabilities root container would be sufficient. - In terms of properties that cannot be changed once written, I would rather see this issue framed more in the direction of it just being extra documentation written in a machine-readable way. Specifically, using the annotation to give an indication that servers MAY reject requests to create/delete, or change, the configuration, but not requiring that they do so. I.e., at the data model level, I don't think that we should preclude servers being able to handle this is in a more client friendly way (e.g., by breaking a single client transaction up into multiple internal transactional changes where needed). - For any immutable related metadata annotations, I think that this additional metadata should only be returned to clients when explicit requested via a separate RPC parameter, and I think that the draft needs to add text for protocol capabilities used to indicate whether this new option is supported (e.g., along the lines of RFC 6243, with-defaults). Regards, Rob // All comments without an AD hat on. > -----Original Message----- > From: netmod <netmod-boun...@ietf.org> On Behalf Of Jan Lindblad (jlindbla) > Sent: 31 March 2023 08:11 > To: maqiufang (A) <maqiufa...@huawei.com>; Balazs Lengyel > <balazs.leng...@ericsson.com> > Cc: NETMOD Group <netmod@ietf.org> > Subject: [netmod] Comments on draft-ma-netmod-immutable-flag-06 > > Quifang, > > Thank you for the excellent presentations at the NETMOD session today. I > understand how and why the immutability topic is important to 3GPP, and > several other IETF liaised organizations, and I certainly think we should > respond > to their liaison inquiry in a timely manner. > > In my opinion, that response should be along the lines that we understand and > support the use cases as put forward in the liaison statement. We should say > that NETMOD is working on a solution which provides an operationally useful > way of handling all the use cases without changing the fundamental properties > of the existing management protocols and modeling standards. > > Going a level deeper into what that solution should look like, I have read the > latest immutable draft, draft-ma-netmod-immutable-flag-06. It lists six use > cases, which I think are the key to resolving this. I think our liaison > response > should focus on them. I noted that UC5 is qualitatively very different from > how > it was in -05. > > In the below, I first discuss why immutable is not already part of > NETCONF/RESTCONF/.../YANG (will call this XC/Y), then go through each of the > use cases. At the end, I also have a few comments about the proposed YANG > constructs. In order to write the liaison response, I think getting our minds > into > agreement about the approach to the use cases is the important thing, and > probably also enough. The exact YANG expression may be agreed later, after > responding to the liaison statement. > > > As emphasized in the draft, a NETCONF server can reject any configuration > attempt at any time for any reason. So by this logic, what the immutable draft > proposes is "nothing new", it's just documenting some of the cases in which > such a rejection will happen. This is true, but by this reasoning there is no > limit > to what sort of rules could be added to XC/Y. Just because there is a > possibility > to reject for any reason doesn't mean that you can impose any set of > additional > rules on top of YANG and still call it YANG. > > Servers often call upon the possibility to "randomly" reject when they are > running out of memory. Or when certain instances (e.g. mgmt interface) are > being deleted, but simply has to be in the config at all times. This is fine, > since > few operators desire configs that exceed the available memory (and it is > generally hard to predict+describe exactly when that happens) or removes the > mgmt interface. The problems arise when operators want to go live with a > config that is fundamentally valid, but the server rejects *at this time* due > to > some settings in the current configuration. > > Such constraints were (are) common in the CLI and SNMP world, and for good > reason in their usage context. Servers are being nice when they protect > operators from goofing. But to apply those same safeguards in a high level > automation context is not a good idea, since it complicates, slows or prevents > core automation use cases. For example, if the "safeguards" require a > transaction to be split into two transactions, the solution is no longer > transactional, and something has been fundamentally lost. The good news is > that I think there are good solutions to the six use cases that preserve the > fundamental properties of our management protocols. > > > The immutable-flag draft often refers to "problems" where constructs are not > allowed in YANG. Here's a typical example: > > However, this is not possible as 'supported-timer-values' must be > read-only thus config=false while 'interface-timer' must be writable > thus config=true. According to the rules of YANG it is not allowed > to put a constraint between config true and false schema nodes. > > This text seems to forget that these YANG rules, e.g. the rule that you cannot > have config true objects below or otherwise depending on a config false one, > were a super-conscious choice made when designing YANG. The SNMP world > "transient configuration" gave operators a lot of gray hairs, so was given as > a > requirement to the NETCONF work to get rid of. So it was that such things are > now very deliberately made impossible to model in YANG. The immutable draft > is trying to reintroduce this (at least in some cases) in YANG. But if we > change > YANG to allow this sort of behavior in general, the additional value of XC/Y > is > lost, and we're back where we started (SNMP-level automation functionality) > 20 years ago. Now with two competing, but equally useless configuration > mechanisms. > > In the routing domain, and in many others, it has proven possible to leave > those > old practices behind and build quite functional management interfaces even > within the confines of current XC/Y rules. I am convinced that this is > possible in > the 5G world too. I am well aware of the traditions in the 3G/4G/5G world, > where the immutable and other concepts were born long ago and are still > considered core functionality today. I have helped many XC/Y server developing > organizations to overcome these traditions, which used to be common > everywhere where CLIs were used. By this experience, I know very well that > this is not only possible, but has actually been done in numerous places, and > across many server/device types. > > > Now, let's review each of the use cases UC1-6 from the appendix A. > > UC1. Modeling of server capabilities. > > Draft example: System specific set of available timer values created by the > system, that other parts of the configuration have to reference. > > This is a common use case. I find it working pretty well without any extension > stmt. As long as the supported values do not change (other than in sw > upgrades, > for example) I think it makes good sense to model them as config true in a > separate part of the tree and simply refuse any changes to them. It would of > course be fine if there was a YANG extension "immutable" that was placed at > the root of the list to indicate to clients in the know that any attempts to > make > changes there would be refused. > > > UC2. HW based auto-configuration - Interface Example > > Draft example: Interface type, which is set by the system and cannot be > changed by the client. Must be config true since other configs depends on the > interface type. > > This is also very common. That a server autodetects which interfaces are > present at startup and fills them in is not a problem at all. Some servers > allow > clients to make changes to this data, such that it does not match HW, and when > that happens, the configured device will be marked as operationally > down/absent. This is the model I personally consider the most advanced and > flexible. Other vendors refuse changes to the config that do not match the > current HW, e.g. interface type or which interfaces are present. I think this > works reasonably well today, but some sort of YANG extension to describe this > case is ok. > > > UC3. Predefined access control rules > > Draft example: Factory predefined access control rule instances that cannot be > deleted. > > This is also quite common. That a server has some (factory default) instances > in > a list that cannot be deleted is not a big problem, and can be described with > YANG must statements already today. Some instance metadata annotation to > mark these entries is also acceptable, even if strictly not necessary. > > > UC4. Declaring System defined configuration unchangeable > > Draft example: System datastore content that is not modifiable by clients. > > I find this similar to the previous use cases 1-3. Not a big problem in the > field > today, but some combination of YANG extension and metadata annotations to > mark certain instances as always there is ok as long as the set of marked > elements and instances remain more or less constant. > > > UC5. Immutable BGP peer type > > Draft example: Detected BGP neighbor peer-type > > In the actual IETF BGP YANG model, the peer-type leaf is modeled as config > false, which seems to make sense. If for some reason this needs to be modeled > as config true, I think this use case becomes similar to UC2. > > > UC6. Modeling existing data handling behavior in other standard organizations > > For this use case, the draft does not really offer an example. The draft > states > that the immutable concept has been in use for a long time in many > organizations, and that that is not likely to change. It is better to > describe the > truth about these systems than silently and "randomly" reject configurations. > > I respect the traditions of these organizations, and I do not wish to impose > the > XC/Y traditions onto the large and complex designs they have built up over > decades. But I think the XC/Y interface to those systems need to follow XC/Y > rules and principles, and I claim from my experience that this is not > particularly > hard to do for a given XC/Y implementation. > > > Bonus: UC7. Handling existing 3GPP objects with attributes marked immutable > > A use case not mentioned among UC1-6, that I think will be relevant to 3GPP > and others, is this: Say a 3GPP object has an attribute marked immutable, > meaning that attribute cannot be changed once the object has been created. > Then a NETCONF client comes around and specifically wants to change that > attribute. > > In my opinion the XC/Y server should then delete the object with the immutable > attribute and recreate it with the client assigned new value. The NC client > will > not have to know anything about this (as expected by looking at the YANG > model), and the existing 3GPP object implementation does not need to know > anything about this either. It will keep implementing the traditional > safeguards. > The only component that will need a bit of work is the XC/Y server running in > the 3GPP defined system. In this case I don't think any immutable extension is > needed, since it is an implementation internal affair in the XC/Y server. > > If the server chooses to instead reject the NC client's request, which it is > allowed to do without disclosing any reasons therefore, the client will have > to > think about what to do. If there was an immutable extension statement > explaining the situation in the YANG, and the client understands this > extension, > it could split the request into two transactions (one to delete, one to create > anew). But this means the server is not transactional, and in my world that > is a > pretty weak server. Safeguards are great when interacting with humans, but > when they get in the way of serious automation, I advise to remove them from > the XC/Y interface, as described above. The market will make the final > decision > about what will be tolerated here. I am opposed to introducing an extension > keyword for this use case. The -06 version of the immutable draft does not > have > this use case, so as far as I am aware nobody is currently suggesting this > either. > > > Finally, some detailed comments about the YANG module in this draft: It is > short and sweet, just as it should be. The immutable extension takes an > argument "exceptions". The naming of the extension in conjunction with the > extension name itself is not ideal, I think, because of the way it reads in > modules that use it. Say we have an immutable leaf that can never be updated > or deleted. This leaf would have the extension "im:immutable create;". I > believe many would read as "not possible to create". After the > negative-feeling > adjective"immutable" would it not feel more natural to list the operations > that > are disallowed? And what if no operations are allowed, should you write > im:immutable ""; ? The extension requires an argument, so something is > needed, according to the definition. > > Or perhaps this extension statement should be changed to have no argument? > Among the use case examples UC1-6 (or 7), I did not see any case that required > the exception argument, so I wonder if it is really needed. As far as I could > see > in the use cases listed, all I think is needed are two things: one YANG > extension > "immutable" for saying the values on or below this schema element must > match whatever the server considers to be appropriate. And one YANG > metadata extension for saying this instance must always exist, but you may > alter the contents within. If those two things are not enough, please either > point > to the use case that requires more, or add a use case to the collection to > capture the need. > > Best Regards, > /jan > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
