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