Title: LS on need for modeling isInvariant and SystemCreated in YANG Submission Date: 2023-03-09 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1818/
From: Susanna Kooistra <[email protected]> To: Kent Watsen <[email protected]>,Lou Berger <[email protected]> Cc: Robert Wilton <[email protected]>,Network Modeling Discussion List <[email protected]>,Kent Watsen <[email protected]>,Lou Berger <[email protected]>,Warren Kumari <[email protected]> Response Contacts: [email protected] Technical Contacts: Purpose: For information Body: 1.1 3GPP SA5 Introduction The 3rd Generation Partnership Project (3GPP) unites seven telecommunications standard development organizations (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). Its work includes development and maintenance of standards for GSM and related 2G and 2.5G standards, including GPRS and EDGE UMTS and related 3G standards, including HSPA and HSPA+ LTE and related 4G standards, including LTE Advanced and LTE Advanced Pro 5G NR and related 5G standards, including 5G-Advanced An evolved IP Multimedia Subsystem (IMS) developed in an access independent manner 3GPP SA5 workgroup specifies Management, Orchestration and Charging requirements, solutions, and protocol specific definitions. The solutions include architecture, service definitions and data definitions. 3GPP SA5 defines OAM information and data models. Stage 2 information models are defined based on a UML subset as defined in 3GPP TS 32.156[3]. The base concepts used are classes/objects arranged in a tree shaped containment hierarchy and attributes that are contained in these classes/objects. 1.2 3GPP SA5 using YANG for 5G – a major YANG community 3GPP introduced YANG as one of the stage3 data models for 5G. Stage 3 data models (Solution Sets) are defined in YANG and in JsonSchema/OpenApi for 5G NR and related 5G standards, including 5G-Advanced. This document considers the YANG models but does not handle the OpenApi models. According to 3GPP rules and processes Stage 3 data models should be a direct mapping of the stage 2 information models. Stage 3 should not add or remove data or data handling concepts to stage 2 definitions. While mapping 3GPP Stage 2 models to any solution set is necessarily imperfect, the goal is to follow stage 2 concepts as closely as possible. 3GPP TS 32.160[4] clause 6.2 defines how to map stage 2 information models to YANG. Classes are mapped to YANG lists. Attributes are mapped to YANG leaves, leaf-lists and lists contained under the list of the class. The most important 3GPP Stage 2 and Stage 3 models are currently defined in 3GPP TS 28.622[5], 28.623[6] and 28.541[7]. 3GPP Stage 2 models include modeling concepts (including isInvariant and SystemCreated Classes) that currently cannot be mapped to IETF defined YANG statements. So a solution to represent the isInvariant and SystemCreated properties in IETF defined YANG statements is needed to support 3GPP stage3 YANG data model. 1.2.1 isInvariant We propose to formally document as a YANG extension a model handling behavior (inVariant) that is allowed today in YANG and which has been used in 3GPP for a long time. 3GPP TS 32.156[3] clause 5.2.1.1 defines the isInvariant property for attributes. An attribute with the isInvariant=True property may be assigned a value when the containing Object is created, but the value of the attribute cannot be modified later. The only way to modify the attribute value is to delete the containing object and re-create it with the same attribute having a different value. However, such a delete/recreate sequence may often have undesirable side-effects e.g., traffic disturbance. RFC 7950 either allows a data node to be written or not (config true/false) but does not differentiate between the initial creation of a data node or a later modification. YANG allows the server to refuse any modification for any reason even if a data node is config=true, so YANG allows behavior according to the 3GPP isInvariant=True property. It is needed to formally document this behavior (which is known already at design/implementation time) in the YANG models so that model driven tools/SW can understand it. 1.2.2 SystemCreated Classes We propose to formally document as a YANG extension a model handling behavior (SystemCreated) that is allowed today in YANG and which has been used in 3GPP for a long time. In TS 28.622[5] and TS 28.541[7] several Classes are defined as created and deleted by the system (MnS Provider in 3GPP terms that is the server in YANG terminology). Managed Object Instances of SystemCreated classes cannot be created or deleted by the client (MnS_Consumer). SystemCreated classes in many cases contain writable attributes. SystemCreated classes include ThresholdMonitor, HeartbeatControl, NtfSubscriptionControl, AlarmList, TraceJob, PerfMetricJob, Files, File, Dynamic5QISet. All 3GPP classes are mapped to YANG lists. Attributes are mapped to YANG leaves, leaf-lists and lists contained under the list of the class. According to RFC 7950 the only way to declare that entries in a list (representing a SystemCreated object) cannot be added or deleted is to mark the list as config=false. However, a config=false list cannot contain writable (config=true) data nodes. YANG allows marking the list of the class as config=true and defining writable (config=true) data nodes (attributes) below it. YANG also allows the server to refuse any modification for any reason even if a data node is config=true, so YANG allows the server to reject the creation/deletion of config=true list entries. YANG allows behavior according to the 3GPP SystemCreated concept. It is needed to formally document this behavior (which is known already at design/implementation time) in the YANG models so that model driven tools/SW can understand it. 1.3 ITU-T usage of the immutable concept ITU-T uses similar concepts with an imperfect YANG mapping. The modeling concepts of isInvariant (a Boolean property that indicates whether an attribute value can be changed after it has been created) and writeAllowed (an Enumeration that indicates various restrictions on creating and setting a value) cannot be modeled in YANG today. The concepts would be supported if the concept of immutable was added to YANG. See G.8052.1[9], G.8152.2, and G.874.1 for examples of specification of a model using isInvariant and writeAllowed but including an incomplete mapping in the accompanying YANG. The properties are only visible in the UML model as YANG support is missing. See also [10]. 1.4 IETF Solution preferred While we raise the issue, in order to document 3GPP concepts, we seek an IETF ratified solution because • IETF ratified solutions are more likely to be implemented by YANG/Netconf SW tools. • 3GPP represents a significant standard, vendor, and user community for YANG. • The invariant and SystemCreated concepts are not unique to 3GPP. They are used by other standard organizations and vendors. • Participants in IETF itself have identified several similar use-cases independent of 3GPP. See [2]. • To avoid using vendor or standard specific solutions for a common problem: o 3GPP uses both above concepts and has already defined a YANG extension for inVariant. o ITU-T uses the invariant concept o Ericsson has a similar extension defined o YumaPro has a similar extension defined yuma-ncx:user-write. o Nokia has a similar extension defined sros-ext: immutable o Huawei also has the very similar extension defined as ext: operation-exclude (see https://github.com/Huawei/yang/blob/master/network-router/8.22.0/ne8000-x/huawei-extension.yang) o Cisco has isInvariant=true data nodes in some of it’s YANG models o Junos OS provides a hidden and immutable configuration group called junos-defaults that is automatically applied to the configuration of your device. 3GPP SA5 sees draft-ma-netmod-immutable-flag [2] as a potential solution. 2 References [1] IETF RFC 7950 he YANG 1.1 Data Modeling Language [2] draft-ma-netmod-immutable-flag YANG Extension and Metadata Annotation for Immutable Flag [3] 3GPP TS 32.156 Telecommunication management; Fixed Mobile Convergence (FMC) Model repertoire [4] 3GPP TS 32.160 Management and orchestration; Management service template [5] 3GPP TS 28.622 Telecommunication management; Generic Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS) [6] 3GPP TS 28.623 Telecommunication management; Generic Network Resource Model (NRM) Integration Reference Point (IRP); Solution Set (SS) definitions [7] 3GPP TS 28.541 Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3 [8] 3GPP YANG module _3gpp-common-yang-extensions.yang [9] ITU-T G.8052.1/Y.1346.1 Operation, administration, maintenance (OAM) management information and data models for the Ethernet-transport network element [10] ONF TR-531 v1.1.03 February 3, 2023, UML to YANG Mapping Guidelines 3 Actions To IETF Netmod WG ACTION: 3GPP SA5 respectfully asks NETMOD WG to consider 3GPP SA5 workgroup’s strong requirement for a solution to represent the isInvariant and SystemCreated properties in an IETF ratified manner. 3 Dates of next TSG SA WG 5 meetings SA5#147 27 February - 3rd March 2023 Athens, GR SA5#148-e 17th – 21st April 2023 Online Attachments: S5-232770 LSout on need for modeling isInvariant and SystemCreated in YANG https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2023-03-09-3gpp-tsg-sa-wg5-netmod-ls-on-need-for-modeling-isinvariant-and-systemcreated-in-yang-attachment-1.doc _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
