module ietf-network {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network";
prefix nd;
import ietf-inet-types {
prefix inet;
}
organization
"IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web:
WG List:
WG Chair: Susan Hares
WG Chair: Russ White
Editor: Alexander Clemm
Editor: Jan Medved
Editor: Robert Varga
Editor: Nitin Bahadur
Editor: Hariharan Ananthakrishnan
Editor: Xufeng Liu
";
description
"This module defines a common base model for a collection
of nodes in a network. Node definitions are further used
in network topologies and inventories.
Copyright (c) 2016 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of
draft-ietf-i2rs-yang-network-topo-08;
see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-08 with RFC
number when published (i.e. RFC xxxx).";
revision 2016-11-16 {
description
"Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-08 with
RFC number when published (i.e. RFC xxxx).";
reference
"draft-ietf-i2rs-yang-network-topo-08";
}
typedef node-id {
type inet:uri;
description
"Identifier for a node. The precise structure of the node-id
will be up to the implementation. Some implementations MAY
for example, pick a uri that includes the network-id as
part of the path. 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.";
}
typedef network-id {
type inet:uri;
description
"Identifier for a network. The precise structure of the
network-id will be up to an implementation.
The identifier SHOULD be chosen such that the same network
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 network.";
}
grouping network-ref {
description
"Contains the information necessary to reference a network,
for example an underlay network.";
leaf network-ref {
type leafref {
path "/nd:networks/nd:network/nd: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 "/nd:networks/nd:network[nd:network-id=current()/../"+
"network-ref]/nd:node/nd:node-id";
require-instance false;
}
description
"Used to reference a node.
Nodes are identified relative to the network they are
contained in.";
}
uses network-ref;
}
container networks {
description
"Serves as 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
network-topology model), as well as 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 network-id;
description
"Identifies a network.";
}
leaf server-provided {
type boolean;
config false;
description
"Indicates whether the information concerning this
particular network is populated by the server
(server-provided true, the general case for network
information discovered from the server),
or whether it is configured by a client
(server-provided true, possible e.g. for
service overlays managed through a controller).
Clients should not attempt to make modifications
to network instances with server-provided set to
true; when they do, they need to be aware that
any modifications they make are subject to be
reverted by the server.
For servers that support NACM (Netconf Access Control
Model), data node rules should ideally prevent
write access by other clients to the network instance
when server-provided is set to true.";
}
list supporting-network {
key "network-ref";
description
"An underlay network, used to represent layered network
topologies.";
leaf network-ref {
type leafref {
path "/networks/network/network-id";
require-instance false;
}
description
"References the underlay network.";
}
}
list node {
key "node-id";
description
"The inventory of nodes of this network.";
leaf node-id {
type node-id;
description
"Identifies a node uniquely within the containing
network.";
}
list supporting-node {
key "network-ref node-ref";
description
"Represents another node, in an underlay network, that
this node is supported by. Used to represent layering
structure.";
leaf network-ref {
type leafref {
path "../../../supporting-network/network-ref";
require-instance false;
}
description
"References the underlay network that the
underlay node is part of.";
}
leaf node-ref {
type leafref {
path "/networks/network/node/node-id";
require-instance false;
}
description
"References the underlay node itself.";
}
}
}
}
}
}