============================================================= NETCONF Data Modeling Language WG (netmod) YANG 1.1 Interim Meeting (New York) Wednesday/Thursday, September 17/18, 2014, 09:00-18:00 Minutes Juergen Schoenwaelder ============================================================= * Agenda The agenda of the meeting is to work on YANG 1.1 open issues and in particular on - issues related to YANG 1.1 conformance; - issues related to YANG 1.1 datastores and I2RS support; - any remaining open YANG 1.1 issues. Wednesday 17: 09:00 Welcome and Agenda Bashing 09:10 YANG 1.1 (Conformance) 12:00 Lunch Break 13:00 YANG 1.1 (Conformance) 15:00 Coffee Break 15:30 YANG 1.1 (Conformance) 17:30 Summary of first day Thursday 18: 09:00 YANG 1.1 (I2RS support) 12:00 Lunch Break 13:00 YANG 1.1 (I2RS support) 15:00 Coffee Break 15:30 YANG 1.1 (other issues) 17:30 Summary of second day The topics mentioned in parenthesis are indicative. We will adapt depending on how fast we make progress. * Participants - Juergen Schoenwaelder (JS), Jacobs University Bremen - Lada Lhotka (LL), CZ.NIC Labs - Andy Bierman (AB), YumaWorks - Martin Bjoerklund (MB), Tail-f Systems / Cisco Systems - Mahesh Jethanandani (MJ), Ciena Corporation - Benoit Claise (BC), Cisco Systems - Balazs Lengyel (BL), Ericsson - Peter Van Horne (PH), Cisco Systems - Jeffrey Haas (JH), Juniper Networks - Dean Bogdanovic (DB), Juniper Networks - Kent Watsen (KW), Juniper Networks (remote) - Dan Romascanu (DR), Avaya (remote) - Eric Voit (EV), Cisco Systems (remote) - Kiran Agrahara Sreenivasa (KS), Brocade (remote) * Etherpad http://etherpad.tools.ietf.org:9000/p/notes-ietf-2014-netmod-interim?useMonospaceFont=true * Recording Wednesday https://cisco.webex.com/ciscosales/lsr.php?RCID=279b4f69a41148a7b35fdd8ababb7d2f Thursday (morning) https://cisco.webex.com/ciscosales/lsr.php?RCID=edc635801eaf44129fb7f12e12c1ea0c Thursday (afternoon, missing last ~2 hours) https://cisco.webex.com/ciscosales/lsr.php?RCID=24f30bd5204346d3883cc6be26e03e7b * Issue List http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html * Y45 better conformance mechanism - JS: What is exactly the problem? - AB: current model based on importing modules this is too coarse grained - LL: routing model is a good example; the model is rather generic but implementations implement certain address families or specific routing protocols - KW: important that a client can figure out what exactly a server implements - JS, JH: What is the actual usage of 'conformance' information? We also need to distinguish conformance requirements from implementation capabilities - MB: This is most important for configuration, much less for state information - AB: There are also some modules that only define things like typedefs where it is unclear what implementing them really means - KW: we could use the "if-feature" more, but assumes being able to anticipate possible/common deviations. (can anyone see this update?) - AB: Customers do not like to write deviations - MB: Some of our customers do like writing deviations - AB: there are cases where the implemented API is split over multiple modules - AB: Announcing a module means "I am implementing the base" which is not always true. - PH: Reality is often that product groups implement subsets of modules that are required by the product groups; we try to work with features but this is difficult - PH: Another problem is that different teams use different tool chains and like to have different annotations to drive automation - PH: We prefer to work with features rather than deviations - JS: Predicting the features needed in the future is hard; refactoring modules is difficult in the IETF but likely also in large companies - AB: We can't change any published contracts - LL: I believe this is too strict - JS: Who writes package definitions? Module writers, management application implementers, NETCONF server implementers? - MB: Does the package definition have to be advertised? - AB: Probably not needed to be advertised - JH: Who is publishing package contracts? A body like the IETF, a management application writer, customers? - LL: Perhaps we need to find a way to define features later and outside of the module - MB: Perhaps we need to allow adding if-feature during module revisions - JS: How is this different from AB's proposal? - MB: This is clearly restricted to what features do and not allow arbitrary changes described in description clauses. - AB: Features right now do not even express how features depend on each other. - JH: How can vendors 'add' a feature to standard module? - AB: We need to have import >= revision (this may be a separate issue to track) - AB: An important goal is to be able to reconstruct the schema tree a certain implementation uses. - LL: Should do something like git-like, that is having 'version' numbers at different levels of the schema tree to make it easier to find out where things have changed? - MB: Consider adding indicators to the existing way we do announce conformance (e.g., indicating a module is just for importing types) - KW: Why not have vendors advertise the xpath of all the leaf/subtrees actually supported? - AB: A module that is purely optional is of little value for network management application writers. - MB: Do we continue to require a revision of a module in order to add a feature? - LL: It would be useful to have a require mechanism; the routing module does not import address specific modules but an implementation needs to implement a concrete address family - JS: What speaks against defining conformance outside of modules? - MB: This makes everything optional and then vendors implement only what they want to implement - KW et al: Vendors already today only implement what they want or are forced to implement, for business reasons. - KW: Turn it around, encourage vendors to announce correctly the 'features' they support instead of expecting them to announce what they do not do fully - MB, BL: It is unclear from RFC6020 whether all modules are advertised. This question came up several times with ietf-yang-types etc. - AB: We have an augmentation of the monitoring data model that says whether a module is implemented or just imported (e.g. to obtain typedefs). Summary so far, 3 potential tracks 1. Let’s drop feature/deviation and have everything as optional 2. Keep what we have today + the ability to have new features in a revised YANG module 3. Define features or something else outside of the modules a. One way is "package" (from draft-bierman-netmod-yang-conformance-02 b. potentially other solution, like a new YANG command Proposal: Keep features as the unit of conformance in YANG 1.1 but consider certain improvements: - indicate in the module advertisement data model the conformance associated with a module (e.g., base = "all unconditional data nodes, rpcs, notifications", import = "only extensions, typedefs, groupings, identities and features that are defined at the top level of the module") - support import by revision >= N OR remove import by revision (which is mostly important for groupings that get modified) - allow adding/removing features/if-features in revised YANG modules - add text with examples to the guidelines document - BL: There are a number of things like cardinality restrictions or subsets of identities supported that are typically implementation / product specific and outside of the general conformance mechanism. - MB: We did consider adding if-feature to enums (and hopefully also for identities). This is covered by Y11. - MB: Shall we require include by revision in YANG 1.1? This seems to be a bug-fix since otherwise it is absolutely unclear what a certain version of a module contains. - MB: If include by revision is mandatory, then we can find everything from the import statements. - AB: SMIv2 conformance remains static even if modules are updated. This is lacking in YANG. * Y16 module advertisement optimization / Y54 remove the advertisement of conformance information in NETCONF hello message - MB: YANG 1.0 modules will continue to be advertised in hello messages but for YANG 1.1 modules, we may advertise only a module set 'hash'. - MB: We should provide access to the module list in the same way for NETCONF and RESTCONF. - DB: We may have to support different module sets on NETCONF/RESTCONF or different module sets for different users or different module sets for different datastores. - MB: Since hello basically works, is this really a problem to fix, given the overall overhead of the secure transports NC is running over? RC does not have the equivalent of hello. - JS: The hello message size is mostly an issue for short lived sessions. - JH: Or for sessions running over links with noticeable packet loss rates. - DB: This may be an issue for eNodeBs. Proposal: We do not send YANG 1.1 module URIs but instead we send a hash or identifier. - JS: What is the scope of the hash or identifier? Is it scoped by the user or just by the NETCONF server? Do we go with a hello RPC or just pull this from a data model? Data model allows control from NACM, which may be a feature. Use the RESTCONF model as a starting point? Or revise RFC 6022? - BL: RFC6022 has NACM applied to it and thus it provides effectively information specific to a user. - LL: I suggest to factor the protocol bindings out of the YANG 1.1 specification into a different document. - JS: It would be nice to have the meta model Randy has been talking about but right now it seems a major surgery to a 1.1 update. - MB: Perhaps it is sufficient if all NETCONF specific parts are flagged in proper subsections. Proposal: We create a new ietf-yang-advertisement module that details a data model for the advertisement of YANG data models (that works in the same way for NETCONF and RESTCONF). * Y49 clarify nested submodule behavior Side discussion that submodule include is too complex. * Y42 a better model for configuration versus state data is needed - JS: Lets address this topic in several steps: 1st step: identify I2RS requirements for YANG 2nd step: identify which of those require changes in YANG 1.1 3rd step: discussion solution space - JH: Main issue seems the requirement to deal with ephemeral state - JS: Who decided when whether something is ephemeral or not? - JS: What determines the lifetime of ephemeral state? - MB: What is the data model for ephemeral state? Can the whole config data model be used for ephemeral state? - JH: One option is to have per module an indication whether it supports ephemeral state - JS: From a NETCONF view, is I2RS not just another (routing) protocol injecting routing state? - JH: Yes, but it may do more than just routing state. +-----------------+ | | +--- (+) ---+ | ^ ^ v +---+ +---+ +---+ | | | | | | |(1)| | | | | | | | | | | +---+ +---+ +---+ NC config ephemeral operational datastore datastore state (1) The complete NC config datastore is at certain synchronization points made persistent (+) Priority resolution, priorities may be per datastore or per user or per 'application' or even per data node - JH: Ephemeral state exists until reboot or an explicit action to clean up a complete ephemeral datastore or all state injected by a certain user into an ephemeral datastore - AB, MB: Important to keep the config datastore sane and valid - MB: What are the semantics of MUST constraints in ephemeral datastores? - BL: Datastore merge semantics are not necessarily clear. Are leafs from the config datastore of a list entry show through given an incomplete list entry in an ephemeral datastore? Do defaults apply? What is the merged content for validation (e.g., evaluation of MUST constraints)? - JH: This looks a lot like a union filesystem. - MB: Do we need to have merge attributes, e.g. to say that a certain prefix is to be deleted. - AB: How can this be made significantly faster than NETCONF's config datastores? Attempt of a summary where we are: - ephemeral is a new datastore that overlays the configuration datastore - data is merged into the operational state (delete/merge/replace attributes control how deltas are applied) - nodes have metadata (who created it, the priority or preference) - BC: How can we keep this simple? Is it realistic to assume that operators will be able to assign meaningful priorities? - JS: Why not have a priority per datastore and if multiple applications need different priorities, use multiple ephemeral datastores. - JH: Priorities (preferences) are assigned based on the target datastore and the user sending the data - BL: What the is value of having priorities/preferences lower than the config datastore? - MB: The config datastore does not have tags to say things not configured really should not be there. - DB: I think priorities lower than the config datastore are not needed. - JH: So far, I2RS wanted to allow priorities lower than config. - BL: I think we should have an edit-soft which can fail if overlay data becomes invalid and an edit-hard that will succeed but push the error to the application injecting ephemeral state. - JS: So, what do we need to change in YANG 1.1? - MB: config true|ephemeral|false (config true means can be edited in config and ephemeral datastores, ephemeral means can only be edited in ephemeral datastores, false means only operational state) Conclusion: We do not need any changes for YANG 1.1 (hurray) but instead we need a document that introduces ephemeral datastores and clarifies what validation means with ephemeral datastores. In addition, the NETCONF WG needs to do work to define suitable protocol operations and RESTCONF needs to make sure it is prepared to support ephemeral datastores. There is also NETCONF work to be done to improve notification handling. The only YANG 1.1 homework is to make sure that the language in the YANG 1.1 specification is flexible enough to enable the introduction of ephemeral datastores. * Y09 optional keys - MB: The current solution requires to change the syntax of instance identifier. Below is an example for a key "a b": | a | b | instance identifier | |---+---+---------------------| | 1 | 1 | /foo/[a=1][b=1] | | 2 | - | /foo/[a=2][not b] | | - | 2 | /foo/[not a][b=2] | | 2 | 1 | /foo/[a=2][b=1] | Note that /foo/[a=2] gives you the two list elements (2,-) and (2,1). - JS: How does this impact NACM? - MB: NACM formally uses an xpath derived type but the description refers to instance-identifier; a 1.0 NACM implementation of course won't support the new 'not' syntax. - PH: Would having a default on a key leaf help? - AB: Not every type has a default unused value in the value space. - JS: Longer discussion about workarounds, artificial keys (surrogate keys in DB speak) vs. natural keys. - JS: The real value of this dropped for me when we realized that optional keys can not be added. - AB: What is the problem? - MB: An old client will suddenly get multiple instances for something he things is leading to a unique instance. - Proposal: It remains unclear what the risk of changing instance-identifier is. To move forward with this, it might be necessary to have an explicit discussion on the mailing list where we explain that this issue leads to a change of the instance-identifier type and people should check whether that is acceptable for their implementations and tool chains or whether this can cause serious implementation problems/costs. * Y36 associate a notification with a data node - BL: for actions, access control rules apply easily - BL: maintaining context of operations associated with data nodes - BL: multiple implementations - JS: This may have to be split into a separate issue. - MB: This is how tail-f does actions today: eth0 container interfaces { list interface { action restart { input {...} output {...} } notification ... { } } } - JS: Why do you not send an instance-identifier as the first argument? - JS: Is this really naturally falling under NACM? - AB: I see the value of having actions linked to resources. - AB: Can actions appear in groupings? - MB: Actions are heavily used by customers. - MB: This requires to define an action RPC (and perhaps a special notification) and an update of NACM detailing how NACM applies to this. Resolution: MB to draft a solution proposal, JS to split actions out of Y36 into a separate issue. * ??? unique leaf-list - AB: The issue is that there is no way to delete a particular element since there is no unique name. - AB: With xpath, you could do /foo[a=1][b-2][position() = 1] leaf-list foo 10 20 30 10 - AB: What happens if there are already 10 nodes? How does 'replace' work? 10 - BL: I am fine with replacing all leaf-list nodes. - AB: 'replace' on a leaf-list has no meaning. - MB: What about 'delete'? What about insert after 10? - MB: It is not clear how to delete the whole list. - LL: This is a problem if one for example represents an AS path as a leaf-list. - JS: We should track this as another issue in the issue list. * Y18 when expression context Not discussed since we did run out of time. * Next Steps - JS will update the issue list, moving issues that have been resolved to the EDIT state. - MB will start producing a series of I-Ds to turn the resolutions into concrete text - We will move to bi-weekly virtual interim meetings to resolve any issues left and to deal with questions that might come up during the editing phase - The next virtual interim meeting will take place on Wednesday October 1st.