draft-ietf-i2rs-yang-l3-topology-10.txt   draft-ietf-i2rs-yang-l3-topology-11.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: January 3, 2018 Cisco Expires: March 23, 2018 Cisco
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
X. Liu X. Liu
Ericsson Ericsson
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
July 2, 2017 September 19, 2017
A YANG Data Model for Layer 3 Topologies A YANG Data Model for Layer 3 Topologies
draft-ietf-i2rs-yang-l3-topology-10.txt draft-ietf-i2rs-yang-l3-topology-11.txt
Abstract Abstract
This document defines a YANG data model for layer 3 network This document defines a YANG data model for layer 3 network
topologies. topologies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 January 3, 2018. This Internet-Draft will expire on March 23, 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
4. Layer 3 Unicast Topology Model Overview . . . . . . . . . . . 5 4. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4
5. Layer 3 Unicast Topology YANG Module . . . . . . . . . . . . 7 5. Layer 3 Unicast Topology Model Overview . . . . . . . . . . . 5
6. Extending the Model . . . . . . . . . . . . . . . . . . . . . 15 6. Layer 3 Unicast Topology YANG Module . . . . . . . . . . . . 7
6.1. Example 1: OSPF Topology . . . . . . . . . . . . . . . . 15 7. Interactions with Other YANG Modules . . . . . . . . . . . . 15
6.1.1. Model Overview . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1.2. OSPF Topology YANG Module . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.2. Example 2: IS-IS Topology . . . . . . . . . . . . . . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1. Model Overview . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
6.2.2. IS-IS Topology YANG Module . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Interactions with Other YANG Modules . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Companion YANG model for non-NMDA compliant Appendix A. Companion YANG model for non-NMDA compliant
implementations . . . . . . . . . . . . . . . . . . 32 implementations . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix B. Extending the Model . . . . . . . . . . . . . . . . 24
B.1. Example OSPF Topology . . . . . . . . . . . . . . . . . . 24
B.1.1. Model Overview . . . . . . . . . . . . . . . . . . . 24
B.1.2. OSPF Topology YANG Module . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This document introduces a YANG [RFC7950] [RFC6991] data model for This document introduces a YANG [RFC7950] [RFC6991] data model for
Layer 3 network topologies, specifically Layer 3 Unicast. The model Layer 3 network topologies, specifically Layer 3 Unicast. The model
allows an application to have a holistic view of the topology of a allows an application to have a holistic view of the topology of a
Layer 3 network, all contained in a single conceptual YANG datastore. Layer 3 network, all contained in a single conceptual YANG datastore.
The data model builds on top of, and augments, the data model for The data model builds on top of, and augments, the data model for
network topologies defined in network topologies defined in
[I-D.draft-ietf-i2rs-yang-network-topo]. [I-D.draft-ietf-i2rs-yang-network-topo].
This document also shows how the model can be further refined to This document also shows how the model can be further refined to
cover different Layer 3 Unicast topology types. For this purpose, cover different Layer 3 Unicast topology types. For this purpose,
example models are introduced that cover IS-IS [RFC1195] and OSPF example model is introduced that covers OSPF [RFC2328]. This example
[RFC2328]. Those examples are intended purely for illustrative is intended purely for illustrative purpose; we expect that full-
purposes; we expect that full-blown IS-IS and OSPF models will be blown OSPF model will be more comprehensive and refined than the
more comprehensive and refined than the examples shown here. example shown here.
There are multiple applications for a topology data model. A number There are multiple applications for a topology data model. A number
of use cases have been defined in section 6 of of use cases have been defined in section 6 of
[I-D.draft-ietf-i2rs-usecase-reqs-summary]. For example, nodes [I-D.draft-ietf-i2rs-usecase-reqs-summary]. For example, nodes
within the network can use the data model to capture their within the network can use the data model to capture their
understanding of the overall network topology and expose it to a understanding of the overall network topology and expose it to a
network controller. A network controller can then use the network controller. A network controller can then use the
instantiated topology data to compare and reconcile its own view of instantiated topology data to compare and reconcile its own view of
the network topology with that of the network elements that it the network topology with that of the network elements that it
controls. Alternatively, nodes within the network could propagate controls. Alternatively, nodes within the network could propagate
skipping to change at page 3, line 34 skipping to change at page 3, line 32
To do so, it augments general network topology model defined in To do so, it augments general network topology model defined in
[I-D.draft-ietf-i2rs-yang-network-topo] with information specific to [I-D.draft-ietf-i2rs-yang-network-topo] with information specific to
Layer 3 Unicast. This way, the general topology model is extended to Layer 3 Unicast. This way, the general topology model is extended to
be able to meet the needs of Layer 3 Unicast topologies. be able to meet the needs of Layer 3 Unicast topologies.
Information that is kept in the Traffic Engineering Database (TED) Information that is kept in the Traffic Engineering Database (TED)
will be specified in a separate model will be specified in a separate model
[I-D.draft-ietf-teas-yang-te-topo] and outside the scope of this [I-D.draft-ietf-teas-yang-te-topo] and outside the scope of this
specification. specification.
2. Definitions and Acronyms 2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Definitions and Acronyms
As this document defines a YANG data model, in this document many As this document defines a YANG data model, in this document many
terms are used that have been defined in conjunction with YANG terms are used that have been defined in conjunction with YANG
[RFC7950] and Netconf [RFC6241]. Some terms, such as datastore and [RFC7950] and NETCONF [RFC6241]. Some terms, such as datastore and
data tree, are repeated here for clarity and to put them in context. data tree, are repeated here for clarity and to put them in context.
Datastore: A conceptual place to store and access information, such Datastore: A conceptual store of instantiated management information,
as instantiated YANG data. with individual data items represented by data nodes which are
Data tree: An instantiated tree of data modeled with YANG, in which
individual data items are represented by data nodes which are
arranged in hierarchical manner. arranged in hierarchical manner.
Data subtree: An instantiated data node and the data nodes that are Data subtree: An instantiated data node and the data nodes that are
hierarchically contained within it. hierarchically contained within it.
HTTP: Hyper-Text Transfer Protocol HTTP: Hyper-Text Transfer Protocol
IGP: Interior Gateway Protocol IGP: Interior Gateway Protocol
IS-IS: Intermediate System to Intermediate System protocol IS-IS: Intermediate System to Intermediate System protocol
LSP: Label Switched Path LSP: Label Switched Path
NETCONF: Network Configuration Protocol NETCONF: Network Configuration Protocol
NMDA: Network Management Datastore Architecture NMDA: Network Management Datastore Architecture
skipping to change at page 4, line 27 skipping to change at page 4, line 30
ReST: Representational State Transfer, a style of stateless interface ReST: Representational State Transfer, a style of stateless interface
and protocol that is generally carried over HTTP and protocol that is generally carried over HTTP
SRLG: Shared Risk Link Group SRLG: Shared Risk Link Group
TED: Traffic Engineering Database TED: Traffic Engineering Database
YANG: A data definition language for NETCONF YANG: A data definition language for NETCONF
3. Model Structure 4. Model Structure
The Layer 3 Unicast topology model is defined by YANG module "l3- The Layer 3 Unicast topology model is defined by YANG module "l3-
unicast-topology". The relationship of this module with other YANG unicast-topology". The relationship of this module with other YANG
modules is roughly depicted in the figure below. modules is roughly depicted in the figure below.
+-----------------------------+ +-----------------------------+
| +-----------------------+ | | +-----------------------+ |
| | ietf-network | | | | ietf-network | |
| +----------^------------+ | | +----------^------------+ |
| | | | | |
| +-----------------------+ | | +-----------------------+ |
| | ietf-network-topology | | | | ietf-network-topology | |
| +----------+------------+ | | +----------+------------+ |
+-------------^---------------+ +-------------^---------------+
| |
| |
+-----------^-------------+ +-----------^-------------+
| L3-UNICAST-TOPOLOGY | | L3-UNICAST-TOPOLOGY |
+----+---------------+----+ +----+------^--------+----+
^ ^ |
| | |
| | +-------^-------+
+--------^-----+ +-----^---------+ | ospf-topology |
| ospf-topology| | isis-topology | +---------------+
+--------------+ +---------------+
Figure 1: Overall model structure Figure 1: Overall model structure
YANG modules "ietf-network" and "ietf-network-topology" collectively YANG modules "ietf-network" and "ietf-network-topology" collectively
define the basic network topology model. YANG module "ietf-l3- define the basic network topology model. YANG module "ietf-l3-
unicast-topology" augments those models with additional definitions unicast-topology" augments those models with additional definitions
needed to represent Layer 3 Unicast topologies. This module in turn needed to represent Layer 3 Unicast topologies. This module in turn
can be augmented by YANG modules with additional definitions for can be augmented by YANG modules with additional definitions for
specific types of Layer 3 Unicast topologies, such as OSPF and for specific types of Layer 3 Unicast topologies, such as OSPF and for
IS-IS topologies. IS-IS topologies.
skipping to change at page 5, line 46 skipping to change at page 5, line 45
The YANG modules ietf-network and ietf-network are designed to be The YANG modules ietf-network and ietf-network are designed to be
used in conjunction with implementations that support the Network used in conjunction with implementations that support the Network
Management Datastore Architecture (NMDA) defined in Management Datastore Architecture (NMDA) defined in
[I-D.draft-ietf-netmod-revised-datastores]. Accordingly, the same is [I-D.draft-ietf-netmod-revised-datastores]. Accordingly, the same is
true for the YANG modules that augment it. In order to allow true for the YANG modules that augment it. In order to allow
implementations to use the model even in cases when NMDA is not implementations to use the model even in cases when NMDA is not
supported, companion YANG modules (that SHOULD NOT be supported by supported, companion YANG modules (that SHOULD NOT be supported by
implementations that support NMDA) are defined in an Appendix, see implementations that support NMDA) are defined in an Appendix, see
Appendix A. Appendix A.
4. Layer 3 Unicast Topology Model Overview 5. Layer 3 Unicast Topology Model Overview
The Layer 3 Unicast topology model is defined by YANG module "ietf- The Layer 3 Unicast topology model is defined by YANG module "ietf-
l3-unicast-topology" and depicted in the following diagram. Brackets l3-unicast-topology". Its structure is depicted in the following
enclose list keys, "rw" means configuration, "ro" operational state diagram. The notation syntax follows
data, "?" designates optional nodes, "*" designates nodes that can [I-D.draft-ietf-netmod-yang-tree-diagrams]. For purposes of brevity,
have multiple instances. Parantheses enclose choice and case nodes. notifications are not depicted.
The prefix "nd:" refers to the YANG module for networks; the prefix
"lnk:" refers to the YANG module for network topology. In the
interest of brevity, notifications are not depicted.
module: ietf-l3-unicast-topology module: ietf-l3-unicast-topology
augment /nd:networks/nd:network/nd:network-types: augment /nd:networks/nd:network/nd:network-types:
+--rw l3-unicast-topology! +--rw l3-unicast-topology!
augment /nd:networks/nd:network: augment /nd:networks/nd:network:
+--rw l3-topology-attributes +--rw l3-topology-attributes
+--rw name? string +--rw name? string
+--rw flag* l3-flag-type +--rw flag* l3-flag-type
augment /nd:networks/nd:network/nd:node: augment /nd:networks/nd:network/nd:node:
+--rw l3-node-attributes +--rw l3-node-attributes
+--rw name? inet:domain-name +--rw name? inet:domain-name
+--rw flag* node-flag-type +--rw flag* node-flag-type
+--rw router-id* inet:ip-address +--rw router-id* inet:ip-address
+--rw prefix* [prefix] +--rw prefix* [prefix]
+--rw prefix inet:ip-prefix +--rw prefix inet:ip-prefix
+--rw metric? uint32 +--rw metric? uint32
+--rw flag* prefix-flag-type +--rw flag* prefix-flag-type
augment /nd:networks/nd:network/lnk:link: augment /nd:networks/nd:network/lnk:link:
+--rw l3-link-attributes +--rw l3-link-attributes
+--rw name? string +--rw name? string
+--rw flag* link-flag-type +--rw flag* link-flag-type
+--rw metric? uint32 +--rw metric1? uint64
augment /nd:networks/nd:network/nd:node/lnk:termination-point: +--rw metric2? uint64
+--rw l3-termination-point-attributes augment /nd:networks/nd:network/nd:node/lnk:termination-point:
+--rw (termination-point-type)? +--rw l3-termination-point-attributes
+--:(ip) +--rw (termination-point-type)?
| +--rw ip-address* inet:ip-address +--:(ip)
+--:(unnumbered) | +--rw ip-address* inet:ip-address
| +--rw unnumbered-id? uint32 +--:(unnumbered)
+--:(interface-name) | +--rw unnumbered-id? uint32
+--ro interface-name? string +--:(interface-name)
+--rw interface-name? string
The module augments the original ietf-network and ietf-network- The module augments the original ietf-network and ietf-network-
topology modules as follows: topology modules as follows:
o A new network topology type is introduced, l3-unicast-topology. o A new network topology type is introduced, l3-unicast-topology.
The corresponding container augments the network-types of the The corresponding container augments the network-types of the
ietf-network module. ietf-network module.
o Additional topology attributes are introduced, defined in a o Additional topology attributes are introduced, defined in a
grouping, which augments the "network" list of the network module. grouping, which augments the "network" list of the network module.
skipping to change at page 7, line 31 skipping to change at page 7, line 29
clients of any events concerning links, nodes, prefixes, and clients of any events concerning links, nodes, prefixes, and
termination points. Each notification includes an indication of the termination points. Each notification includes an indication of the
type of event, the topology from which it originated, and the type of event, the topology from which it originated, and the
affected node, or link, or prefix, or termination point. In affected node, or link, or prefix, or termination point. In
addition, as a convenience to applications, additional data of the addition, as a convenience to applications, additional data of the
affected node, or link, or termination point (respectively) is affected node, or link, or termination point (respectively) is
included. While this makes notifications larger in volume than they included. While this makes notifications larger in volume than they
would need to be, it avoids the need for subsequent retrieval of would need to be, it avoids the need for subsequent retrieval of
context information, which also might have changed in the meantime. context information, which also might have changed in the meantime.
5. Layer 3 Unicast Topology YANG Module 6. Layer 3 Unicast Topology YANG Module
<CODE BEGINS> file "ietf-l3-unicast-topology@2017-07-02.yang" <CODE BEGINS> file "ietf-l3-unicast-topology@2017-09-19.yang"
module ietf-l3-unicast-topology { module ietf-l3-unicast-topology {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology"; "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology";
prefix "l3t"; prefix "l3t";
import ietf-network { import ietf-network {
prefix "nd"; prefix "nd";
} }
import ietf-network-topology { import ietf-network-topology {
prefix "lnk"; prefix "lnk";
} }
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
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/>
WG List: <mailto:i2rs@ietf.org> 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 Editor: Alexander Clemm
<mailto:ludwig@clemm.org> <mailto:ludwig@clemm.org>
Editor: Jan Medved Editor: Jan Medved
<mailto:jmedved@cisco.com> <mailto:jmedved@cisco.com>
Editor: Robert Varga Editor: Robert Varga
<mailto:robert.varga@pantheon.sk> <mailto:robert.varga@pantheon.sk>
Editor: Xufeng Liu Editor: Xufeng Liu
<mailto:xliu@kuatrotech.com> <mailto:xliu@kuatrotech.com>
Editor: Nitin Bahadur Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com> <mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>"; <mailto:hari@packetdesign.com>";
skipping to change at page 8, line 33 skipping to change at page 8, line 27
topologies. topologies.
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2017 IETF Trust and the persons identified as
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-l3-topology-10; draft-ietf-i2rs-yang-l3-topology-11;
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-l3-topology-10 with RFC draft-ietf-i2rs-yang-l3-topology-11 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision "2017-07-02" { revision "2017-09-19" {
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-l3-topology-10 with to draft-ietf-i2rs-yang-l3-topology-11 with
RFC number when published (i.e. RFC xxxx)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-l3-topology-10"; "draft-ietf-i2rs-yang-l3-topology-11";
} }
identity flag-identity { identity flag-identity {
description "Base type for flags"; description "Base type for flags";
} }
typedef l3-event-type { typedef l3-event-type {
type enumeration { type enumeration {
enum "add" { enum "add" {
description description
"An Layer 3 node or link or prefix or termination-point has "An Layer 3 node or link or prefix or termination-point has
been added"; been added";
} }
enum "remove" { enum "remove" {
description description
"An Layer 3 node or link or prefix or termination-point has "An Layer 3 node or link or prefix or termination-point has
skipping to change at page 11, line 44 skipping to change at page 11, line 38
leaf name { leaf name {
type string; type string;
description description
"Link Name"; "Link Name";
} }
leaf-list flag { leaf-list flag {
type link-flag-type; type link-flag-type;
description description
"Link flags"; "Link flags";
} }
leaf metric { leaf metric1 {
type uint32; type uint64;
description description
"Link Metric"; "Link Metric 1";
}
leaf metric2 {
type uint64;
description
"Link Metric 2";
} }
} }
} }
grouping l3-termination-point-attributes { grouping l3-termination-point-attributes {
description "L3 termination point scope attributes"; description "L3 termination point scope attributes";
container l3-termination-point-attributes { container l3-termination-point-attributes {
description description
"Containing termination point attributes"; "Containing termination point attributes";
choice termination-point-type { choice termination-point-type {
description description
skipping to change at page 15, line 4 skipping to change at page 14, line 51
"Notification event for L3 termination point"; "Notification event for L3 termination point";
leaf l3-event-type { leaf l3-event-type {
type l3-event-type; type l3-event-type;
description description
"Event type"; "Event type";
} }
uses lnk:tp-ref; uses lnk:tp-ref;
uses l3-unicast-topology-type; uses l3-unicast-topology-type;
uses l3-termination-point-attributes; uses l3-termination-point-attributes;
} }
} }
<CODE ENDS> <CODE ENDS>
6. Extending the Model
The model can be extended for specific Layer 3 Unicast types.
Examples include OSPF and IS-IS topologies. In the following, two
additional YANG modules are introduced that define simple topology
models for OSPF and IS-IS, respectively. These modules intended to
serve as examples that illustrate how the general topology model can
be refined across multiple levels; they do not constitute full-
fledged OSPF and IS-IS topology models which may be more
comprehensive and refined than the models that are described here.
6.1. Example 1: OSPF Topology
6.1.1. Model Overview
The following model shows how the Layer 3 Unicast topology model can
be extended to cover OSFP topologies. For this purpose, a set of
augmentations are introduced in a separate YANG module, "example-
ietf-ospf-topology", whose structure is depicted in the following
diagram. Like before, brackets enclose list keys, "rw" means
configuration, "ro" operational state data, "?" designates optional
nodes, "*" designates nodes that can have multiple instances.
Parantheses enclose choice and case nodes. A "+" at the end of a
line indicates a line break.
module: example-ietf-ospf-topology
augment /nd:networks/nd:network/nd:network-types/+
l3t:l3-unicast-topology:
+--rw ospf!
augment /nd:networks/nd:network/l3t:l3-topology-attributes:
+--rw ospf-topology-attributes
+--rw area-id? area-id-type
augment /nd:networks/nd:network/nd:node/l3t:l3-node-attributes:
+--rw ospf-node-attributes
+--rw (router-type)?
| +--:(abr)
| | +--rw abr? empty
| +--:(asbr)
| | +--rw asbr? empty
| +--:(internal)
| | +--rw internal? empty
| +--:(pseudonode)
| +--rw pseudonode? empty
+--rw dr-interface-id? uint32
+--rw multi-topology-id* uint8
augment /nd:networks/nd:network/lnk:link/l3t:l3-link-attributes:
+--rw ospf-link-attributes
+--rw multi-topology-id? uint8
augment /l3t:l3-node-event:
+---- ospf!
+---- ospf-node-attributes
+---- (router-type)?
| +--:(abr)
| | +---- abr? empty
| +--:(asbr)
| | +---- asbr? empty
| +--:(internal)
| | +---- internal? empty
| +--:(pseudonode)
| +---- pseudonode? empty
+---- dr-interface-id? uint32
+---- multi-topology-id* uint8
augment /l3t:l3-link-event:
+---- ospf!
+---- ospf-link-attributes
+---- multi-topology-id? uint8
The module augments "ietf-l3-unicast-topology" as follows:
o A new topology type for an OSPF topology is introduced.
o Additional topology attributes are defined in a new grouping which
augments l3-topology-attributes of the ietf-l3-unicast-topology
module. The attributes include an OSPF area-id identifying the
OSPF area.
o Additional data objects for nodes are introduced by augmenting the
l3-node-attributes of the l3-unicast-topology module. New objects
include router-type, dr-interface-id for pseudonodes, list of
multi-topology-ids, ospf node capabilities, and traffic
engineering attributes.
o Links are augmented with a multi-topology-id and traffic
engineering link attributes.
o Prefixes are augmented with OSPF specific forwarding address.
In addition, the module extends notifications for events concerning
Layer 3 nodes, links, termination points, and prefixes with OSPF
attributes.
It should be noted that the model defined here represents topology
and is intended as an example. It does not define how to configure
OSPF routers or interfaces.
6.1.2. OSPF Topology YANG Module
The OSPF Topology YANG Module is specified below. As mentioned, the
module is intended as an example for how the Layer 3 Unicast topology
model can be extended to cover OSFP topologies, but it is not
normative. Accordingly, the module is not delimited with CODE BEGINS
and CODE ENDS tags.
file "example-ietf-ospf-topology@2017-07-02.yang"
module example-ietf-ospf-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology";
prefix "ospft";
import ietf-yang-types {
prefix "yang";
}
import ietf-network {
prefix "nd";
}
import ietf-network-topology {
prefix "lnk";
}
import ietf-l3-unicast-topology {
prefix "l3t";
}
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: Xufeng Liu
<mailto:xliu@kuatrotech.com>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>";
description
"This module defines a model for OSPF network topologies.
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-l3-topology-10;
see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-l3-topology-10 with RFC
number when published (i.e. RFC xxxx).";
revision "2017-07-02" {
description
"Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-l3-topology-10 with
RFC number when published (i.e. RFC xxxx).";
reference
"draft-ietf-i2rs-yang-l3-topology-10";
}
typedef area-id-type {
type yang:dotted-quad;
description
"Area ID type.";
}
grouping ospf-topology-type {
description
"Identifies the OSPF topology type.";
container ospf {
presence "indiates OSPF Topology";
description
"Its presence identifies the OSPF topology type.";
}
}
augment "/nd:networks/nd:network/nd:network-types/"
+ "l3t:l3-unicast-topology" {
description
"Defines the OSPF topology type.";
uses ospf-topology-type;
}
augment "/nd:networks/nd:network/l3t:l3-topology-attributes" {
when "../nd:network-types/l3t:l3-unicast-topology/ospf" {
description
"Augment only for OSPF topology";
}
description
"Augment topology configuration";
container ospf-topology-attributes {
description
"Containing topology attributes";
leaf area-id {
type area-id-type;
description
"OSPF area ID";
}
}
}
augment "/nd:networks/nd:network/nd:node/l3t:l3-node-attributes" {
when "../../nd:network-types/l3t:l3-unicast-topology/ospf" {
description
"Augment only for OSPF topology";
}
description
"Augment node configuration";
uses ospf-node-attributes;
}
augment "/nd:networks/nd:network/lnk:link/l3t:l3-link-attributes" {
when "../../nd:network-types/l3t:l3-unicast-topology/ospf" {
description
"Augment only for OSPF topology";
}
description
"Augment link configuration";
uses ospf-link-attributes;
}
grouping ospf-node-attributes {
description
"OSPF node scope attributes";
container ospf-node-attributes {
description
"Containing node attributes";
choice router-type {
description
"Indicates router type";
case abr {
leaf abr {
type empty;
description
"The node is ABR";
}
}
case asbr {
leaf asbr {
type empty;
description
"The node is ASBR";
}
}
case internal {
leaf internal {
type empty;
description
"The node is internal";
}
}
case pseudonode {
leaf pseudonode {
type empty;
description
"The node is pseudonode";
}
}
}
leaf dr-interface-id {
when "../pseudonode" {
description
"Valid only for pseudonode";
}
type uint32;
default "0";
description
"For pseudonodes, DR interface-id";
}
leaf-list multi-topology-id {
type uint8 {
range "0..127";
}
max-elements "128";
description
"List of Multi-Topology Identifier up-to 128 (0-127).
See RFC 4915";
}
}
}
grouping ospf-link-attributes {
description
"OSPF link scope attributes";
container ospf-link-attributes {
description
"Containing OSPF link attributes";
leaf multi-topology-id {
type uint8 {
range "0..127";
}
description "Multi topology ID";
}
}
} // ospf-link-attributes
augment "/l3t:l3-node-event" {
description
"OSPF node event";
uses ospf-topology-type;
uses ospft:ospf-node-attributes;
}
augment "/l3t:l3-link-event" {
description
"OSPF link event";
uses ospf-topology-type;
uses ospft:ospf-link-attributes;
}
}
6.2. Example 2: IS-IS Topology
6.2.1. Model Overview
IS-IS topologies are another type of Layer 3 Unicast topology. Like
in the case of OSPF topology, a model for IS-IS topology can be
defined in a separate module which augments "ietf-l3-unicast-igp-
topology". The structure of a corresponding model, "ietf-isis-
topology", is depicted in the following diagram. Like before,
brackets enclose list keys, "rw" means configuration, "ro"
operational state data, "?" designates optional nodes, "*" designates
nodes that can have multiple instances. Parantheses enclose choice
and case nodes. A "+" at the end of a line indicates a line break.
module: example-ietf-isis-topology
augment /nd:networks/nd:network/nd:network-types/+
l3t:l3-unicast-topology:
+--rw isis!
augment /nd:networks/nd:network/l3t:l3-topology-attributes:
+--rw isis-topology-attributes
+--rw net? area-address
augment /nd:networks/nd:network/nd:node/l3t:l3-node-attributes:
+--rw isis-node-attributes
+--rw iso
| +--rw iso-system-id? system-id
| +--rw iso-pseudonode-id? iso-pseudonode-id
+--rw net* area-address
+--rw multi-topology-id* uint16
+--rw level? level
augment /nd:networks/nd:network/lnk:link/l3t:l3-link-attributes:
+--rw isis-link-attributes
+--rw multi-topology-id? uint16
augment /l3t:l3-node-event:
+---- isis!
+---- isis-node-attributes
+---- iso
| +---- iso-system-id? system-id
| +---- iso-pseudonode-id? iso-pseudonode-id
+---- net* area-address
+---- multi-topology-id* uint16
+---- level? level
augment /l3t:l3-link-event:
+---- isis!
+---- isis-link-attributes
+---- multi-topology-id? uint16
The module augments the ietf-l3-unicast-topology as follows:
o A new topology type is introduced for isis.
o Additional topology attributes are introduced in a new grouping
which augments "topology-attributes" of the ietf-l3-unicast-
topology module. The attributes include an ISIS NET-id
identifying the area.
o Additional data objects for nodes are introduced by augmenting
"node-attributes" of the ietf-l3-unicast-topology module. New
objects include router-type, iso-system-id to identify the router,
a list of multi-topology-id, a list of NET ids, and traffic
engineering attributes.
o Links are augmented with multi-topology-id and traffic engineering
link attributes.
In addition, the module augments nodes and links with IS-IS
attributes.
Again, it should be noted that the model defined here represents a
topology and is intended as an example. It does not define how to
configure IS-IS routers or interfaces.
6.2.2. IS-IS Topology YANG Module
The IS-IS Topology YANG Module is specified as follows. As
mentioned, the module is intended as an example for how the Layer 3
Unicast topology model can be extended to cover IS-IS topologies, but
it is not normative. Accordingly, the module is not delimited with
CODE BEGINS and CODE ENDS tags.
file "example-ietf-isis-topology@2017-07-02.yang"
module example-ietf-isis-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:example-ietf-isis-topology";
prefix "isist";
import ietf-network {
prefix "nd";
}
import ietf-network-topology {
prefix "lnk";
}
import ietf-l3-unicast-topology {
prefix "l3t";
}
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: Xufeng Liu
<mailto:xliu@kuatrotech.com>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>";
description
"This module defines a model for IS-IS network topologies.
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-l3-topology-10;
see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-l3-topology-10 with RFC
number when published (i.e. RFC xxxx).";
revision "2017-07-02" {
description
"Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-l3-topology-10 with
RFC number when published (i.e. RFC xxxx).";
reference
draft-ietf-i2rs-yang-l3-topology-10;
}
typedef iso-pseudonode-id {
type string {
pattern '[0-9a-fA-F]{2}';
}
description
"ISO pseudonode id for broadcast network.";
}
typedef area-address{
type string {
pattern '[0-9A-Fa-f]{2}\.([0-9A-Fa-f]{4}\.){0,3}';
}
description
"This type defines the area address.";
}
typedef system-id {
type string {
pattern
'[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}';
}
description
"This type defines ISIS system id using a pattern;
an example of a system id looks like: 0143.0438.AeF0.";
}
typedef level {
type enumeration {
enum "level-1" {
description
"This enum describes L1 only capability.";
}
enum "level-2" {
description
"This enum describes L2 only capability.";
}
enum "level-all" {
description
"This enum describes both levels (L1 and L2) capability.";
}
}
default "level-all";
description
"This type defines the ISIS level of an object.";
}
grouping isis-topology-type {
description
"Identifies the ISIS topology type.";
container isis {
presence "Indicates ISIS Topology";
description
"Its presence identifies the ISIS topology type.";
}
}
augment "/nd:networks/nd:network/nd:network-types/"
+"l3t:l3-unicast-topology" {
description
"Defines the ISIS topology type.";
uses isis-topology-type;
}
augment "/nd:networks/nd:network/l3t:l3-topology-attributes" {
when "../nd:network-types/l3t:l3-unicast-topology/isis" {
description
"Augment only for ISIS topology";
}
description
"Augment topology configuration";
container isis-topology-attributes {
description
"Containing topology attributes";
leaf net {
type area-address;
description
"ISO NET ID value";
}
}
}
augment "/nd:networks/nd:network/nd:node/"+
"l3t:l3-node-attributes" {
when "../../nd:network-types/l3t:l3-unicast-topology/isis" {
description
"Augment only for ISIS topology";
}
description
"Augment node configuration";
uses isis-node-attributes;
}
augment "/nd:networks/nd:network/lnk:link/l3t:l3-link-attributes" {
when "../../nd:network-types/l3t:l3-unicast-topology/isis" {
description
"Augment only for ISIS topology";
}
description
"Augment link configuration";
uses isis-link-attributes;
}
grouping isis-node-attributes {
description
"ISIS node scope attributes";
container isis-node-attributes {
description
"Containing node attributes";
container iso {
description
"Containing ISO atrributes";
leaf iso-system-id {
type system-id;
description
"ISO system ID";
}
leaf iso-pseudonode-id {
type iso-pseudonode-id;
default "00";
description
"Pseudonode ID";
}
}
leaf-list net {
type area-address;
max-elements 3;
description
"List of ISO NET IDs";
}
leaf-list multi-topology-id {
type uint16 {
range "0..4095";
}
max-elements "128";
description
"List of Multi Topology Identifier up to 128 (0-127).
RFC 4915";
}
leaf level {
type level;
description "Level 1, Level 2 or Level 1 and 2";
}
}
}
grouping isis-link-attributes {
description
"ISIS link scope attributes";
container isis-link-attributes {
description
"Containing link attributes";
leaf multi-topology-id {
type uint16 {
range "0..4095";
}
description
"Multi topology ID";
}
}
}
augment "/l3t:l3-node-event" {
description
"ISIS node event";
uses isis-topology-type;
uses isis-node-attributes;
}
augment "/l3t:l3-link-event" {
description
"ISIS link event";
uses isis-topology-type;
uses isis-link-attributes;
}
}
7. Interactions with Other YANG Modules 7. Interactions with Other YANG Modules
As described in section Section 3, the model builds on top of, and As described in section Section 4, the model builds on top of, and
augments, the YANG modules defined in augments, the YANG modules defined in
[I-D.draft-ietf-i2rs-yang-network-topo]. Specifically, module ietf- [I-D.draft-ietf-i2rs-yang-network-topo]. Specifically, module ietf-
l3-unicast-topology augments modules "ietf-network" and "ietf- l3-unicast-topology augments modules "ietf-network" and "ietf-
network-topology". In addition, the model makes use of data types network-topology". In addition, the model makes use of data types
that have been defined in [RFC6991]. that have been defined in [RFC6991].
The moodel defines a protocol independent YANG data model with layer The moodel defines a protocol independent YANG data model with layer
3 topology information. It is separate from and not linked with data 3 topology information. It is separate from and not linked with data
models that are used to configure routing protocols or routing models that are used to configure routing protocols or routing
information. This includes e.g. model "ietf-routing" [RFC8022] and information. This includes e.g. model "ietf-routing" [RFC8022] and
skipping to change at page 29, line 15 skipping to change at page 15, line 47
URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
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.
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-l3-unicast-topology Name: ietf-l3-unicast-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
Prefix: l3t Prefix: l3t
Reference: draft-ietf-i2rs-yang-l3-topology-10.txt (RFC form) Reference: draft-ietf-i2rs-yang-l3-topology-11.txt (RFC form)
Name: ietf-l3-unicast-topology-state Name: ietf-l3-unicast-topology-state
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state
Prefix: l3t-s Prefix: l3t-s
Reference: draft-ietf-i2rs-yang-l3-topology-10.txt (RFC form) Reference: draft-ietf-i2rs-yang-l3-topology-11.txt (RFC form)
9. Security Considerations 9. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module defined in this document is designed to be accessed
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the via network management protocols such as NETCONF [RFC6241] or
secure transport layer, and the mandatory-to-implement secure RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
transport is Secure Shell (SSH) [RFC6242]. The NETCONF access layer, and the mandatory-to-implement secure transport is Secure
control model [RFC6536] provides the means to restrict access for Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the
particular NETCONF users to a pre-configured subset of all available mandatory-to-implement secure transport is TLS [RFC5246].
NETCONF protocol operations and content.
In general, Layer 3 Unicast topologies are server-provided and The NETCONF access control model [RFC6536] provides the means to
provide ephemeral topology information. As they provide read-only restrict access for particular NETCONF or RESTCONF users to a
access to clients, they are less vulnerable. That said, the YANG preconfigured subset of all available NETCONF or RESTCONF protocol
module does in principle allow information to be configurable in operations and content.
certain instances (when the server-provided flag for the topology is
set to false). In such cases, a malicious client could introduce In general, Layer 3 Unicast topologies are system-controlled and
topologies that are undesired. For example, a client could remove or provide ephemeral topology information. In an NMDA-complient server,
add topological links between nodes, which could lead to an undesired they are only part of <operational> which provides read-only access
and suboptimal topology, which might impact service levels and to clients, they are less vulnerable. That said, the YANG module
network utilization. It is therefore important that the NETCONF does in principle allow information to be configurable.
access control model is vigorously applied to prevent topology
configuration by unauthorized clients. There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability in the ietf-network module:
l3-topology-attributes: A malicious client could attempt to
sabotage the configuration of any of the ctonained attributes,
i.e. the name or the flag data nodes.
l3-node-attributes: A malicious client could attempt to sabotage
the configuration of important node attributes, such as the
router-id or node prefix.
l3-link-attributes: A malicious client could attempt to sabotage
the configuration of important link attributes, such as name,
flag, and metrics of the link respectively corresponding data
nodes.
l3-termination-point-attributes: A malicious client could attempt
to sabotage the configuration information of a termination point,
such as its ip-address and interface name, respectively the
corresponding data nodes.
10. Contributors 10. Contributors
The model presented in this paper was contributed to by more people The model presented in this document was contributed to by more
than can be listed on the author list. Additional contributors people than can be listed on the author list. Additional
include: contributors include:
o Vishnu Pavan Beeram, Juniper o Vishnu Pavan Beeram, Juniper
o Igor Bryskin, Huawei o Igor Bryskin, Huawei
o Ken Gray, Cisco o Ken Gray, Cisco
o Aihua Guo, Huawei o Aihua Guo, Huawei
o Tom Nadeau, Brocade o Tom Nadeau, Brocade
o Tony Tkacik o Tony Tkacik
skipping to change at page 30, line 19 skipping to change at page 17, line 28
o Tom Nadeau, Brocade o Tom Nadeau, Brocade
o Tony Tkacik o Tony Tkacik
o Aleksandr Zhdankin, Cisco o Aleksandr Zhdankin, Cisco
11. Acknowledgements 11. Acknowledgements
We wish to acknowledge the helpful contributions, comments, and We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Ladislav Lhotka, Andy Bierman, suggestions that were received from Alia Atlas, Andy Bierman, Benoit
Carlos Pignataro, Joel Halpern, Juergen Schoenwaelder, Alia Atlas, Claise, Joel Halpern, Susan Hares, Ladislav Lhotka, Carl Moberg,
Susan Hares, Benoit Claise, and Carl Moberg. Carlos Pignataro, Juergen Schoenwaelder, and Kent Watsen.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.draft-ietf-i2rs-yang-network-topo] [I-D.draft-ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Bahadur, N., Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", I-D draft-ietf-i2rs-yang-network- Network Topologies", I-D draft-ietf-i2rs-yang-network-
topo-14, June 2017. topo-16, September 2017.
[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.
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC 1195, December 1990. Dual Environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000. MIB", RFC 2863, June 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004. 2004.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011. RFC 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. Shell (SSH)", RFC 6242, June 2011.
skipping to change at page 31, line 43 skipping to change at page 19, line 5
[I-D.draft-ietf-i2rs-ephemeral-state] [I-D.draft-ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", I-D draft-ietf-i2rs-ephemeral-state-23, Requirements", I-D draft-ietf-i2rs-ephemeral-state-23,
November 2016. November 2016.
[I-D.draft-ietf-i2rs-usecase-reqs-summary] [I-D.draft-ietf-i2rs-usecase-reqs-summary]
Hares, S. and M. Chen, "Summary of I2RS Use Case Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary-
03, November 2016. 03, November 2016.
[I-D.draft-ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", I-D
draft-ietf-netmod-yang-tree-diagrams, June 2017.
[I-D.draft-ietf-teas-yang-te-topo] [I-D.draft-ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez De Dios, "YANG Data Model for TE Topologies", O. Gonzalez De Dios, "YANG Data Model for TE Topologies",
I-D draft-ietf-teas-yang-te-topo-09, June 2017. I-D draft-ietf-teas-yang-te-topo-09, June 2017.
[RFC7223] Bjorklund, M., "A YANG Data Model for Routing Management", [RFC7223] Bjorklund, M., "A YANG Data Model for Routing Management",
RFC 7223, May 2014. RFC 7223, May 2014.
[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", RFC 8022, November 2016. Management", RFC 8022, November 2016.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, January 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017.
Appendix A. Companion YANG model for non-NMDA compliant implementations Appendix A. Companion YANG model for non-NMDA compliant implementations
The YANG module ietf-l3-unicast-topology defined in this document The YANG module ietf-l3-unicast-topology defined in this document
augments two modules, ietf-network and ietf-network-topology, that augments two modules, ietf-network and ietf-network-topology, that
are designed to be used in conjunction with implementations that are designed to be used in conjunction with implementations that
support the Network Management Datastore Architecture (NMDA) defined support the Network Management Datastore Architecture (NMDA) defined
in [I-D.draft-ietf-netmod-revised-datastores]. In order to allow in [I-D.draft-ietf-netmod-revised-datastores]. In order to allow
implementations to use the model even in cases when NMDA is not implementations to use the model even in cases when NMDA is not
supported, a set of companion modules have been defined that supported, a set of companion modules have been defined that
represent a state model of networks and network topologies, ietf- represent a state model of networks and network topologies, ietf-
skipping to change at page 32, line 27 skipping to change at page 20, line 27
In order to be able to use the model for layer 3 topologies defined In order to be able to use the model for layer 3 topologies defined
in this in this document in conjunction with non-NMDA compliant in this in this document in conjunction with non-NMDA compliant
implementations, a corresponding companion module needs to be implementations, a corresponding companion module needs to be
introduced as well. This companion module, ietf-l3-unicast-topology- introduced as well. This companion module, ietf-l3-unicast-topology-
state, mirrors ietf-l3-unicast-topology. However, the module state, mirrors ietf-l3-unicast-topology. However, the module
augments ietf-network-state and ietf-network-topology-state (instead augments ietf-network-state and ietf-network-topology-state (instead
of ietf-network and ietf-network-state) and all of its data nodes are of ietf-network and ietf-network-state) and all of its data nodes are
non-configurable. non-configurable.
Similar considerations apply for any modules that augment ietf-l3- Similar considerations apply for any modules that augment ietf-l3-
unicast-topology, such as the example modules defined earlier, unicast-topology, such as the example modules defined in see
example-ietf-ospf-topology and example-ietf-isis-topology. For non- Appendix B, example-ietf-ospf-topology. For non-NMDA compliant
NMDA compliant implementations, companion modules will need to be implementations, companion modules will need to be introduced that
introduced that represent state information and are non-configurable, represent state information and are non-configurable, augmenting
augmenting ietf-l3-unicast-topology-state instead of ietf-l3-unicast- ietf-l3-unicast-topology-state instead of ietf-l3-unicast-topology.
topology. Because they served as examples only, companion modules Because they served as examples only, companion modules for those
for those examples are not given. examples are not given.
Like ietf-network-state and ietf-network-topology-state, ietf-l3- Like ietf-network-state and ietf-network-topology-state, ietf-l3-
unicast-topology SHOULD NOT be supported by implementations that unicast-topology SHOULD NOT be supported by implementations that
support NMDA. It is for this reason that the module is defined in support NMDA. It is for this reason that the module is defined in
the Appendix. the Appendix.
The definition of the module follows below. As the structure of the The definition of the module follows below. As the structure of the
module mirrors that of its underlying module, the YANG tree is not module mirrors that of its underlying module, the YANG tree is not
depicted separately. depicted separately.
<CODE BEGINS> file "ietf-l3-unicast-topology-state@2017-07-02.yang" <CODE BEGINS> file "ietf-l3-unicast-topology-state@2017-09-19.yang"
module ietf-l3-unicast-topology-state { module ietf-l3-unicast-topology-state {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state"; "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state";
prefix "l3t-s"; prefix "l3t-s";
import ietf-network-state { import ietf-network-state {
prefix "nd-s"; prefix "nd-s";
} }
import ietf-network-topology-state { import ietf-network-topology-state {
prefix "lnk-s"; prefix "lnk-s";
} }
import ietf-l3-unicast-topology { import ietf-l3-unicast-topology {
prefix "l3t"; prefix "l3t";
} }
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/>
WG List: <mailto:i2rs@ietf.org> 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 Editor: Alexander Clemm
<mailto:ludwig@clemm.org> <mailto:ludwig@clemm.org>
Editor: Jan Medved Editor: Jan Medved
<mailto:jmedved@cisco.com> <mailto:jmedved@cisco.com>
Editor: Robert Varga Editor: Robert Varga
<mailto:robert.varga@pantheon.sk> <mailto:robert.varga@pantheon.sk>
Editor: Xufeng Liu Editor: Xufeng Liu
<mailto:xliu@kuatrotech.com> <mailto:xliu@kuatrotech.com>
Editor: Nitin Bahadur Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com> <mailto:nitin_bahadur@yahoo.com>
skipping to change at page 34, line 4 skipping to change at page 21, line 48
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2017 IETF Trust and the persons identified as
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-l3-topology-10; draft-ietf-i2rs-yang-l3-topology-11;
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-l3-topology-10 with RFC draft-ietf-i2rs-yang-l3-topology-11 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision "2017-07-02" { revision "2017-09-19" {
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-l3-topology-10 with to draft-ietf-i2rs-yang-l3-topology-11 with
RFC number when published (i.e. RFC xxxx)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-l3-topology-10"; "draft-ietf-i2rs-yang-l3-topology-11";
} }
augment "/nd-s:networks/nd-s:network/nd-s:network-types" { augment "/nd-s:networks/nd-s:network/nd-s:network-types" {
description description
"Introduce new network type for L3 unicast topology"; "Introduce new network type for L3 unicast topology";
uses l3t:l3-unicast-topology-type; uses l3t:l3-unicast-topology-type;
} }
augment "/nd-s:networks/nd-s:network" { augment "/nd-s:networks/nd-s:network" {
when "nd-s:network-types/l3-unicast-topology" { when "nd-s:network-types/l3-unicast-topology" {
description description
skipping to change at page 36, line 24 skipping to change at page 24, line 20
"Event type"; "Event type";
} }
uses lnk-s:tp-ref; uses lnk-s:tp-ref;
uses l3t:l3-unicast-topology-type; uses l3t:l3-unicast-topology-type;
uses l3t:l3-termination-point-attributes; uses l3t:l3-termination-point-attributes;
} }
} }
<CODE ENDS> <CODE ENDS>
Appendix B. Extending the Model
The model can be extended for specific Layer 3 Unicast types.
Examples include OSPF and IS-IS topologies. In the following, one
additional YANG module is introduced that define simple topology
model for OSPF. This module is intended to serve as an example that
illustrates how the general topology model can be refined across
multiple levels. It does not constitute full-fledged OSPF topology
model which may be more comprehensive and refined than the model that
is described here.
B.1. Example OSPF Topology
B.1.1. Model Overview
The following model shows how the Layer 3 Unicast topology model can
be extended to cover OSFP topologies. For this purpose, a set of
augmentations are introduced in a separate YANG module, "example-
ietf-ospf-topology", whose structure is depicted in the following
diagram. As before, the notation syntax follows
[I-D.draft-ietf-netmod-yang-tree-diagrams].
module: example-ietf-ospf-topology
augment /nd:networks/nd:network/nd:network-types/l3t:l3-unicast-topology:
+--rw ospf!
augment /nd:networks/nd:network/l3t:l3-topology-attributes:
+--rw ospf-topology-attributes
+--rw area-id? area-id-type
augment /nd:networks/nd:network/nd:node/l3t:l3-node-attributes:
+--rw ospf-node-attributes
+--rw (router-type)?
| +--:(abr)
| | +--rw abr? empty
| +--:(asbr)
| | +--rw asbr? empty
| +--:(internal)
| | +--rw internal? empty
| +--:(pseudonode)
| +--rw pseudonode? empty
+--rw dr-interface-id? uint32
augment /nd:networks/nd:network/lnk:link/l3t:l3-link-attributes:
+--rw ospf-link-attributes
augment /l3t:l3-node-event:
+---- ospf!
+---- ospf-node-attributes
+---- (router-type)?
| +--:(abr)
| | +---- abr? empty
| +--:(asbr)
| | +---- asbr? empty
| +--:(internal)
| | +---- internal? empty
| +--:(pseudonode)
| +---- pseudonode? empty
+---- dr-interface-id? uint32
augment /l3t:l3-link-event:
+---- ospf!
+---- ospf-link-attributes
The module augments "ietf-l3-unicast-topology" as follows:
o A new topology type for an OSPF topology is introduced.
o Additional topology attributes are defined in a new grouping which
augments l3-topology-attributes of the ietf-l3-unicast-topology
module. The attributes include an OSPF area-id identifying the
OSPF area.
o Additional data objects for nodes are introduced by augmenting the
l3-node-attributes of the l3-unicast-topology module. New objects
include router-type and dr-interface-id for pseudonodes.
o Links are augmented with ospf link attributes.
In addition, the module extends notifications for events concerning
Layer 3 nodes and links with OSPF attributes.
It should be noted that the model defined here represents topology
and is intended as an example. It does not define how to configure
OSPF routers or interfaces.
B.1.2. OSPF Topology YANG Module
The OSPF Topology YANG Module is specified below. As mentioned, the
module is intended as an example for how the Layer 3 Unicast topology
model can be extended to cover OSFP topologies, but it is not
normative. Accordingly, the module is not delimited with CODE BEGINS
and CODE ENDS tags.
file "example-ietf-ospf-topology@2017-09-19.yang"
module example-ietf-ospf-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology";
prefix "ospft";
import ietf-yang-types {
prefix "yang";
}
import ietf-network {
prefix "nd";
}
import ietf-network-topology {
prefix "lnk";
}
import ietf-l3-unicast-topology {
prefix "l3t";
}
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>
Editor: Alexander Clemm
<mailto:ludwig@clemm.org>
Editor: Jan Medved
<mailto:jmedved@cisco.com>
Editor: Robert Varga
<mailto:robert.varga@pantheon.sk>
Editor: Xufeng Liu
<mailto:xliu@kuatrotech.com>
Editor: Nitin Bahadur
<mailto:nitin_bahadur@yahoo.com>
Editor: Hariharan Ananthakrishnan
<mailto:hari@packetdesign.com>";
description
"This module defines a model for OSPF network topologies.
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-l3-topology-11;
see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-l3-topology-11 with RFC
number when published (i.e. RFC xxxx).";
revision "2017-09-19" {
description
"Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-l3-topology-11 with
RFC number when published (i.e. RFC xxxx).";
reference
"draft-ietf-i2rs-yang-l3-topology-11";
}
typedef area-id-type {
type yang:dotted-quad;
description
"Area ID type.";
}
grouping ospf-topology-type {
description
"Identifies the OSPF topology type.";
container ospf {
presence "indiates OSPF Topology";
description
"Its presence identifies the OSPF topology type.";
}
}
augment "/nd:networks/nd:network/nd:network-types/"
+ "l3t:l3-unicast-topology" {
description
"Defines the OSPF topology type.";
uses ospf-topology-type;
}
augment "/nd:networks/nd:network/l3t:l3-topology-attributes" {
when "../nd:network-types/l3t:l3-unicast-topology/ospf" {
description
"Augment only for OSPF topology";
}
description
"Augment topology configuration";
container ospf-topology-attributes {
description
"Containing topology attributes";
leaf area-id {
type area-id-type;
description
"OSPF area ID";
}
}
}
augment "/nd:networks/nd:network/nd:node/l3t:l3-node-attributes" {
when "../../nd:network-types/l3t:l3-unicast-topology/ospf" {
description
"Augment only for OSPF topology";
}
description
"Augment node configuration";
uses ospf-node-attributes;
}
augment "/nd:networks/nd:network/lnk:link/l3t:l3-link-attributes" {
when "../../nd:network-types/l3t:l3-unicast-topology/ospf" {
description
"Augment only for OSPF topology";
}
description
"Augment link configuration";
uses ospf-link-attributes;
}
grouping ospf-node-attributes {
description
"OSPF node scope attributes";
container ospf-node-attributes {
description
"Containing node attributes";
choice router-type {
description
"Indicates router type";
case abr {
leaf abr {
type empty;
description
"The node is ABR";
}
}
case asbr {
leaf asbr {
type empty;
description
"The node is ASBR";
}
}
case internal {
leaf internal {
type empty;
description
"The node is internal";
}
}
case pseudonode {
leaf pseudonode {
type empty;
description
"The node is pseudonode";
}
}
}
leaf dr-interface-id {
when "../pseudonode" {
description
"Valid only for pseudonode";
}
type uint32;
default "0";
description
"For pseudonodes, DR interface-id";
}
}
}
grouping ospf-link-attributes {
description
"OSPF link scope attributes";
container ospf-link-attributes {
description
"Containing OSPF link attributes";
}
} // ospf-link-attributes
augment "/l3t:l3-node-event" {
description
"OSPF node event";
uses ospf-topology-type;
uses ospft:ospf-node-attributes;
}
augment "/l3t:l3-link-event" {
description
"OSPF link event";
uses ospf-topology-type;
uses ospft:ospf-link-attributes;
}
}
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Huawei Huawei
EMail: ludwig@clemm.org EMail: ludwig@clemm.org
Jan Medved Jan Medved
Cisco Cisco
 End of changes. 55 change blocks. 
762 lines changed or deleted 460 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/