Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8345

A YANG Data Model for Network Topologies

Pages: 57
Proposed Standard
Errata
Part 3 of 3 – Pages 39 to 57
First   Prev   None

Top   ToC   RFC8345 - Page 39   prevText

Appendix B. Companion YANG Data Models for Implementations Not Compliant with NMDA

The YANG modules defined in this document are designed to be used in conjunction with implementations that support the Network Management Datastore Architecture (NMDA) as defined in [RFC8342]. In order to allow implementations to use the data model even in cases when NMDA is not supported, the following two companion modules -- "ietf-network-state" and "ietf-network-topology-state" -- are defined; they represent the operational state of networks and network topologies, respectively. These modules mirror the "ietf-network"
Top   ToC   RFC8345 - Page 40
   and "ietf-network-topology" modules (defined in Sections 6.1 and 6.2
   of this document); however, in the case of these modules, all data
   nodes are non-configurable.  They represent state that comes into
   being by either (1) learning topology information from the network or
   (2) applying configuration from the mirrored modules.

   The "ietf-network-state" and "ietf-network-topology-state" companion
   modules are redundant and SHOULD NOT be supported by implementations
   that support NMDA; therefore, we define these modules in
   Appendices B.1 and B.2 (below) instead of the main body of this
   document.

   As the structure of both modules mirrors that of their underlying
   modules, the YANG tree is not depicted separately.

B.1. YANG Module for Network State

<CODE BEGINS> file "ietf-network-state@2018-02-26.yang" module ietf-network-state { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-state"; prefix nw-s; import ietf-network { prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/i2rs/> WG List: <mailto:i2rs@ietf.org> Editor: Alexander Clemm <mailto:ludwig@clemm.org> Editor: Jan Medved <mailto:jmedved@cisco.com> Editor: Robert Varga <mailto:robert.varga@pantheon.tech> Editor: Nitin Bahadur <mailto:nitin_bahadur@yahoo.com>
Top   ToC   RFC8345 - Page 41
     Editor:    Hariharan Ananthakrishnan
                <mailto:hari@packetdesign.com>

     Editor:    Xufeng Liu
                <mailto:xufeng.liu.ietf@gmail.com>";

  description
    "This module defines a common base data model for a collection
     of nodes in a network.  Node definitions are further used
     in network topologies and inventories.  It represents
     information that either (1) is learned and automatically
     populated or (2) results from applying network information
     that has been configured per the 'ietf-network' data model,
     mirroring the corresponding data nodes in this data model.

     The data model mirrors 'ietf-network' but contains only
     read-only state data.  The data model is not needed when the
     underlying implementation infrastructure supports the Network
     Management Datastore Architecture (NMDA).

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

     This version of this YANG module is part of RFC 8345;
     see the RFC itself for full legal notices.";

  revision 2018-02-26 {
    description
      "Initial revision.";
    reference
      "RFC 8345: A YANG Data Model for Network Topologies";
  }
Top   ToC   RFC8345 - Page 42
  grouping network-ref {
    description
      "Contains the information necessary to reference a network --
       for example, an underlay network.";
    leaf network-ref {
      type leafref {
        path "/nw-s:networks/nw-s:network/nw-s:network-id";
      require-instance false;
      }
      description
        "Used to reference a network -- for example, an underlay
         network.";
    }
  }

  grouping node-ref {
    description
      "Contains the information necessary to reference a node.";
    leaf node-ref {
      type leafref {
        path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
          "/../network-ref]/nw-s:node/nw-s:node-id";
        require-instance false;
      }
      description
        "Used to reference a node.
         Nodes are identified relative to the network that
         contains them.";
    }
    uses network-ref;
  }
Top   ToC   RFC8345 - Page 43
  container networks {
    config false;
    description
      "Serves as a top-level container for a list of networks.";
    list network {
      key "network-id";
      description
        "Describes a network.
         A network typically contains an inventory of nodes,
         topological information (augmented through the
         network-topology data model), and layering information.";
      container network-types {
        description
          "Serves as an augmentation target.
           The network type is indicated through corresponding
           presence containers augmented into this container.";
      }
      leaf network-id {
        type nw:network-id;
        description
          "Identifies a network.";
      }
      list supporting-network {
        key "network-ref";
        description
          "An underlay network, used to represent layered network
           topologies.";
        leaf network-ref {
          type leafref {
            path "/nw-s:networks/nw-s:network/nw-s:network-id";
          require-instance false;
          }
          description
            "References the underlay network.";
        }
      }
Top   ToC   RFC8345 - Page 44
      list node {
        key "node-id";
        description
          "The inventory of nodes of this network.";
        leaf node-id {
          type nw:node-id;
          description
            "Uniquely identifies a node within the containing
             network.";
        }
        list supporting-node {
          key "network-ref node-ref";
          description
            "Represents another node that is in an underlay network
             and that supports this node.  Used to represent layering
             structure.";
          leaf network-ref {
            type leafref {
              path "../../../nw-s:supporting-network/nw-s:network-ref";
            require-instance false;
            }
            description
              "References the underlay network of which the
               underlay node is a part.";
          }
          leaf node-ref {
            type leafref {
              path "/nw-s:networks/nw-s:network/nw-s:node/nw-s:node-id";
            require-instance false;
            }
            description
              "References the underlay node itself.";
          }
        }
      }
    }
  }
}

