draft-ietf-i2rs-yang-network-topo-12.txt   draft-ietf-i2rs-yang-network-topo-13.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: September 2, 2017 Cisco Expires: December 24, 2017 Cisco
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
X. Liu X. Liu
Jabil Jabil
March 1, 2017 June 22, 2017
A Data Model for Network Topologies A Data Model for Network Topologies
draft-ietf-i2rs-yang-network-topo-12.txt draft-ietf-i2rs-yang-network-topo-13.txt
Abstract Abstract
This document defines an abstract (generic) YANG data model for This document defines an abstract (generic) YANG data model for
network/service topologies and inventories. The model serves as a network/service topologies and inventories. The model serves as a
base model which is augmented with technology-specific details in base model which is augmented with technology-specific details in
other, more specific topology and inventory models. other, more specific topology and inventory models.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2017. This Internet-Draft will expire on December 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4. Model Structure Details . . . . . . . . . . . . . . . . . . . 8 4. Model Structure Details . . . . . . . . . . . . . . . . . . . 8
4.1. Base Network Model . . . . . . . . . . . . . . . . . . . 8 4.1. Base Network Model . . . . . . . . . . . . . . . . . . . 8
4.2. Base Network Topology Model . . . . . . . . . . . . . . . 10 4.2. Base Network Topology Model . . . . . . . . . . . . . . . 10
4.3. Extending the model . . . . . . . . . . . . . . . . . . . 12 4.3. Extending the model . . . . . . . . . . . . . . . . . . . 12
4.4. Discussion and selected design decisions . . . . . . . . 12 4.4. Discussion and selected design decisions . . . . . . . . 12
4.4.1. Container structure . . . . . . . . . . . . . . . . . 12 4.4.1. Container structure . . . . . . . . . . . . . . . . . 12
4.4.2. Underlay hierarchies and mappings . . . . . . . . . . 13 4.4.2. Underlay hierarchies and mappings . . . . . . . . . . 13
4.4.3. Dealing with changes in underlay networks . . . . . . 13 4.4.3. Dealing with changes in underlay networks . . . . . . 13
4.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 14 4.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 14
4.4.5. Cardinality and directionality of links . . . . . . . 14 4.4.5. Cardinality and directionality of links . . . . . . . 14
4.4.6. Multihoming and link aggregation . . . . . . . . . . 14 4.4.6. Multihoming and link aggregation . . . . . . . . . . 15
4.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 15 4.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 15
4.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 15 4.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 15
4.4.9. Representing the same device in multiple networks . . 15 4.4.9. Representing the same device in multiple networks . . 15
4.4.10. Supporting client-configured and server-provided 4.4.10. Supporting client-configured and server-provided
network topology . . . . . . . . . . . . . . . . . . 16 network topology . . . . . . . . . . . . . . . . . . 16
4.4.11. Identifiers of string or URI type . . . . . . . . . . 17 4.4.11. Identifiers of string or URI type . . . . . . . . . . 17
5. Interactions with Other YANG Modules . . . . . . . . . . . . 18 5. Interactions with Other YANG Modules . . . . . . . . . . . . 18
6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Defining the Abstract Network: network.yang . . . . . . . 18 6.1. Defining the Abstract Network: network.yang . . . . . . . 18
6.2. Creating Abstract Network Topology: network-topology.yang 23 6.2. Creating Abstract Network Topology: network-topology.yang 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Appendix: Model Use Cases . . . . . . . . . . . . . 34 Appendix A. Appendix: Model Use Cases . . . . . . . . . . . . . 33
A.1. Fetching Topology from a Network Element . . . . . . . . 34 A.1. Fetching Topology from a Network Element . . . . . . . . 33
A.2. Modifying TE Topology Imported from an Optical Controller 34 A.2. Modifying TE Topology Imported from an Optical Controller 33
A.3. Annotating Topology for Local Computation . . . . . . . . 35 A.3. Annotating Topology for Local Computation . . . . . . . . 34
A.4. SDN Controller-Based Configuration of Overlays on Top of A.4. SDN Controller-Based Configuration of Overlays on Top of
Underlays . . . . . . . . . . . . . . . . . . . . . . . . 35 Underlays . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
This document introduces an abstract (base) YANG [RFC7950] [RFC6991] This document introduces an abstract (base) YANG [RFC7950] [RFC6991]
data model to represent networks and topologies. The data model is data model to represent networks and topologies. The data model is
divided into two parts. The first part of the model defines a divided into two parts. The first part of the model defines a
network model that allows to define network hierarchies (i.e. network network model that allows to define network hierarchies (i.e. network
stacks) and to maintain an inventory of nodes contained in a network. stacks) and to maintain an inventory of nodes contained in a network.
The second part of the model augments the basic network model with The second part of the model augments the basic network model with
information to describe topology information. Specifically, it adds information to describe topology information. Specifically, it adds
skipping to change at page 8, line 32 skipping to change at page 8, line 32
4. Model Structure Details 4. Model Structure Details
4.1. Base Network Model 4.1. Base Network Model
The abstract (base) network model is defined in the network.yang The abstract (base) network model is defined in the network.yang
module. Its structure is shown in the following figure. Brackets module. Its structure is shown in the following figure. Brackets
enclose list keys, "rw" means configuration data, "ro" means enclose list keys, "rw" means configuration data, "ro" means
operational state data, and "?" designates optional nodes. A "+" operational state data, and "?" designates optional nodes. A "+"
indicates a line break. indicates a line break.
module: ietf-network module: ietf-network
+--rw networks +--rw networks
+--rw network* [network-id] +--rw network* [network-id]
+--rw network-types +--rw network-types
+--rw network-id network-id +--rw network-id network-id
+--ro server-provided? boolean
+--rw supporting-network* [network-ref] +--rw supporting-network* [network-ref]
| +--rw network-ref -> /networks/network/network-id | +--rw network-ref -> /networks/network/network-id
+--rw node* [node-id] +--rw node* [node-id]
+--rw node-id node-id +--rw node-id node-id
+--rw supporting-node* [network-ref node-ref] +--rw supporting-node* [network-ref node-ref]
+--rw network-ref -> ../../../supporting-network/ + +--rw network-ref -> ../../../supporting-network/ +
| network-ref | network-ref
+--rw node-ref -> /networks/network/node/node-id +--rw node-ref -> /networks/network/node/node-id
Figure 4: The structure of the abstract (base) network model Figure 4: The structure of the abstract (base) network model
skipping to change at page 10, line 10 skipping to change at page 10, line 10
Similar to a network, a node can be supported by other nodes, and map Similar to a network, a node can be supported by other nodes, and map
onto one or more other nodes in an underlay network. This is onto one or more other nodes in an underlay network. This is
captured in the list "supporting-node". The resulting hierarchy of captured in the list "supporting-node". The resulting hierarchy of
nodes allows also to represent device stacks, where a node at one nodes allows also to represent device stacks, where a node at one
level is supported by a set of nodes at an underlying level. For level is supported by a set of nodes at an underlying level. For
example, a "router" node might be supported by a node representing a example, a "router" node might be supported by a node representing a
route processor and separate nodes for various line cards and service route processor and separate nodes for various line cards and service
modules, a virtual router might be supported or hosted on a physical modules, a virtual router might be supported or hosted on a physical
device represented by a separate node, and so on. device represented by a separate node, and so on.
Finally, there is an object "server-provided". This object is state Network data of a network at a particular layer can come into being
that indicates how the network came into being. Network data can in one of two ways. In one way, network data is configured by client
come into being in one of two ways. In one way, network data is applications, for example in case of overlay networks that are
configured by client applications, for example in case of overlay configured by an SDN Controller application. In another way, it is
networks that are configured by an SDN Controller application. In automatically populated by the server, in case of networks that can
annother way, it is populated by the server, in case of networks that be discovered. It is possible for a configured (overlay) network to
can be discovered. refer to a (discovered) underlay network.
If server-provided is set to false, the network was configured by a The revised datastore architecture
client application, for example in the case of an overlay network [I-D.draft-ietf-netmod-revised-datastores] is used to account for
that is configured by a controller application. If server-provided those possibilities. Specifically, for each network, the origin of
is set to true, the network was populated by the server itself, its data is indicated per the origin metadata annotation - "intended"
respectively an application on the server that is able to discover for data that was configured by a client application, "learned" for
the network. Client applications SHOULD NOT modify configurations of data that is discovered. Network data that is discovered is
networks for which "server-provided" is true. When they do, they automatically populated as part of the operational datastore.
need to be aware that any modifications they make are subject to be Network data that is configured is part of the configuration and
reverted by the server. For servers that support NACM (Netconf intended datastores, respectively. Configured network data that is
Access Control Model), data node rules should ideally prevent write actually in effect is in addition reflected in the operational
access by other clients to network instances for which server- datastore. Data in the operational datastore will always have
provided is set to true. complete referential integrity. Should a configured data item (such
as a node) have a dangling reference that refers to a non-existing
data item (such as a supporting node), the configured data item will
automatically be removed from the operational datastore and show up
only in the intended datastore. It will be up to the client
application to resolve the situation and ensure that the reference to
the supporting resources is configured properly.
4.2. Base Network Topology Model 4.2. Base Network Topology Model
The abstract (base) network topology model is defined in the The abstract (base) network topology model is defined in the
"network-topology.yang" module. It builds on the network model "network-topology.yang" module. It builds on the network model
defined in the "network.yang" module, augmenting it with links defined in the "network.yang" module, augmenting it with links
(defining how nodes are connected) and termination-points (which (defining how nodes are connected) and termination-points (which
anchor the links and are contained in nodes). The structure of the anchor the links and are contained in nodes). The structure of the
network topology module is shown in the following figure. Brackets network topology module is shown in the following figure. Brackets
enclose list keys, "rw" means configuration data, "ro" means enclose list keys, "rw" means configuration data, "ro" means
skipping to change at page 13, line 47 skipping to change at page 13, line 47
at another level of the hierarchy. at another level of the hierarchy.
4.4.3. Dealing with changes in underlay networks 4.4.3. Dealing with changes in underlay networks
It is possible for a network to undergo churn even as other networks It is possible for a network to undergo churn even as other networks
are layered on top of it. When a supporting node, link, or are layered on top of it. When a supporting node, link, or
termination point is deleted, the supporting leafrefs in the overlay termination point is deleted, the supporting leafrefs in the overlay
will be left dangling. To allow for this possibility, the model will be left dangling. To allow for this possibility, the model
makes use of the "require-instance" construct of YANG 1.1 [RFC7950]. makes use of the "require-instance" construct of YANG 1.1 [RFC7950].
A dangling leafref of a configured object leaves the corresponding
instance in a state in which it lacks referential integrity,
rendering it in effect inoperational. Any corresponding object
instance is therefore removed from the operational datastore until
the situation has been resolved, i.e. until either the supporting
object is added to the operational datastore, or until the instance
is reconfigured to refer to another object that is actually reflected
in the operational datastore. It does remain part of the intended
datastore.
It is the responsibility of the application maintaining the overlay It is the responsibility of the application maintaining the overlay
to deal with the possibility of churn in the underlay network. When to deal with the possibility of churn in the underlay network. When
a server receives a request to configure an overlay network, it a server receives a request to configure an overlay network, it
SHOULD validate whether supporting nodes/links/tps refer to nodes in SHOULD validate whether supporting nodes/links/tps refer to nodes in
the underlay are actually in existence. Configuration requests in the underlay are actually in existence, i.e. nodes which are
reflected in the operational datastore. Configuration requests in
which supporting nodes/links/tps refer to objects currently not in which supporting nodes/links/tps refer to objects currently not in
existence SHOULD be rejected. It is the responsibility of the existence SHOULD be rejected. It is the responsibility of the
application to update the overlay when a supporting node/link/tp is application to update the overlay when a supporting node/link/tp is
deleted at a later point in time. For this purpose, an application deleted at a later point in time. For this purpose, an application
might subscribe to updates when changes to the underlay occur, for might subscribe to updates when changes to the underlay occur, for
example using mechanisms defined in example using mechanisms defined in
[I-D.draft-ietf-netconf-yang-push]. [I-D.draft-ietf-netconf-yang-push].
4.4.4. Use of groupings 4.4.4. Use of groupings
skipping to change at page 16, line 41 skipping to change at page 16, line 49
4.4.10. Supporting client-configured and server-provided network 4.4.10. Supporting client-configured and server-provided network
topology topology
YANG requires data nodes to be designated as either configuration or YANG requires data nodes to be designated as either configuration or
operational data, but not both, yet it is important to have all operational data, but not both, yet it is important to have all
network information, including vertical cross-network dependencies, network information, including vertical cross-network dependencies,
captured in one coherent model. In most cases, network topology captured in one coherent model. In most cases, network topology
information is discovered about a network; the topology is considered information is discovered about a network; the topology is considered
a property of the network that is reflected in the model. That said, a property of the network that is reflected in the model. That said,
it is conceivable that certain types of topology need to also be certain types of topology need to also be configurable by an
configurable by an application. The model needs to support both application, such as in the case of overlay topologies.
cases.
There are several alternatives in which this can be addressed. The
alternative chosen in this draft does not restrict network topology
information as read-only, but includes a state "server-provided" that
indicates for each network whether it is populated by the server or
by a client application. Client applications that do attempt to
modify network topology may simply see their actions reverted, not
unlike other client applications that compete with one another, each
wanting to "own" the same data. When Netconf Access Control Model
[RFC6536] is supported, node access rules SHOULD be automatically
maintained by a server to deny client write access to network and
topology instances for which "server-provided" is true.
It should be noted that this solution stretches its use of the Network topology data that is discovered is automatically populated
configuration concept slightly. Configuration information in general as part of the operational datastore. Network topology that is
is subject to backup and restore, which is not applicable to server- configured is instantiated as part of a configuration datastore, e.g.
provided information. Perhaps more noteworthy is the potential the <intended> datastore. Only when it has actually taken effect, it
ability of a client to lock a configuration and thus prevent changes is also instantiated as part of the operational datastore.
to server-provided network topology while the lock is in effect. As
a result it would potentially incur a time lag until topology changes
that occur in the meantime are reflected, unless implementations
choose to provide special treatment for network topology information.
Other alternatives had been considered. In one alternative, all Configured network topology will in general refer to an underlay
information about network topology is in effect is represented as topology and include layering information, such as the supporting
network state, i.e. as read-only information, regardless of how it node(s) underlying a node, supporting link(s) underlying a link, and
came into being. For cases where network topology needs to be supporting termination point(s) underlying a termination point. The
configured, a second branch for configurable topology information is supporting objects must be instantiated in the operational datastore
introduced. Any network topology configuration is mirrored by in order for the dependent overlay object to be reflected in the
network state information. A configurable network will thus be operational datastore. Should a configured data item (such as a
represented twice: once in the read-only list of all networks, a node) have a dangling reference that refers to a non-existing data
second time in a configuration sandbox. One implication of this item (such as a supporting node), the configured data item will
solution would have been significantly increased complexity of automatically be removed from the operational datastore and show up
augmentations due to multiple target branches. only in the intended datastore. It will be up to the client
application to resolve the situation and ensure that the reference to
the supporting resources is configured properly.
Another alternative would make use of a YANG extension to tag For each network, the origin of its data is indicated per the
specific network instances as "server-provided" instead of defining a "origin" metadata annotation defined in
leaf object, or rely on the concept of YANG metadata [RFC7952] for [I-D.draft-ietf-netmod-revised-datastores]. In general, the origin
the same effect. The tag would be automatically applied to any of discovered network data is "learned"; the origin of configured
topology data that comes into being (respectively is configured) by network data is "intended".
an embedded application on the network, as opposed to e.g. a
controller application.
4.4.11. Identifiers of string or URI type 4.4.11. Identifiers of string or URI type
The current model defines identifiers of nodes, networks, links, and The current model defines identifiers of nodes, networks, links, and
termination points as URIs. An alternative would define them as termination points as URIs. An alternative would define them as
string. string.
The case for strings is that they will be easier to implement. The The case for strings is that they will be easier to implement. The
reason for choosing URIs is that the topology/node/tp exists in a reason for choosing URIs is that the topology/node/tp exists in a
larger context, hence it is useful to be able to correlate larger context, hence it is useful to be able to correlate
skipping to change at page 18, line 32 skipping to change at page 18, line 26
document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral
topology data that is server provided, the process tasked with topology data that is server provided, the process tasked with
maintaining topology information will load information from the maintaining topology information will load information from the
routing process (such as OSPF) into the data model without relying on routing process (such as OSPF) into the data model without relying on
a configuration datastore. a configuration datastore.
6. YANG Modules 6. YANG Modules
6.1. Defining the Abstract Network: network.yang 6.1. Defining the Abstract Network: network.yang
<CODE BEGINS> file "ietf-network@2017-03-01.yang" <CODE BEGINS> file "ietf-network@2017-06-22.yang"
module ietf-network { module ietf-network {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network"; namespace "urn:ietf:params:xml:ns:yang:ietf-network";
prefix nd; prefix nd;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
organization organization
skipping to change at page 19, line 42 skipping to change at page 19, line 34
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of This version of this YANG module is part of
draft-ietf-i2rs-yang-network-topo-12; draft-ietf-i2rs-yang-network-topo-13;
see the RFC itself for full legal notices. see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-12 with RFC draft-ietf-i2rs-yang-network-topo-13 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2017-03-01 { revision 2017-06-22 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-12 with to draft-ietf-i2rs-yang-network-topo-13 with
RFC number when published (i.e. RFC xxxx)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-network-topo-12"; "draft-ietf-i2rs-yang-network-topo-13";
} }
typedef node-id { typedef node-id {
type inet:uri; type inet:uri;
description description
"Identifier for a node. The precise structure of the node-id "Identifier for a node. The precise structure of the node-id
will be up to the implementation. Some implementations MAY will be up to the implementation. Some implementations MAY
for example, pick a uri that includes the network-id as for example, pick a uri that includes the network-id as
part of the path. The identifier SHOULD be chosen such that part of the path. The identifier SHOULD be chosen such that
the same node in a real network topology will always be the same node in a real network topology will always be
skipping to change at page 21, line 42 skipping to change at page 21, line 36
description description
"Serves as an augmentation target. "Serves as an augmentation target.
The network type is indicated through corresponding The network type is indicated through corresponding
presence containers augmented into this container."; presence containers augmented into this container.";
} }
leaf network-id { leaf network-id {
type network-id; type network-id;
description description
"Identifies a network."; "Identifies a network.";
} }
leaf server-provided {
type boolean;
config false;
description
"Indicates whether the information concerning this
particular network is populated by the server
(server-provided true, the general case for network
information discovered from the server),
or whether it is configured by a client
(server-provided true, possible e.g. for
service overlays managed through a controller).
Clients should not attempt to make modifications
to network instances with server-provided set to
true; when they do, they need to be aware that
any modifications they make are subject to be
reverted by the server.
For servers that support NACM (Netconf Access Control
Model), data node rules should ideally prevent
write access by other clients to the network instance
when server-provided is set to true.";
}
list supporting-network { list supporting-network {
key "network-ref"; key "network-ref";
description description
"An underlay network, used to represent layered network "An underlay network, used to represent layered network
topologies."; topologies.";
leaf network-ref { leaf network-ref {
type leafref { type leafref {
path "/networks/network/network-id"; path "/networks/network/network-id";
require-instance false; require-instance false;
} }
skipping to change at page 23, line 24 skipping to change at page 22, line 44
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6.2. Creating Abstract Network Topology: network-topology.yang 6.2. Creating Abstract Network Topology: network-topology.yang
<CODE BEGINS> file "ietf-network-topology@2017-03-01.yang" <CODE BEGINS> file "ietf-network-topology@2017-06-22.yang"
module ietf-network-topology { module ietf-network-topology {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
prefix lnk; prefix lnk;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-network { import ietf-network {
prefix nd; prefix nd;
} }
organization organization
"IETF I2RS (Interface to the Routing System) Working Group"; "IETF I2RS (Interface to the Routing System) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2rs/> "WG Web: <http://tools.ietf.org/wg/i2rs/>
skipping to change at page 24, line 36 skipping to change at page 24, line 8
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of This version of this YANG module is part of
draft-ietf-i2rs-yang-network-topo-12; draft-ietf-i2rs-yang-network-topo-13;
see the RFC itself for full legal notices. see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to NOTE TO RFC EDITOR: Please replace above reference to
draft-ietf-i2rs-yang-network-topo-12 with RFC draft-ietf-i2rs-yang-network-topo-13 with RFC
number when published (i.e. RFC xxxx)."; number when published (i.e. RFC xxxx).";
revision 2017-03-01 { revision 2017-06-22 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference NOTE TO RFC EDITOR: Please replace the following reference
to draft-ietf-i2rs-yang-network-topo-12 with to draft-ietf-i2rs-yang-network-topo-13 with
RFC number when published (i.e. RFC xxxx)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-network-topo-12"; "draft-ietf-i2rs-yang-network-topo-13";
} }
typedef link-id { typedef link-id {
type inet:uri; type inet:uri;
description description
"An identifier for a link in a topology. "An identifier for a link in a topology.
The precise structure of the link-id The precise structure of the link-id
will be up to the implementation. will be up to the implementation.
The identifier SHOULD be chosen such that the same link in a The identifier SHOULD be chosen such that the same link in a
real network topology will always be identified through the real network topology will always be identified through the
same identifier, even if the model is instantiated in same identifier, even if the model is instantiated in
separate datastores. An implementation MAY choose to capture separate datastores. An implementation MAY choose to capture
skipping to change at page 30, line 11 skipping to change at page 29, line 32
URI:urn:ietf:params:xml:ns:yang:ietf-network-topology URI:urn:ietf:params:xml:ns:yang:ietf-network-topology
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document registers the following YANG modules in the "YANG This document registers the following YANG modules in the "YANG
Module Names" registry [RFC6020]: Module Names" registry [RFC6020]:
Name: ietf-network Name: ietf-network
Namespace: urn:ietf:params:xml:ns:yang:ietf-network Namespace: urn:ietf:params:xml:ns:yang:ietf-network
Prefix: nd Prefix: nd
Reference: draft-ietf-i2rs-yang-network-topo-12.txt (RFC form) Reference: draft-ietf-i2rs-yang-network-topo-13.txt (RFC form)
Name: ietf-network-topology Name: ietf-network-topology
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology
Prefix: lnk Prefix: lnk
Reference: draft-ietf-i2rs-yang-network-topo-12.txt (RFC form) Reference: draft-ietf-i2rs-yang-network-topo-13.txt (RFC form)
8. Security Considerations 8. Security Considerations
The YANG module defined in this memo is independent of a particular The YANG module defined in this memo is independent of a particular
protocol and can be accessed via a number of protocols that need to protocol and can be accessed via a number of protocols that need to
access YANG-defined data. This includes but is not limited to the access YANG-defined data. This includes but is not limited to the
NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure
transport layer and the mandatory-to-implement secure transport is transport layer and the mandatory-to-implement secure transport is
Secure Shell (SSH) [RFC6242]. Secure Shell (SSH) [RFC6242].
skipping to change at page 30, line 48 skipping to change at page 30, line 20
rules for other transports is clearly undesirable, as this would not rules for other transports is clearly undesirable, as this would not
only inhibit ease-of-use of systems that implement multiple protocols only inhibit ease-of-use of systems that implement multiple protocols
to access YANG data, but also open the specter of security holes due to access YANG data, but also open the specter of security holes due
to inconsistencies in articulation and enforcement of rules across to inconsistencies in articulation and enforcement of rules across
mechanisms that are essentially redundant. mechanisms that are essentially redundant.
The YANG module defines information that can be configurable in The YANG module defines information that can be configurable in
certain instances, for example in the case of overlay topologies that certain instances, for example in the case of overlay topologies that
can be created by client applications. In such cases, a malicious can be created by client applications. In such cases, a malicious
client could introduce topologies that are undesired. Specifically, client could introduce topologies that are undesired. Specifically,
a malicious client could attempt to do the following: a malicious client could attempt to remove or add a node, a link, a
termination point, by creating or deleting corresponding elements in
o Remove or add a node, a link, a termination point, by creating or the node, link, and termination point lists, respectively. In the
deleting corresponding elements in the node, link, and termination case of a topology that is learned, the server will automatically
point lists, respectively. In the case of a topology that is prohibit such misconfiguration attempts. In the case of a topology
server-provided, the server will automaticaly correct such that is configured, i.e. whose origin is "intended", the undesired
misconfiguration attempts. In the case of a topology that is configuration could become effective and be reflected in the
configured, the services provided via this topology might be operational datastore, leading to disruption of services provided via
disrupted. For example, the topology could be "cut" or be this topology might be disrupted. For example, the topology could be
configured in a suboptimal way, leading to degradation of service "cut" or be configured in a suboptimal way, leading to increased
levels and possibly disruption of service. consumption of resources in the underlay network due to resulting
routing and bandwidth utilization inefficiencies. Likewise, it could
o Modify the underlay information, i.e. the configuration of lead to degradation of service levels as well as possibly disruption
supporting-node, supporting-link, and supporting-termination- of service. For those reasons, it is important that the NETCONF
point, respectively. Again, in the case of a topology that is access control model is vigorously applied to prevent topology
server-provided, the server will automaticaly correct such misconfiguration by unauthorized clients.
misconfiguration attempts. However, in the case of a topology
that is configured, this will affect the vertical layering and the
way in which the overlay maps onto an overlay. This could be
exploited to severely disrupt the overlay network by degrading
service levels. In addition, it could be exploited to result in
increased consumption of resources in the underlay network, for
example by disrupting congruence between overlay and underlay
nodes which would result in routing and bandwidth utilization
inefficiencies.
For those reasons, it is important that the NETCONF access control
model is vigorously applied to prevent topology misconfiguration by
unauthorized clients.
Topologies that are server-provided and that provide ephemeral
topology information are less vulnerable, as they provide read-only
access to clients.
9. Contributors 9. 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 Vishnu Pavan Beeram, Juniper o Vishnu Pavan Beeram, Juniper
o Ken Gray, Cisco Systems o Ken Gray, Cisco
o Tom Nadeau, Brocade o Tom Nadeau, Brocade
o Tony Tkacik o Tony Tkacik
o Kent Watsen, Juniper o Kent Watsen, Juniper
o Aleksandr Zhdankin, Cisco o Aleksandr Zhdankin, Cisco
10. Acknowledgements 10. Acknowledgements
We wish to acknowledge the helpful contributions, comments, and We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Alia Atlas, Andy Bierman, Martin suggestions that were received from Alia Atlas, Andy Bierman, Martin
Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka, Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka,
Carlos Pignataro, Juergen Schoenwaelder, and Xian Zhang. Carlos Pignataro, Juergen Schoenwaelder, and Xian Zhang.
11. References 11. References
skipping to change at page 32, line 16 skipping to change at page 31, line 17
We wish to acknowledge the helpful contributions, comments, and We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Alia Atlas, Andy Bierman, Martin suggestions that were received from Alia Atlas, Andy Bierman, Martin
Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka, Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka,
Carlos Pignataro, Juergen Schoenwaelder, and Xian Zhang. Carlos Pignataro, Juergen Schoenwaelder, and Xian Zhang.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.draft-ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "A Revised Conceptual Model for YANG
Datastores", I-D draft-ietf-netmod-revised-datastores-02,
May 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997. requirement levels", RFC 2119, March 1997.
[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
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
skipping to change at page 33, line 8 skipping to change at page 32, line 15
11.2. Informative References 11.2. Informative References
[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-
30, November 2016. 03, November 2016.
[I-D.draft-ietf-netconf-yang-push] [I-D.draft-ietf-netconf-yang-push]
Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A.,
Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, Nilsen-Nygaard, E., Bierman, A., and B. Lengyel,
"Subscribing to YANG datastore push updates", I-D draft- "Subscribing to YANG datastore push updates", I-D draft-
ietf-netconf-yang-push-04, October 2016. ietf-netconf-yang-push-06, April 2017.
[I-D.draft-ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "A Revised Conceptual Model for YANG
Datastores", I-D draft-ietf-netmod-revised-datastores-00,
December 2016.
[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.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
 End of changes. 42 change blocks. 
159 lines changed or deleted 121 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/