[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                     R. Wilton, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                            July 3, 2017
Expires: January 4, 2018


               Interface Properties for YANG Data Models
              draft-wilton-netmod-interface-properties-00

Abstract

   This document specifies a better way to restrict interface YANG
   schema nodes to only those types of interfaces that the nodes are
   applicable to.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 4, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Wilton                   Expires January 4, 2018                [Page 1]


Internet-Draft                                                 July 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Definition  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Interface Property Identities . . . . . . . . . . . . . . . .   4
   5.  Potential issues and considerations:  . . . . . . . . . . . .   4
   6.  YANG Modules  . . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     10.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Appendix A.  Examples of possible updates to iana-if-types.yang .   7
   Appendix B.  Example of interface properties usage in ietf-
                interfaces-common.yang . . . . . . . . . . . . . . .  10
   Appendix C.  Example of interface properties usage in ietf-
                interfaces-ethernet-like.yang  . . . . . . . . . . .  15
   Appendix D.  Example of interface properties usage in ietf-
                interfaces.yang  . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   This document introduces the concept of generic interface property
   identities in YANG [RFC7950] data models to solve the problem of how
   to restrict interface configuration and state schema nodes to the
   appropriate types of interfaces.  E.g., it is desirable to restrict
   MAC address configuration and state schema nodes to only those types
   of interfaces that use Ethernet framing, and hence for which MAC
   address configuration may be applicable.  This document defines a set
   of common interface property YANG identities (e.g., Ethernet-like),
   and proposes that the iana-interface-type identities in iana-if-
   type.yang are updated to also derive from the interface property
   identities (a backwards compatible change).  Interface based YANG
   schema nodes can then be made conditional on the interface property
   identities rather than being conditional on a hardcoded set of IANA
   interface types.  This approach also allows newly defined interface
   types to reuse published standard interface YANG schema nodes just by
   deriving from the appropriate interface property identities, and
   without requiring new revisions of those published standard YANG
   modules each time a new IANA interface type is defined.








Wilton                   Expires January 4, 2018                [Page 2]


Internet-Draft                                                 July 2017


2.  Terminology

   This document defines the following terms:

   o  interface property identity: A YANG identity that defines a
      particular generic interface related property that generally
      relates to multiple interface type identities defined in iana-
      interface-type.yang.  An example of such a property is
      'Ethernet-like'.

3.  Problem Definition

   The YANG language offers the "when" statement that can be used to
   make nodes conditional on some particular X-Path expression.

   In the case, of interface related configuration, the when statement
   can be used to explicitly list all the iana-interface-type identities
   that an interface's 'type' leaf may take.

   However, the current solution is not ideal for several reasons:

   o  Explicitly listing the interface types is somewhat unwieldy,
      particularly in the case that a schema node may apply to many
      interfaces.  When faced with this scenario, YANG model authors
      sometimes decide that it is better to keep the model simple and
      just allow the schema node to be used regardless of interface
      type.

   o  Explicly listing the inteface types has the further problem that
      the model cannot easily be extended to handle new interface types.
      If a new interface type is introduced then to reuse the same
      interface related schema nodes requires that all of the applicable
      model when statements must be updated to reference the new IANA
      interface type identity.

   o  The current solution does not really work for bespoke vendor
      specific interface types.  Even though the proprietrary interface
      types may be defined in the IANA interface type identity list, it
      is unlikely that it would be acceptable to update a standards
      based YANG model to reference a proprietrary interface type.
      Requiring bespoke interfaces to use separate similar configuration
      and state nodes makes the models less generic and more tedious to
      use by clients.








Wilton                   Expires January 4, 2018                [Page 3]


Internet-Draft                                                 July 2017


4.  Interface Property Identities

   This draft introduces "Interface Property Identities".  These are a
   set of YANG identities that describe properties that could be
   associated with multiple different types of interface.

   The existing IANA interface type identities are then selectively
   updated to also derive from one or more of these interface property
   identities.  The YANG module upgrade rules in [RFC7950] allow for the
   interface type identities to derive from additional identities in a
   fully backwards compatible way.

   YANG modules that define interface specific nodes can then use the
   YANG 1.1 derived-from() macro in the 'when' statement xpath
   expression to indicate that the node applies to all interfaces that
   inherit from the specified interface property.

   As new IANA interface types are defined they can derive from the
   interface property identities and hence acquire the interface
   specific YANG nodes that have been defined in existing YANG modules
   without requiring any changes beyond the device updating to use the
   latest iana-if-types YANG file.

   Similarly, vendor specific interface types can also inherit from the
   interface property identities and also acquire access to the
   appropriate interface configuration nodes.

   As required, new interface property identities can also be defined,
   again in a backwards compatible way.

5.  Potential issues and considerations:

   o  Would IANA be willing to manage the new interface property types?

   o  iana-interface-types.yang would need to be YANG 1.1.  Would this
      be an issue?

   o  Need to define a suitable set of base interface properties.

   o  Need to then apply the set of base interface properties to
      appropriate interface types.  Coordination between vendors may be
      required to get a reasonable base coverage.

6.  YANG Modules

   <CODE BEGINS> file "iana-if-property-type@2017-06-27.yang"

   module iana-if-property-type {



Wilton                   Expires January 4, 2018                [Page 4]


Internet-Draft                                                 July 2017


     namespace "urn:ietf:params:xml:ns:yang:iana-if-property-type";
     prefix ianaifp;

     organization "IANA";
     contact "";
     description
       "This YANG module defines YANG identities for IANA-registered
        interface property types.

        This YANG module is maintained by IANA.

        The latest revision of this YANG module can be obtained from
        the IANA web site.

        Requests for new values should be made to IANA via
        email (iana&iana.org).

        Copyright (c) 2017 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (http://trustee.ietf.org/license-info).

        The initial version of this YANG module is part of XXX;
        see the RFC itself for full legal notices.";
     reference
       "IANA 'interface property definitions' registry.";

     revision 2017-06-27 {
       description
         "Initial revision";
       reference
         "RFC XXX: IANA Interface Property Type YANG Module";
     }

     identity iana-if-property-type {
       description
         "Base identity from which specific interface property types are
          derived.";
     }

     identity physical {
       base iana-if-property-type;
       description



Wilton                   Expires January 4, 2018                [Page 5]


Internet-Draft                                                 July 2017


         "This property represents an interface that has a physical
          hardware representation, or is modelled as such.";
     }

     identity virtual {
       base iana-if-property-type;
       description
         "This property represents an interface that has no external
          physical hardware representation, and is used to represent
          interfaces that are created via configuration.";
     }

     identity sub-interface {
       base iana-if-property-type;
       description
         "This property represents an interface that is a child
          interface that is parented to another interface.";
     }

     identity point-to-point {
       base iana-if-property-type;
       description
         "This property represents an interface that is always
          point-to-point, i.e. the interface can only ever be connected
          to a single other interface, and hence broadcast and multicast
          packet statistics do not make sense.";
     }

     identity multicast {
       base iana-if-property-type;
       description
         "This property represents an interface that could have multiple
          end points, e.g. like an Ethernet interface.  Such an
          interface could have separate broadcast and multicast packet
          counters.";
     }

     identity ethernet-like {
       base iana-if-property-type;
       description
         "This property represents an interface that is similar in
          behaviour to an Ethernet interface, and uses Ethernet
          framing.";
     }
   }

   <CODE ENDS>




Wilton                   Expires January 4, 2018                [Page 6]


Internet-Draft                                                 July 2017


7.  IANA Considerations

   This draft proposes that IANA also manage a new registry of
   "interface properties" alongside the existing "interface type"
   registry, and to

    extend the "interface type" registry to also derive from interface
    properties identities.

8.  Security Considerations

   This document discusses an approach how to structure interface
   related YANG schema.  It has no security impact on the Internet.

9.  Acknowledgments

   This document arose from discussions with Martin Bjorklund, Ladislav
   Lhotka, and Vladimir Vassilev on the Netmod WG alias.

10.  References

10.1.  Normative References

   [RFC7224]  Bjorklund, M., "IANA Interface Type YANG Module",
              RFC 7224, DOI 10.17487/RFC7224, May 2014,
              <http://www.rfc-editor.org/info/rfc7224>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <http://www.rfc-editor.org/info/rfc7950>.

10.2.  Informative References

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
              <http://www.rfc-editor.org/info/rfc7223>.

Appendix A.  Examples of possible updates to iana-if-types.yang

   The example-iana-if-type.yang module illustrates the type of updates
   that would be made to iana-if-types.yang to make use of interface
   properties.

   <CODE BEGINS> file "example-iana-if-type@2017-06-27.yang"

   module example-iana-if-type {
     yang-version "1.1";
     namespace "urn:ietf:params:xml:ns:yang:example-iana-if-type";



Wilton                   Expires January 4, 2018                [Page 7]


Internet-Draft                                                 July 2017


     prefix ianaift;

     import ietf-interfaces {
       prefix if;
     }

     import iana-if-property-type {
       prefix ianaifp;
     }

     // Full description, etc elided for clarity.
     organization "IANA";
     contact "";
     description
       "This example module illustrates how iana-if-type.yang could
        be extended to use interface properties.";
     reference
       "IANA 'ifType definitions' registry.
        <http://www.iana.org/assignments/smi-numbers>";

     revision 2017-06-27 {
       description
         "Initial example of how IANA if type could be extended";
       reference
         "Taken from draft-rwilton-netmod-interface-properties-00";
     }

     // Previous revision statements elided for clarity.

     identity iana-interface-type {
       base if:interface-type;
       description
         "This identity is used as a base for all interface types
          defined in the 'ifType definitions' registry.";
     }

     // Most identies elided for clarity, some are retained to
     // illustrate how the interface properties are defined.
     identity other {
       base iana-interface-type;
       description
         "None of the following";
     }

     identity ethernetCsmacd {
       base iana-interface-type;
       base ianaifp:physical;
       base ianaifp:multicast;



Wilton                   Expires January 4, 2018                [Page 8]


Internet-Draft                                                 July 2017


       base ianaifp:ethernet-like;
       description
         "For all Ethernet-like interfaces, regardless of speed,
          as per RFC 3635.";
       reference
         "RFC 3635 - Definitions of Managed Objects for the
                     Ethernet-like Interface Types";
     }

     identity ieee8023adLag {
       base iana-interface-type;
       base ianaifp:virtual;
       base ianaifp:multicast;
       base ianaifp:ethernet-like;
       description
         "IEEE 802.3ad Link Aggregate.";
     }

     identity atm {
       base iana-interface-type;
       base ianaifp:physical;
       base ianaifp:multicast;
       description
         "ATM cells.";
     }

     identity atmSubInterface {
       base iana-interface-type;
       base ianaifp:virtual;
       base ianaifp:sub-interface;
       base ianaifp:multicast;
       description
         "ATM Sub Interface.";
     }

     identity l2vlan {
       base iana-interface-type;
       base ianaifp:virtual;
       base ianaifp:sub-interface;
       base ianaifp:multicast;
       description
         "Layer 2 Virtual LAN using 802.1Q.";
     }

     identity pos {
       base iana-interface-type;
       base ianaifp:point-to-point;
       description



Wilton                   Expires January 4, 2018                [Page 9]


Internet-Draft                                                 July 2017


         "Packet over SONET/SDH Interface.";
     }

     identity irb {
       base iana-interface-type;
       base ianaifp:virtual;
       base ianaifp:multicast;
       base ianaifp:ethernet-like;

       description
         "Integrated Routing and Bridging interface, also known as an
          SVI or BVI interface.

          Note, not currently defined in if-type.yang";
     }
   }

   <CODE ENDS>

Appendix B.  Example of interface properties usage in ietf-interfaces-
             common.yang

   The ietf-interfaces-common module defines various interface
   configuration nodes that are applicable to different types of
   interfaces and hence would benefit from interface properties.

   <CODE BEGINS> file "example-ietf-interfaces-common@2017-06-27.yang"

   module example-ietf-interfaces-common {
     yang-version 1.1;

     namespace
       "urn:ietf:params:xml:ns:yang:example-ietf-interfaces-common";

     prefix if-cmn;

     import ietf-interfaces {
       prefix if;
     }

     import iana-if-type {
       prefix ianaift;
     }

     import iana-if-property-type {
       prefix ianaifp;
     }




Wilton                   Expires January 4, 2018               [Page 10]


Internet-Draft                                                 July 2017


     organization
       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

     contact
       "WG Web:   <http://tools.ietf.org/wg/netmod/>
        WG List:  <mailto:netmod@ietf.org>

        WG Chair: Lou Berger
                  <mailto:lberger@labn.net>

        WG Chair: Kent Watsen
                  <mailto:kwatsen@juniper.net>

        Editor:   Robert Wilton
                  <mailto:rwilton@cisco.com>";

     description
       "Example of using when statements with interface properties";

     revision 2017-06-27 {
       description
         "Examples of using when statements with interface properties";

       reference "Internet draft: draft-ietf-netmod-intf-ext-yang-04";
     }

     feature bandwidth {
       description "<description elided>";
       reference "Section 3.1 Bandwidth";
     }

     feature carrier-delay {
       description "<description elided>";
       reference "Section 3.2 Carrier Delay";
     }

     feature dampening {
       description "<description elided>";
       reference "Section 3.3 Dampening";
     }

     feature loopback {
       description "<description elided>";
       reference "Section 3.5 Loopback";
     }

     feature configurable-l2-mtu {
       description "<description elided>";



Wilton                   Expires January 4, 2018               [Page 11]


Internet-Draft                                                 July 2017


       reference "Section 3.6 MTU";
     }

     feature sub-interfaces {
       description
         "This feature indicates that the device supports the
          instantiation of sub-interfaces.  Sub-interfaces are defined
          as logical child interfaces that allow features and forwarding
          decisions to be applied to a subset of the traffic processed
          on the specified parent interface.";
       reference "Section 3.7 Sub-interface";
     }

     feature forwarding-mode {
       description "<description elided>";
       reference "Section 3.8 Forwarding Mode";
     }

     /*
      * Define common identities to help allow interface types to be
      * assigned properties.
      */

     identity loopback {
       description "Base identity for interface loopback options";
     }
     identity loopback-internal {
       base loopback;
       description "<description elided>";
     }
     identity loopback-line {
       base loopback;
       description "<description elided>";
     }
     identity loopback-connector {
       base loopback;
       description "<description elided>";
     }


     /*
      * Augments the IETF interfaces model with a leaf to explicitly
      * specify the bandwidth available on an interface.
      */
     augment "/if:interfaces/if:interface" {
       description
         "Augments the IETF interface model with optional common
          interface level commands that are not formally covered by any



Wilton                   Expires January 4, 2018               [Page 12]


Internet-Draft                                                 July 2017


          specific standard";

       // Various features/nodes elided.


       /*
        * Various types of interfaces support a configurable layer 2
        * encapsulation, any that are supported by YANG should be
        * listed here.
        *
        * Different encapsulations can hook into the common encaps-type
        * choice statement.
        */
       container encapsulation {
         when
           "derived-from-or-self(../if:type, 'ianaifp:ethernet-like') or
            derived-from-or-self(../if:type, 'ianaifp:sub-interface')" {

           description
             "All interface types that can have a configurable L2
              encapsulation";
           /*
            * TODO - Should we introduce an abstract type to make this
            *        extensible to new interface types, or vendor
            *        specific interface types?
            */
         }

         description
           "Holds the OSI layer 2 encapsulation associated with an
            interface";
         choice encaps-type {
           description "Extensible choice of L2 encapsulations";
         }
       }

        /*
         * Various types of interfaces support loopback configuration,
         * any that are supported by YANG should be listed here.
         */
       leaf loopback {
         when "derived-from(if:type, 'ianaifp:physical')" {
           description
             "Applies to all interfaces that derive from the physical
              interface property.";
         }

         if-feature "loopback";



Wilton                   Expires January 4, 2018               [Page 13]


Internet-Draft                                                 July 2017


         type identityref {
           base loopback;
         }
         description "Enables traffic loopback.";
       }

       /*
        * Many types of interfaces support a configurable layer 2 MTU.
        */
       leaf l2-mtu {
         if-feature "configurable-l2-mtu";
         type uint16 {
           range "64 .. 65535";
         }
         description
           "The maximum size of layer 2 frames that may be transmitted
            or received on the interface (excluding any FCS overhead).
            In the case of Ethernet interfaces it also excludes the
            4-8 byte overhead of any known (i.e. explicitly matched by
            a child sub-interface) 801.1Q VLAN tags.";
       }
     }

     /*
      * Add generic support for sub-interfaces.
      *
      * This should be extended to cover all interface types that are
      * child interfaces of other interfaces.
      */
     augment "/if:interfaces/if:interface" {
       when "derived-from(if:type, 'ianaifp:sub-interface')" {
         description
           "Applies to all interfaces that derive from the Ethernet-like
            interface property.";
       }

       if-feature "sub-interfaces";

       description
         "Add a parent interface field to interfaces that model
          sub-interfaces";
       leaf parent-interface {

         type if:interface-ref;

         mandatory true;
         description
           "This is the reference to the parent interface of this



Wilton                   Expires January 4, 2018               [Page 14]


Internet-Draft                                                 July 2017


            sub-interface.";
       }
     }
   }

   <CODE ENDS>

Appendix C.  Example of interface properties usage in ietf-interfaces-
             ethernet-like.yang

   The ietf-interfaces-ethernet-like module defines various interface
   configuration nodes that are applicable to any interfaces that have
   "Ethernet-like" semantics, and hence would benefit from interface
   properties.

   <CODE BEGINS> file "example-ietf-interfaces-ethernet-
   like@2017-06-27.yang"

  module example-ietf-interfaces-ethernet-like {
    yang-version 1.1;

    namespace
      "urn:ietf:params:xml:ns:yang:" +
      "example-ietf-interfaces-ethernet-like";

    prefix ethlike;

    import ietf-interfaces {
      prefix if;
    }

    import ietf-yang-types {
      prefix yang;
    }

    import iana-if-property-type {
      prefix ianaifp;
    }

    organization
      "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

    contact
      "WG Web:   <http://tools.ietf.org/wg/netmod/>
       WG List:  <mailto:netmod@ietf.org>

       WG Chair: Lou Berger
                 <mailto:lberger@labn.net>



Wilton                   Expires January 4, 2018               [Page 15]


Internet-Draft                                                 July 2017


       WG Chair: Kent Watsen
                 <mailto:kwatsen@juniper.net>

       Editor:   Robert Wilton
                 <mailto:rwilton@cisco.com>";

    description
      "Example for when statements using interface properties.";

    revision 2017-06-27 {
      description
        "Examples of using when statements with interface properties";

      reference "Internet draft: draft-ietf-netmod-intf-ext-yang-04";
    }

    /*
     * Configuration parameters for Ethernet-like interfaces.
     */
    augment "/if:interfaces/if:interface" {
      when "derived-from(if:type, 'ianaifp:ethernet-like')" {
        description
          "Applies to all interfaces that derive from the Ethernet-like
           interface property.";
      }
      description
        "Augment the interface model with configuration parameters for
         all Ethernet-like interfaces";

      container ethernet-like {
        description "Contains configuration parameters for interfaces
                     that use Ethernet framing and expose an Ethernet
                     MAC layer.";
        leaf mac-address {
          type yang:mac-address;
          description
            "The configured MAC address of the interface.";
        }
      }
    }

    /*
     * Operational state for Ethernet-like interfaces.
     */
    augment "/if:interfaces-state/if:interface" {
      when "derived-from(if:type, 'ianaifp:ethernet-like')" {
        description
          "Applies to all interfaces that derive from the Ethernet-like



Wilton                   Expires January 4, 2018               [Page 16]


Internet-Draft                                                 July 2017


           interface property.";
      }
      description
        "Augments the interface model with operational state parameters
         for all Ethernet-like interfaces.";
      container ethernet-like {
        description
          "Contains operational state parameters for interfaces that use
           Ethernet framing and expose an Ethernet MAC layer.";
        leaf mac-address {
          type yang:mac-address;
          description
            "The operational MAC address of the interface, if
             applicable";
        }

        leaf bia-mac-address {
          type yang:mac-address;
          description
            "The 'burnt-in' MAC address.  I.e the default MAC address
             assigned to the interface if none is explicitly
             configured.";
        }

        container statistics {
          description
            "Packet statistics that apply to all Ethernet-like
             interfaces";
          leaf in-drop-unknown-dest-mac-pkts {
            type yang:counter64;
            units frames;
            description "<long description elided>";
          }
        }
      }
    }
  }

   <CODE ENDS>

Appendix D.  Example of interface properties usage in ietf-
             interfaces.yang

   Here is an example of how the ietf-interfaces.yang module could have
   used interface properties to restrict multicast packet statistics to
   only those interfaces that support it.

   <CODE BEGINS> file "example-ietf-interfaces@2017-06-27.yang"



Wilton                   Expires January 4, 2018               [Page 17]


Internet-Draft                                                 July 2017


   module example-ietf-interfaces {
     yang-version 1.1;

     namespace "urn:ietf:params:xml:ns:yang:example-ietf-interfaces";

     prefix if;
     import ietf-yang-types {
       prefix yang;
     }

     import "iana-if-property-type" {
       prefix ianaifp;
     }

     organization
       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
     contact "<elided>";
     description
       "Example of when statements for refining interface statistics";

     revision 2017-06-27 {
       description
         "Example of how some interface statistics could make use of
          interface properties";
       reference
         "RFC 7223: A YANG Data Model for Interface Management";
     }
     /*
      * Typedefs
      */
     // interface-ref typedef elided.
     typedef interface-state-ref {
       type leafref {
         path "/if:interfaces-state/if:interface/if:name";
       }
       description
         "This type is used by data models that need to reference
          the operationally present interfaces.";
     }
     /*
      * Identities
      */
     identity interface-type {
       description
         "Base identity from which specific interface types are
          derived.";
     }




Wilton                   Expires January 4, 2018               [Page 18]


Internet-Draft                                                 July 2017


     // Features elided.
     // Configuration tree elided.

     /*
      * Operational state data nodes
      */
     container interfaces-state {
       config false;
       description
         "Data nodes for the operational state of interfaces.";
       list interface {
         key "name";
         description
           "The list of interfaces on the device.
            System-controlled interfaces created by the system are
            always present in this list, whether they are configured or
            not.";
         leaf name {
           type string;
           description
             "The name of the interface.
              A server implementation MAY map this leaf to the ifName
              MIB object.  Such an implementation needs to use some
              mechanism to handle the differences in size and characters
              allowed between this leaf and ifName.  The definition of
              such a mechanism is outside the scope of this document.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifName";
         }
         leaf type {
           type identityref {
             base interface-type;
           }
           mandatory true;
           description
             "The type of the interface.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifType";
         }

         // Various leaves elided.

         container statistics {
           description
             "A collection of interface-related statistics objects.";
           leaf discontinuity-time {
             type yang:date-and-time;
             mandatory true;



Wilton                   Expires January 4, 2018               [Page 19]


Internet-Draft                                                 July 2017


             description "<description elided>";
           }
           leaf in-octets {
             type yang:counter64;
             description "<description elided>";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCInOctets";
           }
           leaf in-unicast-pkts {
             type yang:counter64;
             description
               "The number of packets, delivered by this sub-layer to a
                higher (sub-)layer, that were not addressed to a
                multicast or broadcast address at this sub-layer.
                Discontinuities in the value of this counter can occur
                at re-initialization of the management system, and at
                other times as indicated by the value of
                'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts";
           }
           leaf in-broadcast-pkts {
             when "derived-from(if:type, 'ianaifp:multicast')" {
               description
                 "Applies to interfaces that inherit the multicast
                  interface property.";
             }

             type yang:counter64;
             description
               "The number of packets, delivered by this sub-layer to a
                higher (sub-)layer, that were addressed to a broadcast
                address at this sub-layer.
                Discontinuities in the value of this counter can occur
                at re-initialization of the management system, and at
                other times as indicated by the value of
                'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCInBroadcastPkts";
           }
           leaf in-multicast-pkts {
             when "derived-from(if:type, 'ianaifp:multicast')" {
               description
                 "Applies to interfaces that inherit the multicast
                  interface property.";
             }




Wilton                   Expires January 4, 2018               [Page 20]


Internet-Draft                                                 July 2017


             type yang:counter64;
             description
               "The number of packets, delivered by this sub-layer to a
                higher (sub-)layer, that were addressed to a multicast
                address at this sub-layer.  For a MAC-layer protocol,
                this includes both Group and Functional addresses.
                Discontinuities in the value of this counter can occur
                at re-initialization of the management system, and at
                other times as indicated by the value of
                'discontinuity-time'.";
             reference
               "RFC 2863: The Interfaces Group MIB -
                          ifHCInMulticastPkts";
           }
           // Remaining counters elided.
         }
       }
     }
   }

   <CODE ENDS>

Author's Address

   Robert Wilton (editor)
   Cisco Systems

   Email: rwilton@cisco.com























Wilton                   Expires January 4, 2018               [Page 21]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/