<CODE ENDS>
Top   ToC   RFC8345 - Page 45

B.2. YANG Module for Network Topology State

<CODE BEGINS> file "ietf-network-topology-state@2018-02-26.yang" module ietf-network-topology-state { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state"; prefix nt-s; import ietf-network-state { prefix nw-s; reference "RFC 8345: A YANG Data Model for Network Topologies"; } import ietf-network-topology { prefix nt; reference "RFC 8345: A YANG Data Model for Network Topologies"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/i2rs/> WG List: <mailto:i2rs@ietf.org> Editor: Alexander Clemm <mailto:ludwig@clemm.org> Editor: Jan Medved <mailto:jmedved@cisco.com> Editor: Robert Varga <mailto:robert.varga@pantheon.tech> Editor: Nitin Bahadur <mailto:nitin_bahadur@yahoo.com> Editor: Hariharan Ananthakrishnan <mailto:hari@packetdesign.com> Editor: Xufeng Liu <mailto:xufeng.liu.ietf@gmail.com>";
Top   ToC   RFC8345 - Page 46
    description
      "This module defines a common base data model for network
       topology state, representing topology that either (1) is learned
       or (2) results from applying topology that has been configured
       per the 'ietf-network-topology' data model, mirroring the
       corresponding data nodes in this data model.  It augments the
       base network state data model with links to connect nodes, as
       well as termination points to terminate links on nodes.

       The data model mirrors 'ietf-network-topology' but contains only
       read-only state data.  The data model is not needed when the
       underlying implementation infrastructure supports the Network
       Management Datastore Architecture (NMDA).

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

       This version of this YANG module is part of RFC 8345;
       see the RFC itself for full legal notices.";

    revision 2018-02-26 {
      description
        "Initial revision.";
      reference
        "RFC 8345: A YANG Data Model for Network Topologies";
    }
Top   ToC   RFC8345 - Page 47
    grouping link-ref {
      description
        "References a link in a specific network.  Although this
         grouping is not used in this module, it is defined here for
         the convenience of augmenting modules.";
      leaf link-ref {
        type leafref {
          path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
            "/../network-ref]/nt-s:link/nt-s:link-id";
          require-instance false;
        }
        description
          "A type for an absolute reference to a link instance.
           (This type should not be used for relative references.
           In such a case, a relative path should be used instead.)";
      }
      uses nw-s:network-ref;
    }

    grouping tp-ref {
      description
        "References a termination point in a specific node.  Although
         this grouping is not used in this module, it is defined here
         for the convenience of augmenting modules.";
      leaf tp-ref {
        type leafref {
          path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
            "/../network-ref]/nw-s:node[nw-s:node-id=current()/../"+
            "node-ref]/nt-s:termination-point/nt-s:tp-id";
          require-instance false;
        }
        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 nw-s:node-ref;
    }

    augment "/nw-s:networks/nw-s:network" {
      description
        "Add links to the network data model.";
      list link {
        key "link-id";
        description
          "A network link connects a local (source) node and
           a remote (destination) node via a set of the respective
           node's termination points.  It is possible to have several
Top   ToC   RFC8345 - Page 48
           links between the same source and destination nodes.
           Likewise, a link could potentially be re-homed between
           termination points.  Therefore, in order 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.";
        container source {
          description
            "This container holds the logical source of a particular
             link.";
          leaf source-node {
            type leafref {
              path "../../../nw-s:node/nw-s:node-id";
              require-instance false;
            }
            description
              "Source node identifier.  Must be in the same topology.";
          }
          leaf source-tp {
            type leafref {
              path "../../../nw-s:node[nw-s:node-id=current()/../"+
                "source-node]/termination-point/tp-id";
              require-instance false;
            }
            description
              "This termination point is located within the source node
               and terminates the link.";
          }
        }
        container destination {
          description
            "This container holds the logical destination of a
             particular link.";
          leaf dest-node {
            type leafref {
              path "../../../nw-s:node/nw-s:node-id";
            require-instance false;
            }
            description
              "Destination node identifier.  Must be in the same
               network.";
          }
Top   ToC   RFC8345 - Page 49
          leaf dest-tp {
            type leafref {
              path "../../../nw-s:node[nw-s:node-id=current()/../"+
                "dest-node]/termination-point/tp-id";
              require-instance false;
            }
            description
              "This termination point is located within the
               destination node and terminates the link.";
          }
        }
        leaf link-id {
          type nt:link-id;
          description
            "The identifier of a link in the topology.
             A link is specific to a topology to which it belongs.";
        }
        list supporting-link {
          key "network-ref link-ref";
          description
            "Identifies the link or links on which this link depends.";
          leaf network-ref {
            type leafref {
              path "../../../nw-s:supporting-network/nw-s:network-ref";
            require-instance false;
            }
            description
              "This leaf identifies in which underlay topology
               the supporting link is present.";
          }
          leaf link-ref {
            type leafref {
              path "/nw-s:networks/nw-s:network[nw-s:network-id="+
                "current()/../network-ref]/link/link-id";
              require-instance false;
            }
            description
              "This leaf identifies a link that is a part
               of this link's underlay.  Reference loops in which
               a link identifies itself as its underlay, either
               directly or transitively, are not allowed.";
          }
        }
      }
    }
Top   ToC   RFC8345 - Page 50
    augment "/nw-s:networks/nw-s:network/nw-s:node" {
      description
        "Augments termination points that terminate links.
         Termination points can ultimately be mapped to interfaces.";
      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 nt:tp-id;
          description
            "Termination point identifier.";
        }
        list supporting-termination-point {
          key "network-ref node-ref tp-ref";
          description
            "This list identifies any termination points on which a
             given termination point depends or onto which it maps.
             Those termination points will themselves be contained
             in a supporting node.  This dependency information can be
             inferred from the dependencies between links.  Therefore,
             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 network-ref {
            type leafref {
              path "../../../nw-s:supporting-node/nw-s:network-ref";
            require-instance false;
            }
            description
              "This leaf identifies in which topology the
               supporting termination point is present.";
          }
          leaf node-ref {
            type leafref {
              path "../../../nw-s:supporting-node/nw-s:node-ref";
            require-instance false;
            }
            description
              "This leaf identifies in which node the supporting
               termination point is present.";
          }
Top   ToC   RFC8345 - Page 51
          leaf tp-ref {
            type leafref {
              path "/nw-s:networks/nw-s:network[nw-s:network-id="+
                "current()/../network-ref]/nw-s:node[nw-s:node-id="+
                "current()/../node-ref]/termination-point/tp-id";
              require-instance false;
            }
            description
              "Reference to the underlay node (the underlay node must
               be in a different topology).";
          }
        }
      }
    }
  }

  <CODE ENDS>
