draft-clemm-i2rs-yang-network-topo.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes"?>
<rfc category="exp" docName="draft-clemm-i2rs-yang-network-topo-01.txt" ipr="pre5378Trust200902">
    <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
    <?rfc toc="yes" ?>
    <?rfc compact="yes" ?>
    <?rfc symrefs="yes" ?>
    <?rfc sortrefs="yes"?>
    <?rfc iprnotified="no" ?>
    <?rfc strict="yes" ?>
    <front>
      <title abbrev="draft-clemm-i2rs-yang-network-topo-01.txt">A Data Model for Network Topologies</title>

      <author fullname="Alexander Clemm" initials="A." surname="Clemm">
        <organization>Cisco</organization>
        <address>
          <email>alex@cisco.com</email>
        </address>
      </author>
      <author fullname="Jan Medved" initials="J." surname="Medved">
        <organization>Cisco</organization>
        <address>
          <email>jmedved@cisco.com</email>
        </address>
      </author>
      <author fullname="Tony Tkacik" initials="T." surname="Tkacik">
        <organization>Cisco</organization>
        <address>
          <email>ttkacik@cisco.com</email>
        </address>
      </author>
      <author fullname="Robert Varga" initials="R." surname="Varga">
        <organization>Pantheon Technologies SRO</organization>
        <address>
          <email>robert.varga@pantheon.sk</email>
        </address>
      </author>
      <author fullname="Nitin Bahadur" initials="N." surname="Bahadur">
		<organization>Bracket Computing</organization>
			<address>
				<email>nitin_bahadur@yahoo.com</email>
			</address>
		</author>
      <author fullname="Hariharan Ananthakrishnan" initials="H." surname="Ananthakrishnan">
			<organization>Packet Design</organization>
			<address>
				<email>hanantha@juniper.net</email>
			</address>
		</author>
      <date day="8" month="October" year="2014"/>
      <abstract>
        <t>
          This document defines a YANG data model for network and service
          topologies.
        </t>
      </abstract>
    </front>
    <middle>
      <section title="Introduction">
        <t>
          This document introduces an abstract (basic) topology YANG <xref
          target="RFC6020"/> <xref target="RFC6021"/> model, which can be
          augmented to cover many different network topologies.  Applications
          can operate on any topology at a generic level where specifics of
          particular topology types are not required, or at a topology-specific
          level when those specifics come into play. Examples of specific
          topology types include Layer 2 topology, Layer 3 topologies such as
          Unicast IGP, IS-IS <xref target="RFC1195"/> and OSPF <xref
          target="RFC2328"/>, traffic engineering (TE) data <xref
	  target="RFC3209"/>, or any of the variety of transport and service
          topologies. Information specific to such a particular type of network
          topology would be captured in a separate, technology-specific model.
          The basic data model introduced in this document is generic in nature
          and can be applied to many network topologies.
        </t>
        <t>
          This document introduces the network-topology YANG module, which
          defines a generic topology model at its most general level of
          abstraction. The module defines a topology graph and components from
          which it is composed: nodes, edges and termination points. Nodes
          represent graph vertices and links represent graph edges. Nodes
          contain termination points that anchor the links. A network can
          contain multiple topologies, for example topologies at different
          layers and overlay topologies. The model therefore allows to capture
          relationships between topologies, as well as dependencies between
          nodes and termination points across topologies. An example of a
          topology stack is shown in the following figure.
		</t>

        <figure align="center">
          <artwork align="left">
       +---------------------------------------+
      /            _[X1]_          "Service"  /
     /           _/  :   \_                  /
    /          _/     :    \_               /
   /         _/        :     \_            /
  /         /           :      \          /
 /       [X1]__________________[X3]      /
+---------:--------------:------:-------+
           :              :     :
       +----:--------------:----:--------------+
      /      :              :   :        "L3" /
     /        :              :  :            /
    /         :               : :           /
   /         [Y1]_____________[Y2]         /
  /           *               * *         /
 /            *              *  *        /
+--------------*-------------*--*-------+
                *           *   *
       +--------*----------*----*--------------+
      /     [Z1]_______________[Z1] "Optical" /
     /         \_         *   _/             /
    /            \_      *  _/              / 
   /               \_   * _/               /
  /                  \ * /                /
 /                    [Z]                /
