Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: NETMOD

RFC 8342

Network Management Datastore Architecture (NMDA)

Pages: 44
Proposed STD
Errata
Updates:  7950
Part 2 of 2 – Pages 20 to 44
First   Prev   None

Top   ToC   RFC8342 - Page 20   prevText
7.  YANG Modules

   <CODE BEGINS> file "ietf-datastores@2018-02-14.yang"

   module ietf-datastores {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
     prefix ds;

     organization
       "IETF Network Modeling (NETMOD) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>

        WG List:  <mailto:netmod@ietf.org>

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>

        Author:   Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de>

        Author:   Phil Shafer
                  <mailto:phil@juniper.net>

        Author:   Kent Watsen
                  <mailto:kwatsen@juniper.net>

        Author:   Rob Wilton
                  <rwilton@cisco.com>";

     description
       "This YANG module defines a set of identities for identifying
        datastores.

        Copyright (c) 2018 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
        (https://trustee.ietf.org/license-info).
Top   ToC   RFC8342 - Page 21
        This version of this YANG module is part of RFC 8342
        (https://www.rfc-editor.org/info/rfc8342); see the RFC itself
        for full legal notices.";

     revision 2018-02-14 {
       description
         "Initial revision.";
       reference
         "RFC 8342: Network Management Datastore Architecture (NMDA)";
     }

     /*
      * Identities
      */

     identity datastore {
       description
         "Abstract base identity for datastore identities.";
     }

     identity conventional {
       base datastore;
       description
         "Abstract base identity for conventional configuration
          datastores.";
     }

     identity running {
       base conventional;
       description
         "The running configuration datastore.";
     }

     identity candidate {
       base conventional;
       description
         "The candidate configuration datastore.";
     }

     identity startup {
       base conventional;
       description
         "The startup configuration datastore.";
     }
Top   ToC   RFC8342 - Page 22
     identity intended {
       base conventional;
       description
         "The intended configuration datastore.";
     }

     identity dynamic {
       base datastore;
       description
         "Abstract base identity for dynamic configuration datastores.";
     }

     identity operational {
       base datastore;
       description
         "The operational state datastore.";
     }

     /*
      * Type definitions
      */

     typedef datastore-ref {
       type identityref {
         base datastore;
       }
       description
         "A datastore identity reference.";
     }
   }

   <CODE ENDS>
Top   ToC   RFC8342 - Page 23
   <CODE BEGINS> file "ietf-origin@2018-02-14.yang"

   module ietf-origin {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
     prefix or;

     import ietf-yang-metadata {
       prefix md;
     }

     organization
       "IETF Network Modeling (NETMOD) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>

        WG List:  <mailto:netmod@ietf.org>

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com>

        Author:   Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de>

        Author:   Phil Shafer
                  <mailto:phil@juniper.net>

        Author:   Kent Watsen
                  <mailto:kwatsen@juniper.net>

        Author:   Rob Wilton
                  <rwilton@cisco.com>";

     description
       "This YANG module defines an 'origin' metadata annotation and a
        set of identities for the origin value.

        Copyright (c) 2018 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
        (https://trustee.ietf.org/license-info).
Top   ToC   RFC8342 - Page 24
        This version of this YANG module is part of RFC 8342
        (https://www.rfc-editor.org/info/rfc8342); see the RFC itself
        for full legal notices.";

     revision 2018-02-14 {
       description
         "Initial revision.";
       reference
         "RFC 8342: Network Management Datastore Architecture (NMDA)";
     }

     /*
      * Identities
      */

     identity origin {
       description
         "Abstract base identity for the origin annotation.";
     }

     identity intended {
       base origin;
       description
         "Denotes configuration from the intended configuration
          datastore.";
     }

     identity dynamic {
       base origin;
       description
         "Denotes configuration from a dynamic configuration
          datastore.";
     }

     identity system {
       base origin;
       description
         "Denotes configuration originated by the system itself.

          Examples of system configuration include applied configuration
          for an always-existing loopback interface, or interface
          configuration that is auto-created due to the hardware
          currently present in the device.";
     }
Top   ToC   RFC8342 - Page 25
     identity learned {
       base origin;
       description
         "Denotes configuration learned from protocol interactions with
          other devices, instead of via either the intended
          configuration datastore or any dynamic configuration
          datastore.

          Examples of protocols that provide learned configuration
          include link-layer negotiations, routing protocols, and
          DHCP.";
     }

     identity default {
       base origin;
       description
         "Denotes configuration that does not have a configured or
          learned value but has a default value in use.  Covers both
          values defined in a 'default' statement and values defined
          via an explanation in a 'description' statement.";
     }

     identity unknown {
       base origin;
       description
         "Denotes configuration for which the system cannot identify the
          origin.";
     }

     /*
      * Type definitions
      */

     typedef origin-ref {
       type identityref {
         base origin;
       }
       description
         "An origin identity reference.";
     }
Top   ToC   RFC8342 - Page 26
     /*
      * Metadata annotations
      */

     md:annotation origin {
       type origin-ref;
       description
         "The 'origin' annotation can be present on any configuration
          data node in the operational state datastore.  It specifies
          from where the node originated.  If not specified for a given
          configuration data node, then the origin is the same as the
          origin of its parent node in the data tree.  The origin for
          any top-level configuration data nodes must be specified.";
     }
   }

   <CODE ENDS>

8.  IANA Considerations

8.1.  Updates to the IETF XML Registry

   This document registers two URIs in the "IETF XML Registry"
   [RFC3688].  Following the format in [RFC3688], the following
   registrations have been made:

      URI: urn:ietf:params:xml:ns:yang:ietf-datastores
      Registrant Contact: The IESG.
      XML: N/A; the requested URI is an XML namespace.

      URI: urn:ietf:params:xml:ns:yang:ietf-origin
      Registrant Contact: The IESG.
      XML: N/A; the requested URI is an XML namespace.
Top   ToC   RFC8342 - Page 27
8.2.  Updates to the YANG Module Names Registry

   This document registers two YANG modules in the "YANG Module Names"
   registry [RFC6020].  Following the format in [RFC6020], the following
   registrations have been made:

      name:         ietf-datastores
      namespace:    urn:ietf:params:xml:ns:yang:ietf-datastores
      prefix:       ds
      reference:    RFC 8342

      name:         ietf-origin
      namespace:    urn:ietf:params:xml:ns:yang:ietf-origin
      prefix:       or
      reference:    RFC 8342

9.  Security Considerations

   This document discusses an architectural model of datastores for
   network management using NETCONF/RESTCONF and YANG.  It has no
   security impact on the Internet.

   Although this document specifies several YANG modules, these modules
   only define identities and a metadata annotation; hence, the "YANG
   module security guidelines" [YANG-SEC] do not apply.

   The origin metadata annotation exposes the origin of values in the
   applied configuration.  Origin information may provide hints that
   certain control-plane protocols are active on a device.  Since origin
   information is tied to applied configuration values, it is only
   accessible to clients that have the permissions to read the applied
   configuration values.  Security administrators should consider the
   sensitivity of origin information while defining access control
   rules.
Top   ToC   RFC8342 - Page 28
10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

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

   [RFC7952]  Lhotka, L., "Defining and Using Metadata with YANG",
              RFC 7952, DOI 10.17487/RFC7952, August 2016,
              <https://www.rfc-editor.org/info/rfc7952>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [W3C.REC-xml-20081126]
              Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0
              (Fifth Edition)", World Wide Web Consortium Recommendation
              REC-xml-20081126, November 2008,
              <https://www.w3.org/TR/2008/REC-xml-20081126>.
Top   ToC   RFC8342 - Page 29
10.2.  Informative References

   [NETMOD-Operational]
              Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF
              and YANG", Work in Progress, draft-bjorklund-netmod-
              operational-00, October 2012.

   [OpState-Enhance]
              Watsen, K., Bierman, A., Bjorklund, M., and J.
              Schoenwaelder, "Operational State Enhancements for YANG,
              NETCONF, and RESTCONF", Work in Progress, draft-kwatsen-
              netmod-opstate-02, February 2016.

   [OpState-Modeling]
              Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling
              of Operational State Data in YANG", Work in Progress,
              draft-openconfig-netmod-opstate-01, July 2015.

   [OpState-Reqs]
              Watsen, K. and T. Nadeau, "Terminology and Requirements
              for Enhanced Handling of Operational State", Work in
              Progress, draft-ietf-netmod-opstate-reqs-04, January 2016.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6244]  Shafer, P., "An Architecture for Network Management Using
              NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244,
              June 2011, <https://www.rfc-editor.org/info/rfc6244>.

   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              <https://www.rfc-editor.org/info/rfc8343>.

   [RFC8344]  Bjorklund, M., "A YANG Data Model for IP Management",
              RFC 8344, DOI 10.17487/RFC8344, March 2018,
              <https://www.rfc-editor.org/info/rfc8344>.
Top   ToC   RFC8342 - Page 30
   [With-config-state]
              Wilton, R., ""With-config-state" Capability for
              NETCONF/RESTCONF", Work in Progress, draft-wilton-netmod-
              opstate-yang-02, December 2015.

   [YANG-SEC] IETF, "YANG Security Guidelines", <https://trac.ietf.org/
              trac/ops/wiki/yang-security-guidelines>.
Top   ToC   RFC8342 - Page 31
Appendix A.  Guidelines for Defining Datastores

   The definition of a new datastore in this architecture should be
   provided in a document (e.g., an RFC) purposed for defining the
   datastore.  When it makes sense, more than one datastore may be
   defined in the same document (e.g., when the datastores are logically
   connected).  Each datastore's definition should address the points
   specified in the subsections below.

A.1.  Define Which YANG Modules Can Be Used in the Datastore

   Not all YANG modules may be used in all datastores.  Some datastores
   may constrain which data models can be used in them.  If it is
   desirable that a subset of all modules can be targeted to the
   datastore, then the documentation defining the datastore must
   indicate this.

A.2.  Define Which Subset of YANG-Modeled Data Applies

   By default, the data in a datastore is modeled by all YANG statements
   in the available YANG modules.  However, it is possible to specify
   criteria that YANG statements must satisfy in order to be present in
   a datastore.  For instance, maybe only "config true" nodes, or
   "config false" nodes that also have a specific YANG extension, are
   present in the datastore.

A.3.  Define How Data Is Actualized

   The new datastore must specify how it interacts with other
   datastores.

   For example, the diagram in Section 5 depicts dynamic configuration
   datastores feeding into <operational>.  How this interaction occurs
   has to be defined by the particular dynamic configuration datastores.
   In some cases, it may occur implicitly, as soon as the data is put
   into the dynamic configuration datastore, while in other cases an
   explicit action (e.g., an RPC) may be required to trigger the
   application of the datastore's data.

A.4.  Define Which Protocols Can Be Used

   By default, it is assumed that both the NETCONF and RESTCONF
   protocols can be used to interact with a datastore.  However, it may
   be that only a specific protocol can be used (e.g., Forwarding and
   Control Element Separation (ForCES)) or that a subset of all protocol
   operations or capabilities are available (e.g., no locking or no
   XPath-based filtering).
Top   ToC   RFC8342 - Page 32
A.5.  Define YANG Identities for the Datastore

   The datastore must be defined with a YANG identity that uses the
   "ds:datastore" identity, or one of its derived identities, as its
   base.  This identity is necessary, so that the datastore can be
   referenced in protocol operations (e.g., <get-data>).

   The datastore may also be defined with an identity that uses the
   "or:origin" identity, or one of its derived identities, as its base.
   This identity is needed if the datastore interacts with
   <operational>, so that data originating from the datastore can be
   identified as such via the "origin" metadata attribute defined in
   Section 7.

   An example of these guidelines in use is provided in Appendix B.

Appendix B.  Example of an Ephemeral Dynamic Configuration Datastore

   This section defines documentation for an example dynamic
   configuration datastore using the guidelines provided in Appendix A.
   For brevity, only a terse example is provided; it is expected that a
   standalone RFC would be written when this type of scenario is fully
   considered.

   This example defines a dynamic configuration datastore called
   "ephemeral", which is loosely modeled after the work done in the I2RS
   Working Group.

   +--------------------+----------------------------------------------+
   | Name               | Value                                        |
   +--------------------+----------------------------------------------+
   | Name               | ephemeral                                    |
   |                    |                                              |
   | YANG modules       | all (default)                                |
   |                    |                                              |
   | YANG nodes         | all "config true" data nodes                 |
   |                    |                                              |
   | How applied        | changes automatically propagated to          |
   |                    | <operational>                                |
   |                    |                                              |
   | Protocols          | NETCONF/RESTCONF (default)                   |
   |                    |                                              |
   | Defining YANG      | "example-ds-ephemeral"                       |
   | module             |                                              |
   +--------------------+----------------------------------------------+

              Properties of the Example "ephemeral" Datastore
Top   ToC   RFC8342 - Page 33
   module example-ds-ephemeral {
     yang-version 1.1;
     namespace "urn:example:ds-ephemeral";
     prefix eph;

     import ietf-datastores {
       prefix ds;
     }
     import ietf-origin {
       prefix or;
     }

     // datastore identity
     identity ds-ephemeral {
       base ds:dynamic;
       description
         "The ephemeral dynamic configuration datastore.";
     }

     // origin identity
     identity or-ephemeral {
       base or:dynamic;
       description
         "Denotes data from the ephemeral dynamic configuration
          datastore.";
     }
   }

Appendix C.  Example Data

   The use of datastores is complex, and many of the subtle effects are
   more easily presented using examples.  This section presents a series
   of example data models with some sample contents of the various
   datastores.

   The XML [W3C.REC-xml-20081126] snippets that follow are provided as
   examples only.
Top   ToC   RFC8342 - Page 34
C.1.  System Example

   In this example, the following fictional module is used:

   module example-system {
     yang-version 1.1;
     namespace urn:example:system;
     prefix sys;

     import ietf-inet-types {
       prefix inet;
     }

     container system {
       leaf hostname {
         type string;
       }

       list interface {
         key name;

         leaf name {
           type string;
         }

         container auto-negotiation {
           leaf enabled {
             type boolean;
             default true;
           }
           leaf speed {
             type uint32;
             units mbps;
             description
               "The advertised speed, in Mbps.";
           }
         }

         leaf speed {
           type uint32;
           units mbps;
           config false;
           description
             "The speed of the interface, in Mbps.";
         }
Top   ToC   RFC8342 - Page 35
         list address {
           key ip;

           leaf ip {
             type inet:ip-address;
           }
           leaf prefix-length {
             type uint8;
           }
         }
       }
     }
   }

   The operator has configured the hostname and two interfaces, so the
   contents of <intended> are:

   <system xmlns="urn:example:system">

     <hostname>foo.example.com</hostname>

     <interface>
       <name>eth0</name>
       <auto-negotiation>
         <speed>1000</speed>
       </auto-negotiation>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface>
       <name>eth1</name>
       <address>
         <ip>2001:db8::20</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

   </system>

   The system has detected that the hardware for one of the configured
   interfaces ("eth1") is not yet present, so the configuration for that
   interface is not applied.  Further, the system has received a
   hostname and an additional IP address for "eth0" over DHCP.  In
   addition to filling in the default value for the auto-negotiation
   enabled leaf, a loopback interface entry is also automatically
Top   ToC   RFC8342 - Page 36
   instantiated by the system.  All of this is reflected in
   <operational>.  Note how the "origin" metadata attribute for several
   "config true" data nodes is inherited from their parent data nodes.

   <system
       xmlns="urn:example:system"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

     <hostname or:origin="or:learned">bar.example.com</hostname>

     <interface or:origin="or:intended">
       <name>eth0</name>
       <auto-negotiation>
         <enabled or:origin="or:default">true</enabled>
         <speed>1000</speed>
       </auto-negotiation>
       <speed>100</speed>
       <address>
         <ip>2001:db8::10</ip>
         <prefix-length>64</prefix-length>
       </address>
       <address or:origin="or:learned">
         <ip>2001:db8::1:100</ip>
         <prefix-length>64</prefix-length>
       </address>
     </interface>

     <interface or:origin="or:system">
       <name>lo0</name>
       <address>
         <ip>::1</ip>
         <prefix-length>128</prefix-length>
       </address>
     </interface>

   </system>
Top   ToC   RFC8342 - Page 37
C.2.  BGP Example

   Consider the following fragment of a fictional BGP module:

       container bgp {
         leaf local-as {
           type uint32;
         }
         leaf peer-as {
           type uint32;
         }
         list peer {
           key name;
           leaf name {
             type inet:ip-address;
           }
           leaf local-as {
             type uint32;
             description
               "... Defaults to ../local-as.";
           }
           leaf peer-as {
             type uint32;
             description
               "... Defaults to ../peer-as.";
           }
           leaf local-port {
             type inet:port;
           }
           leaf remote-port {
             type inet:port;
             default 179;
           }
           leaf state {
             config false;
             type enumeration {
               enum init;
               enum established;
               enum closing;
             }
           }
         }
       }

   In this example model, both bgp/peer/local-as and bgp/peer/peer-as
   have complex hierarchical values, allowing the user to specify
   default values for all peers in a single location.
Top   ToC   RFC8342 - Page 38
   The model also follows the pattern of fully integrating state
   ("config false") nodes with configuration ("config true") nodes.
   There is no separate "bgp-state" hierarchy, with the accompanying
   repetition of containment and naming nodes.  This makes the model
   simpler and more readable.

C.2.1.  Datastores

   Each datastore represents differing views of these nodes.  <running>
   will hold the configuration provided by the operator -- for example,
   a single BGP peer.  <intended> will conceptually hold the data as
   validated, after the removal of data not intended for validation and
   after any local template mechanisms are performed.  <operational>
   will show data from <intended> as well as any "config false" nodes.

C.2.2.  Adding a Peer

   If the user configures a single BGP peer, then that peer will be
   visible in both <running> and <intended>.  It may also appear in
   <candidate> if the server supports the candidate configuration
   datastore.  Retrieving the peer will return only the user-specified
   values.

   No time delay should exist between the appearance of the peer in
   <running> and <intended>.

   In this scenario, we've added the following to <running>:

     <bgp>
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
       </peer>
     </bgp>

C.2.2.1.  <operational>

   The operational datastore will contain the fully expanded peer data,
   including "config false" nodes.  In our example, this means that the
   "state" node will appear.

   In addition, <operational> will contain the "currently in use" values
   for all nodes.  This means that local-as and peer-as will be
   populated even if they are not given values in <intended>.  The value
   of bgp/local-as will be used if bgp/peer/local-as is not provided;
   bgp/peer-as and bgp/peer/peer-as will have the same relationship.  In
Top   ToC   RFC8342 - Page 39
   the operational view, this means that every peer will have values for
   their local-as and peer-as, even if those values are not explicitly
   configured but are provided by bgp/local-as and bgp/peer-as.

   Each BGP peer has a TCP connection associated with it, using the
   values of local-port and remote-port from <intended>.  If those
   values are not supplied, the system will select values.  When the
   connection is established, <operational> will contain the current
   values for the local-port and remote-port nodes regardless of the
   origin.  If the system has chosen the values, the "origin" attribute
   will be set to "system".  Before the connection is established, one
   or both of the nodes may not appear, since the system may not yet
   have their values.

     <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
          or:origin="or:intended">
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
         <local-as or:origin="or:default">64501</local-as>
         <peer-as or:origin="or:default">64502</peer-as>
         <local-port or:origin="or:system">60794</local-port>
         <remote-port or:origin="or:default">179</remote-port>
         <state>established</state>
       </peer>
     </bgp>

C.2.3.  Removing a Peer

   Changes to configuration may take time to percolate through the
   various software components involved.  During this period, it is
   imperative to continue to give an accurate view of the working of the
   device.  <operational> will contain nodes for both the previous and
   current configuration, as closely as possible tracking the current
   operation of the device.

   Consider the scenario where a client removes a BGP peer.  When a peer
   is removed, the operational state will continue to reflect the
   existence of that peer until the peer's resources are released,
   including closing the peer's connection.  During this period, the
   current data values will continue to be visible in <operational>,
   with the "origin" attribute set to indicate the origin of the
   original data.
Top   ToC   RFC8342 - Page 40
     <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
          or:origin="or:intended">
       <local-as>64501</local-as>
       <peer-as>64502</peer-as>
       <peer>
         <name>2001:db8::2:3</name>
         <local-as or:origin="or:default">64501</local-as>
         <peer-as or:origin="or:default">64502</peer-as>
         <local-port or:origin="or:system">60794</local-port>
         <remote-port or:origin="or:default">179</remote-port>
         <state>closing</state>
       </peer>
     </bgp>

   Once resources are released and the connection is closed, the peer's
   data is removed from <operational>.

C.3.  Interface Example

   In this section, we will use this simple interface data model:

     container interfaces {
       list interface {
         key name;
         leaf name {
           type string;
         }
         leaf description {
           type string;
         }
         leaf mtu {
           type uint16;
         }
         leaf-list ip-address {
           type inet:ip-address;
         }
       }
     }
Top   ToC   RFC8342 - Page 41
C.3.1.  Pre-provisioned Interfaces

   One common issue in networking devices is the support of Field
   Replaceable Units (FRUs) that can be inserted and removed from the
   device without requiring a reboot or interfering with normal
   operation.  These FRUs are typically interface cards, and the devices
   support pre-provisioning of these interfaces.

   If a client creates an interface "et-0/0/0" but the interface does
   not physically exist at this point, then <intended> might contain the
   following:

     <interfaces>
       <interface>
         <name>et-0/0/0</name>
         <description>Test interface</description>
       </interface>
     </interfaces>

   Since the interface does not exist, this data does not appear in
   <operational>.

   When a FRU containing this interface is inserted, the system will
   detect it and process the associated configuration.  <operational>
   will contain the data from <intended>, as well as nodes added by the
   system, such as the current value of the interface's MTU.

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>et-0/0/0</name>
         <description>Test interface</description>
         <mtu or:origin="or:system">1500</mtu>
       </interface>
     </interfaces>

   If the FRU is removed, the interface data is removed from
   <operational>.
Top   ToC   RFC8342 - Page 42
C.3.2.  System-Provided Interface

   Imagine that the system provides a loopback interface (named "lo0")
   with a default IPv4 address of "127.0.0.1" and a default IPv6 address
   of "::1".  The system will only provide configuration for this
   interface if there is no data for it in <intended>.

   When no configuration for "lo0" appears in <intended>, <operational>
   will show the system-provided data:

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface or:origin="or:system">
         <name>lo0</name>
         <ip-address>127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>

   When configuration for "lo0" does appear in <intended>, <operational>
   will show that data with the origin set to "intended".  If the
   "ip-address" is not provided, then the system-provided value will
   appear as follows:

     <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                 or:origin="or:intended">
       <interface>
         <name>lo0</name>
         <description>loopback</description>
         <ip-address or:origin="or:system">127.0.0.1</ip-address>
         <ip-address>::1</ip-address>
       </interface>
     </interfaces>
Top   ToC   RFC8342 - Page 43
Acknowledgments

   This document grew out of many discussions that took place since
   2010.  Several documents ([NETMOD-Operational] [With-config-state]
   [OpState-Reqs] [OpState-Enhance] [OpState-Modeling], as well as
   [RFC6244]), touched on some of the problems of the original datastore
   model.  The following people were authors of these works in progress
   or were otherwise actively involved in the discussions that led to
   this document:

   o  Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>

   o  Andy Bierman, YumaWorks, <andy@yumaworks.com>

   o  Marcus Hines, Google, <hines@google.com>

   o  Christian Hopps, Deutsche Telekom, <chopps@chopps.org>

   o  Balazs Lengyel, Ericsson, <balazs.lengyel@ericsson.com>

   o  Ladislav Lhotka, CZ.NIC, <lhotka@nic.cz>

   o  Acee Lindem, Cisco Systems, <acee@cisco.com>

   o  Thomas Nadeau, Brocade Networks, <tnadeau@lucidvision.com>

   o  Tom Petch, Engineering Networks Ltd, <ietfc@btconnect.com>

   o  Anees Shaikh, Google, <aashaikh@google.com>

   o  Rob Shakir, Google, <robjs@google.com>

   o  Jason Sterne, Nokia, <jason.sterne@nokia.com>

   Juergen Schoenwaelder was partly funded by Flamingo, a Network of
   Excellence project (ICT-318488) supported by the European Commission
   under its Seventh Framework Programme.
Top   ToC   RFC8342 - Page 44
Authors' Addresses

   Martin Bjorklund
   Tail-f Systems

   Email: mbj@tail-f.com


   Juergen Schoenwaelder
   Jacobs University

   Email: j.schoenwaelder@jacobs-university.de


   Phil Shafer
   Juniper Networks

   Email: phil@juniper.net


   Kent Watsen
   Juniper Networks

   Email: kwatsen@juniper.net


   Robert Wilton
   Cisco Systems

   Email: rwilton@cisco.com