Top   ToC   RFC8345 - Page 52

Appendix C. An Example

This section contains an example of an instance data tree in JSON encoding [RFC7951]. The example instantiates "ietf-network-topology" (and "ietf-network", which "ietf-network-topology" augments) for the topology depicted in Figure 7. There are three nodes: D1, D2, and D3. D1 has three termination points (1-0-1, 1-2-1, and 1-3-1). D2 has three termination points as well (2-1-1, 2-0-1, and 2-3-1). D3 has two termination points (3-1-1 and 3-2-1). In addition, there are six links, two between each pair of nodes with one going in each direction. +------------+ +------------+ | D1 | | D2 | /-\ /-\ /-\ /-\ | | 1-0-1 | |---------------->| | 2-1-1 | | | | 1-2-1 | |<----------------| | 2-0-1 | | \-/ 1-3-1 \-/ \-/ 2-3-1 \-/ | /----\ | | /----\ | +---| |---+ +---| |---+ \----/ \----/ A | A | | | | | | | | | | | +------------+ | | | | | D3 | | | | | /-\ /-\ | | | +----->| | 3-1-1 | |-------+ | +---------| | 3-2-1 | |<---------+ \-/ \-/ | | +------------+ Figure 7: A Network Topology Example
Top   ToC   RFC8345 - Page 53
   The corresponding instance data tree is depicted in Figure 8:

   {
     "ietf-network:networks": {
       "network": [
         {
           "network-types": {
           },
           "network-id": "otn-hc",
           "node": [
             {
               "node-id": "D1",
               "termination-point": [
                 {
                   "tp-id": "1-0-1"
                 },
                 {
                   "tp-id": "1-2-1"
                 },
                 {
                   "tp-id": "1-3-1"
                 }
               ]
             },
             {
               "node-id": "D2",
               "termination-point": [
                 {
                   "tp-id": "2-0-1"
                 },
                 {
                   "tp-id": "2-1-1"
                 },
                 {
                   "tp-id": "2-3-1"
                 }
               ]
             },
Top   ToC   RFC8345 - Page 54
             {
               "node-id": "D3",
               "termination-point": [
                 {
                   "tp-id": "3-1-1"
                 },
                 {
                   "tp-id": "3-2-1"
                 }
               ]
             }
           ],
           "ietf-network-topology:link": [
             {
               "link-id": "D1,1-2-1,D2,2-1-1",
               "source": {
                 "source-node": "D1",
                 "source-tp": "1-2-1"
               }
               "destination": {
                 "dest-node": "D2",
                 "dest-tp": "2-1-1"
               }
             },
             {
               "link-id": "D2,2-1-1,D1,1-2-1",
               "source": {
                 "source-node": "D2",
                 "source-tp": "2-1-1"
               }
               "destination": {
                 "dest-node": "D1",
                 "dest-tp": "1-2-1"
               }
             },
             {
               "link-id": "D1,1-3-1,D3,3-1-1",
               "source": {
                 "source-node": "D1",
                 "source-tp": "1-3-1"
               }
               "destination": {
                 "dest-node": "D3",
                 "dest-tp": "3-1-1"
               }
             },
Top   ToC   RFC8345 - Page 55
             {
               "link-id": "D3,3-1-1,D1,1-3-1",
               "source": {
                 "source-node": "D3",
                 "source-tp": "3-1-1"
               }
               "destination": {
                 "dest-node": "D1",
                 "dest-tp": "1-3-1"
               }
             },
             {
               "link-id": "D2,2-3-1,D3,3-2-1",
               "source": {
                 "source-node": "D2",
                 "source-tp": "2-3-1"
               }
               "destination": {
                 "dest-node": "D3",
                 "dest-tp": "3-2-1"
               }
             },
             {
               "link-id": "D3,3-2-1,D2,2-3-1",
               "source": {
                 "source-node": "D3",
                 "source-tp": "3-2-1"
               }
               "destination": {
                 "dest-node": "D2",
                 "dest-tp": "2-3-1"
               }
             }
           ]
         }
       ]
     }
   }

                       Figure 8: Instance Data Tree
Top   ToC   RFC8345 - Page 56

Acknowledgments

We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Alia Atlas, Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Robert Wilton, Qin Wu, and Xian Zhang.

Contributors

More people contributed to the data model presented in this paper than can be listed in the "Authors' Addresses" section. Additional contributors include: o Vishnu Pavan Beeram, Juniper o Ken Gray, Cisco o Tom Nadeau, Brocade o Tony Tkacik o Kent Watsen, Juniper o Aleksandr Zhdankin, Cisco
Top   ToC   RFC8345 - Page 57

Authors' Addresses

Alexander Clemm Huawei USA - Futurewei Technologies Inc. Santa Clara, CA United States of America Email: ludwig@clemm.org, alexander.clemm@huawei.com Jan Medved Cisco Email: jmedved@cisco.com Robert Varga Pantheon Technologies SRO Email: robert.varga@pantheon.tech Nitin Bahadur Bracket Computing Email: nitin_bahadur@yahoo.com Hariharan Ananthakrishnan Packet Design Email: hari@packetdesign.com Xufeng Liu Jabil Email: xufeng.liu.ietf@gmail.com