idnits 2.17.1 draft-ietf-i2rs-yang-network-topo-09.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 (November 30, 2016) is 2703 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 (-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 (-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 (~~), 14 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: June 3, 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 30, 2016 16 A Data Model for Network Topologies 17 draft-ietf-i2rs-yang-network-topo-09.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 June 3, 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 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] and model "ietf-fb-rib" 775 [I-D.draft-acee-rtgwg-yang-rib-extend]. 777 The model obeys the requirements for the ephemeral state found in the 778 document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral 779 topology data that is server provided, the process tasked with 780 maintaining topology information will load information from the 781 routing process (such as OSPF) into the data model without relying on 782 a configuration datastore. 784 6. YANG Modules 786 6.1. Defining the Abstract Network: network.yang 788 file "ietf-network@2016-11-30.yang" 789 module ietf-network { 790 yang-version 1.1; 791 namespace "urn:ietf:params:xml:ns:yang:ietf-network"; 792 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) 2016 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). 843 This version of this YANG module is part of 844 draft-ietf-i2rs-yang-network-topo-09; 845 see the RFC itself for full legal notices. 847 NOTE TO RFC EDITOR: Please replace above reference to 848 draft-ietf-i2rs-yang-network-topo-09 with RFC 849 number when published (i.e. RFC xxxx)."; 851 revision 2016-11-30 { 852 description 853 "Initial revision. 854 NOTE TO RFC EDITOR: Please replace the following reference 855 to draft-ietf-i2rs-yang-network-topo-09 with 856 RFC number when published (i.e. RFC xxxx)."; 857 reference 858 "draft-ietf-i2rs-yang-network-topo-09"; 859 } 861 typedef node-id { 862 type inet:uri; 863 description 864 "Identifier for a node. The precise structure of the node-id 865 will be up to the implementation. Some implementations MAY 866 for example, pick a uri that includes the network-id as 867 part of the path. The identifier SHOULD be chosen such that 868 the same node in a real network topology will always be 869 identified through the same identifier, even if the model is 870 instantiated in separate datastores. An implementation MAY 871 choose to capture semantics in the identifier, for example to 872 indicate the type of node."; 873 } 875 typedef network-id { 876 type inet:uri; 877 description 878 "Identifier for a network. The precise structure of the 879 network-id will be up to an implementation. 880 The identifier SHOULD be chosen such that the same network 881 will always be identified through the same identifier, 882 even if the model is instantiated in separate datastores. 883 An implementation MAY choose to capture semantics in the 884 identifier, for example to indicate the type of network."; 885 } 887 grouping network-ref { 888 description 889 "Contains the information necessary to reference a network, 890 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."; 986 } 987 list supporting-node { 988 key "network-ref node-ref"; 989 description 990 "Represents another node, in an underlay network, that 991 this node is supported by. Used to represent layering 992 structure."; 993 leaf network-ref { 994 type leafref { 995 path "../../../supporting-network/network-ref"; 996 require-instance false; 997 } 998 description 999 "References the underlay network that the 1000 underlay node is part of."; 1001 } 1002 leaf node-ref { 1003 type leafref { 1004 path "/networks/network/node/node-id"; 1005 require-instance false; 1006 } 1007 description 1008 "References the underlay node itself."; 1009 } 1010 } 1011 } 1012 } 1013 } 1014 } 1016 1018 6.2. Creating Abstract Network Topology: network-topology.yang 1020 file "ietf-network-topology@2016-11-30.yang" 1021 module ietf-network-topology { 1022 yang-version 1.1; 1023 namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; 1024 prefix lnk; 1026 import ietf-inet-types { 1027 prefix inet; 1028 } 1029 import ietf-network { 1030 prefix nd; 1031 } 1033 organization 1034 "IETF I2RS (Interface to the Routing System) Working Group"; 1036 contact 1037 "WG Web: 1038 WG List: 1040 WG Chair: Susan Hares 1041 1043 WG Chair: Russ White 1044 1046 Editor: Alexander Clemm 1047 1049 Editor: Jan Medved 1050 1052 Editor: Robert Varga 1053 1055 Editor: Nitin Bahadur 1056 1058 Editor: Hariharan Ananthakrishnan 1059 1061 Editor: Xufeng Liu 1062 "; 1064 description 1065 "This module defines a common base model for network topology, 1066 augmenting the base network model with links to connect nodes, 1067 as well as termination points to terminate links on nodes. 1069 Copyright (c) 2016 IETF Trust and the persons identified as 1070 authors of the code. All rights reserved. 1072 Redistribution and use in source and binary forms, with or 1073 without modification, is permitted pursuant to, and subject 1074 to the license terms contained in, the Simplified BSD License 1075 set forth in Section 4.c of the IETF Trust's Legal Provisions 1076 Relating to IETF Documents 1077 (http://trustee.ietf.org/license-info). 1079 This version of this YANG module is part of 1080 draft-ietf-i2rs-yang-network-topo-09; 1081 see the RFC itself for full legal notices. 1083 NOTE TO RFC EDITOR: Please replace above reference to 1084 draft-ietf-i2rs-yang-network-topo-09 with RFC 1085 number when published (i.e. RFC xxxx)."; 1087 revision 2016-11-30 { 1088 description 1089 "Initial revision. 1090 NOTE TO RFC EDITOR: Please replace the following reference 1091 to draft-ietf-i2rs-yang-network-topo-09 with 1092 RFC number when published (i.e. RFC xxxx)."; 1093 reference 1094 "draft-ietf-i2rs-yang-network-topo-09"; 1095 } 1097 typedef link-id { 1098 type inet:uri; 1099 description 1100 "An identifier for a link in a topology. 1101 The precise structure of the link-id 1102 will be up to the implementation. 1103 The identifier SHOULD be chosen such that the same link in a 1104 real network topology will always be identified through the 1105 same identifier, even if the model is instantiated in 1106 separate datastores. An implementation MAY choose to capture 1107 semantics in the identifier, for example to indicate the type 1108 of link and/or the type of topology that the link is a part 1109 of."; 1110 } 1112 typedef tp-id { 1113 type inet:uri; 1114 description 1115 "An identifier for termination points (TPs) on a node. 1116 The precise structure of the tp-id 1117 will be up to the implementation. 1118 The identifier SHOULD be chosen such that the same termination 1119 point in a real network topology will always be identified 1120 through the same identifier, even if the model is instantiated 1121 in separate datastores. An implementation MAY choose to 1122 capture semantics in the identifier, for example to indicate 1123 the type of termination point and/or the type of node 1124 that contains the termination point."; 1125 } 1127 grouping link-ref { 1128 description 1129 "References a link in a specific network."; 1130 leaf link-ref { 1131 type leafref { 1132 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1133 "network-ref]/lnk:link/lnk:link-id"; 1134 require-instance false; 1135 } 1136 description 1137 "A type for an absolute reference a link instance. 1138 (This type should not be used for relative references. 1139 In such a case, a relative path should be used instead.)"; 1140 } 1141 uses nd:network-ref; 1142 } 1144 grouping tp-ref { 1145 description 1146 "References a termination point in a specific node."; 1147 leaf tp-ref { 1148 type leafref { 1149 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1150 "network-ref]/nd:node[nd:node-id=current()/../"+ 1151 "node-ref]/lnk:termination-point/lnk:tp-id"; 1152 require-instance false; 1153 } 1154 description 1155 "A type for an absolute reference to a termination point. 1156 (This type should not be used for relative references. 1157 In such a case, a relative path should be used instead.)"; 1158 } 1159 uses nd:node-ref; 1160 } 1162 augment "/nd:networks/nd:network" { 1163 description 1164 "Add links to the network model."; 1165 list link { 1166 key "link-id"; 1167 description 1168 "A network link connects a local (source) node and 1169 a remote (destination) node via a set of 1170 the respective node's termination points. 1171 It is possible to have several links between the same 1172 source and destination nodes. Likewise, a link could 1173 potentially be re-homed between termination points. 1174 Therefore, in order to ensure that we would always know 1175 to distinguish between links, every link is identified by 1176 a dedicated link identifier. Note that a link models a 1177 point-to-point link, not a multipoint link. 1178 Layering dependencies on links in underlay topologies are 1179 not represented, as the layering information of nodes and of 1180 termination points is sufficient."; 1181 container source { 1182 description 1183 "This container holds the logical source of a particular 1184 link."; 1185 leaf source-node { 1186 type leafref { 1187 path "../../../nd:node/nd:node-id"; 1188 require-instance false; 1189 } 1190 description 1191 "Source node identifier, must be in same topology."; 1192 } 1193 leaf source-tp { 1194 type leafref { 1195 path "../../../nd:node[nd:node-id=current()/../"+ 1196 "source-node]/termination-point/tp-id"; 1197 require-instance false; 1198 } 1199 description 1200 "Termination point within source node that terminates 1201 the link."; 1202 } 1203 } 1204 container destination { 1205 description 1206 "This container holds the logical destination of a 1207 particular link."; 1208 leaf dest-node { 1209 type leafref { 1210 path "../../../nd:node/nd:node-id"; 1211 require-instance false; 1212 } 1213 description 1214 "Destination node identifier, must be in the same 1215 network."; 1216 } 1217 leaf dest-tp { 1218 type leafref { 1219 path "../../../nd:node[nd:node-id=current()/../"+ 1220 "dest-node]/termination-point/tp-id"; 1221 require-instance false; 1222 } 1223 description 1224 "Termination point within destination node that 1225 terminates the link."; 1226 } 1228 } 1229 leaf link-id { 1230 type link-id; 1231 description 1232 "The identifier of a link in the topology. 1233 A link is specific to a topology to which it belongs."; 1234 } 1235 list supporting-link { 1236 key "network-ref link-ref"; 1237 description 1238 "Identifies the link, or links, that this link 1239 is dependent on."; 1240 leaf network-ref { 1241 type leafref { 1242 path "../../../nd:supporting-network/nd:network-ref"; 1243 require-instance false; 1244 } 1245 description 1246 "This leaf identifies in which underlay topology 1247 the supporting link is present."; 1248 } 1249 leaf link-ref { 1250 type leafref { 1251 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1252 "../network-ref]/link/link-id"; 1253 require-instance false; 1254 } 1255 description 1256 "This leaf identifies a link which is a part 1257 of this link's underlay. Reference loops in which 1258 a link identifies itself as its underlay, either 1259 directly or transitively, are not allowed."; 1260 } 1261 } 1262 } 1263 } 1264 augment "/nd:networks/nd:network/nd:node" { 1265 description 1266 "Augment termination points which terminate links. 1267 Termination points can ultimately be mapped to interfaces."; 1268 list termination-point { 1269 key "tp-id"; 1270 description 1271 "A termination point can terminate a link. 1272 Depending on the type of topology, a termination point 1273 could, for example, refer to a port or an interface."; 1274 leaf tp-id { 1275 type tp-id; 1276 description 1277 "Termination point identifier."; 1278 } 1279 list supporting-termination-point { 1280 key "network-ref node-ref tp-ref"; 1281 description 1282 "This list identifies any termination points that 1283 the termination point is dependent on, or maps onto. 1284 Those termination points will themselves be contained 1285 in a supporting node. 1286 This dependency information can be inferred from 1287 the dependencies between links. For this reason, 1288 this item is not separately configurable. Hence no 1289 corresponding constraint needs to be articulated. 1290 The corresponding information is simply provided by the 1291 implementing system."; 1292 leaf network-ref { 1293 type leafref { 1294 path "../../../nd:supporting-node/nd:network-ref"; 1295 require-instance false; 1296 } 1297 description 1298 "This leaf identifies in which topology the 1299 supporting termination point is present."; 1300 } 1301 leaf node-ref { 1302 type leafref { 1303 path "../../../nd:supporting-node/nd:node-ref"; 1304 require-instance false; 1305 } 1306 description 1307 "This leaf identifies in which node the supporting 1308 termination point is present."; 1309 } 1310 leaf tp-ref { 1311 type leafref { 1312 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1313 "../network-ref]/nd:node[nd:node-id=current()/../"+ 1314 "node-ref]/termination-point/tp-id"; 1315 require-instance false; 1316 } 1317 description 1318 "Reference to the underlay node, must be in a 1319 different topology"; 1320 } 1321 } 1322 } 1323 } 1325 } 1327 1329 7. IANA Considerations 1331 This document registers the following namespace URIs in the "IETF XML 1332 Registry" [RFC3688]: 1334 URI: urn:ietf:params:xml:ns:yang:ietf-network 1335 Registrant Contact: The IESG. 1336 XML: N/A; the requested URI is an XML namespace. 1338 URI:urn:ietf:params:xml:ns:yang:ietf-network-topology 1339 Registrant Contact: The IESG. 1340 XML: N/A; the requested URI is an XML namespace. 1342 This document registers the following YANG modules in the "YANG 1343 Module Names" registry [RFC6020]: 1345 Name: ietf-network 1346 Namespace: urn:ietf:params:xml:ns:yang:ietf-network 1347 Prefix: nd 1348 Reference: draft-ietf-i2rs-yang-network-topo-09.txt (RFC form) 1350 Name: ietf-network-topology 1351 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology 1352 Prefix: lnk 1353 Reference: draft-ietf-i2rs-yang-network-topo-09.txt (RFC form) 1355 8. Security Considerations 1357 The YANG module defined in this memo is designed to be accessed via 1358 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1359 secure transport layer, and the mandatory-to-implement secure 1360 transport is Secure Shell (SSH) [RFC6242]. The NETCONF access 1361 control model [RFC6536] provides the means to restrict access for 1362 particular NETCONF users to a pre-configured subset of all available 1363 NETCONF protocol operations and content. 1365 The YANG module defines information that can be configurable in 1366 certain instances, for example in the case of overlay topologies that 1367 can be created by client applications. In such cases, a malicious 1368 client could introduce topologies that are undesired. For example, a 1369 client could remove or add topological links between nodes, which 1370 could lead to an undesired and suboptimal topology, which might 1371 impact service levels and network utilization. It is therefore 1372 important that the NETCONF access control model is vigorously applied 1373 to prevent topology configuration by unauthorized clients. 1375 Topologies that are server-provided and that provide ephemeral 1376 topology information are less vulnerable, as they provide read-only 1377 access to clients. 1379 9. Contributors 1381 The model presented in this paper was contributed to by more people 1382 than can be listed on the author list. Additional contributors 1383 include: 1385 o Ken Gray, Cisco Systems 1387 o Tom Nadeau, Brocade 1389 o Tony Tkacik 1391 o Aleksandr Zhdankin, Cisco 1393 10. Acknowledgements 1395 We wish to acknowledge the helpful contributions, comments, and 1396 suggestions that were received from Alia Atlas, Vishnu Pavan Beeram, 1397 Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan 1398 Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Kent 1399 Watsen, and Xian Zhang. 1401 11. References 1403 11.1. Normative References 1405 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 1406 requirement levels", RFC 2119, March 1997. 1408 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 1409 2004. 1411 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1412 Network Configuration Protocol (NETCONF)", RFC 6020, 1413 October 2010. 1415 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1416 Bierman, "Network Configuration Protocol (NETCONF)", 1417 RFC 6241, June 2011. 1419 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1420 Shell (SSH)", RFC 6242, June 2011. 1422 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1423 Protocol (NETCONF) Access Control Model", RFC 6536, March 1424 2012. 1426 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1427 July 2013. 1429 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 1430 RFC 7950, August 2016. 1432 11.2. Informative References 1434 [I-D.draft-acee-rtgwg-yang-rib-extend] 1435 Lindem, A. and Y. Qu, "YANG Data Model for RIB 1436 Extensions", I-D draft-acee-rtgwg-yang-rib-extend-02, 1437 October 2016. 1439 [I-D.draft-ietf-i2rs-ephemeral-state] 1440 Haas, J. and S. Hares, "I2RS Ephemeral State 1441 Requirements", I-D draft-ietf-i2rs-ephemeral-state-22, 1442 November 2016. 1444 [I-D.draft-ietf-i2rs-usecase-reqs-summary] 1445 Hares, S. and M. Chen, "Summary of I2RS Use Case 1446 Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- 1447 03, November 2016. 1449 [I-D.draft-ietf-netconf-yang-push] 1450 Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., 1451 Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, 1452 "Subscribing to YANG datastore push updates", I-D draft- 1453 ietf-netconf-yang-push-04, October 2016. 1455 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1456 Dual Environments", RFC 1195, December 1990. 1458 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1460 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1461 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1462 Tunnels", RFC 3209, December 2001. 1464 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1465 Management", RFC 7223, May 2014. 1467 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1468 RFC 7952, August 2016. 1470 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 1471 Management", RFC 8022, November 2016. 1473 Authors' Addresses 1475 Alexander Clemm 1476 Sympotech 1478 EMail: alex@sympotech.com 1480 Jan Medved 1481 Cisco 1483 EMail: jmedved@cisco.com 1485 Robert Varga 1486 Pantheon Technologies SRO 1488 EMail: robert.varga@pantheon.sk 1490 Nitin Bahadur 1491 Bracket Computing 1493 EMail: nitin_bahadur@yahoo.com 1495 Hariharan Ananthakrishnan 1496 Packet Design 1498 EMail: hari@packetdesign.com 1500 Xufeng Liu 1501 Ericsson 1503 EMail: xliu@kuatrotech.com