draft-ietf-i2rs-yang-l3-topology-06.txt   draft-ietf-i2rs-yang-l3-topology-07.txt 
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft Sympotech Internet-Draft Huawei
Intended status: Standards Track J. Medved Intended status: Standards Track J. Medved
Expires: June 3, 2017 Cisco Expires: July 7, 2017 Cisco
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
X. Liu X. Liu
Ericsson Ericsson
I. Bryskin
Huawei
A. Guo
Adva Optical
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
V. Beeram January 3, 2017
Juniper Networks
November 30, 2016
A YANG Data Model for Layer 3 Topologies A YANG Data Model for Layer 3 Topologies
draft-ietf-i2rs-yang-l3-topology-06.txt draft-ietf-i2rs-yang-l3-topology-07.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.
skipping to change at page 1, line 46 skipping to change at page 1, line 40
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 June 3, 2017. This Internet-Draft will expire on July 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4 3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4
4. Layer 3 Unicast Topology Model Overview . . . . . . . . . . . 5 4. Layer 3 Unicast Topology Model Overview . . . . . . . . . . . 5
5. Layer 3 Unicast Topology YANG Module . . . . . . . . . . . . 7 5. Layer 3 Unicast Topology YANG Module . . . . . . . . . . . . 7
6. Extending the Model . . . . . . . . . . . . . . . . . . . . . 14 6. Extending the Model . . . . . . . . . . . . . . . . . . . . . 14
6.1. Example 1: OSPF Topology . . . . . . . . . . . . . . . . 14 6.1. Example 1: OSPF Topology . . . . . . . . . . . . . . . . 15
6.1.1. Model Overview . . . . . . . . . . . . . . . . . . . 14 6.1.1. Model Overview . . . . . . . . . . . . . . . . . . . 15
6.1.2. OSPF Topology YANG Module . . . . . . . . . . . . . . 16 6.1.2. OSPF Topology YANG Module . . . . . . . . . . . . . . 17
6.2. Example 2: IS-IS Topology . . . . . . . . . . . . . . . . 21 6.2. Example 2: IS-IS Topology . . . . . . . . . . . . . . . . 22
6.2.1. Model Overview . . . . . . . . . . . . . . . . . . . 21 6.2.1. Model Overview . . . . . . . . . . . . . . . . . . . 22
6.2.2. IS-IS Topology YANG Module . . . . . . . . . . . . . 23 6.2.2. IS-IS Topology YANG Module . . . . . . . . . . . . . 23
7. Interactions with Other YANG Modules . . . . . . . . . . . . 28 7. Interactions with Other YANG Modules . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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]. An earlier revision of that This document also shows how the model can be further refined to
Internet Draft contained not just the general model for network cover different Layer 3 Unicast topology types. For this purpose,
topologies, but also the model for layer 3 network topologies that is example models are introduced that cover IS-IS [RFC1195] and OSPF
being specified here. However, we decided to "split" the earlier [RFC2328]. Those examples are intended purely for illustrative
draft to separate the truly general aspects of a topology data model, purposes; we expect that full-blown IS-IS and OSPF models will be
which apply to any type of topology, from the application of this more comprehensive and refined than the examples shown here.
model to a particular domain, here: a Layer 3 network.
The document also shows how the model can be further refined to cover
different Layer 3 Unicast topology types. For this purpose, example
models are introduced that cover IS-IS [RFC1195] and OSPF [RFC2328].
Those examples are intended purely for illustrative purposes; we
expect that full-blown IS-IS and OSPF models will be more
comprehensive and refined than the examples 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
this understanding to compare and reconcile this understanding either this understanding to compare and reconcile this understanding either
amongst themselves or with help of a controller. Beyond the network amongst themselves or with help of a controller. Beyond the network
element itself, a network controller might even use the data model to element itself, a network controller might even use the data model to
represent its view of the topology that it controls and expose it to represent its view of the topology that it controls and expose it to
applications north of itself. applications north of itself.
There are several reasons to choose YANG to define the data model.
Data defined using YANG can be exposed by a server to client
applications and controllers via Netconf [RFC6241]. The fact that
YANG can potentially be used with different protocols and interfaces
provides for a degree of "future-proofing" of model implementations.
Also, YANG can serve as the basis for model-driven toolchains, such
as used in the Open Daylight project [OpenDaylight].
The data model for Layer 3 Unicast topologies defined in this The data model for Layer 3 Unicast topologies defined in this
document is specified in a YANG module "ietf-l3-unicast-topology". document is specified in a YANG module "ietf-l3-unicast-topology".
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) is Information that is kept in the Traffic Engineering Database (TED)
specified in a separate model and outside the scope of this will be specified in a separate model
[I-D.draft-ietf-teas-yang-te-topo] and outside the scope of this
specification. specification.
2. Definitions and Acronyms 2. Definitions and Acronyms
Datastore: A conceptual store of instantiated management information, As this document defines a YANG data model, in this document many
with individual data items represented by data nodes which are terms are used that have been defined in conjunction with YANG
[RFC7950] and Netconf [RFC6241]. Some terms, such as datastore and
data tree, are repeated here for clarity and to put them in context.
Datastore: A conceptual place to store and access information, such
as instantiated YANG data.
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
OSPF: Open Shortest Path First, a link state routing protocol OSPF: Open Shortest Path First, a link state routing protocol
URI: Uniform Resource Identifier URI: Uniform Resource Identifier
skipping to change at page 6, line 32 skipping to change at page 6, line 32
+--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 metric? uint32
augment /nd:networks/nd:network/nd:node/lnk:termination-point: augment /nd:networks/nd:network/nd:node/lnk:termination-point:
+--rw l3-termination-point-attributes +--rw l3-termination-point-attributes
+--rw (termination-point-type)? +--rw (termination-point-type)?
+--:(ip) +--:(ip)
| +--rw ip-address* inet:ip-address | +--rw ip-address* inet:ip-address
+--:(unnumbered) +--:(unnumbered)
+--rw unnumbered-id? uint32 | +--rw unnumbered-id? uint32
+--:(interface-name)
+--ro 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 12 skipping to change at page 7, line 13
"node" list of the network module. New objects include again a "node" list of the network module. New objects include again a
set of flags, as well as a list of prefixes. Each prefix in turn set of flags, as well as a list of prefixes. Each prefix in turn
includes an ip prefix, a metric, and a prefix-specific set of includes an ip prefix, a metric, and a prefix-specific set of
flags. flags.
o Links (in the ietf-network-topology module) are augmented with a o Links (in the ietf-network-topology module) are augmented with a
set of parameters as well, allowing to associate a link with a set of parameters as well, allowing to associate a link with a
link name, another set of flags, and a link metric. link name, another set of flags, and a link metric.
o Termination points (in the ietf-network-topology module as well) o Termination points (in the ietf-network-topology module as well)
are augmented with a choice of IP address or identifier. are augmented with a choice of IP address, identifier, or name.
In addition, the module defines a set of notifications to alert In addition, the module defines a set of notifications to alert
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 5. Layer 3 Unicast Topology YANG Module
<CODE BEGINS> file "ietf-l3-unicast-topology@2016-11-30.yang" <CODE BEGINS> file "ietf-l3-unicast-topology@2017-01-03.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";
skipping to change at page 7, line 51 skipping to change at page 8, line 4
} }
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 WG Chair: Susan Hares
<mailto:shares@ndzh.com> <mailto:shares@ndzh.com>
WG Chair: Russ White WG Chair: Russ White
<mailto:russ@riw.us> <mailto:russ@riw.us>
Editor: Alexander Clemm Editor: Alexander Clemm
<mailto:alex@sympotech.com> <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: Igor Bryskin
<mailto:Igor.Bryskin@huawei.com>
Editor: Aihua Guo
<mailto:aguo@advaoptical.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>";
Editor: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net>";
description description
"This module defines a model for Layer 3 Unicast "This module defines a model for Layer 3 Unicast
topologies. topologies.
Copyright (c) 2016 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-06; draft-ietf-i2rs-yang-l3-topology-07;
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-06 with RFC draft-ietf-i2rs-yang-l3-topology-07 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision "2016-11-30" { revision "2017-01-03" {
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-06 with to draft-ietf-i2rs-yang-l3-topology-07 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-06"; "draft-ietf-i2rs-yang-l3-topology-07";
} }
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 9, line 43 skipping to change at page 9, line 38
type identityref { type identityref {
base "flag-identity"; base "flag-identity";
} }
description "Node flag attributes"; description "Node flag attributes";
} }
typedef link-flag-type { typedef link-flag-type {
type identityref { type identityref {
base "flag-identity"; base "flag-identity";
} }
description "Prefix flag attributes"; description "Link flag attributes";
} }
typedef l3-flag-type { typedef l3-flag-type {
type identityref { type identityref {
base "flag-identity"; base "flag-identity";
} }
description "L3 flag attributes"; description "L3 flag attributes";
} }
grouping l3-prefix-attributes { grouping l3-prefix-attributes {
description description
"L3 prefix attributes"; "L3 prefix attributes";
leaf prefix { leaf prefix {
type inet:ip-prefix; type inet:ip-prefix;
description description
"IP prefix value"; "IP prefix value";
} }
leaf metric { leaf metric {
type uint32; type uint32;
skipping to change at page 12, line 25 skipping to change at page 12, line 22
"IPv4 or IPv6 address"; "IPv4 or IPv6 address";
} }
} }
case unnumbered { case unnumbered {
leaf unnumbered-id { leaf unnumbered-id {
type uint32; type uint32;
description description
"Unnumbered interface identifier"; "Unnumbered interface identifier";
} }
} }
case interface-name {
leaf interface-name {
type string;
description
"A name of the interface. The name can (but does not
have to) correspond to an interface reference of a
containing node's interface, i.e. the path name of a
corresponding interface data node on the containing
node reminiscent of data type if-ref defined in
RFC 7223. It should be noted that data type if-ref of
RFC 7223 cannot be used directly, as this data type
is used to reference an interface in a datastore of
a single node in the network, not to uniquely
reference interfaces across a network.";
}
}
} }
} }
} }
augment "/nd:networks/nd:network/nd:network-types" { augment "/nd:networks/nd:network/nd:network-types" {
description description
"Introduce new network type for L3 unicast topology"; "Introduce new network type for L3 unicast topology";
uses l3-unicast-topology-type; uses l3-unicast-topology-type;
} }
augment "/nd:networks/nd:network" { augment "/nd:networks/nd:network" {
when "nd:network-types/l3-unicast-topology" { when "nd:network-types/l3-unicast-topology" {
skipping to change at page 16, line 41 skipping to change at page 17, line 37
OSPF routers or interfaces. OSPF routers or interfaces.
6.1.2. OSPF Topology YANG Module 6.1.2. OSPF Topology YANG Module
The OSPF Topology YANG Module is specified below. As mentioned, the The OSPF Topology YANG Module is specified below. As mentioned, the
module is intended as an example for how the Layer 3 Unicast topology 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 model can be extended to cover OSFP topologies, but it is not
normative. Accordingly, the module is not delimited with <CODE normative. Accordingly, the module is not delimited with <CODE
BEGINS> and <CODE ENDS> tags. BEGINS> and <CODE ENDS> tags.
file "example-ietf-ospf-topology@2016-11-30.yang" file "example-ietf-ospf-topology@2017-01-03.yang"
module example-ietf-ospf-topology { module example-ietf-ospf-topology {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology"; namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology";
prefix "ospft"; prefix "ospft";
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix "yang";
} }
import ietf-network { import ietf-network {
prefix "nd"; prefix "nd";
} }
skipping to change at page 17, line 19 skipping to change at page 18, line 16
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 WG Chair: Susan Hares
<mailto:shares@ndzh.com> <mailto:shares@ndzh.com>
WG Chair: Russ White WG Chair: Russ White
<mailto:russ@riw.us> <mailto:russ@riw.us>
Editor: Alexander Clemm Editor: Alexander Clemm
<mailto:alex@sympotech.com> <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: Igor Bryskin
<mailto:Igor.Bryskin@huawei.com>
Editor: Aihua Guo
<mailto:aguo@advaoptical.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>";
Editor: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net>";
description description
"This module defines a model for OSPF network topologies. "This module defines a model for OSPF network topologies.
Copyright (c) 2016 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-06; draft-ietf-i2rs-yang-l3-topology-07;
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-06 with RFC draft-ietf-i2rs-yang-l3-topology-07 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision "2017-01-03" {
revision "2016-11-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-l3-topology-06 with to draft-ietf-i2rs-yang-l3-topology-07 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-06"; "draft-ietf-i2rs-yang-l3-topology-07";
} }
typedef area-id-type { typedef area-id-type {
type yang:dotted-quad; type yang:dotted-quad;
description description
"Area ID type."; "Area ID type.";
} }
grouping ospf-topology-type { grouping ospf-topology-type {
description description
"Identifies the OSPF topology type."; "Identifies the OSPF topology type.";
container ospf { container ospf {
skipping to change at page 23, line 23 skipping to change at page 23, line 38
configure IS-IS routers or interfaces. configure IS-IS routers or interfaces.
6.2.2. IS-IS Topology YANG Module 6.2.2. IS-IS Topology YANG Module
The IS-IS Topology YANG Module is specified as follows. As The IS-IS Topology YANG Module is specified as follows. As
mentioned, the module is intended as an example for how the Layer 3 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 Unicast topology model can be extended to cover IS-IS topologies, but
it is not normative. Accordingly, the module is not delimited with it is not normative. Accordingly, the module is not delimited with
<CODE BEGINS> and <CODE ENDS> tags. <CODE BEGINS> and <CODE ENDS> tags.
file "example-ietf-isis-topology@2016-11-30.yang" file "example-ietf-isis-topology@2017-01-03.yang"
module example-ietf-isis-topology { module example-ietf-isis-topology {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:example-ietf-isis-topology"; namespace "urn:ietf:params:xml:ns:yang:example-ietf-isis-topology";
prefix "isist"; prefix "isist";
import ietf-network { import ietf-network {
prefix "nd"; prefix "nd";
} }
import ietf-network-topology { import ietf-network-topology {
prefix "lnk"; prefix "lnk";
} }
skipping to change at page 24, line 5 skipping to change at page 24, line 20
WG Chair: Russ White WG Chair: Russ White
<mailto:russ@riw.us> <mailto:russ@riw.us>
Editor: Alexander Clemm Editor: Alexander Clemm
<mailto:sympotech.com> <mailto:sympotech.com>
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: Igor Bryskin
<mailto:Igor.Bryskin@huawei.com>
Editor: Aihua Guo
<mailto:aguo@advaoptical.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>";
Editor: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net>";
description description
"This module defines a model for IS-IS network topologies. "This module defines a model for IS-IS network topologies.
Copyright (c) 2016 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-06; draft-ietf-i2rs-yang-l3-topology-07;
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-06 with RFC draft-ietf-i2rs-yang-l3-topology-07 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision "2016-11-30" { revision "2017-01-03" {
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-06 with to draft-ietf-i2rs-yang-l3-topology-07 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-06; draft-ietf-i2rs-yang-l3-topology-07;
} }
typedef iso-pseudonode-id { typedef iso-pseudonode-id {
type string { type string {
pattern '[0-9a-fA-F]{2}'; pattern '[0-9a-fA-F]{2}';
} }
description description
"ISO pseudonode id for broadcast network."; "ISO pseudonode id for broadcast network.";
} }
typedef area-address{ typedef area-address{
type string { type string {
pattern '[0-9A-Fa-f]{2}\.([0-9A-Fa-f]{4}\.){0,3}'; pattern '[0-9A-Fa-f]{2}\.([0-9A-Fa-f]{4}\.){0,3}';
} }
description description
"This type defines the area address."; "This type defines the area address.";
skipping to change at page 28, line 49 skipping to change at page 29, line 11
URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-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.
This document registers the following YANG module in the "YANG Module This document registers the following YANG module in the "YANG Module
Names" registry [RFC6020]: 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-06.txt (RFC form) Reference: draft-ietf-i2rs-yang-l3-topology-07.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 memo is designed to be accessed via
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
secure transport layer, and the mandatory-to-implement secure secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The NETCONF access transport is Secure Shell (SSH) [RFC6242]. The NETCONF access
control model [RFC6536] provides the means to restrict access for control model [RFC6536] provides the means to restrict access for
particular NETCONF users to a pre-configured subset of all available particular NETCONF users to a pre-configured subset of all available
NETCONF protocol operations and content. NETCONF protocol operations and content.
skipping to change at page 29, line 34 skipping to change at page 29, line 42
network utilization. It is therefore important that the NETCONF network utilization. It is therefore important that the NETCONF
access control model is vigorously applied to prevent topology access control model is vigorously applied to prevent topology
configuration by unauthorized clients. configuration by unauthorized clients.
10. Contributors 10. Contributors
The model presented in this paper was contributed to by more people The model presented in this paper was contributed to by more people
than can be listed on the author list. Additional contributors than can be listed on the author list. Additional contributors
include: include:
o Ken Gray, Juniper Networks o Vishnu Pavan Beeram, Juniper
o Igor Bryskin, Huawei
o Ken Gray, Cisco
o Aihua Guo, Adva Optical
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 Ladislav Lhotka, Andy Bierman,
Carlos Pignataro, Joel Halpern, Juergen Schoenwaelder, Alia Atlas, Carlos Pignataro, Joel Halpern, Juergen Schoenwaelder, Alia Atlas,
Susan Hares, Benoit Claise, and Carl Moberg. Susan Hares, Benoit Claise, and Carl Moberg.
12. References 12. References
skipping to change at page 30, line 13 skipping to change at page 30, line 21
Susan Hares, Benoit Claise, and Carl Moberg. Susan Hares, Benoit Claise, and Carl Moberg.
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-09, November 2016. topo-10, January 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.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004. 2004.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
skipping to change at page 31, line 7 skipping to change at page 31, line 14
12.2. Informative References 12.2. Informative References
[I-D.draft-acee-rtgwg-yang-rib-extend] [I-D.draft-acee-rtgwg-yang-rib-extend]
Lindem, A. and Y. Qu, "YANG Data Model for RIB Lindem, A. and Y. Qu, "YANG Data Model for RIB
Extensions", I-D draft-acee-rtgwg-yang-rib-extend-02, Extensions", I-D draft-acee-rtgwg-yang-rib-extend-02,
October 2016. October 2016.
[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-22, 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.
[OpenDaylight] [I-D.draft-ietf-teas-yang-te-topo]
Medved, J., Varga, R., Tkacik, T., and K. Gray, Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
"OpenDaylight: Towards a Model-Driven SDN Controller O. Gonzelz De Dios, "YANG Data Model for TE Topologies",
architecture", IEEE 15th Int. Symposium on World of I-D draft-ietf-teas-yang-te-topo-06, October 2016.
Wireless, Mobile and Multimedia Networks (IEEE WoWMoM
2014), June 2014. [RFC7223] Bjorklund, M., "A YANG Data Model for Routing Management",
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.
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Sympotech Huawei
EMail: alex@sympotech.com 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
skipping to change at page 31, line 41 skipping to change at page 32, line 4
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
Xufeng Liu Xufeng Liu
Ericsson Ericsson
EMail: xliu@kuatrotech.com EMail: xliu@kuatrotech.com
Igor Bryskin
Huawei
EMail: Igor.Bryskin@huawei.com
Aihua Guo
Adva Optical
EMail: aguo@advaoptical.com
Hariharan Ananthakrishnan Hariharan Ananthakrishnan
Packet Design Packet Design
EMail: hari@packetdesign.com EMail: hari@packetdesign.com
Nitin Bahadur Nitin Bahadur
Bracket Computing Bracket Computing
EMail: nitin_bahadur@yahoo.com EMail: nitin_bahadur@yahoo.com
Vishnu Pavan Beeram
Juniper Networks
EMail: vbeeram@juniper.net
 End of changes. 66 change blocks. 
119 lines changed or deleted 104 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/