+---------------------------------------+
          </artwork>
        </figure>

        <t>
          The figure shows three topology levels. At top, the "Service" topology
          shows relationships between service entities, such as service
          functions in a service chain. The "L3" topology shows network elements
          at Layer 3 (IP) and the "Optical" topology shows network elements at
          Layer 1. Service functions in the "Service" topology are mapped onto
          network elements in the "L3" topology, which in turn are mapped onto
          network elements in the "Optical" topology. The figure shows two
          Service Functions - X1 and X2 - mapping onto a single L3 network
          element; this could happen, for example, if two service functions
          reside in the same VM (or server) and share the same set of network
          interfaces. The figure shows a single "L3" network element mapped onto
          multiple "Optical" network elements. This could happen, for example,
          if a single IP router attaches to multiple ROADMs in the optical
          domain.
        </t>

        <t>
		  There are multiple applications for such a data model.  For example,
		  within the context of I2RS, nodes within the network can use the data
		  model to capture their understanding of the overall network topology
		  and expose it to a network controller.  A network controller can then
		  use the instantiated topology data to compare and reconcile its own
		  view of the network topology with that of the network elements that it
		  controls.  Alternatively, nodes within the network could propagate
		  this understanding to compare and reconcile this understanding either
		  among themselves or with help of a controller.  Beyond the network
		  element and the immediate context of I2RS itself, a network controller
		  might even use the data model to represent its view of the topology
		  that it controls and expose it to applications north of itself.
		  Further use cases that the data model can be applied to are described
		  in <xref target="topology-use-cases"/>.
        </t>
      </section>
      <section title="Definitions and Acronyms">
        <t>
          Datastore: A conceptual store of instantiated management information,
          with individual data items represented by data nodes which are
          arranged in hierarchical manner.
        </t>
        <t>
          Data subtree: An instantiated data node and the data nodes that are
          hierarchically contained within it.
        </t>
        <t>
          HTTP: Hyper-Text Transfer Protocol
        </t>
        <t>
		  IGP: Interior Gateway Protocol
		</t>
		<t>
          IS-IS: Intermediate System to Intermediate System protocol 
		</t>
        <t>
          NETCONF: Network Configuration Protocol
        </t>
		<t>
		  OSPF: Open Shortest Path First, a link state routing protocol
		</t>
        <t>
          URI: Uniform Resource Identifier
        </t>
        <t>
          ReST: Representational State Transfer, a style of stateless interface
          and protocol that is generally carried over HTTP
        </t>
        <t>
          YANG: A data definition language for NETCONF
        </t>
      </section>
      <section title="Model Structure">
        <t>
          The structure of the network topology data model is depicted in the
          following diagram. Brackets enclose list keys, "rw" means
          configuration data, "ro" means operational state data, and "?"
          designates optional nodes.
        </t>
        <figure align="center">
          <artwork align="left">
