idnits 2.17.1 draft-ietf-i2rs-yang-network-topo-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 15, 2016) is 2691 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Z' is mentioned on line 223, but not defined == Missing Reference: 'Y5' is mentioned on line 249, but not defined == Missing Reference: 'Z5' is mentioned on line 249, but not defined == Missing Reference: 'Z3' is mentioned on line 249, but not defined == Missing Reference: 'Y4' is mentioned on line 253, but not defined == Missing Reference: 'Y1' is mentioned on line 253, but not defined == Missing Reference: 'Z2' is mentioned on line 253, but not defined == Missing Reference: 'X5' is mentioned on line 262, but not defined == Missing Reference: 'D1' is mentioned on line 692, but not defined == Missing Reference: 'D2' is mentioned on line 692, but not defined ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-10) exists of draft-acee-rtgwg-yang-rib-extend-02 == Outdated reference: A later version (-23) exists of draft-ietf-i2rs-ephemeral-state-22 == Outdated reference: A later version (-03) exists of draft-ietf-i2rs-usecase-reqs-summary-02 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-04 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Clemm 3 Internet-Draft Sympotech 4 Intended status: Standards Track J. Medved 5 Expires: May 19, 2017 Cisco 6 R. Varga 7 Pantheon Technologies SRO 8 N. Bahadur 9 Bracket Computing 10 H. Ananthakrishnan 11 Packet Design 12 X. Liu 13 Ericsson 14 November 15, 2016 16 A Data Model for Network Topologies 17 draft-ietf-i2rs-yang-network-topo-07.txt 19 Abstract 21 This document defines an abstract (generic) YANG data model for 22 network/service topologies and inventories. The model serves as a 23 base model which is augmented with technology-specific details in 24 other, more specific topology and inventory models. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 19, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 7 75 4. Model Structure Details . . . . . . . . . . . . . . . . . . . 7 76 4.1. Base Network Model . . . . . . . . . . . . . . . . . . . 7 77 4.2. Base Network Topology Model . . . . . . . . . . . . . . . 10 78 4.3. Extending the model . . . . . . . . . . . . . . . . . . . 11 79 4.4. Discussion and selected design decisions . . . . . . . . 12 80 4.4.1. Container structure . . . . . . . . . . . . . . . . . 12 81 4.4.2. Underlay hierarchies and mappings . . . . . . . . . . 12 82 4.4.3. Dealing with changes in underlay networks . . . . . . 13 83 4.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 13 84 4.4.5. Cardinality and directionality of links . . . . . . . 13 85 4.4.6. Multihoming and link aggregation . . . . . . . . . . 14 86 4.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 14 87 4.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 14 88 4.4.9. Representing the same device in multiple networks . . 14 89 4.5. Supporting client-configured and server-provided network 90 topology . . . . . . . . . . . . . . . . . . . . . . . . 15 91 4.6. Identifiers of string or URI type . . . . . . . . . . . . 17 92 5. Interactions with Other YANG Modules . . . . . . . . . . . . 17 93 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 94 6.1. Defining the Abstract Network: network.yang . . . . . . . 17 95 6.2. Creating Abstract Network Topology: network-topology.yang 22 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 99 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 103 11.2. Informative References . . . . . . . . . . . . . . . . . 31 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 106 1. Introduction 108 This document introduces an abstract (base) YANG [RFC7950] [RFC6991] 109 data model to represent networks and topologies. The data model is 110 divided into two parts. The first part of the model defines a 111 network model that allows to define network hierarchies (i.e. network 112 stacks) and to maintain an inventory of nodes contained in a network. 113 The second part of the model augments the basic network model with 114 information to describe topology information. Specifically, it adds 115 the concepts of links and termination points to describe how nodes in 116 a network are connected to each other. Moreover the model introduces 117 vertical layering relationships between networks that can be 118 augmented to cover both network inventories and network/service 119 topologies. 121 While it would be possible to combine both parts into a single model, 122 the separation facilitates integration of network topology and 123 network inventory models, by allowing to augment network inventory 124 information separately and without concern for topology into the 125 network model. 127 The model can be augmented to describe specifics of particular types 128 of networks and topologies. For example, an augmenting model can 129 provide network node information with attributes that are specific to 130 a particular network type. Examples of augmenting models include 131 models for Layer 2 network topologies, Layer 3 network topologies, 132 such as Unicast IGP, IS-IS [RFC1195] and OSPF [RFC2328], traffic 133 engineering (TE) data [RFC3209], or any of the variety of transport 134 and service topologies. Information specific to particular network 135 types will be captured in separate, technology-specific models. 137 The basic data models introduced in this document are generic in 138 nature and can be applied to many network and service topologies and 139 inventories. The models allow applications to operate on an 140 inventory or topology of any network at a generic level, where 141 specifics of particular inventory/topology types are not required. 142 At the same time, where data specific to a network type does comes 143 into play and the model is augmented, the instantiated data still 144 adheres to the same structure and is represented in consistent 145 fashion. This also facilitates the representation of network 146 hierarchies and dependencies between different network components and 147 network types. 149 The abstract (base) network YANG module introduced in this document, 150 entitled "network.yang", contains a list of abstract network nodes 151 and defines the concept of network hierarchy (network stack). The 152 abstract network node can be augmented in inventory and topology 153 models with inventory and topology specific attributes. Network 154 hierarchy (stack) allows any given network to have one or more 155 "supporting networks". The relationship of the base network model, 156 the inventory models and the topology models is shown in the 157 following figure (dotted lines in the figure denote possible 158 augmentations to models defined in this document). 160 +------------------------+ 161 | | 162 | Abstract Network Model | 163 | | 164 +------------------------+ 165 | 166 +-------+-------+ 167 | | 168 V V 169 +------------+ .............. 170 | Abstract | : Inventory : 171 | Topology | : Model(s) : 172 | Model | : : 173 +------------+ '''''''''''''' 174 | 175 +-------------+-------------+-------------+ 176 | | | | 177 V V V V 178 ............ ............ ............ ............ 179 : L1 : : L2 : : L3 : : Service : 180 : Topology : : Topology : : Topology : : Topology : 181 : Model : : Model : : Model : : Model : 182 '''''''''''' '''''''''''' '''''''''''' '''''''''''' 184 Figure 1: The network model structure 186 The network-topology YANG module introduced in this document, 187 entitled "network-topology.yang", defines a generic topology model at 188 its most general level of abstraction. The module defines a topology 189 graph and components from which it is composed: nodes, edges and 190 termination points. Nodes (from the network.yang module) represent 191 graph vertices and links represent graph edges. Nodes also contain 192 termination points that anchor the links. A network can contain 193 multiple topologies, for example topologies at different layers and 194 overlay topologies. The model therefore allows to capture 195 relationships between topologies, as well as dependencies between 196 nodes and termination points across topologies. An example of a 197 topology stack is shown in the following figure. 199 +---------------------------------------+ 200 / _[X1]_ "Service" / 201 / _/ : \_ / 202 / _/ : \_ / 203 / _/ : \_ / 204 / / : \ / 205 / [X2]__________________[X3] / 206 +---------:--------------:------:-------+ 207 : : : 208 +----:--------------:----:--------------+ 209 / : : : "L3" / 210 / : : : / 211 / : : : / 212 / [Y1]_____________[Y2] / 213 / * * * / 214 / * * * / 215 +--------------*-------------*--*-------+ 216 * * * 217 +--------*----------*----*--------------+ 218 / [Z1]_______________[Z1] "Optical" / 219 / \_ * _/ / 220 / \_ * _/ / 221 / \_ * _/ / 222 / \ * / / 223 / [Z] / 224 +---------------------------------------+ 226 Figure 2: Topology hierarchy (stack) example 228 The figure shows three topology levels. At top, the "Service" 229 topology shows relationships between service entities, such as 230 service functions in a service chain. The "L3" topology shows 231 network elements at Layer 3 (IP) and the "Optical" topology shows 232 network elements at Layer 1. Service functions in the "Service" 233 topology are mapped onto network elements in the "L3" topology, which 234 in turn are mapped onto network elements in the "Optical" topology. 235 The figure shows two Service Functions - X1 and X2 - mapping onto a 236 single L3 network element; this could happen, for example, if two 237 service functions reside in the same VM (or server) and share the 238 same set of network interfaces. The figure shows a single "L3" 239 network element mapped onto multiple "Optical" network elements. 241 This could happen, for example, if a single IP router attaches to 242 multiple ROADMs in the optical domain. 244 Another example of a service topology stack is shown in the following 245 figure. 247 VPN1 VPN2 248 +---------------------+ +---------------------+ 249 / [Y5]... / / [Z5]______[Z3] / 250 / / \ : / / : \_ / : / 251 / / \ : / / : \_ / : / 252 / / \ : / / : \ / : / 253 / [Y4]____[Y1] : / / : [Z2] : / 254 +------:-------:---:--+ +---:---------:-----:-+ 255 : : : : : : 256 : : : : : : 257 : +-------:---:-----:------------:-----:-----+ 258 : / [X1]__:___:___________[X2] : / 259 :/ / \_ : : _____/ / : / 260 : / \_ : _____/ / : / 261 /: / \: / / : / 262 / : / [X5] / : / 263 / : / __/ \__ / : / 264 / : / ___/ \__ / : / 265 / : / ___/ \ / : / 266 / [X4]__________________[X3]..: / 267 +------------------------------------------+ 268 L3 Topology 270 Figure 3: Topology hierarchy (stack) example 272 The figure shows two VPN service topologies (VPN1 and VPN2) 273 instantiated over a common L3 topology. Each VPN service topology is 274 mapped onto a subset of nodes from the common L3 topology. 276 There are multiple applications for such a data model. For example, 277 within the context of I2RS, nodes within the network can use the data 278 model to capture their understanding of the overall network topology 279 and expose it to a network controller. A network controller can then 280 use the instantiated topology data to compare and reconcile its own 281 view of the network topology with that of the network elements that 282 it controls. Alternatively, nodes within the network could propagate 283 this understanding to compare and reconcile this understanding either 284 among themselves or with help of a controller. Beyond the network 285 element and the immediate context of I2RS itself, a network 286 controller might even use the data model to represent its view of the 287 topology that it controls and expose it to applications north of 288 itself. Further use cases that the data model can be applied to are 289 described in [I-D.draft-ietf-i2rs-usecase-reqs-summary]. 291 2. Key Words 293 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 294 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 295 document are to be interpreted as described in [RFC2119]. 297 3. Definitions and Acronyms 299 Datastore: A conceptual store of instantiated management information, 300 with individual data items represented by data nodes which are 301 arranged in hierarchical manner. 303 Data subtree: An instantiated data node and the data nodes that are 304 hierarchically contained within it. 306 HTTP: Hyper-Text Transfer Protocol 308 IGP: Interior Gateway Protocol 310 IS-IS: Intermediate System to Intermediate System protocol 312 NETCONF: Network Configuration Protocol 314 OSPF: Open Shortest Path First, a link state routing protocol 316 URI: Uniform Resource Identifier 318 ReST: Representational State Transfer, a style of stateless interface 319 and protocol that is generally carried over HTTP 321 YANG: A data definition language for NETCONF 323 4. Model Structure Details 325 4.1. Base Network Model 327 The abstract (base) network model is defined in the network.yang 328 module. Its structure is shown in the following figure. Brackets 329 enclose list keys, "rw" means configuration data, "ro" means 330 operational state data, and "?" designates optional nodes. A "+" 331 indicates a line break. 333 module: ietf-network 334 +--rw networks 335 +--rw network* [network-id] 336 +--rw network-types 337 +--rw network-id network-id 338 +--ro server-provided? boolean 339 +--rw supporting-network* [network-ref] 340 | +--rw network-ref -> /networks/network/network-id 341 +--rw node* [node-id] 342 +--rw node-id node-id 343 +--rw supporting-node* [network-ref node-ref] 344 +--rw network-ref -> ../../../supporting-network/ + 345 | network-ref 346 +--rw node-ref -> /networks/network/node/node-id 348 Figure 4: The structure of the abstract (base) network model 350 The model contains a container with a list of networks. Each network 351 is captured in its own list entry, distinguished via a network-id. 353 A network has a certain type, such as L2, L3, OSPF or IS-IS. A 354 network can even have multiple types simultaneously. The type, or 355 types, are captured underneath the container "network-types". In 356 this module it serves merely as an augmentation target; network- 357 specific modules will later introduce new data nodes to represent new 358 network types below this target, i.e. insert them below "network- 359 types" by ways of YANG augmentation. 361 When a network is of a certain type, it will contain a corresponding 362 data node. Network types SHOULD always be represented using presence 363 containers, not leafs of empty type. This allows to represent 364 hierarchies of network subtypes within the instance information. For 365 example, an instance of an OSPF network (which, at the same time, is 366 a layer 3 unicast IGP network) would contain underneath "network- 367 types" another container "l3-unicast-igp-network", which in turn 368 would contain a container "ospf-network". 370 A network can in turn be part of a hierarchy of networks, building on 371 top of other networks. Any such networks are captured in the list 372 "supporting-network". A supporting network is in effect an underlay 373 network. 375 Furthermore, a network contains an inventory of nodes that are part 376 of the network. The nodes of a network are captured in their own 377 list. Each node is identified relative to its containing network by 378 a node-id. 380 It should be noted that a node does not exist independently of a 381 network; instead it is a part of the network that it is contained in. 382 In cases where the same entity takes part in multiple networks, or at 383 multiple layers of a networking stack, the same entity will be 384 represented by multiple nodes, one for each network. In other words, 385 the node represents an abstraction of the device for the particular 386 network that it a is part of. To represent that the same entity or 387 same device is part of multiple topologies or networks, it is 388 possible to create one "physical" network with a list of nodes for 389 each of the devices or entities. This (physical) network, 390 respectively the (entities) nodes in that network, can then be 391 referred to as underlay network and nodes from the other (logical) 392 networks and nodes, respectively. Note that the model allows to 393 define more than one underlay network (and node), allowing for 394 simultaneous representation of layered network- and service 395 topologies and physical instantiation. 397 Similar to a network, a node can be supported by other nodes, and map 398 onto one or more other nodes in an underlay network. This is 399 captured in the list "supporting-node". The resulting hierarchy of 400 nodes allows also to represent device stacks, where a node at one 401 level is supported by a set of nodes at an underlying level. For 402 example, a "router" node might be supported by a node representing a 403 route processor and separate nodes for various line cards and service 404 modules, a virtual router might be supported or hosted on a physical 405 device represented by a separate node, and so on. 407 Finally, there is an object "server-provided". This object is state 408 that indicates how the network came into being. Network data can 409 come into being in one of two ways. In one way, network data is 410 configured by client applications, for example in case of overlay 411 networks that are configured by an SDN Controller application. In 412 annother way, it is populated by the server, in case of networks that 413 can be discovered. 415 If server-provided is set to false, the network was configured by a 416 client application, for example in the case of an overlay network 417 that is configured by a controller application. If server-provided 418 is set to true, the network was populated by the server itself, 419 respectively an application on the server that is able to discover 420 the network. Client applications SHOULD NOT modify configurations of 421 networks for which "server-provided" is true. When they do, they 422 need to be aware that any modifications they make are subject to be 423 reverted by the server. For servers that support NACM (Netconf 424 Access Control Model), data node rules should ideally prevent write 425 access by other clients to network instances for which server- 426 provided is set to true. 428 4.2. Base Network Topology Model 430 The abstract (base) network topology model is defined in the 431 "network-topology.yang" module. It builds on the network model 432 defined in the "network.yang" module, augmenting it with links 433 (defining how nodes are connected) and termination-points (which 434 anchor the links and are contained in nodes). The structure of the 435 network topology module is shown in the following figure. Brackets 436 enclose list keys, "rw" means configuration data, "ro" means 437 operational state data, and "?" designates optional nodes. A "+" 438 indicates a line break. 440 module: ietf-network-topology 441 augment /nd:networks/nd:network: 442 +--rw link* [link-id] 443 +--rw source 444 | +--rw source-node? -> ../../../nd:node/node-id 445 | +--rw source-tp? -> ../../../nd:node[nd:node-id=current()/+ 446 | ../source-node]/termination-point/tp-id 447 +--rw destination 448 | +--rw dest-node? -> ../../../nd:node/node-id 449 | +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+ 450 | ../dest-node]/termination-point/tp-id 451 +--rw link-id link-id 452 +--rw supporting-link* [network-ref link-ref] 453 +--rw network-ref -> ../../../nd:supporting-network/+ 454 | network-ref 455 +--rw link-ref -> /nd:networks/network+ 456 [nd:network-id=current()/../network-ref]/+ 457 link/link-id 458 augment /nd:networks/nd:network/nd:node: 459 +--rw termination-point* [tp-id] 460 +--rw tp-id tp-id 461 +--rw supporting-termination-point* [network-ref node-ref tp-ref] 462 +--rw network-ref -> ../../../nd:supporting-node/network-ref 463 +--rw node-ref -> ../../../nd:supporting-node/node-ref 464 +--rw tp-ref -> /nd:networks/network[nd:network-id=+ 465 current()/../network-ref]/node+ 466 [nd:node-id=current()/../node-ref]/+ 467 termination-point/tp-id 469 Figure 5: The structure of the abstract (base) network topology model 471 A node has a list of termination points that are used to terminate 472 links. An example of a termination point might be a physical or 473 logical port or, more generally, an interface. 475 Like a node, a termination point can in turn be supported by an 476 underlying termination point, contained in the supporting node of the 477 underlay network. 479 A link is identified by a link-id that uniquely identifies the link 480 within a given topology. Links are point-to-point and 481 unidirectional. Accordingly, a link contains a source and a 482 destination. Both source and destination reference a corresponding 483 node, as well as a termination point on that node. Similar to a 484 node, a link can map onto one or more links in an underlay topology 485 (which are terminated by the corresponding underlay termination 486 points). This is captured in the list "supporting-link". 488 4.3. Extending the model 490 In order to derive a model for a specific type of network, the base 491 model can be extended. This can be done roughly as follows: for the 492 new network type, a new YANG module is introduced. In this module, a 493 number of augmentations are defined against the network and network- 494 topology YANG modules. 496 We start with augmentations against the network.yang module. First, 497 a new network type needs to be defined. For this, a presence 498 container that resembles the new network type is defined. It is 499 inserted by means of augmentation below the network-types container. 500 Subsequently, data nodes for any network-type specific node 501 parameters are defined and augmented into the node list. The new 502 data nodes can be defined as conditional ("when") on the presence of 503 the corresponding network type in the containing network. In cases 504 where there are any requirements or restrictions in terms of network 505 hierarchies, such as when a network of a new network-type requires a 506 specific type of underlay network, it is possible to define 507 corresponding constraints as well and augment the supporting-network 508 list accordingly. However, care should be taken to avoid excessive 509 definitions of constraints. 511 Subsequently, augmentations are defined against network- 512 topology.yang. Data nodes are defined both for link parameters, as 513 well as termination point parameters, that are specific to the new 514 network type. Those data nodes are inserted by way of augmentation 515 into the link and termination-point lists, respectively. Again, data 516 nodes can be defined as conditional on the presence of the 517 corresponding network-type in the containing network, by adding a 518 corresponding "when"-statement. 520 It is possible, but not required, to group data nodes for a given 521 network-type under a dedicated container. Doing so introduces 522 further structure, but lengthens data node path names. 524 In cases where a hierarchy of network types is defined, augmentations 525 can in turn against augmenting modules, with the module of a network 526 "sub-type" augmenting the module of a network "super-type". 528 4.4. Discussion and selected design decisions 530 4.4.1. Container structure 532 Rather than maintaining lists in separate containers, the model is 533 kept relatively flat in terms of its containment structure. Lists of 534 nodes, links, termination-points, and supporting-nodes, supporting- 535 links, and supporting-termination-points are not kept in separate 536 containers. Therefore, path specifiers used to refer to specific 537 nodes, be it in management operations or in specifications of 538 constraints, can remain relatively compact. Of course, this means 539 there is no separate structure in instance information that separates 540 elements of different lists from one another. Such structure is 541 semantically not required, although it might enhance human 542 readability in some cases. 544 4.4.2. Underlay hierarchies and mappings 546 To minimize assumptions of what a particular entity might actually 547 represent, mappings between networks, nodes, links, and termination 548 points are kept strictly generic. For example, no assumptions are 549 made whether a termination point actually refers to an interface, or 550 whether a node refers to a specific "system" or device; the model at 551 this generic level makes no provisions for that. 553 Where additional specifics about mappings between upper and lower 554 layers are required, those can be captured in augmenting modules. 555 For example, to express that a termination point in a particular 556 network type maps to an interface, an augmenting module can introduce 557 an augmentation to the termination point which introduces a leaf of 558 type ifref that references the corresponding interface [RFC7223]. 559 Similarly, if a node maps to a particular device or network element, 560 an augmenting module can augment the node data with a leaf that 561 references the network element. 563 It is possible for links at one level of a hierarchy to map to 564 multiple links at another level of the hierarchy. For example, a VPN 565 topology might model VPN tunnels as links. Where a VPN tunnel maps 566 to a path that is composed of a chain of several links, the link will 567 contain a list of those supporting links. Likewise, it is possible 568 for a link at one level of a hierarchy to aggregate a bundle of links 569 at another level of the hierarchy. 571 4.4.3. Dealing with changes in underlay networks 573 It is possible for a network to undergo churn even as other networks 574 are layered on top of it. When a supporting node, link, or 575 termination point is deleted, the supporting leafrefs in the overlay 576 will be left dangling. To allow for this possibility, the model 577 makes use of the "require-instance" construct of YANG 1.1 [RFC7950]. 579 It is the responsibility of the application maintaining the overlay 580 to deal with the possibility of churn in the underlay network. When 581 a server receives a request to configure an overlay network, it 582 SHOULD validate whether supporting nodes/links/tps refer to nodes in 583 the underlay are actually in existence. Configuration requests in 584 which supporting nodes/links/tps refer to objects currently not in 585 existence SHOULD be rejected. It is the responsibility of the 586 application to update the overlay when a supporting node/link/tp is 587 deleted at a later point in time. For this purpose, an application 588 might subscribe to updates when changes to the underlay occur, for 589 example using mechanisms defined in 590 [I-D.draft-ietf-netconf-yang-push]. 592 4.4.4. Use of groupings 594 The model makes use of groupings, instead of simply defining data 595 nodes "in-line". This allows to more easily include the 596 corresponding data nodes in notifications, which then do not need to 597 respecify each data node that is to be included. The tradeoff for 598 this is that it makes the specification of constraints more complex, 599 because constraints involving data nodes outside the grouping need to 600 be specified in conjunction with a "uses" statement where the 601 grouping is applied. This also means that constraints and XPath- 602 statements need to specified in such a way that they navigate "down" 603 first and select entire sets of nodes, as opposed to being able to 604 simply specify them against individual data nodes. 606 4.4.5. Cardinality and directionality of links 608 The topology model includes links that are point-to-point and 609 unidirectional. It does not directly support multipoint and 610 bidirectional links. While this may appear as a limitation, it does 611 keep the model simple, generic, and allows it to very easily be 612 subjected to applications that make use of graph algorithms. Bi- 613 directional connections can be represented through pairs of 614 unidirectional links. Multipoint networks can be represented through 615 pseudo-nodes (similar to IS-IS, for example). By introducing 616 hierarchies of nodes, with nodes at one level mapping onto a set of 617 other nodes at another level, and introducing new links for nodes at 618 that level, topologies with connections representing non-point-to- 619 point communication patterns can be represented. 621 4.4.6. Multihoming and link aggregation 623 Links are terminated by a single termination point, not sets of 624 termination points. Connections involving multihoming or link 625 aggregation schemes need to be represented using multiple point-to- 626 point links, then defining a link at a higher layer that is supported 627 by those individual links. 629 4.4.7. Mapping redundancy 631 In a hierarchy of networks, there are nodes mapping to nodes, links 632 mapping to links, and termination points mapping to termination 633 points. Some of this information is redundant. Specifically, if the 634 link-to-links mapping known, and the termination points of each link 635 known, termination point mapping information can be derived via 636 transitive closure and does not have to be explicitly configured. 637 Nonetheless, in order to not constrain applications regarding which 638 mappings they want to configure and which should be derived, the 639 model does provide for the option to configure this information 640 explicitly. The model includes integrity constraints to allow for 641 validating for consistency. 643 4.4.8. Typing 645 A network's network types are represented using a container which 646 contains a data node for each of its network types. A network can 647 encompass several types of network simultaneously, hence a container 648 is used instead of a case construct, with each network type in turn 649 represented by a dedicated presence container itself. The reason for 650 not simply using an empty leaf, or even simpler, do away even with 651 the network container and just use a leaf-list of network-type 652 instead, is to be able to represent "class hierarchies" of network 653 types, with one network type refining the other. Network-type 654 specific containers are to be defined in the network-specific 655 modules, augmenting the network-types container. 657 4.4.9. Representing the same device in multiple networks 659 One common requirement concerns the ability to represent that the 660 same device can be part of multiple networks and topologies. 661 However, the model defines a node as relative to the network that it 662 is contained in. The same node cannot be part of multiple 663 topologies. In many cases, a node will be the abstraction of a 664 particular device in a network. To reflect that the same device is 665 part of multiple topologies, the following approach might be chosen: 667 A new type of network to represent a "physical" (or "device") network 668 is introduced, with nodes representing devices. This network forms 669 an underlay network for logical networks above it, with nodes of the 670 logical network mapping onto nodes in the physical network. 672 This scenario is depicted in the following figure. It depicts three 673 networks with two nodes each. A physical network P consists of an 674 inventory of two nodes, D1 and D2, each representing a device. A 675 second network, X, has a third network, Y, as its underlay. Both X 676 and Y also have the physical network P as underlay. X1 has both Y1 677 and D1 as underlay nodes, while Y1 has D1 as underlay node. 678 Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as 679 underlay node. The fact that X1 and Y1 are both instantiated on the 680 same physical node D1 can be easily derived. 682 +---------------------+ 683 / [X1]____[X2] / X(Service Overlay) 684 +----:--:----:--------+ 685 ..: :..: : 686 ........: ....: : :.... 687 +-----:-------------:--+ : :... 688 / [Y1]____[Y2]....: / :.. : 689 +------|-------|-------+ :.. :... 690 Y(L3) | +---------------------:-----+ : 691 | +----:----|-:----------+ 692 +------------------------/---[D1] [D2] / 693 +----------------------+ 694 P (Physical network) 696 Figure 6: Topology hierarchy example - multiple underlays 698 In the case of a physical network, nodes represent physical devices 699 and termination points physical ports. It should be noted that it is 700 also conceivable to augment the model for a physical network-type, 701 defining augmentations that have nodes reference system information 702 and termination points reference physical interfaces, in order to 703 provide a bridge between network and device models. 705 4.5. Supporting client-configured and server-provided network topology 707 YANG requires data nodes to be designated as either configuration or 708 operational data, but not both, yet it is important to have all 709 network information, including vertical cross-network dependencies, 710 captured in one coherent model. In most cases, network topology 711 information is discovered about a network; the topology is considered 712 a property of the network that is reflected in the model. That said, 713 it is conceivable that certain types of topology need to also be 714 configurable by an application. The model needs to support both 715 cases. 717 There are several alternatives in which this can be addressed. The 718 alternative chosen in this draft does not restrict network topology 719 information as read-only, but includes a state "server-provided" that 720 indicates for each network whether it is populated by the server or 721 by a client application. Client applications that do attempt to 722 modify network topology may simply see their actions reverted, not 723 unlike other client applications that compete with one another, each 724 wanting to "own" the same data. When Netconf Access Control Model 725 [RFC6536] is supported, node access rules SHOULD be automatically 726 maintained by a server to deny client write access to network and 727 topology instances for which "server-provided" is true. 729 It should be noted that this solution stretches its use of the 730 configuration concept slightly. Configuration information in general 731 is subject to backup and restore, which is not applicable to server- 732 provided information. Perhaps more noteworthy is the potential 733 ability of a client to lock a configuration and thus prevent changes 734 to server-provided network topology while the lock is in effect. As 735 a result it would potentially incur a time lag until topology changes 736 that occur in the meantime are reflected, unless implementations 737 choose to provide special treatment for network topology information. 739 Other alternatives had been considered. In one alternative, all 740 information about network topology is in effect is represented as 741 network state, i.e. as read-only information, regardless of how it 742 came into being. For cases where network topology needs to be 743 configured, a second branch for configurable topology information is 744 introduced. Any network topology configuration is mirrored by 745 network state information. A configurable network will thus be 746 represented twice: once in the read-only list of all networks, a 747 second time in a configuration sandbox. One implication of this 748 solution would have been significantly increased complexity of 749 augmentations due to multiple target branches. 751 Another alternative would make use of a YANG extension to tag 752 specific network instances as "server-provided" instead of defining a 753 leaf object, or rely on the concept of YANG metadata [RFC7952] for 754 the same effect. The tag would be automatically applied to any 755 topology data that comes into being (respectively is configured) by 756 an embedded application on the network, as opposed to e.g. a 757 controller application. 759 4.6. Identifiers of string or URI type 761 The current model defines identifiers of nodes, networks, links, and 762 termination points as URIs. An alternative would define them as 763 string. 765 The case for strings is that they will be easier to implement. The 766 reason for choosing URIs is that the topology/node/tp exists in a 767 larger context, hence it is useful to be able to correlate 768 identifiers across systems. While strings, being the universal data 769 type, are easier for human beings (a string is a string is a string), 770 they also muddle things. What typically happens is that strings have 771 some structure which is magically assigned and the knowledge of this 772 structure has to be communicated to each system working with the 773 data. A URI makes the structure explicit and also attaches 774 additional semantics: the URI, unlike a free-form string, can be fed 775 into a URI resolver, which can point to additional resources 776 associated with the URI. This property is important when the 777 topology data is integrated into a larger, more complex system. 779 5. Interactions with Other YANG Modules 781 The model makes use of data types that have been defined in 782 [RFC6991]. 784 This is a protocol independent yang model with topology information. 785 It is separate from and not linked with data models that are used to 786 configure routing protocols or routing information. This includes 787 e.g. model "ietf-routing" [RFC8022] and model "ietf-fb-rib" 788 [I-D.draft-acee-rtgwg-yang-rib-extend]. 790 The model obeys the requirements for the ephemeral state found in the 791 document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral 792 topology data that is server provided, the process tasked with 793 maintaining topology information will load information from the 794 routing process (such as OSPF) into the data model without relying on 795 a configuration datastore. 797 6. YANG Modules 799 6.1. Defining the Abstract Network: network.yang 801 file "ietf-network@2016-11-15.yang" 802 module ietf-network { 803 yang-version 1.1; 804 namespace "urn:ietf:params:xml:ns:yang:ietf-network"; 805 prefix nd; 806 import ietf-inet-types { 807 prefix inet; 808 } 810 organization 811 "IETF I2RS (Interface to the Routing System) Working Group"; 813 contact 814 "WG Web: 815 WG List: 817 WG Chair: Susan Hares 818 820 WG Chair: Russ White 821 823 Editor: Alexander Clemm 824 826 Editor: Jan Medved 827 829 Editor: Robert Varga 830 832 Editor: Nitin Bahadur 833 835 Editor: Hariharan Ananthakrishnan 836 838 Editor: Xufeng Liu 839 "; 841 description 842 "This module defines a common base model for a collection 843 of nodes in a network. Node definitions are further used 844 in network topologies and inventories. 846 Copyright (c) 2016 IETF Trust and the persons identified as 847 authors of the code. All rights reserved. 849 Redistribution and use in source and binary forms, with or 850 without modification, is permitted pursuant to, and subject 851 to the license terms contained in, the Simplified BSD License 852 set forth in Section 4.c of the IETF Trust's Legal Provisions 853 Relating to IETF Documents 854 (http://trustee.ietf.org/license-info). 856 This version of this YANG module is part of 857 draft-ietf-i2rs-yang-network-topo-07; 858 see the RFC itself for full legal notices. 860 NOTE TO RFC EDITOR: Please replace above reference to 861 draft-ietf-i2rs-yang-network-topo-07 with RFC 862 number when published (i.e. RFC xxxx)."; 864 revision 2016-11-15 { 865 description 866 "Initial revision. 867 NOTE TO RFC EDITOR: Please replace the following reference 868 to draft-ietf-i2rs-yang-network-topo-07 with 869 RFC number when published (i.e. RFC xxxx)."; 870 reference 871 "draft-ietf-i2rs-yang-network-topo-07"; 872 } 874 typedef node-id { 875 type inet:uri; 876 description 877 "Identifier for a node. The precise structure of the node-id 878 will be up to the implementation. Some implementations MAY 879 for example, pick a uri that includes the network-id as 880 part of the path. The identifier SHOULD be chosen such that 881 the same node in a real network topology will always be 882 identified through the same identifier, even if the model is 883 instantiated in separate datastores. An implementation MAY 884 choose to capture semantics in the identifier, for example to 885 indicate the type of node."; 886 } 888 typedef network-id { 889 type inet:uri; 890 description 891 "Identifier for a network. The precise structure of the 892 network-id will be up to an implementation. 893 The identifier SHOULD be chosen such that the same network 894 will always be identified through the same identifier, 895 even if the model is instantiated in separate datastores. 896 An implementation MAY choose to capture semantics in the 897 identifier, for example to indicate the type of network."; 898 } 900 grouping network-ref { 901 description 902 "Contains the information necessary to reference a network, 903 for example an underlay network."; 904 leaf network-ref { 905 type leafref { 906 path "/nd:networks/nd:network/nd:network-id"; 907 require-instance false; 908 } 909 description 910 "Used to reference a network, for example an underlay 911 network."; 912 } 913 } 915 grouping node-ref { 916 description 917 "Contains the information necessary to reference a node."; 918 leaf node-ref { 919 type leafref { 920 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 921 "network-ref]/nd:node/nd:node-id"; 922 require-instance false; 923 } 924 description 925 "Used to reference a node. 926 Nodes are identified relative to the network they are 927 contained in."; 928 } 929 uses network-ref; 930 } 932 container networks { 933 description 934 "Serves as top-level container for a list of networks."; 935 list network { 936 key "network-id"; 937 description 938 "Describes a network. 939 A network typically contains an inventory of nodes, 940 topological information (augmented through 941 network-topology model), as well as layering 942 information."; 943 container network-types { 944 description 945 "Serves as an augmentation target. 946 The network type is indicated through corresponding 947 presence containers augmented into this container."; 948 } 949 leaf network-id { 950 type network-id; 951 description 952 "Identifies a network."; 953 } 954 leaf server-provided { 955 type boolean; 956 config false; 957 description 958 "Indicates whether the information concerning this 959 particular network is populated by the server 960 (server-provided true, the general case for network 961 information discovered from the server), 962 or whether it is configured by a client 963 (server-provided true, possible e.g. for 964 service overlays managed through a controller). 965 Clients should not attempt to make modifications 966 to network instances with server-provided set to 967 true; when they do, they need to be aware that 968 any modifications they make are subject to be 969 reverted by the server. 970 For servers that support NACM (Netconf Access Control 971 Model), data node rules should ideally prevent 972 write access by other clients to the network instance 973 when server-provided is set to true."; 974 } 975 list supporting-network { 976 key "network-ref"; 977 description 978 "An underlay network, used to represent layered network 979 topologies."; 980 leaf network-ref { 981 type leafref { 982 path "/networks/network/network-id"; 983 require-instance false; 984 } 985 description 986 "References the underlay network."; 987 } 988 } 989 list node { 990 key "node-id"; 991 description 992 "The inventory of nodes of this network."; 993 leaf node-id { 994 type node-id; 995 description 996 "Identifies a node uniquely within the containing 997 network."; 999 } 1000 list supporting-node { 1001 key "network-ref node-ref"; 1002 description 1003 "Represents another node, in an underlay network, that 1004 this node is supported by. Used to represent layering 1005 structure."; 1006 leaf network-ref { 1007 type leafref { 1008 path "../../../supporting-network/network-ref"; 1009 require-instance false; 1010 } 1011 description 1012 "References the underlay network that the 1013 underlay node is part of."; 1014 } 1015 leaf node-ref { 1016 type leafref { 1017 path "/networks/network/node/node-id"; 1018 require-instance false; 1019 } 1020 description 1021 "References the underlay node itself."; 1022 } 1023 } 1024 } 1025 } 1026 } 1027 } 1029 1031 6.2. Creating Abstract Network Topology: network-topology.yang 1033 file "ietf-network-topology@2016-11-15.yang" 1034 module ietf-network-topology { 1035 yang-version 1.1; 1036 namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; 1037 prefix lnk; 1039 import ietf-inet-types { 1040 prefix inet; 1041 } 1042 import ietf-network { 1043 prefix nd; 1044 } 1046 organization 1047 "IETF I2RS (Interface to the Routing System) Working Group"; 1049 contact 1050 "WG Web: 1051 WG List: 1053 WG Chair: Susan Hares 1054 1056 WG Chair: Russ White 1057 1059 Editor: Alexander Clemm 1060 1062 Editor: Jan Medved 1063 1065 Editor: Robert Varga 1066 1068 Editor: Nitin Bahadur 1069 1071 Editor: Hariharan Ananthakrishnan 1072 1074 Editor: Xufeng Liu 1075 "; 1077 description 1078 "This module defines a common base model for network topology, 1079 augmenting the base network model with links to connect nodes, 1080 as well as termination points to terminate links on nodes. 1082 Copyright (c) 2016 IETF Trust and the persons identified as 1083 authors of the code. All rights reserved. 1085 Redistribution and use in source and binary forms, with or 1086 without modification, is permitted pursuant to, and subject 1087 to the license terms contained in, the Simplified BSD License 1088 set forth in Section 4.c of the IETF Trust's Legal Provisions 1089 Relating to IETF Documents 1090 (http://trustee.ietf.org/license-info). 1092 This version of this YANG module is part of 1093 draft-ietf-i2rs-yang-network-topo-07; 1094 see the RFC itself for full legal notices. 1096 NOTE TO RFC EDITOR: Please replace above reference to 1097 draft-ietf-i2rs-yang-network-topo-07 with RFC 1098 number when published (i.e. RFC xxxx)."; 1100 revision 2016-11-15 { 1101 description 1102 "Initial revision. 1103 NOTE TO RFC EDITOR: Please replace the following reference 1104 to draft-ietf-i2rs-yang-network-topo-07 with 1105 RFC number when published (i.e. RFC xxxx)."; 1106 reference 1107 "draft-ietf-i2rs-yang-network-topo-07"; 1108 } 1110 typedef link-id { 1111 type inet:uri; 1112 description 1113 "An identifier for a link in a topology. 1114 The precise structure of the link-id 1115 will be up to the implementation. 1116 The identifier SHOULD be chosen such that the same link in a 1117 real network topology will always be identified through the 1118 same identifier, even if the model is instantiated in 1119 separate datastores. An implementation MAY choose to capture 1120 semantics in the identifier, for example to indicate the type 1121 of link and/or the type of topology that the link is a part 1122 of."; 1123 } 1125 typedef tp-id { 1126 type inet:uri; 1127 description 1128 "An identifier for termination points (TPs) on a node. 1129 The precise structure of the tp-id 1130 will be up to the implementation. 1131 The identifier SHOULD be chosen such that the same termination 1132 point in a real network topology will always be identified 1133 through the same identifier, even if the model is instantiated 1134 in separate datastores. An implementation MAY choose to 1135 capture semantics in the identifier, for example to indicate 1136 the type of termination point and/or the type of node 1137 that contains the termination point."; 1138 } 1140 grouping link-ref { 1141 description 1142 "References a link in a specific network."; 1143 leaf link-ref { 1144 type leafref { 1145 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1146 "network-ref]/lnk:link/lnk:link-id"; 1147 require-instance false; 1148 } 1149 description 1150 "A type for an absolute reference a link instance. 1151 (This type should not be used for relative references. 1152 In such a case, a relative path should be used instead.)"; 1153 } 1154 uses nd:network-ref; 1155 } 1157 grouping tp-ref { 1158 description 1159 "References a termination point in a specific node."; 1160 leaf tp-ref { 1161 type leafref { 1162 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1163 "network-ref]/nd:node[nd:node-id=current()/../"+ 1164 "node-ref]/lnk:termination-point/lnk:tp-id"; 1165 require-instance false; 1166 } 1167 description 1168 "A type for an absolute reference to a termination point. 1169 (This type should not be used for relative references. 1170 In such a case, a relative path should be used instead.)"; 1171 } 1172 uses nd:node-ref; 1173 } 1175 augment "/nd:networks/nd:network" { 1176 description 1177 "Add links to the network model."; 1178 list link { 1179 key "link-id"; 1180 description 1181 "A network link connects a local (source) node and 1182 a remote (destination) node via a set of 1183 the respective node's termination points. 1184 It is possible to have several links between the same 1185 source and destination nodes. Likewise, a link could 1186 potentially be re-homed between termination points. 1187 Therefore, in order to ensure that we would always know 1188 to distinguish between links, every link is identified by 1189 a dedicated link identifier. Note that a link models a 1190 point-to-point link, not a multipoint link. 1191 Layering dependencies on links in underlay topologies are 1192 not represented, as the layering information of nodes and of 1193 termination points is sufficient."; 1194 container source { 1195 description 1196 "This container holds the logical source of a particular 1197 link."; 1198 leaf source-node { 1199 type leafref { 1200 path "../../../nd:node/nd:node-id"; 1201 require-instance false; 1202 } 1203 description 1204 "Source node identifier, must be in same topology."; 1205 } 1206 leaf source-tp { 1207 type leafref { 1208 path "../../../nd:node[nd:node-id=current()/../"+ 1209 "source-node]/termination-point/tp-id"; 1210 require-instance false; 1211 } 1212 description 1213 "Termination point within source node that terminates 1214 the link."; 1215 } 1216 } 1217 container destination { 1218 description 1219 "This container holds the logical destination of a 1220 particular link."; 1221 leaf dest-node { 1222 type leafref { 1223 path "../../../nd:node/nd:node-id"; 1224 require-instance false; 1225 } 1226 description 1227 "Destination node identifier, must be in the same 1228 network."; 1229 } 1230 leaf dest-tp { 1231 type leafref { 1232 path "../../../nd:node[nd:node-id=current()/../"+ 1233 "dest-node]/termination-point/tp-id"; 1234 require-instance false; 1235 } 1236 description 1237 "Termination point within destination node that 1238 terminates the link."; 1239 } 1241 } 1242 leaf link-id { 1243 type link-id; 1244 description 1245 "The identifier of a link in the topology. 1246 A link is specific to a topology to which it belongs."; 1247 } 1248 list supporting-link { 1249 key "network-ref link-ref"; 1250 description 1251 "Identifies the link, or links, that this link 1252 is dependent on."; 1253 leaf network-ref { 1254 type leafref { 1255 path "../../../nd:supporting-network/nd:network-ref"; 1256 require-instance false; 1257 } 1258 description 1259 "This leaf identifies in which underlay topology 1260 the supporting link is present."; 1261 } 1262 leaf link-ref { 1263 type leafref { 1264 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1265 "../network-ref]/link/link-id"; 1266 require-instance false; 1267 } 1268 description 1269 "This leaf identifies a link which is a part 1270 of this link's underlay. Reference loops in which 1271 a link identifies itself as its underlay, either 1272 directly or transitively, are not allowed."; 1273 } 1274 } 1275 } 1276 } 1277 augment "/nd:networks/nd:network/nd:node" { 1278 description 1279 "Augment termination points which terminate links. 1280 Termination points can ultimately be mapped to interfaces."; 1281 list termination-point { 1282 key "tp-id"; 1283 description 1284 "A termination point can terminate a link. 1285 Depending on the type of topology, a termination point 1286 could, for example, refer to a port or an interface."; 1287 leaf tp-id { 1288 type tp-id; 1289 description 1290 "Termination point identifier."; 1291 } 1292 list supporting-termination-point { 1293 key "network-ref node-ref tp-ref"; 1294 description 1295 "This list identifies any termination points that 1296 the termination point is dependent on, or maps onto. 1297 Those termination points will themselves be contained 1298 in a supporting node. 1299 This dependency information can be inferred from 1300 the dependencies between links. For this reason, 1301 this item is not separately configurable. Hence no 1302 corresponding constraint needs to be articulated. 1303 The corresponding information is simply provided by the 1304 implementing system."; 1305 leaf network-ref { 1306 type leafref { 1307 path "../../../nd:supporting-node/nd:network-ref"; 1308 require-instance false; 1309 } 1310 description 1311 "This leaf identifies in which topology the 1312 supporting termination point is present."; 1313 } 1314 leaf node-ref { 1315 type leafref { 1316 path "../../../nd:supporting-node/nd:node-ref"; 1317 require-instance false; 1318 } 1319 description 1320 "This leaf identifies in which node the supporting 1321 termination point is present."; 1322 } 1323 leaf tp-ref { 1324 type leafref { 1325 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1326 "../network-ref]/nd:node[nd:node-id=current()/../"+ 1327 "node-ref]/termination-point/tp-id"; 1328 require-instance false; 1329 } 1330 description 1331 "Reference to the underlay node, must be in a 1332 different topology"; 1333 } 1334 } 1335 } 1336 } 1338 } 1340 1342 7. IANA Considerations 1344 This document registers the following namespace URIs in the "IETF XML 1345 Registry" [RFC3688]: 1347 URI: urn:ietf:params:xml:ns:yang:ietf-network 1348 Registrant Contact: The IESG. 1349 XML: N/A; the requested URI is an XML namespace. 1351 URI:urn:ietf:params:xml:ns:yang:ietf-network-topology 1352 Registrant Contact: The IESG. 1353 XML: N/A; the requested URI is an XML namespace. 1355 This document registers the following YANG modules in the "YANG 1356 Module Names" registry [RFC6020]: 1358 Name: ietf-network 1359 Namespace: urn:ietf:params:xml:ns:yang:ietf-network 1360 Prefix: l3t 1361 Reference: draft-ietf-i2rs-yang-network-topo-06.txt (RFC form) 1363 Name: ietf-network-topology 1364 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology 1365 Prefix: lnk 1366 Reference: draft-ietf-i2rs-yang-network-topo-06.txt (RFC form) 1368 8. Security Considerations 1370 The YANG module defined in this memo is designed to be accessed via 1371 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1372 secure transport layer, and the mandatory-to-implement secure 1373 transport is Secure Shell (SSH) [RFC6242]. The NETCONF access 1374 control model [RFC6536] provides the means to restrict access for 1375 particular NETCONF users to a pre-configured subset of all available 1376 NETCONF protocol operations and content. 1378 The YANG module defines information that can be configurable in 1379 certain instances, for example in the case of overlay topologies that 1380 can be created by client applications. In such cases, a malicious 1381 client could introduce topologies that are undesired. For example, a 1382 client could remove or add topological links between nodes, which 1383 could lead to an undesired and suboptimal topology, which might 1384 impact service levels and network utilization. It is therefore 1385 important that the NETCONF access control model is vigorously applied 1386 to prevent topology configuration by unauthorized clients. 1388 Topologies that are server-provided and that provide ephemeral 1389 topology information are less vulnerable, as they provide read-only 1390 access to clients. 1392 9. Contributors 1394 The model presented in this paper was contributed to by more people 1395 than can be listed on the author list. Additional contributors 1396 include: 1398 o Ken Gray, Cisco Systems 1400 o Tom Nadeau, Brocade 1402 o Tony Tkacik 1404 o Aleksandr Zhdankin, Cisco 1406 10. Acknowledgements 1408 We wish to acknowledge the helpful contributions, comments, and 1409 suggestions that were received from Alia Atlas, Vishnu Pavan Beeram, 1410 Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan 1411 Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Kent 1412 Watsen, and Xian Zhang. 1414 11. References 1416 11.1. Normative References 1418 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 1419 requirement levels", RFC 2119, March 1997. 1421 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 1422 2004. 1424 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1425 Network Configuration Protocol (NETCONF)", RFC 6020, 1426 October 2010. 1428 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1429 Bierman, "Network Configuration Protocol (NETCONF)", 1430 RFC 6241, June 2011. 1432 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1433 Shell (SSH)", RFC 6242, June 2011. 1435 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1436 Protocol (NETCONF) Access Control Model", RFC 6536, March 1437 2012. 1439 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1440 July 2013. 1442 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 1443 RFC 7950, August 2016. 1445 11.2. Informative References 1447 [I-D.draft-acee-rtgwg-yang-rib-extend] 1448 Lindem, A. and Y. Qu, "YANG Data Model for RIB 1449 Extensions", I-D draft-acee-rtgwg-yang-rib-extend-02, 1450 October 2016. 1452 [I-D.draft-ietf-i2rs-ephemeral-state] 1453 Haas, J. and S. Hares, "I2RS Ephemeral State 1454 Requirements", I-D draft-ietf-i2rs-ephemeral-state-22, 1455 November 2016. 1457 [I-D.draft-ietf-i2rs-usecase-reqs-summary] 1458 Hares, S. and M. Chen, "Summary of I2RS Use Case 1459 Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- 1460 02, March 2015. 1462 [I-D.draft-ietf-netconf-yang-push] 1463 Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., 1464 Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, 1465 "Subscribing to YANG datastore push updates", I-D draft- 1466 ietf-netconf-yang-push-04, October 2016. 1468 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1469 Dual Environments", RFC 1195, December 1990. 1471 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1473 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1474 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1475 Tunnels", RFC 3209, December 2001. 1477 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1478 Management", RFC 7223, May 2014. 1480 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1481 RFC 7952, August 2016. 1483 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 1484 Management", RFC 8022, November 2016. 1486 Authors' Addresses 1488 Alexander Clemm 1489 Sympotech 1491 EMail: alex@sympotech.com 1493 Jan Medved 1494 Cisco 1496 EMail: jmedved@cisco.com 1498 Robert Varga 1499 Pantheon Technologies SRO 1501 EMail: robert.varga@pantheon.sk 1503 Nitin Bahadur 1504 Bracket Computing 1506 EMail: nitin_bahadur@yahoo.com 1508 Hariharan Ananthakrishnan 1509 Packet Design 1511 EMail: hari@packetdesign.com 1513 Xufeng Liu 1514 Ericsson 1516 EMail: xliu@kuatrotech.com