Skip to main content

Minutes for NETMOD at IETF-90
minutes-90-netmod-1

Meeting Minutes Network Modeling (netmod) WG
Date and time 2014-07-21 13:00
Title Minutes for NETMOD at IETF-90
State Active
Other versions plain text
Last updated 2014-08-29

minutes-90-netmod-1
=============================================================
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