module: network-topology
   +--rw network-topology
      +--rw topology* [topology-id]
         +--rw topology-id            topology-id
         +--ro server-provided?       boolean
         +--rw topology-types
         +--rw supporting-topology* [topo-ref]
         |  +--rw topo-ref    leafref
         +--rw node* [node-id]
         |  +--rw node-id              node-id
         |  +--rw termination-point* [tp-id]
         |  |  +--rw tp-id                           tp-id
         |  |  +--rw supporting-termination-point* [topo-ref node-ref tp-ref]
         |  |     +--rw topo-ref    leafref
         |  |     +--rw node-ref    leafref
         |  |     +--rw tp-ref      leafref
         |  +--rw supporting-node* [topo-ref node-ref]
         |     +--rw topo-ref    leafref
         |     +--rw node-ref    leafref
         +--rw link* [link-id]
            +--rw link-id            link-id
            +--rw source
            |  +--rw source-node    leafref
            |  +--rw source-tp?     leafref
            +--rw destination
            |  +--rw dest-node    leafref
            |  +--rw dest-tp?     leafref
            +--rw supporting-link* [topo-ref link-ref]
               +--rw topo-ref    leafref
               +--rw link-ref    leafref
          </artwork>
        </figure>
        <section title="Main building blocks">
		  <t>
            A network can contain multiple topologies.  Each topology is
            captured in its own list entry, distinguished via a topology-id.
            This is captured by list "topology", contained underneath the root
            container for this module, "network-topology".
		  </t>
		  <t>
            A topology has a certain type, such as L2, L3, OSPF or IS-IS.  A
            topology can even have multiple types simultaneously.  The type, or
            types, are captured underneath the container "topology-types".  This
            container serves as container for data nodes that represent specific
            topology types.  In this module it serves merely as an augmentation
            target; topology-specific modules will later introduce new data
            nodes to represent new topology types below this target, i.e. insert
            them below "topology-types" by ways of yang augmentation.
		  </t>
		  <t>
            Topology types SHOULD always be represented using presence
            containers, not leafs of empty type.  This allows to represent
            hierarchies of topology subtypes within the instance information.
            For example, an instance of an OSPF topology (which, at the same
            time, is a layer 3 unicast IGP topology) would contain underneath
            "topology-types" another container "l3-unicast-igp-topology", which
            in turn would contain a container "ospf-topology".
		  </t>
		  <t>
            A topology can in turn be part of a hierarchy of topologies,
            building on top of other topologies.  Any such topologies are
            captured in the list "underlay-topology".
		  </t>
		  <t>
            Furthermore, a topology contains nodes and links, each captured in
            their own list.
		  </t>
		  <t>
            A node has a node-id that distinguishes the node from other nodes in
            the list.  In addition, a node has a list of termination points that
            are used to terminate links.  An example of a termination point
            might be a physical or logical port or, more generally, an
            interface.  Also, a node can map onto one or more other nodes in an
            underlay topology.  This is captured in the list "supporting-node".
		  </t>
		  <t>
            A link is identified by a link-id that uniquely identifies the link
            within a given topology.  Links are point-to-point and
            unidirectional.  Accordingly, a link contains a source and a
            destination. Both source and destination reference a corresponding
            node, as well as a termination point on that node. Similar to a
            node, a link can map onto one or more links in an underlay topology.
            This is captured in the list "supporting-link".
		  </t>
        </section>
        <section title="Discussion and selected design decisions">
		  <t>
            Rather than maintaining lists in separate containers, the model is
            kept relatively flat in terms of its containment structure.
            Therefore, path specifiers used to refer to specific nodes, be it in
            management operations or in specifications of constraints, can
            remain relatively compact.  Of course, this means there is no
            separate structure in instance information that separates elements
            of different lists from one another.  Such structure is semantically
            not required, although it might enhance human readability in some
            cases.
		  </t>
		  <t>
            To minimize assumptions of what a topology might actually represent,
            mappings between topologies, nodes, links, and termination points
            are kept strictly generic.  For example, no assumptions are made
            whether a termination point actually refers to an interface, or
            whether a node refers to a specific "system" or device; the model at
            this generic level makes no provisions for that.  Any greater
            specifics about mappings between upper and lower layers can be
            captured in augmenting modules.  For example, if a termination point
            maps to an interface, an augmenting module can augment the
            termination point with a leaf that references the corresponding
            interface <xref target="if-config"/>.  If a node maps to a
            particular device or network element, an augmenting module can
            augment node with a leaf that references the network element.
		  </t>
		  <t>
            The model makes use of groupings, instead of simply defining data
            nodes "in-line".  This allows to more easily include the
            corresponding data nodes in notifications, which then do not need to
            respecify each data node that is to be included.  The tradeoff for
            this is that it makes the specification of constraints more complex,
            because constraints involving data nodes outside the grouping need
            to be specified in conjunction with a "uses" statement where the
            grouping is applied.  This also means that constraints and
            XPath-statements need to specified in such a way that the navigate
            "down" first and select entire sets of nodes, as opposed to being
            able to simply specify them against individual data nodes.
		  </t>
		  <t>
            The topology model includes links that are point-to-point and
            unidirectional.  It does not directly support multipoint and
            bidirectional links.  While this may appear as a limitation, it does
            keep the model simple, generic, and allows it to very easily be
            subjected applications that make use of graph algorithms.
            Bi-directional connections can be represented through pairs of
            unidirectional links. Multipoint networks can be represented through
            pseudo-nodes (similar to IS-IS, for example).  By introducing
            hierarchies of nodes, with nodes at one level mapping onto a set of
            other nodes at another level, and the introducing new links for
            nodes at that level, topologies with connections representing
            non-point-to-point communication patterns can be represented.
		  </t>
		  <t>
            Links are terminated by a single termination point, not sets of
            termination points.  Connections involving multihoming or link
            aggregation schemes need to be represented using multiple
            point-to-point links, then defining a link at a higher layer that is
            supported by those individual links.
		  </t>
		  <t>
            In a hierarchy of topologies, there are nodes mapping to nodes,
            links mapping to links, and termination points mapping to
            termination points. Some of this information is redundant.
            Specifically, with the link-to-links mapping known, and the
            termination points of each link known, maintaining separate
            termination point mapping information is not needed but can be
            derived via transitive closure.  The model does provide for the
            option to include this information explicitly, but does not allow
            for it to be configured to avoid the potential to introduce (and
            having to validate) corresponding integrity issues.
		  </t>
          <t>
            A topology's topology types are represented using a container which
            contains a data node for each of its topology types.  A topology can
            encompass several types of topology simultaneously, hence a
            container is used instead of a case construct, with each topology
            type in turn represented by a dedicated presence container itself.
            The reason for not simply using an empty leaf, or even simpler, do
            away even with the topology container and just use a leaf-list of
            topology-type instead, is to be able to represent "class
            hierarchies" of topology types, with one topology type refining the
            other.  Topology-type specific containers are to be defined in the
            topology-specific modules, augmenting the topology-types container.
          </t>
		</section>
		<section title="Open issues and items for further discussion">
          <t>
			YANG requires data needs to be designated as either configuration or
			operational data, but not both, yet it is important to have all
			topology information, including vertical cross-topology
			dependencies, captured in one coherent model.  In most cases
			topology information is discovered about a network; the topology is
			considered a property of the network that is reflected in the model.
			That said, it is conceivable that certain types of topology need to
			also be configurable by an application.
          </t>
          <t>
			There are several alternatives in which this can be addressed. The
			alternative chosen in this draft does not restrict topology
			information as read-only, but includes a flag that indicates for
			each topology whether it should be considered as read-only or
			configurable by applications.
          </t>
          <t>
			An alternative would be to designate topology list elements as read
			only.  The read-only topology list includes each topology; it is the
			complete reference. In parallel a second topology list is
			introduced.  This list serves the purpose of being able to configure
			topologies which are then mirrored in the read-only list.  The
			configurable topology list adheres to the same structure and uses
			the same groupings as its read-only counterpart. As most data is
			defined in those groupings, the amount of additional definitions
			required will be limited.  A configurable topology will thus be
			represented twice: once in the read-only list of all topologies, a
			second time in a configuration sandbox.
          </t>
		</section>
      </section>
    <section title="Network Topology YANG module">
	<t>
      <figure>
        <artwork>
