draft-ietf-i2rs-yang-network-topo-13.txt   draft-ietf-i2rs-yang-network-topo-14.txt 
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track J. Medved Intended status: Standards Track J. Medved
Expires: December 24, 2017 Cisco Expires: January 1, 2018 Cisco
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
X. Liu X. Liu
Jabil Jabil
June 22, 2017 June 30, 2017
A Data Model for Network Topologies A Data Model for Network Topologies
draft-ietf-i2rs-yang-network-topo-13.txt draft-ietf-i2rs-yang-network-topo-14.txt
Abstract Abstract
This document defines an abstract (generic) YANG data model for This document defines an abstract (generic) YANG data model for
network/service topologies and inventories. The model serves as a network/service topologies and inventories. The model serves as a
base model which is augmented with technology-specific details in base model which is augmented with technology-specific details in
other, more specific topology and inventory models. other, more specific topology and inventory models.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 24, 2017. This Internet-Draft will expire on January 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 7 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 8
4. Model Structure Details . . . . . . . . . . . . . . . . . . . 8 4. Model Structure Details . . . . . . . . . . . . . . . . . . . 8
4.1. Base Network Model . . . . . . . . . . . . . . . . . . . 8 4.1. Base Network Model . . . . . . . . . . . . . . . . . . . 8
4.2. Base Network Topology Model . . . . . . . . . . . . . . . 10 4.2. Base Network Topology Model . . . . . . . . . . . . . . . 11
4.3. Extending the model . . . . . . . . . . . . . . . . . . . 12 4.3. Extending the model . . . . . . . . . . . . . . . . . . . 12
4.4. Discussion and selected design decisions . . . . . . . . 12 4.4. Discussion and selected design decisions . . . . . . . . 13
4.4.1. Container structure . . . . . . . . . . . . . . . . . 12 4.4.1. Container structure . . . . . . . . . . . . . . . . . 13
4.4.2. Underlay hierarchies and mappings . . . . . . . . . . 13 4.4.2. Underlay hierarchies and mappings . . . . . . . . . . 13
4.4.3. Dealing with changes in underlay networks . . . . . . 13 4.4.3. Dealing with changes in underlay networks . . . . . . 14
4.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 14 4.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 14
4.4.5. Cardinality and directionality of links . . . . . . . 14 4.4.5. Cardinality and directionality of links . . . . . . . 15
4.4.6. Multihoming and link aggregation . . . . . . . . . . 15 4.4.6. Multihoming and link aggregation . . . . . . . . . . 15
4.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 15 4.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 15
4.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 15 4.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.9. Representing the same device in multiple networks . . 15 4.4.9. Representing the same device in multiple networks . . 16
4.4.10. Supporting client-configured and server-provided 4.4.10. Supporting client-configured and server-provided
network topology . . . . . . . . . . . . . . . . . . 16 network topology . . . . . . . . . . . . . . . . . . 17
4.4.11. Identifiers of string or URI type . . . . . . . . . . 17 4.4.11. Identifiers of string or URI type . . . . . . . . . . 17
5. Interactions with Other YANG Modules . . . . . . . . . . . . 18 5. Interactions with Other YANG Modules . . . . . . . . . . . . 18
6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Defining the Abstract Network: network.yang . . . . . . . 18 6.1. Defining the Abstract Network: network.yang . . . . . . . 18
6.2. Creating Abstract Network Topology: network-topology.yang 22 6.2. Creating Abstract Network Topology: network-topology.yang 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Appendix: Model Use Cases . . . . . . . . . . . . . 33 Appendix A. Appendix: Model Use Cases . . . . . . . . . . . . . 34
A.1. Fetching Topology from a Network Element . . . . . . . . 33 A.1. Fetching Topology from a Network Element . . . . . . . . 34
A.2. Modifying TE Topology Imported from an Optical Controller 33 A.2. Modifying TE Topology Imported from an Optical Controller 34
A.3. Annotating Topology for Local Computation . . . . . . . . 34 A.3. Annotating Topology for Local Computation . . . . . . . . 35
A.4. SDN Controller-Based Configuration of Overlays on Top of A.4. SDN Controller-Based Configuration of Overlays on Top of
Underlays . . . . . . . . . . . . . . . . . . . . . . . . 34 Underlays . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Appendix: Companion YANG models for non-NMDA
compliant implementations . . . . . . . . . . . . . 35
B.1. YANG Model for Network State . . . . . . . . . . . . . . 36
B.2. YANG Model for Network Topology State . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
This document introduces an abstract (base) YANG [RFC7950] [RFC6991] This document introduces an abstract (base) YANG [RFC7950] [RFC6991]
data model to represent networks and topologies. The data model is data model to represent networks and topologies. The data model is
divided into two parts. The first part of the model defines a divided into two parts. The first part of the model defines a
network model that allows to define network hierarchies (i.e. network network model that allows to define network hierarchies (i.e. network
stacks) and to maintain an inventory of nodes contained in a network. stacks) and to maintain an inventory of nodes contained in a network.
The second part of the model augments the basic network model with The second part of the model augments the basic network model with
information to describe topology information. Specifically, it adds information to describe topology information. Specifically, it adds
skipping to change at page 18, line 26 skipping to change at page 18, line 40
document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral
topology data that is server provided, the process tasked with topology data that is server provided, the process tasked with
maintaining topology information will load information from the maintaining topology information will load information from the
routing process (such as OSPF) into the data model without relying on routing process (such as OSPF) into the data model without relying on
a configuration datastore. a configuration datastore.
6. YANG Modules 6. YANG Modules
6.1. Defining the Abstract Network: network.yang 6.1. Defining the Abstract Network: network.yang
<CODE BEGINS> file "ietf-network@2017-06-22.yang" <CODE BEGINS> file "ietf-network@2017-06-30.yang"
module ietf-network { module ietf-network {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network"; namespace "urn:ietf:params:xml:ns:yang:ietf-network";
prefix nd; prefix nd;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
organization organization
skipping to change at page 19, line 34 skipping to change at page 19, line 49
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of This version of this YANG module is part of
draft-ietf-i2rs-yang-network-topo-13; draft-ietf-i2rs-yang-network-topo-14;
see the RFC itself for full legal notices. see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-13 with RFC draft-ietf-i2rs-yang-network-topo-14 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2017-06-22 { revision 2017-06-30 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-13 with to draft-ietf-i2rs-yang-network-topo-14 with
RFC number when published (i.e. RFC xxxx)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-network-topo-13"; "draft-ietf-i2rs-yang-network-topo-14";
} }
typedef node-id { typedef node-id {
type inet:uri; type inet:uri;
description description
"Identifier for a node. The precise structure of the node-id "Identifier for a node. The precise structure of the node-id
will be up to the implementation. Some implementations MAY will be up to the implementation. Some implementations MAY
for example, pick a uri that includes the network-id as for example, pick a uri that includes the network-id as
part of the path. The identifier SHOULD be chosen such that part of the path. The identifier SHOULD be chosen such that
the same node in a real network topology will always be the same node in a real network topology will always be
skipping to change at page 22, line 38 skipping to change at page 23, line 4
path "/networks/network/node/node-id"; path "/networks/network/node/node-id";
require-instance false; require-instance false;
} }
description description
"References the underlay node itself."; "References the underlay node itself.";
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6.2. Creating Abstract Network Topology: network-topology.yang 6.2. Creating Abstract Network Topology: network-topology.yang
<CODE BEGINS> file "ietf-network-topology@2017-06-22.yang" <CODE BEGINS> file "ietf-network-topology@2017-06-30.yang"
module ietf-network-topology { module ietf-network-topology {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
prefix lnk; prefix lnk;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-network { import ietf-network {
prefix nd; prefix nd;
} }
organization organization
"IETF I2RS (Interface to the Routing System) Working Group"; "IETF I2RS (Interface to the Routing System) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2rs/> "WG Web: <http://tools.ietf.org/wg/i2rs/>
skipping to change at page 24, line 8 skipping to change at page 24, line 22
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of This version of this YANG module is part of
draft-ietf-i2rs-yang-network-topo-13; draft-ietf-i2rs-yang-network-topo-14;
see the RFC itself for full legal notices. see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-13 with RFC draft-ietf-i2rs-yang-network-topo-14 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2017-06-22 { revision 2017-06-30 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-13 with to draft-ietf-i2rs-yang-network-topo-14 with
RFC number when published (i.e. RFC xxxx)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-network-topo-13"; "draft-ietf-i2rs-yang-network-topo-14";
} }
typedef link-id { typedef link-id {
type inet:uri; type inet:uri;
description description
"An identifier for a link in a topology. "An identifier for a link in a topology.
The precise structure of the link-id The precise structure of the link-id
will be up to the implementation. will be up to the implementation.
The identifier SHOULD be chosen such that the same link in a The identifier SHOULD be chosen such that the same link in a
real network topology will always be identified through the real network topology will always be identified through the
skipping to change at page 29, line 26 skipping to change at page 29, line 39
Registry" [RFC3688]: Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-network URI: urn:ietf:params:xml:ns:yang:ietf-network
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf-network-topology URI:urn:ietf:params:xml:ns:yang:ietf-network-topology
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-network-state
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf-network-topology-state
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document registers the following YANG modules in the "YANG This document registers the following YANG modules in the "YANG
Module Names" registry [RFC6020]: Module Names" registry [RFC6020]:
Name: ietf-network Name: ietf-network
Namespace: urn:ietf:params:xml:ns:yang:ietf-network Namespace: urn:ietf:params:xml:ns:yang:ietf-network
Prefix: nd Prefix: nd
Reference: draft-ietf-i2rs-yang-network-topo-13.txt (RFC form) Reference: draft-ietf-i2rs-yang-network-topo-14.txt (RFC form)
Name: ietf-network-topology Name: ietf-network-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology
Prefix: lnk Prefix: lnk
Reference: draft-ietf-i2rs-yang-network-topo-13.txt (RFC form) Reference: draft-ietf-i2rs-yang-network-topo-14.txt (RFC form)
Name: ietf-network-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state
Prefix: nd-s
Reference: draft-ietf-i2rs-yang-network-topo-14.txt (RFC form)
Name: ietf-network-topology-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state
Prefix: lnk-s
Reference: draft-ietf-i2rs-yang-network-topo-14.txt (RFC form)
8. Security Considerations 8. Security Considerations
The YANG module defined in this memo is independent of a particular The YANG module defined in this memo is independent of a particular
protocol and can be accessed via a number of protocols that need to protocol and can be accessed via a number of protocols that need to
access YANG-defined data. This includes but is not limited to the access YANG-defined data. This includes but is not limited to the
NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure
transport layer and the mandatory-to-implement secure transport is transport layer and the mandatory-to-implement secure transport is
Secure Shell (SSH) [RFC6242]. Secure Shell (SSH) [RFC6242].
skipping to change at page 31, line 4 skipping to change at page 31, line 36
o Vishnu Pavan Beeram, Juniper o Vishnu Pavan Beeram, Juniper
o Ken Gray, Cisco o Ken Gray, Cisco
o Tom Nadeau, Brocade o Tom Nadeau, Brocade
o Tony Tkacik o Tony Tkacik
o Kent Watsen, Juniper o Kent Watsen, Juniper
o Aleksandr Zhdankin, Cisco o Aleksandr Zhdankin, Cisco
10. Acknowledgements 10. Acknowledgements
We wish to acknowledge the helpful contributions, comments, and We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Alia Atlas, Andy Bierman, Martin suggestions that were received from Alia Atlas, Andy Bierman, Martin
Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka, Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka,
Carlos Pignataro, Juergen Schoenwaelder, and Xian Zhang. Carlos Pignataro, Juergen Schoenwaelder, Robert Wilton, and Xian
Zhang.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.draft-ietf-netmod-revised-datastores] [I-D.draft-ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "A Revised Conceptual Model for YANG and R. Wilton, "A Revised Conceptual Model for YANG
Datastores", I-D draft-ietf-netmod-revised-datastores-02, Datastores", I-D draft-ietf-netmod-revised-datastores-02,
May 2017. May 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997. requirement levels", RFC 2119, March 1997.
skipping to change at page 34, line 42 skipping to change at page 35, line 42
be another system's server (or "uber-network device"). be another system's server (or "uber-network device").
In this scenario, the SDN controller maintains a consolidated model In this scenario, the SDN controller maintains a consolidated model
of multiple layers of topology. This includes the lower layers of of multiple layers of topology. This includes the lower layers of
the network topology, built from information that is discovered from the network topology, built from information that is discovered from
the network. It also includes upper layers of topology overlay, the network. It also includes upper layers of topology overlay,
configurable by the controller's client, i.e. the OSS. To the OSS, configurable by the controller's client, i.e. the OSS. To the OSS,
the lower topology layers constitute "read-only" information. The the lower topology layers constitute "read-only" information. The
upper topology layers need to be read-writable. upper topology layers need to be read-writable.
Appendix B. Appendix: Companion YANG models for non-NMDA compliant
implementations
The YANG modules defined in this document are designed to be used in
conjunction with implementations that support the Network Management
Datastore Architecture (NMDA) defined in
[I-D.draft-ietf-netmod-revised-datastores]. In order to allow
implementations to use the model even in cases when NMDA is not
supported, in the following two companion modules are defined that
represent a state model of networks and network topologies. The
modules, ietf-network-state and ietf-network-topology-state, mirror
modules ietf-network and ietf-network-topology defined earlier in
this document. However, all data nodes are non-configurable. They
represent state that comes into being by either learning topology
information from the network, or by applying configuration from the
mirrored modules.
The companion modules, ietf-network-state and ietf-network-topology-
state, are redundant and SHOULD NOT be supported by implementations
that support NMDA. It is for this reason that the definitions are
defined in an appendix.
As the structure of both modules mirrors that of their underlying
modules, the YANG tree is not depicted separately.
B.1. YANG Model for Network State
<CODE BEGINS> file "ietf-network-state@2017-06-30.yang"
module ietf-network-state {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-state";
prefix nd-s;
import ietf-network {
prefix nd;
}
organization
"IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
WG Chair: Susan Hares
<mailto:shares@ndzh.com>
WG Chair: Russ White
<mailto:russ@riw.us>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.sk>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Xufeng Liu
<mailto:Xufeng_Liu@jabil.com>";
description
"This module defines a common base model for for a collection
of nodes in a network. Node definitions are further used
in network topologies and inventories. It represents
information that is either learned and automatically populated,
or information that results from applying configured netwok
information configured per the ietf-network model, mirroring
the corresponding data nodes in this model.
The model mirrors ietf-network, but contains only
read-only state data. The model is not needed when the
underlying implementation infrastructure supports the Network
Management Datastore Architecture (NMDA).
Copyright (c) 2017 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-14;
see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-14 with RFC
number when published (i.e. RFC xxxx).";
revision 2017-06-30 {
description
"Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-14 with
RFC number when published (i.e. RFC xxxx).";
reference
"draft-ietf-i2rs-yang-network-topo-14";
}
grouping network-ref {
description
"Contains the information necessary to reference a network,
for example an underlay network.";
leaf network-ref {
type leafref {
path "/nd-s:networks/nd-s:network/nd-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 "/nd-s:networks/nd-s:network[nd-s:network-id=current()"+
"/../network-ref]/nd-s:node/nd-s: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 {
config false;
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 nd: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 "/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 nd: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.";
}
}
}
}
}
}
<CODE ENDS>
B.2. YANG Model for Network Topology State
<CODE BEGINS> file "ietf-network-topology-state@2017-06-30.yang"
module ietf-network-topology-state {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state";
prefix lnk-s;
import ietf-network-state {
prefix nd-s;
}
import ietf-network-topology {
prefix lnk;
}
organization
"IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
WG Chair: Susan Hares
<mailto:shares@ndzh.com>
WG Chair: Russ White
<mailto:russ@riw.us>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.sk>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>
Editor: Xufeng Liu
<mailto:Xufeng_Liu@jabil.com>";
description
"This module defines a common base model for network topology
state, representing topology that is either learned, or topology
that results from applying topology that has been configured per
the ietf-network-topology model, mirroring the corresponding
data nodes in this model. It augments the base network state
model with links to connect nodes, as well as termination
points to terminate links on nodes.
The model mirrors ietf-network-topology, but contains only
read-only state data. The model is not needed when the
underlying implementation infrastructure supports the Network
Management Datastore Architecture (NMDA).
Copyright (c) 2017 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-14;
see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-14 with RFC
number when published (i.e. RFC xxxx).";
revision 2017-06-30 {
description
"Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-14 with
RFC number when published (i.e. RFC xxxx).";
reference
"draft-ietf-i2rs-yang-network-topo-14";
}
grouping link-ref {
description
"References a link in a specific network.";
leaf link-ref {
type leafref {
path "/nd-s:networks/nd-s:network[nd-s:network-id=current()"+
"/../network-ref]/lnk-s:link/lnk-s:link-id";
require-instance false;
}
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 nd-s:network-ref;
}
grouping tp-ref {
description
"References a termination point in a specific node.";
leaf tp-ref {
type leafref {
path "/nd-s:networks/nd-s:network[nd-s:network-id=current()"+
"/../network-ref]/nd-s:node[nd-s:node-id=current()/../"+
"node-ref]/lnk-s:termination-point/lnk-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 nd-s:node-ref;
}
augment "/nd-s:networks/nd-s:network" {
description
"Add links to the network 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 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 "../../../nd-s:node/nd-s:node-id";
require-instance false;
}
description
"Source node identifier, must be in same topology.";
}
leaf source-tp {
type leafref {
path "../../../nd-s:node[nd-s:node-id=current()/../"+
"source-node]/termination-point/tp-id";
require-instance false;
}
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 "../../../nd-s:node/nd-s:node-id";
require-instance false;
}
description
"Destination node identifier, must be in the same
network.";
}
leaf dest-tp {
type leafref {
path "../../../nd-s:node[nd-s:node-id=current()/../"+
"dest-node]/termination-point/tp-id";
require-instance false;
}
description
"Termination point within destination node that
terminates the link.";
}
}
leaf link-id {
type lnk: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, that this link
is dependent on.";
leaf network-ref {
type leafref {
path "../../../nd-s:supporting-network/nd-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 "/nd-s:networks/nd-s:network[nd-s:network-id="+
"current()/../network-ref]/link/link-id";
require-instance false;
}
description
"This leaf identifies a link which 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.";
}
}
}
}
augment "/nd-s:networks/nd-s:network/nd-s:node" {
description
"Augment termination points which 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 lnk:tp-id;
description
"Termination point identifier.";
}
list supporting-termination-point {
key "network-ref node-ref tp-ref";
description
"This 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 network-ref {
type leafref {
path "../../../nd-s:supporting-node/nd-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 "../../../nd-s:supporting-node/nd-s:node-ref";
require-instance false;
}
description
"This leaf identifies in which node the supporting
termination point is present.";
}
leaf tp-ref {
type leafref {
path "/nd-s:networks/nd-s:network[nd-s:network-id="+
"current()/../network-ref]/nd-s:node[nd-s:node-id="+
"current()/../node-ref]/termination-point/tp-id";
require-instance false;
}
description
"Reference to the underlay node, must be in a
different topology";
}
}
}
}
}
<CODE ENDS>
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Huawei Huawei
EMail: ludwig@clemm.org EMail: ludwig@clemm.org
Jan Medved Jan Medved
Cisco Cisco
EMail: jmedved@cisco.com EMail: jmedved@cisco.com
Robert Varga Robert Varga
Pantheon Technologies SRO Pantheon Technologies SRO
EMail: robert.varga@pantheon.sk EMail: robert.varga@pantheon.sk
 End of changes. 38 change blocks. 
39 lines changed or deleted 569 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/