Skip to main content

Minutes for NETMOD at interim-2014-netmod-11
minutes-interim-2014-netmod-11-1

Meeting Minutes Network Modeling (netmod) WG
Date and time 2014-09-17 07:00
Title Minutes for NETMOD at interim-2014-netmod-11
State Active
Other versions plain text
Last updated 2014-09-26

minutes-interim-2014-netmod-11-1
=============================================================
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:

                <rpc>
                  <action>
                    <interfaces>
                      <interface>
                        <name>eth0</name>
                        <restart>
                      </interface>
                    </interfaces>
                  </action>
                </rpc>

                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

        <foo>10</foo>
        <foo>20</foo>
        <foo>30</foo>
        <foo>10</foo>

  - AB: What happens if there are already <foo>10</foo> nodes? How
    does 'replace' work?

        <config>
          <foo operation="replace">10</foo>
        </config>

  - 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.