&lt;CODE BEGINS&gt; file "network-topology.yang"
module network-topology {
  yang-version 1;
  namespace "urn:TBD:params:xml:ns:yang:network-topology";
  prefix nt;

  import ietf-inet-types {
    prefix inet;
  }

  organization "TBD";
  contact
    "WILL-BE-DEFINED-LATER";
  description
    "This module defines a model for the topology of a network.
     Key design decisions are as follows:
     A topology consists of a set of nodes and links.
     Links are point-to-point and unidirectional.
     Bidirectional connections need to be represented through
     two separate links.
     Multipoint connections, broadcast domains etc can be represented
     through a hierarchy of nodes, then connecting nodes at
     upper layers of the hierarchy.";

  revision 2014-10-11 {
    description
      "Initial revision.";
    reference "draft-clemm-i2rs-yang-network-topo-01";
  }

  typedef topology-id {
    type inet:uri;
    description
      "An identifier for a topology.";
  }

  typedef node-id {
    type inet:uri;
    description
      "An identifier for a node in a topology.
       The identifier may be opaque.
       The identifier SHOULD be chosen such that the same node in a
       real network topology will always be identified through the
       same identifier, even if the model is instantiated in separate
       datastores. An implementation MAY choose to capture semantics
       in the identifier, for example to indicate the type of node
       and/or the type of topology that the node is a part of.";
  }

