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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
