[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-clemm-netmod-yang-network-topo) 00 01 02 03 04 draft-ietf-i2rs-yang-network-topo

Network Working Group                                           A. Clemm
Internet-Draft                                                 J. Medved
Intended status: Experimental                                  T. Tkacik
Expires: April 13, 2015                                         R. Varga
                                                                   Cisco
                                                              N. Bahadur
                                                       Bracket Computing
                                                      H. Ananthakrishnan
                                                           Packet Design
                                                        October 10, 2014


                A YANG Data Model for Network Topologies
               draft-clemm-i2rs-yang-network-topo-01.txt

Abstract

   This document defines a YANG data model for network and service
   topologies.

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 April 13, 2015.

Copyright Notice

   Copyright (c) 2014 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



Clemm, et al.            Expires April 13, 2015                 [Page 1]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   4
   3.  Model Structure . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Main building blocks  . . . . . . . . . . . . . . . . . .   5
     3.2.  Discussion and selected design decisions  . . . . . . . .   6
     3.3.  Open issues and items for further discussion  . . . . . .   8
   4.  Network Topology YANG module  . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  17
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  18

1.  Introduction

   This document introduces an abstract (basic) topology YANG [RFC6020]
   [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 1,
   Layer 2 and Layer 3 topologies, such as unicast or multicast IGP
   topologies (IS-IS [RFC1195] or OSPF [RFC2328]), traffic engineering
   (TE) data [RFC3209], or any of the variety of transport and service
   topologies.  Information specific to particular network topology
   tpyes would be captured in separate, technology-specific models.  The
   basic data model introduced in this document is generic in nature and
   can be applied to many network topologies.




Clemm, et al.            Expires April 13, 2015                 [Page 2]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


   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.

          +---------------------------------------+
         /            _[X1]_          "Service"  /
        /           _/  :   \_                  /
       /          _/     :    \_               /
      /         _/        :     \_            /
     /         /           :      \          /
    /       [X1]__________________[X3]      /
   +---------:--------------:------:-------+
              :              :     :
          +----:--------------:----:--------------+
         /      :              :   :        "L3" /
        /        :              :  :            /
       /         :               : :           /
      /         [Y1]_____________[Y2]         /
     /           *               * *         /
    /            *              *  *        /
   +--------------*-------------*--*-------+
                   *           *   *
          +--------*----------*----*--------------+
         /     [Z1]_______________[Z1] "Optical" /
        /         \_         *   _/             /
       /            \_      *  _/              /
      /               \_   * _/               /
     /                  \ * /                /
    /                    [Z]                /
   +---------------------------------------+

   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



Clemm, et al.            Expires April 13, 2015                 [Page 3]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


   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.

   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 [topology-use-cases].

2.  Definitions and Acronyms

   Datastore: A conceptual store of instantiated management information,
   with individual data items represented by data nodes which are
   arranged in hierarchical manner ([RFC6241]).

   Data subtree: An instantiated data node and the data nodes that are
   hierarchically contained within it.

   HTTP: Hyper-Text Transfer Protocol

   IGP: Interior Gateway Protocol

   IS-IS: Intermediate System to Intermediate System protocol

   NETCONF: Network Configuration Protocol

   OSPF: Open Shortest Path First, a link state routing protocol

   URI: Uniform Resource Identifier

   ReST: Representational State Transfer, a style of stateless interface
   and protocol that is generally carried over HTTP

   YANG: A data definition language for NETCONF





Clemm, et al.            Expires April 13, 2015                 [Page 4]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


3.  Model Structure

   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.

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

3.1.  Main building blocks

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

   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



Clemm, et al.            Expires April 13, 2015                 [Page 5]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


   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.

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

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

   Furthermore, a topology contains nodes and links, each captured in
   their own list.

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

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

3.2.  Discussion and selected design decisions

   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.





Clemm, et al.            Expires April 13, 2015                 [Page 6]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


   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 [RFC7223].
   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.

   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.

   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.

   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.

   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



Clemm, et al.            Expires April 13, 2015                 [Page 7]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


   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.

   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.

3.3.  Open issues and items for further discussion

   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.

   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.

   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.



Clemm, et al.            Expires April 13, 2015                 [Page 8]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


4.  Network Topology YANG module

<CODE BEGINS> 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



Clemm, et al.            Expires April 13, 2015                 [Page 9]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


       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";



Clemm, et al.            Expires April 13, 2015                [Page 10]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


      }
    }
  }

  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 {



Clemm, et al.            Expires April 13, 2015                [Page 11]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


        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";



Clemm, et al.            Expires April 13, 2015                [Page 12]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


        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.";
            }



Clemm, et al.            Expires April 13, 2015                [Page 13]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


            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";
          }



Clemm, et al.            Expires April 13, 2015                [Page 14]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


        }
      }
      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 {



Clemm, et al.            Expires April 13, 2015                [Page 15]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


          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.";
          }
        }
      }



Clemm, et al.            Expires April 13, 2015                [Page 16]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


    }
  }
}
<CODE ENDS>

5.  Security Considerations

   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.

6.  Contributors

   The model presented in this paper was contributed to by more people
   than can be listed on the author list.  Additional contributors
   include:

   o  Ken Gray, Cisco Systems

   o  Tom Nadeau, Brocade

   o  Aleksandr Zhdankin, Cisco

7.  Acknowledgements

   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.

8.  References

8.1.  Normative References

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.





Clemm, et al.            Expires April 13, 2015                [Page 17]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


   [RFC6021]  Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
              October 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

8.2.  Informative References

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-02 (work in
              progress), October 2014.

   [I-D.ietf-netmod-yang-json]
              Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              draft-ietf-netmod-yang-json-00 (work in progress), April
              2014.

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, May 2014.

   [topology-use-cases]
              Medved, J., Previdi, S., Lopez, V., and S. Amante,
              "Topology API Use Cases", I-D draft-amante-i2rs-topology-
              use-cases-01, October 2013.

Authors' Addresses

   Alexander Clemm
   Cisco

   EMail: alex@cisco.com


   Jan Medved
   Cisco

   EMail: jmedved@cisco.com


   Tony Tkacik
   Cisco

   EMail: ttkacik@cisco.com






Clemm, et al.            Expires April 13, 2015                [Page 18]


Internet-Draft  draft-clemm-i2rs-yang-network-topo-01.txt   October 2014


   Robert Varga
   Cisco

   EMail: rovarga@cisco.com


   Nitin Bahadur
   Bracket Computing

   EMail: nitin_bahadur@yahoo.com


   Hariharan Ananthakrishnan
   Packet Design

   EMail: hanantha@juniper.net



































Clemm, et al.            Expires April 13, 2015                [Page 19]


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