============================================================= NETCONF Data Modeling Language WG (netmod) IETF #90, Toronto, Canada Monday, July 21st, 2014, 09:00-11:30, Salon B Minutes Balazs Lengyel, Juergen Schoenwaelder ============================================================= WG Chairs: Thomas Nadeau Juergen Schoenwaelder WG URL: http://tools.ietf.org/wg/netmod/ Jabber: xmpp:netmod@jabber.ietf.org Agenda: 1. Administrivia (chairs) 09:00 [ 5 min] 2. YANG Data Model Encoding in JSON 09:05 [ 5 min] 3. YANG Guidelines Revision 09:10 [10 min] 4. YANG 1.1 Issues 09:20 [70 min] 5. Activities to Accelerate Development 10:30 [20 min] 6. Routing Data Model(s) 10:50 [10 min] 7. YANG Model for Access Control Lists 11:00 [ 5 min] 8. YANG Model for SYSLOG 11:05 [ 5 min] 9. YANG Model for OAM 11:10 [ 5 min] 10. YANG Model for WDM Interfaces 11:15 [ 5 min] 11. Integrating Operations in YANG Models 11:20 [ 5 min] 12. YANG Data Model for Location Information 11:25 [ 5 min] Summary: The NETMOD meeting in Toronto (Monday 09:00-11:30) was attended by about 100 people. - The JSON mapping is almost complete. A few remaining issues related to I-JSON were discussed and they should be resolved soon so that the document can go into WG last call. - Work on the YANG usage guidelines update started. It was discussed to put an issue tracker in place. This work will likely not finish before the work on YANG 1.1 is done. - Several YANG 1.1 open issues were discussed. It was agreed to continue with weekly virtual interim meetings. A number of people indicated interest in a face-to-face interim meeting to resolve some of the more challenging issues. - Several ideas to speed up the development of YANG data models were discussed (getting the right subject exports involved, usage of tools like git and github, early involvement of YANG doctors). - The core routing data model, which already was submitted to the AD, received very valuable input from routing experts that were involved in projects to write YANG data models for concrete routing protocols and from people involved in I2RS work. The document will be moved back to the working group in order to make the necessary changes. The meeting did run out of time to discuss several proposed new data models. Discussions should continue on the mailing list. It may be necessary to allocate two meeting slots in upcoming IETF meetings or to focus the meeting time more clearly on infrastructure related topics and data model related topics. Slides: http://www.ietf.org/proceedings/90/netmod.html Audio: http://www.ietf.org/audio/ietf90/ Meetecho: http://ietf90.conf.meetecho.com/index.php/Recorded_Sessions Actors: - JS = Juergen Schoenwaelder - TN = Thomas Nadeau - AB = Andy Bierman - MB = Martin Bjorklund - LL = Ladislav Lhotka - BC = Benoit Claise - KW = Kent Watsen - BL = Balazs Lengyel - LH = Lisa Huang - JH = Jeffrey Haas - KK = Kiran Koushik - JZ = Jeffrey (Zhaohui) Zhang - SL = Stephane Litkovski - KC = Kireeti Kompella Meeting Notes: * YANG Data Model Encoding in JSON LL: Is this I-D the right place to define a metadata encoding? AB: YANG defines attributes for NETCONF operations. AB: I eventually want to run NETCONF functionality without XML. LL: I know that AB and MB like to have this defined. LL: There is an issue related to namespaces that may not be properly handled. LL: Need to resolve that on the mailing list. LL: Handling of potentially 'large numbers'. LL: I-JSON recommends to encode 'large numbers' as strings. LL: I suggest that we still represent large numbers as numbers. JS: This is not just an I-JSON issue, even the JSON spec warns about this. Implementations usually do nothing else than giving you a double. MB: Follow the I-JSON recommendation, why do you not want to do that? LL: Making this a string adds burden to other software. MB: But this is true for all our types since they are string encoded. LL: You can write a custom JSON parser. MB: I think it better to be able to work with off the shelf JSON parsers. AB: Do we need a canonical format for numbers? XPATH already uses double. LH: I support Martins recommendation to follow I-JSON. LL: base64 vs base64url (the later recommended by I-JSON). LL: It seems we do not need base64url in our context. LL: I will consult with the I-JSON experts concerning this rule. Actions: - LL to start a thread on the mailing list concerning metadata - LL to confirm that we go with string encoding for 'large numbers' - LL to check with I-JSON experts concerning the base64url usage * YANG Guidelines Revision AB: This update will likely not finish before YANG 1.1 is done AB: XPATH guidelines updates, need to decide whether we can relax some of the text, working with some XPATH experts AB: Separate RFC for tree diagrams or include in guidelines update? MB: Prefer to have them defined in this document JH: Tree diagrams are often used and they need to be defined somewhere AB: Will put a definition into the guidelines document AB: Will setup an issue tracker so we can keep track of things (sometimes guideline issues come up in the YANG 1.1 discussions) Actions: - AB to work on XPATH clarifications - AB to include tree diagram definition - AB to start issue tracking for guidelines update * YANG 1.1. Issues ** Y30: allow leafref in union MB: A leafref requires that the instance exists. If a leafref is used in a union and the instance the leafref refers to ceases to exist, the type selected of the union might change as a side effect. LL: Concerns about unions as a list key, type changes like this make this even worse because they affect comparison rules. MB: For XML encoding, I do not see a big difference; with JSON the difference surely can be there in the encoding. LL: In XML, if I send a 1, the server can treat it as a number or as a string. MB: But this is a general property of unions as list keys. LL: Prefer to stick to the CLR, where was this needed? MB: The desire to use a leafref in a union came up a few times. ??: A use case is a union of a leafref and an empty string. AB: This can be considered an implementation problem. From a YANG point of view, whenever a value matches one of the types of a union, the value is valid. AB: I suggest we remove the CLR. MB: I agree. Proposal: Remove CLR. Followup on Lada's issue concerning unions as keys. ** Y31: allow require-instance in leafref JS: What is the default? MB: The default is true, it creates no backward compatibility issue. MB: We have a tailf-yang extension for this? Proposal: Allow require-instance in leafref. ** Y34: remove/deprecate/replace the 'anyxml' statement MB: The anyxml type is complicated for the JSON encoding. LL: This type is not covered by the JSON mapping specification, it is implementation specific how this is handled but an example is given for XML that is 'well behaved'. MB: The problem is that anyxml allows everything including processing instructions, mixed content, comments, but we usually only need the subset that can be expressed in YANG. Hence, have something like anydata instead of anyxml. KW: Never used anyxml before but for the zero-touch I-D now uses anyxml for configlets (and they might be defined by XSD). AB: We can't remove anyxml since this would break YANG 1.0 backward compatibility. All we can do is add anydata (without the format substatement). AB: Anydata really maps to a hierarchy of containers and leafs and it does not matter how this hierarchy has been defined. MB: The idea is to restrict anydata to XML that could be defined in YANG. Mixed content would not be allowed in anydata. KW: What about introducing anyjson and then we define a union of anyxml and anyjson. MB: If we ever do a new encoding in the future, we have to update this union again. JS: The JSON encoding is type specific. How does this work for anydata if you do not know the schema? MB: This also applies to XML encoding. LL: We may have also problems with the encoding of namespaces in JSON if the module name is not known. Proposal: Introduce a new restrictive anydata type and keep anyxml for backwards compatibility (7 in favor, 4 in favor of doing nothing, 1 in favor to just deprecate anyxml, 0 in favor to introduce anydata and to deprecate/remove anyxml). Actions: - AB to work out a concrete proposal. ** Y35 allow empty in union MB: Since a string with length zero allowed, empty should be allowed as well. LH: There is an issue if there is a default and an empty type in the union since it is unclear whether the union resolves to the default or the empty type. Proposal: Allow empty in unions unless LH has a strong argument against this. Actions: - LH to send an email to the list explaining her concerns with allowing empty in a union. ** Y41: clarification of must in NP container AB: The rules for must statements are clear: The container node must exist. MB: The goal is to make the rule similar to default handling, needs to be clarified. AB: The same situation exists for a must statement that is on a leaf with a default. Servers behave different in this case and this is a bug that needs to be solved. LL: This essentially means that NP containers will be added as default content to a document even if empty. This is how it currently works for the DSDL mapping for leafs with defaults. AB: So the proposal is to treat NP container as always exist for XPATH evaluations. MB: Yes. LL: Yes. But we need to clarify what is being used for XPATH evaluations and what is sent over the wire. Proposal: For validation purposes, NP containers always exist. ** Y42: better model for state data versus config data LL: I am not sure we can resolve this here since this is a bigger problem. MB: Difficult issue, needs more time to resolve. AB: I do not see any problem to have non-config nodes in a config tree, in particular if the state data's lifetime is bound to the config. MB: Yes. AB: The idea of editing operational state is broken. For me, i2rs is just more config. BL: My understanding is that I2RS has configuration with a limited lifetime. MB: Perhaps this is just another configuration datastore with specific properties. JH: There is terminology confusion. I2RS provides additional configuration data (e.g. a new datastore). What we want to avoid is the NETCONF commit model. MB: The big issue is how standard NETCONF configuration data interacts with information in such a new datastore. JH: One option is to have some sort of a precedence that breaks the tie, similar as route precedence. LL: Embedding state under config is problematic if the operationally used value is different then the configured value. MB: I think this depends on the data model. In some use cases, having state associated with config makes sense. And example would be counters attached to firewall rules that count how often they have been used. LL: But this binds the counters to the lifetime of the config. WH: I often create firewall rules that are temporary while being tested but eventually should become persistent config and it is a common error to miss the final 'copy to startup'. We should be able to tag config nodes to easily do partial commits of temporary (ephemeral) config to persistent config. KW: Sounds like a use case for conditional enablement. ** How to continue with the YANG 1.1. work JS: Should we schedule specific virtual interim meetings for the harder issues. In particular, I assume that I2RS people are not interested in all YANG 1.1 issues but only in those that related to I2RS work. JS: Proposal: Continue virtual interim meetings end of August. JS: Alternative: A physical interim meeting for the hard issues. MB: I prefer a physical interim meeting for conformance related issues and I2RS related issues. JS: Several people including core contributors raise their hands for a physical interim meeting. JS: One option is to hold an interim meeting mid September in the New York area. Who would be able to make it? Almost the same number of hands. BC: What went wrong with the virtual interim meetings that we need a physical interim meeting? LL: The more complicated issues are difficult to resolve in our conference calls. The YANG 1.0 experience is that the physical interim meetings helped a lot. Actions: - Chairs to organize an interim meeting in September to resolve the hard issues. - Chairs to organize virtual interim meetings to make progress on the smaller issues. * Accelerated YANG Models Standardization AB: We had design teams for decades. Getting concensus in small teams is faster than concensus in large teams. The problem often are late reviews and lack of tools to end the process. BC: Key are good YANG doctor reviews and the right people involved in writing the YANG model. I want issue trackers to better deal with attempts to reopen issues. JH: I agree this is not new. What is happening right now, however, is a change of energy now that we are getting past the bootstrapping process. * Open Source Development of YANG Modules LL: Is the github repository for starting writing collaborative MIB modules or more a repository of things almost finished? KK: The idea is that only few people have commit rights but everybody can make submissions. We are working on integrating this with Gerrit and Jenkins. LH: I see the value but IETF is an open process. KK: The goal is to support work by streamlining processes. First focus on the YANG module. Once the module is getting stable, add I-D text around it and feed into the IETF process. Github provides a collaborative environment for development. JH: The repository layout is not clear, in particular whether it is fresh or not. JH: Have you thought about tools to drive the I-D document generation out of the YANG model? KK: We are working on this right now. TN: The initial commit problem can be handled by allowing initial committer to keep commit rights and the right to add additional committers. * Routing Data Model(s) JZ: For the logical router scenario, both Juniper and Cisco think that this is not a routing instance. LL: But I prefer to leave it open to have a single NETCONF server managing all virtual router instances in say a mininet environment. JZ: The key difference here is the management entity. JH: Ignoring the naming confusion here, we are talking of containers of routing tables and you may have multiple instances of those containers. What Juniper calls a logical router is a complete instance of the routing subsystem and as such a logical router can have multiple containers of routing tables. VRFs often have the semantic that a set of routing containes is bound to certain interfaces. In the current model, how the routing instances are tied to forwarding is not clear. LL: Earlier, we had only a single instance but the model gets more complex now that we apply the model to real routers. JH: This is going to be the same headache like in SNMP where the context is selecting things. LL: Current consensus of the routing experts is to go with option #2 on slide 5, namely to rename standard-routing-instance to default-routing-instance. JH: The preference property is typically per route but it might be set on a courser granularity. The preference should always be a property of every route. Nice to have feature is to have a default for each protocol. SL: The name 'active' route may be wrong. Perhaps better use 'installed', since this is consistent with I2RS usage of 'active' (which is a different concept in I2RS). JH: The 'active' property we are looking here is a RIP property. SL: It is which route is installed in the FIB. JH: The active route is often the installed route but there are cases (e.g. in OSPF) where the active route and installed route may differ. Installed is a FIB property. LL: Please send this input to the mailing list so that we can sort out which changes are needed. JH: Bookkeeping is painful. What we are looking for is a mechanism to identify a particular routing entry. What we have right now is not precise enough, leading slow scans for routing entries, which is painful. We need to find a way to find a routing entry fast. LL: Perhaps this is not universally needed? JH: A precise ID is useful for other purposes as well, e.g. consider tagging an IPFIX record with a routing entry. JZ: ID may only be need to be unique for a specific prefix, not necessarily globally unique. JS: Instead of having the ID be a list key, consider making it a leaf that may then not be necessary to implement everywhere. KC: I suggest to keep this ID. I will get back to you on the list. Managing the IDs is not such a big problem, not having the IDs where they are needed is a problem. LL: I suggest to make IDs a feature that is optional to implement. JH: This model has broad overlap with policy-based routing, where the key is usually not destination but the combination of source and destination. For multicast, we would need something similar. JZ: Originally, we discussed two routes for the same prefix with different next hops. For multicast, things are different because the prefix may include already the combination of destination and source address. JH: Can this be taking into a grouping where the instantiations would have to have different keys (destination vs source+destination)? KC: Can we not use the same ID as in the previous slide? LL: No, RIBs have way more routes. KC: Still we could use the same ID. Why two mechanisms? LL: What if a client assigns an ID for a static route that is already in the RIB? KC: In general, having two IDs is painful. ??: Right now, not all implementations have unique IDs. LL: YANG does not have support for optional keys (yet), this would help to solve this issue. JS: Procedurally, this document is back in the WG and will have another WG last call before we try a second attempt to move it through the IESG. LL: I can post a new revision of the I-D and then we see whether everybody is happy. JH: Feedback is comming late. This module will be effected by many other protocols and hence late feedback is to be expected in this case. Actions: - LL to post a new I-D for the routing experts to review