  typedef link-id {
    type inet:uri;
    description
      "An identifier for a link in a topology.
       The identifier may be opaque.
       The identifier SHOULD be chosen such that the same link in a
       real network topology will always be identified through the
       same identifier, even if the model is instantiated in separate
       datastores. An implementation MAY choose to capture semantics
       in the identifier, for example to indicate the type of link
       and/or the type of topology that the link is a part of.";
  }

  typedef tp-id {
    type inet:uri;
    description
      "An identifier for termination points on a node.
       The identifier may be opaque.
       The identifier SHOULD be chosen such that the same TP in a
       real network topology will always be identified through the
       same identifier, even if the model is instantiated in separate
       datastores. An implementation MAY choose to capture semantics
       in the identifier, for example to indicate the type of TP
       and/or the type of node and topology that the TP is a part
       of.";
  }

  grouping topo-ref {
    leaf topo-ref {
      type leafref {
        path "/network-topology/topology/topology-id";
      }
    }
  }

  grouping link-ref {
    description
      "A type for an absolute reference a link instance.
       (This type should not be used for relative references.
       In such a case, a relative path should be used instead.)";
    uses topo-ref;
    leaf link-ref {
      type leafref {
        path "/network-topology/topology[topology-id=current()/../topo-ref]/link/link-id";
      }
    }
  }

  grouping node-ref {
    uses topo-ref;
    leaf node-ref {
      type leafref {
        path "/network-topology/topology[topology-id=current()/../topo-ref]/node/node-id";
      }
    }
  }

  grouping tp-ref {
    description
      "A type for an absolute reference to a termination point.
       (This type should not be used for relative references.
       In such a case, a relative path should be used instead.)";
    uses node-ref;
    leaf tp-ref {
      type leafref {
        path "/network-topology/topology[topology-id=current()/../topo-ref]/node[node-id=current()/../node-ref]/termination-point/tp-id";
      }
    }
  }

  container network-topology {
    description
      "This container acts as the top-level data element of this
       model.";
    list topology {
      key "topology-id";
      description
        "This is the model of an abstract topology. A topology
	contains nodes and links. Each topology MUST be identified
	by a unique topology-id for reason that a network could
	contain many topologies.";
      leaf topology-id {
        type topology-id;
        description
          "It is presumed that a datastore will contain many
	  topologies. To distinguish between topologies it is
	  vital to have UNIQUE topology identifiers.";
      }
      leaf server-provided {
        type boolean;
        config false;
        description
          "Indicates whether the topology is configurable by clients,
          or whether it is provided by the server.  This leaf is
          populated by the server implementing the model.
          It is set to false for topologies that are created by a
	  client; it is set to true otherwise.  If it is set to true,
	  any attempt to edit the topology MUST be rejected.";
      }
      container topology-types {
        description
          "This container is used to identify the type, or types (as
	  a topology can support several types simultaneously), of
	  the topology.
          Topology types are the subject of several integrity
	  constraints that an implementing server can validate in
	  order to maintain integrity of the datastore.
          Topology types are indicated through separate data nodes;
          the set of topology types is expected to increase over
	  time.
          To add support for a new topology, an augmenting module
          needs to augment this container with a new empty optional
          container to indicate the new topology type.
          The use of a container allows to indicate a
	  subcategorization of topology types.
          The container SHALL NOT be augmented with any data nodes
          that serve a purpose other than identifying a particular
          topology type.";
      }
      list supporting-topology {
        key "topo-ref";
        leaf topo-ref {
          type leafref {
            path "/network-topology/topology/topology-id";
          }
          description
            "This leaf identifies a topology which is forms a part
             of this topology's underlay. Reference loops, where
             a topology identifies itself as its underlay, either
             directly or transitively, are not allowed.";
        }
        description
          "Identifies the topology, or topologies, that this topology
           is dependent on.";
      }
      list node {
        key "node-id";
        leaf node-id {
          type node-id;
          description
            "The identifier of a node in the topology.
             A node is specific to a topology to which it belongs.";
        }
        description
          "The list of network nodes defined for the topology.";
        list termination-point {
          key "tp-id";
          description
            "A termination point can terminate a link.
            Depending on the type of topology, a termination point
	    could, for example, refer to a port or an interface.";
          leaf tp-id {
            type tp-id;
            description
              "Termination point identifier.";
          }
          list supporting-termination-point {
            key "topo-ref node-ref tp-ref";
            description
              "The leaf list identifies any termination points that
	      the termination point is dependent on, or maps onto.
              Those termination points will themselves be contained
              in a supporting node.
              This dependency information can be inferred from
              the dependencies between links.  For this reason,
              this item is not separately configurable.  Hence no
              corresponding constraint needs to be articulated.
              The corresponding information is simply provided by the
              implementing system.";
            leaf topo-ref {
              type leafref {
                path "../../../supporting-node/topo-ref";
              }
              description
                "This leaf identifies in which topology the
		supporting termination point is present.";
            }
            leaf node-ref {
              type leafref {
                path "../../../supporting-node/node-ref";
              }
              description
                "This leaf identifies in which node the supporting
                 termination point is present.";
            }
            leaf tp-ref {
              type leafref {
                path "/network-topology/topology[topology-id=current()/../topo-ref]/node[node-id=current()/../node-ref]/termination-point/tp-id";
              }
              description
                "Reference to the underlay node, must be in a
                different topology";
            }
          }
        }
        list supporting-node {
          key "topo-ref node-ref";
          description
            "This list defines vertical layering information for
	    nodes.
            It allows to capture for any given node, which node (or
	    nodes) in the corresponding underlay topology it maps
	    onto.
            A node can map to zero, one, or more nodes below it;
            accordingly there can be zero, one, or more elements in
	    the list.
            If there are specific layering requirements, for example
            specific to a particular type of topology that only
	    allows for certain layering relationships, the choice
            below can be augmented with additional cases.
            A list has been chosen rather than a leaf-list in order
            to provide room for augmentations, e.g. for
            statistics or priorization information associated with
            supporting nodes.";
          leaf topo-ref {
            type leafref {
              path "../../../supporting-topology/topo-ref";
            }
            description
              "This leaf identifies in which underlay topology
	      supporting node is present.";
          }
          leaf node-ref {
            type leafref {
              path "/network-topology/topology[topology-id=current()/../topo-ref]/node/node-id";
            }
            description
              "Reference to the underlay node, must be in a
              different topology";
          }
        }
      }
      list link {
        key "link-id";
        leaf link-id {
          type link-id;
          description
            "The identifier of a link in the topology.
             A link is specific to a topology to which it belongs.";
        }
        description
          "A Network Link connects a by Local (Source) node and
          a Remote (Destination) Network Nodes via a set of the
          nodes' termination points.
          As it is possible to have several links between the same
          source and destination nodes, and as a link could
	  potentially be re-homed between termination points, to
	  ensure that we would always know to distinguish between
	  links, every link is identified by a dedicated link
	  identifier.
          Note that a link models a point-to-point link, not a
	  multipoint link.
          Layering dependencies on links in underlay topologies are
          not represented as the layering information of nodes and of
          termination points is sufficient.";
        container source {
          description
            "This container holds the logical source of a particular
            link.";
          leaf source-node {
            type leafref {
              path "../../../node/node-id";
            }
            mandatory true;
            description
              "Source node identifier, must be in same topology.";
          }
          leaf source-tp {
            type leafref {
              path "../../../node[node-id=current()/../source-node]/termination-point/tp-id";
            }
            description
              "Termination point within source node that terminates
	      the link.";
          }
        }
        container destination {
          description
            "This container holds the logical destination of a
	    particular link.";
          leaf dest-node {
            type leafref {
              path "../../../node/node-id";
            }
            mandatory true;
            description
              "Destination node identifier, must be in the same
	      topology.";
          }
          leaf dest-tp {
            type leafref {
              path "../../../node[node-id=current()/../dest-node]/termination-point/tp-id";
            }
            description
              "Termination point within destination node that
	      terminates the link.";
          }
        }
        list supporting-link {
          key "topo-ref link-ref";
          description
            "Identifies the link, or links, that this link
            is dependent on.";
          leaf topo-ref {
            type leafref {
              path "../../../supporting-topology/topo-ref";
            }
            description
              "This leaf identifies in which underlay topology
	      supporting link is present.";
          }
          leaf link-ref {
            type leafref {
              path "/network-topology/topology[topology-id=current()/../topo-ref]/link/link-id";
            }
            description
              "This leaf identifies a link which is forms a part
              of this link's underlay. Reference loops, where
              a link identifies itself as its underlay, either
              directly or transitively, are not allowed.";
          }
        }
      }
    }
  }
}
&lt;CODE ENDS&gt;
        </artwork>
      </figure>
	</t>
    </section>
    <section title="Security Considerations">
       <t>
       The transport protocol used for sending the topology data MUST support authentication and
       SHOULD support encryption.
       The data-model by itself does not create any security implications.
       </t>
    </section>
    <section title="Contributors">
    <t>
    The model presented in this paper was contributed to by more people
    than can be listed on the author list.  Additional contributors include:
    <list style="symbols" >
		<t>
		Ken Gray, Cisco Systems
		</t>
		<t>
		Tom Nadeau, Brocade
		</t>
		<t>
		Aleksandr Zhdankin, Cisco
		</t>
	</list>
	</t>
    </section>

    <section title="Acknowledgements">
        <t> We wish to acknowledge the helpful contributions, comments, and
        suggestions that were received from Martin Bjorklund, Ladislav Lhotka,
        Andy Bierman, Carlos Pignataro, Juergen Schoenwaelder, Alia Atlas and
        Benoit Claise.
		</t>
    </section>
    </middle>
    <back>
    		<references title="Normative References">
          <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195"?>
          <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328"?>
          <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209"?>
          <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020"?>
          <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6021"?>
          <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241"?>
		</references>
		<references title="Informative References">
			<reference anchor="if-config">
				<front>
					<title>A YANG Data Model for Interface Management</title>
					<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
						<organization/>
					</author>
					<date month="July" year="2013"/>
				</front>
				<seriesInfo name="I-D" value="draft-ietf-netmod-interfaces-cfg-16"/>
			</reference>
			<reference anchor="restconf">
				<front>
					<title>RESTCONF Protocol</title>
					<author initials="A." surname="Bierman" fullname="A. Bierman">
						<organization/>
					</author>
					<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
						<organization></organization>
					</author>
					<author initials="K." surname="Watsen" fullname="K. Watsen">
						<organization/>
					</author>
					<author initials="R." surname="Fernando" fullname="R. Fernando">
						<organization/>
					</author>
					<date month="February" year="2014"/>
				</front>
				<seriesInfo name="I-D" value="draft-bierman-netconf-restconf-04"/>
			</reference>
			<reference anchor="yang-json">
				<front>
					<title>Modeling JSON Text with YANG</title>
					<author initials="L." surname="Lhotka" fullname="L. Lhotka">
						<organization/>
					</author>
					<date month="September" year="2013"/>
				</front>
				<seriesInfo name="I-D" value="draft-lhotka-etmod-yang-json-02"/>
			</reference>
			<reference anchor="topology-use-cases">
				<front>
					<title>Topology API Use Cases</title>
					<author initials="J." surname="Medved" fullname="J.Medved">
						<organization/>
					</author>
					<author initials="S." surname="Previdi" fullname="S. Previdi">
						<organization></organization>
					</author>
					<author initials="V." surname="Lopez" fullname="V. Lopez">
						<organization/>
					</author>
					<author initials="S." surname="Amante" fullname="S. Amante">
						<organization/>
					</author>
					<date month="October" year="2013"/>
				</front>
				<seriesInfo name="I-D" value="draft-amante-i2rs-topology-use-cases-01"/>
			</reference>
		</references>
   </back>
</rfc>