idnits 2.17.1 draft-ietf-i2rs-yang-network-topo-11.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 (February 16, 2017) is 2598 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 716, but not defined == Missing Reference: 'D2' is mentioned on line 716, but not defined ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) -- Unexpected draft version: The latest known version of draft-ietf-i2rs-usecase-reqs-summary is -03, but you're referring to -30. == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-04 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-00 -- 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 (==), 4 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: August 20, 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 February 16, 2017 16 A Data Model for Network Topologies 17 draft-ietf-i2rs-yang-network-topo-11.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 August 20, 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 . . . . . . . . . . . . . . . . . . . 8 64 4.1. Base Network Model . . . . . . . . . . . . . . . . . . . 8 65 4.2. Base Network Topology Model . . . . . . . . . . . . . . . 10 66 4.3. Extending the model . . . . . . . . . . . . . . . . . . . 12 67 4.4. Discussion and selected design decisions . . . . . . . . 12 68 4.4.1. Container structure . . . . . . . . . . . . . . . . . 12 69 4.4.2. Underlay hierarchies and mappings . . . . . . . . . . 13 70 4.4.3. Dealing with changes in underlay networks . . . . . . 13 71 4.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 14 72 4.4.5. Cardinality and directionality of links . . . . . . . 14 73 4.4.6. Multihoming and link aggregation . . . . . . . . . . 14 74 4.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 15 75 4.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.4.9. Representing the same device in multiple networks . . 15 77 4.4.10. Supporting client-configured and server-provided 78 network topology . . . . . . . . . . . . . . . . . . 16 79 4.4.11. Identifiers of string or URI type . . . . . . . . . . 17 80 5. Interactions with Other YANG Modules . . . . . . . . . . . . 18 81 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 82 6.1. Defining the Abstract Network: network.yang . . . . . . . 18 83 6.2. Creating Abstract Network Topology: network-topology.yang 23 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 90 11.2. Informative References . . . . . . . . . . . . . . . . . 32 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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 In this data model, a network is categorized as either server- 278 provided or not. If a network is server-provided, then it is 279 dynamically learned information that can be read from the operational 280 data-store. For example, as mentioned above, when a network 281 controller reads a router's topology, that network is server- 282 provided. This data model can also be used to create or modify 283 network topologies such as might be associated with an inventory or 284 with an overlay network. Such a network is not server-provided but 285 configured. This data model allows a network to refer to a 286 supporting-network, supporting-nodes, supporting-links, etc. 288 The model does allow to layer a network that is configured on top of 289 one that is server-provided. This permits the configuration of 290 overlay networks on top of networks that are discovered. 291 Specifically, this data model is structured to support being 292 implemented as part of the ephemeral data-store 293 [I-D.draft-ietf-netmod-revised-datastores], defined as requirement 294 Ephemeral-REQ-03 in [I-D.draft-ietf-i2rs-ephemeral-state]. This 295 allows a written (e.g. not server-provided) network topology to refer 296 to a dynamically learned server-provided network. A simple use case 297 might involve creating an overlay network that is supported by the 298 dynamically discovered IP routed network topology. When an 299 implementation places written data for this data model in the 300 ephemeral data store, then such a network MAY refer to another 301 network that is server-provided. 303 An implementation's security policy MAY further restrict what 304 information the server-provided model is allowed to access in 305 standard configuration data-stores, or what server-provided network 306 an ephemeral data store may access. These security policies are 307 outside the scope of the standardization of this model. 309 Finally, it should be noted that the model is still subject to update 310 per ongoing discussions that are related to design decisions 311 regarding the fact that some layers of the network topology may be 312 server provided while others may be configured. These issues are 313 outlined in section 4.4.10. 315 2. Key Words 317 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 318 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 319 document are to be interpreted as described in [RFC2119]. 321 3. Definitions and Acronyms 323 Datastore: A conceptual store of instantiated management information, 324 with individual data items represented by data nodes which are 325 arranged in hierarchical manner. 327 Data subtree: An instantiated data node and the data nodes that are 328 hierarchically contained within it. 330 HTTP: Hyper-Text Transfer Protocol 332 IGP: Interior Gateway Protocol 334 IS-IS: Intermediate System to Intermediate System protocol 336 NETCONF: Network Configuration Protocol 338 OSPF: Open Shortest Path First, a link state routing protocol 340 URI: Uniform Resource Identifier 342 ReST: Representational State Transfer, a style of stateless interface 343 and protocol that is generally carried over HTTP 345 YANG: A data definition language for NETCONF 347 4. Model Structure Details 349 4.1. Base Network Model 351 The abstract (base) network model is defined in the network.yang 352 module. Its structure is shown in the following figure. Brackets 353 enclose list keys, "rw" means configuration data, "ro" means 354 operational state data, and "?" designates optional nodes. A "+" 355 indicates a line break. 357 module: ietf-network 358 +--rw networks 359 +--rw network* [network-id] 360 +--rw network-types 361 +--rw network-id network-id 362 +--ro server-provided? boolean 363 +--rw supporting-network* [network-ref] 364 | +--rw network-ref -> /networks/network/network-id 365 +--rw node* [node-id] 366 +--rw node-id node-id 367 +--rw supporting-node* [network-ref node-ref] 368 +--rw network-ref -> ../../../supporting-network/ + 369 | network-ref 370 +--rw node-ref -> /networks/network/node/node-id 372 Figure 4: The structure of the abstract (base) network model 374 The model contains a container with a list of networks. Each network 375 is captured in its own list entry, distinguished via a network-id. 377 A network has a certain type, such as L2, L3, OSPF or IS-IS. A 378 network can even have multiple types simultaneously. The type, or 379 types, are captured underneath the container "network-types". In 380 this module it serves merely as an augmentation target; network- 381 specific modules will later introduce new data nodes to represent new 382 network types below this target, i.e. insert them below "network- 383 types" by ways of YANG augmentation. 385 When a network is of a certain type, it will contain a corresponding 386 data node. Network types SHOULD always be represented using presence 387 containers, not leafs of empty type. This allows to represent 388 hierarchies of network subtypes within the instance information. For 389 example, an instance of an OSPF network (which, at the same time, is 390 a layer 3 unicast IGP network) would contain underneath "network- 391 types" another container "l3-unicast-igp-network", which in turn 392 would contain a container "ospf-network". 394 A network can in turn be part of a hierarchy of networks, building on 395 top of other networks. Any such networks are captured in the list 396 "supporting-network". A supporting network is in effect an underlay 397 network. 399 Furthermore, a network contains an inventory of nodes that are part 400 of the network. The nodes of a network are captured in their own 401 list. Each node is identified relative to its containing network by 402 a node-id. 404 It should be noted that a node does not exist independently of a 405 network; instead it is a part of the network that it is contained in. 406 In cases where the same entity takes part in multiple networks, or at 407 multiple layers of a networking stack, the same entity will be 408 represented by multiple nodes, one for each network. In other words, 409 the node represents an abstraction of the device for the particular 410 network that it a is part of. To represent that the same entity or 411 same device is part of multiple topologies or networks, it is 412 possible to create one "physical" network with a list of nodes for 413 each of the devices or entities. This (physical) network, 414 respectively the (entities) nodes in that network, can then be 415 referred to as underlay network and nodes from the other (logical) 416 networks and nodes, respectively. Note that the model allows to 417 define more than one underlay network (and node), allowing for 418 simultaneous representation of layered network- and service 419 topologies and physical instantiation. 421 Similar to a network, a node can be supported by other nodes, and map 422 onto one or more other nodes in an underlay network. This is 423 captured in the list "supporting-node". The resulting hierarchy of 424 nodes allows also to represent device stacks, where a node at one 425 level is supported by a set of nodes at an underlying level. For 426 example, a "router" node might be supported by a node representing a 427 route processor and separate nodes for various line cards and service 428 modules, a virtual router might be supported or hosted on a physical 429 device represented by a separate node, and so on. 431 Finally, there is an object "server-provided". This object is state 432 that indicates how the network came into being. Network data can 433 come into being in one of two ways. In one way, network data is 434 configured by client applications, for example in case of overlay 435 networks that are configured by an SDN Controller application. In 436 annother way, it is populated by the server, in case of networks that 437 can be discovered. 439 If server-provided is set to false, the network was configured by a 440 client application, for example in the case of an overlay network 441 that is configured by a controller application. If server-provided 442 is set to true, the network was populated by the server itself, 443 respectively an application on the server that is able to discover 444 the network. Client applications SHOULD NOT modify configurations of 445 networks for which "server-provided" is true. When they do, they 446 need to be aware that any modifications they make are subject to be 447 reverted by the server. For servers that support NACM (Netconf 448 Access Control Model), data node rules should ideally prevent write 449 access by other clients to network instances for which server- 450 provided is set to true. 452 4.2. Base Network Topology Model 454 The abstract (base) network topology model is defined in the 455 "network-topology.yang" module. It builds on the network model 456 defined in the "network.yang" module, augmenting it with links 457 (defining how nodes are connected) and termination-points (which 458 anchor the links and are contained in nodes). The structure of the 459 network topology module is shown in the following figure. Brackets 460 enclose list keys, "rw" means configuration data, "ro" means 461 operational state data, and "?" designates optional nodes. A "+" 462 indicates a line break. 464 module: ietf-network-topology 465 augment /nd:networks/nd:network: 466 +--rw link* [link-id] 467 +--rw source 468 | +--rw source-node? -> ../../../nd:node/node-id 469 | +--rw source-tp? -> ../../../nd:node[nd:node-id=current()/+ 470 | ../source-node]/termination-point/tp-id 471 +--rw destination 472 | +--rw dest-node? -> ../../../nd:node/node-id 473 | +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+ 474 | ../dest-node]/termination-point/tp-id 475 +--rw link-id link-id 476 +--rw supporting-link* [network-ref link-ref] 477 +--rw network-ref -> ../../../nd:supporting-network/+ 478 | network-ref 479 +--rw link-ref -> /nd:networks/network+ 480 [nd:network-id=current()/../network-ref]/+ 481 link/link-id 482 augment /nd:networks/nd:network/nd:node: 483 +--rw termination-point* [tp-id] 484 +--rw tp-id tp-id 485 +--rw supporting-termination-point* [network-ref node-ref tp-ref] 486 +--rw network-ref -> ../../../nd:supporting-node/network-ref 487 +--rw node-ref -> ../../../nd:supporting-node/node-ref 488 +--rw tp-ref -> /nd:networks/network[nd:network-id=+ 489 current()/../network-ref]/node+ 490 [nd:node-id=current()/../node-ref]/+ 491 termination-point/tp-id 493 Figure 5: The structure of the abstract (base) network topology model 495 A node has a list of termination points that are used to terminate 496 links. An example of a termination point might be a physical or 497 logical port or, more generally, an interface. 499 Like a node, a termination point can in turn be supported by an 500 underlying termination point, contained in the supporting node of the 501 underlay network. 503 A link is identified by a link-id that uniquely identifies the link 504 within a given topology. Links are point-to-point and 505 unidirectional. Accordingly, a link contains a source and a 506 destination. Both source and destination reference a corresponding 507 node, as well as a termination point on that node. Similar to a 508 node, a link can map onto one or more links in an underlay topology 509 (which are terminated by the corresponding underlay termination 510 points). This is captured in the list "supporting-link". 512 4.3. Extending the model 514 In order to derive a model for a specific type of network, the base 515 model can be extended. This can be done roughly as follows: for the 516 new network type, a new YANG module is introduced. In this module, a 517 number of augmentations are defined against the network and network- 518 topology YANG modules. 520 We start with augmentations against the network.yang module. First, 521 a new network type needs to be defined. For this, a presence 522 container that resembles the new network type is defined. It is 523 inserted by means of augmentation below the network-types container. 524 Subsequently, data nodes for any network-type specific node 525 parameters are defined and augmented into the node list. The new 526 data nodes can be defined as conditional ("when") on the presence of 527 the corresponding network type in the containing network. In cases 528 where there are any requirements or restrictions in terms of network 529 hierarchies, such as when a network of a new network-type requires a 530 specific type of underlay network, it is possible to define 531 corresponding constraints as well and augment the supporting-network 532 list accordingly. However, care should be taken to avoid excessive 533 definitions of constraints. 535 Subsequently, augmentations are defined against network- 536 topology.yang. Data nodes are defined both for link parameters, as 537 well as termination point parameters, that are specific to the new 538 network type. Those data nodes are inserted by way of augmentation 539 into the link and termination-point lists, respectively. Again, data 540 nodes can be defined as conditional on the presence of the 541 corresponding network-type in the containing network, by adding a 542 corresponding "when"-statement. 544 It is possible, but not required, to group data nodes for a given 545 network-type under a dedicated container. Doing so introduces 546 further structure, but lengthens data node path names. 548 In cases where a hierarchy of network types is defined, augmentations 549 can in turn against augmenting modules, with the module of a network 550 "sub-type" augmenting the module of a network "super-type". 552 4.4. Discussion and selected design decisions 554 4.4.1. Container structure 556 Rather than maintaining lists in separate containers, the model is 557 kept relatively flat in terms of its containment structure. Lists of 558 nodes, links, termination-points, and supporting-nodes, supporting- 559 links, and supporting-termination-points are not kept in separate 560 containers. Therefore, path specifiers used to refer to specific 561 nodes, be it in management operations or in specifications of 562 constraints, can remain relatively compact. Of course, this means 563 there is no separate structure in instance information that separates 564 elements of different lists from one another. Such structure is 565 semantically not required, although it might enhance human 566 readability in some cases. 568 4.4.2. Underlay hierarchies and mappings 570 To minimize assumptions of what a particular entity might actually 571 represent, mappings between networks, nodes, links, and termination 572 points are kept strictly generic. For example, no assumptions are 573 made whether a termination point actually refers to an interface, or 574 whether a node refers to a specific "system" or device; the model at 575 this generic level makes no provisions for that. 577 Where additional specifics about mappings between upper and lower 578 layers are required, those can be captured in augmenting modules. 579 For example, to express that a termination point in a particular 580 network type maps to an interface, an augmenting module can introduce 581 an augmentation to the termination point which introduces a leaf of 582 type ifref that references the corresponding interface [RFC7223]. 583 Similarly, if a node maps to a particular device or network element, 584 an augmenting module can augment the node data with a leaf that 585 references the network element. 587 It is possible for links at one level of a hierarchy to map to 588 multiple links at another level of the hierarchy. For example, a VPN 589 topology might model VPN tunnels as links. Where a VPN tunnel maps 590 to a path that is composed of a chain of several links, the link will 591 contain a list of those supporting links. Likewise, it is possible 592 for a link at one level of a hierarchy to aggregate a bundle of links 593 at another level of the hierarchy. 595 4.4.3. Dealing with changes in underlay networks 597 It is possible for a network to undergo churn even as other networks 598 are layered on top of it. When a supporting node, link, or 599 termination point is deleted, the supporting leafrefs in the overlay 600 will be left dangling. To allow for this possibility, the model 601 makes use of the "require-instance" construct of YANG 1.1 [RFC7950]. 603 It is the responsibility of the application maintaining the overlay 604 to deal with the possibility of churn in the underlay network. When 605 a server receives a request to configure an overlay network, it 606 SHOULD validate whether supporting nodes/links/tps refer to nodes in 607 the underlay are actually in existence. Configuration requests in 608 which supporting nodes/links/tps refer to objects currently not in 609 existence SHOULD be rejected. It is the responsibility of the 610 application to update the overlay when a supporting node/link/tp is 611 deleted at a later point in time. For this purpose, an application 612 might subscribe to updates when changes to the underlay occur, for 613 example using mechanisms defined in 614 [I-D.draft-ietf-netconf-yang-push]. 616 4.4.4. Use of groupings 618 The model makes use of groupings, instead of simply defining data 619 nodes "in-line". This allows to more easily include the 620 corresponding data nodes in notifications, which then do not need to 621 respecify each data node that is to be included. The tradeoff for 622 this is that it makes the specification of constraints more complex, 623 because constraints involving data nodes outside the grouping need to 624 be specified in conjunction with a "uses" statement where the 625 grouping is applied. This also means that constraints and XPath- 626 statements need to specified in such a way that they navigate "down" 627 first and select entire sets of nodes, as opposed to being able to 628 simply specify them against individual data nodes. 630 4.4.5. Cardinality and directionality of links 632 The topology model includes links that are point-to-point and 633 unidirectional. It does not directly support multipoint and 634 bidirectional links. While this may appear as a limitation, it does 635 keep the model simple, generic, and allows it to very easily be 636 subjected to applications that make use of graph algorithms. Bi- 637 directional connections can be represented through pairs of 638 unidirectional links. Multipoint networks can be represented through 639 pseudo-nodes (similar to IS-IS, for example). By introducing 640 hierarchies of nodes, with nodes at one level mapping onto a set of 641 other nodes at another level, and introducing new links for nodes at 642 that level, topologies with connections representing non-point-to- 643 point communication patterns can be represented. 645 4.4.6. Multihoming and link aggregation 647 Links are terminated by a single termination point, not sets of 648 termination points. Connections involving multihoming or link 649 aggregation schemes need to be represented using multiple point-to- 650 point links, then defining a link at a higher layer that is supported 651 by those individual links. 653 4.4.7. Mapping redundancy 655 In a hierarchy of networks, there are nodes mapping to nodes, links 656 mapping to links, and termination points mapping to termination 657 points. Some of this information is redundant. Specifically, if the 658 link-to-links mapping known, and the termination points of each link 659 known, termination point mapping information can be derived via 660 transitive closure and does not have to be explicitly configured. 661 Nonetheless, in order to not constrain applications regarding which 662 mappings they want to configure and which should be derived, the 663 model does provide for the option to configure this information 664 explicitly. The model includes integrity constraints to allow for 665 validating for consistency. 667 4.4.8. Typing 669 A network's network types are represented using a container which 670 contains a data node for each of its network types. A network can 671 encompass several types of network simultaneously, hence a container 672 is used instead of a case construct, with each network type in turn 673 represented by a dedicated presence container itself. The reason for 674 not simply using an empty leaf, or even simpler, do away even with 675 the network container and just use a leaf-list of network-type 676 instead, is to be able to represent "class hierarchies" of network 677 types, with one network type refining the other. Network-type 678 specific containers are to be defined in the network-specific 679 modules, augmenting the network-types container. 681 4.4.9. Representing the same device in multiple networks 683 One common requirement concerns the ability to represent that the 684 same device can be part of multiple networks and topologies. 685 However, the model defines a node as relative to the network that it 686 is contained in. The same node cannot be part of multiple 687 topologies. In many cases, a node will be the abstraction of a 688 particular device in a network. To reflect that the same device is 689 part of multiple topologies, the following approach might be chosen: 690 A new type of network to represent a "physical" (or "device") network 691 is introduced, with nodes representing devices. This network forms 692 an underlay network for logical networks above it, with nodes of the 693 logical network mapping onto nodes in the physical network. 695 This scenario is depicted in the following figure. It depicts three 696 networks with two nodes each. A physical network P consists of an 697 inventory of two nodes, D1 and D2, each representing a device. A 698 second network, X, has a third network, Y, as its underlay. Both X 699 and Y also have the physical network P as underlay. X1 has both Y1 700 and D1 as underlay nodes, while Y1 has D1 as underlay node. 702 Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as 703 underlay node. The fact that X1 and Y1 are both instantiated on the 704 same physical node D1 can be easily derived. 706 +---------------------+ 707 / [X1]____[X2] / X(Service Overlay) 708 +----:--:----:--------+ 709 ..: :..: : 710 ........: ....: : :.... 711 +-----:-------------:--+ : :... 712 / [Y1]____[Y2]....: / :.. : 713 +------|-------|-------+ :.. :... 714 Y(L3) | +---------------------:-----+ : 715 | +----:----|-:----------+ 716 +------------------------/---[D1] [D2] / 717 +----------------------+ 718 P (Physical network) 720 Figure 6: Topology hierarchy example - multiple underlays 722 In the case of a physical network, nodes represent physical devices 723 and termination points physical ports. It should be noted that it is 724 also conceivable to augment the model for a physical network-type, 725 defining augmentations that have nodes reference system information 726 and termination points reference physical interfaces, in order to 727 provide a bridge between network and device models. 729 4.4.10. Supporting client-configured and server-provided network 730 topology 732 YANG requires data nodes to be designated as either configuration or 733 operational data, but not both, yet it is important to have all 734 network information, including vertical cross-network dependencies, 735 captured in one coherent model. In most cases, network topology 736 information is discovered about a network; the topology is considered 737 a property of the network that is reflected in the model. That said, 738 it is conceivable that certain types of topology need to also be 739 configurable by an application. The model needs to support both 740 cases. 742 There are several alternatives in which this can be addressed. The 743 alternative chosen in this draft does not restrict network topology 744 information as read-only, but includes a state "server-provided" that 745 indicates for each network whether it is populated by the server or 746 by a client application. Client applications that do attempt to 747 modify network topology may simply see their actions reverted, not 748 unlike other client applications that compete with one another, each 749 wanting to "own" the same data. When Netconf Access Control Model 750 [RFC6536] is supported, node access rules SHOULD be automatically 751 maintained by a server to deny client write access to network and 752 topology instances for which "server-provided" is true. 754 It should be noted that this solution stretches its use of the 755 configuration concept slightly. Configuration information in general 756 is subject to backup and restore, which is not applicable to server- 757 provided information. Perhaps more noteworthy is the potential 758 ability of a client to lock a configuration and thus prevent changes 759 to server-provided network topology while the lock is in effect. As 760 a result it would potentially incur a time lag until topology changes 761 that occur in the meantime are reflected, unless implementations 762 choose to provide special treatment for network topology information. 764 Other alternatives had been considered. In one alternative, all 765 information about network topology is in effect is represented as 766 network state, i.e. as read-only information, regardless of how it 767 came into being. For cases where network topology needs to be 768 configured, a second branch for configurable topology information is 769 introduced. Any network topology configuration is mirrored by 770 network state information. A configurable network will thus be 771 represented twice: once in the read-only list of all networks, a 772 second time in a configuration sandbox. One implication of this 773 solution would have been significantly increased complexity of 774 augmentations due to multiple target branches. 776 Another alternative would make use of a YANG extension to tag 777 specific network instances as "server-provided" instead of defining a 778 leaf object, or rely on the concept of YANG metadata [RFC7952] for 779 the same effect. The tag would be automatically applied to any 780 topology data that comes into being (respectively is configured) by 781 an embedded application on the network, as opposed to e.g. a 782 controller application. 784 4.4.11. Identifiers of string or URI type 786 The current model defines identifiers of nodes, networks, links, and 787 termination points as URIs. An alternative would define them as 788 string. 790 The case for strings is that they will be easier to implement. The 791 reason for choosing URIs is that the topology/node/tp exists in a 792 larger context, hence it is useful to be able to correlate 793 identifiers across systems. While strings, being the universal data 794 type, are easier for human beings (a string is a string is a string), 795 they also muddle things. What typically happens is that strings have 796 some structure which is magically assigned and the knowledge of this 797 structure has to be communicated to each system working with the 798 data. A URI makes the structure explicit and also attaches 799 additional semantics: the URI, unlike a free-form string, can be fed 800 into a URI resolver, which can point to additional resources 801 associated with the URI. This property is important when the 802 topology data is integrated into a larger, more complex system. 804 5. Interactions with Other YANG Modules 806 The model makes use of data types that have been defined in 807 [RFC6991]. 809 This is a protocol independent yang model with topology information. 810 It is separate from and not linked with data models that are used to 811 configure routing protocols or routing information. This includes 812 e.g. model "ietf-routing" [RFC8022]. 814 The model obeys the requirements for the ephemeral state found in the 815 document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral 816 topology data that is server provided, the process tasked with 817 maintaining topology information will load information from the 818 routing process (such as OSPF) into the data model without relying on 819 a configuration datastore. 821 6. YANG Modules 823 6.1. Defining the Abstract Network: network.yang 825 file "ietf-network@2017-02-16.yang" 826 module ietf-network { 827 yang-version 1.1; 828 namespace "urn:ietf:params:xml:ns:yang:ietf-network"; 829 prefix nd; 831 import ietf-inet-types { 832 prefix inet; 833 } 835 organization 836 "IETF I2RS (Interface to the Routing System) Working Group"; 838 contact 839 "WG Web: 840 WG List: 842 WG Chair: Susan Hares 843 845 WG Chair: Russ White 846 848 Editor: Alexander Clemm 849 851 Editor: Jan Medved 852 854 Editor: Robert Varga 855 857 Editor: Nitin Bahadur 858 860 Editor: Hariharan Ananthakrishnan 861 863 Editor: Xufeng Liu 864 "; 866 description 867 "This module defines a common base model for a collection 868 of nodes in a network. Node definitions are further used 869 in network topologies and inventories. 871 Copyright (c) 2017 IETF Trust and the persons identified as 872 authors of the code. All rights reserved. 874 Redistribution and use in source and binary forms, with or 875 without modification, is permitted pursuant to, and subject 876 to the license terms contained in, the Simplified BSD License 877 set forth in Section 4.c of the IETF Trust's Legal Provisions 878 Relating to IETF Documents 879 (http://trustee.ietf.org/license-info). 881 This version of this YANG module is part of 882 draft-ietf-i2rs-yang-network-topo-11; 883 see the RFC itself for full legal notices. 885 NOTE TO RFC EDITOR: Please replace above reference to 886 draft-ietf-i2rs-yang-network-topo-11 with RFC 887 number when published (i.e. RFC xxxx)."; 889 revision 2017-02-16 { 890 description 891 "Initial revision. 892 NOTE TO RFC EDITOR: Please replace the following reference 893 to draft-ietf-i2rs-yang-network-topo-11 with 894 RFC number when published (i.e. RFC xxxx)."; 895 reference 896 "draft-ietf-i2rs-yang-network-topo-11"; 897 } 899 typedef node-id { 900 type inet:uri; 901 description 902 "Identifier for a node. The precise structure of the node-id 903 will be up to the implementation. Some implementations MAY 904 for example, pick a uri that includes the network-id as 905 part of the path. The identifier SHOULD be chosen such that 906 the same node in a real network topology will always be 907 identified through the same identifier, even if the model is 908 instantiated in separate datastores. An implementation MAY 909 choose to capture semantics in the identifier, for example to 910 indicate the type of node."; 911 } 913 typedef network-id { 914 type inet:uri; 915 description 916 "Identifier for a network. The precise structure of the 917 network-id will be up to an implementation. 918 The identifier SHOULD be chosen such that the same network 919 will always be identified through the same identifier, 920 even if the model is instantiated in separate datastores. 921 An implementation MAY choose to capture semantics in the 922 identifier, for example to indicate the type of network."; 923 } 925 grouping network-ref { 926 description 927 "Contains the information necessary to reference a network, 928 for example an underlay network."; 929 leaf network-ref { 930 type leafref { 931 path "/nd:networks/nd:network/nd:network-id"; 932 require-instance false; 933 } 934 description 935 "Used to reference a network, for example an underlay 936 network."; 937 } 938 } 940 grouping node-ref { 941 description 942 "Contains the information necessary to reference a node."; 943 leaf node-ref { 944 type leafref { 945 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 946 "network-ref]/nd:node/nd:node-id"; 947 require-instance false; 948 } 949 description 950 "Used to reference a node. 951 Nodes are identified relative to the network they are 952 contained in."; 953 } 954 uses network-ref; 955 } 957 container networks { 958 description 959 "Serves as top-level container for a list of networks."; 960 list network { 961 key "network-id"; 962 description 963 "Describes a network. 964 A network typically contains an inventory of nodes, 965 topological information (augmented through 966 network-topology model), as well as layering 967 information."; 968 container network-types { 969 description 970 "Serves as an augmentation target. 971 The network type is indicated through corresponding 972 presence containers augmented into this container."; 973 } 974 leaf network-id { 975 type network-id; 976 description 977 "Identifies a network."; 978 } 979 leaf server-provided { 980 type boolean; 981 config false; 982 description 983 "Indicates whether the information concerning this 984 particular network is populated by the server 985 (server-provided true, the general case for network 986 information discovered from the server), 987 or whether it is configured by a client 988 (server-provided true, possible e.g. for 989 service overlays managed through a controller). 990 Clients should not attempt to make modifications 991 to network instances with server-provided set to 992 true; when they do, they need to be aware that 993 any modifications they make are subject to be 994 reverted by the server. 995 For servers that support NACM (Netconf Access Control 996 Model), data node rules should ideally prevent 997 write access by other clients to the network instance 998 when server-provided is set to true."; 999 } 1000 list supporting-network { 1001 key "network-ref"; 1002 description 1003 "An underlay network, used to represent layered network 1004 topologies."; 1005 leaf network-ref { 1006 type leafref { 1007 path "/networks/network/network-id"; 1008 require-instance false; 1009 } 1010 description 1011 "References the underlay network."; 1012 } 1013 } 1014 list node { 1015 key "node-id"; 1016 description 1017 "The inventory of nodes of this network."; 1018 leaf node-id { 1019 type node-id; 1020 description 1021 "Identifies a node uniquely within the containing 1022 network."; 1023 } 1024 list supporting-node { 1025 key "network-ref node-ref"; 1026 description 1027 "Represents another node, in an underlay network, that 1028 this node is supported by. Used to represent layering 1029 structure."; 1030 leaf network-ref { 1031 type leafref { 1032 path "../../../supporting-network/network-ref"; 1033 require-instance false; 1034 } 1035 description 1036 "References the underlay network that the 1037 underlay node is part of."; 1038 } 1039 leaf node-ref { 1040 type leafref { 1041 path "/networks/network/node/node-id"; 1042 require-instance false; 1043 } 1044 description 1045 "References the underlay node itself."; 1046 } 1047 } 1048 } 1049 } 1050 } 1051 } 1053 1055 6.2. Creating Abstract Network Topology: network-topology.yang 1057 file "ietf-network-topology@2017-02-16.yang" 1058 module ietf-network-topology { 1059 yang-version 1.1; 1060 namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; 1061 prefix lnk; 1063 import ietf-inet-types { 1064 prefix inet; 1065 } 1066 import ietf-network { 1067 prefix nd; 1068 } 1070 organization 1071 "IETF I2RS (Interface to the Routing System) Working Group"; 1073 contact 1074 "WG Web: 1075 WG List: 1077 WG Chair: Susan Hares 1078 1080 WG Chair: Russ White 1081 1083 Editor: Alexander Clemm 1084 1086 Editor: Jan Medved 1087 1089 Editor: Robert Varga 1090 1092 Editor: Nitin Bahadur 1093 1095 Editor: Hariharan Ananthakrishnan 1096 1098 Editor: Xufeng Liu 1099 "; 1101 description 1102 "This module defines a common base model for network topology, 1103 augmenting the base network model with links to connect nodes, 1104 as well as termination points to terminate links on nodes. 1106 Copyright (c) 2017 IETF Trust and the persons identified as 1107 authors of the code. All rights reserved. 1109 Redistribution and use in source and binary forms, with or 1110 without modification, is permitted pursuant to, and subject 1111 to the license terms contained in, the Simplified BSD License 1112 set forth in Section 4.c of the IETF Trust's Legal Provisions 1113 Relating to IETF Documents 1114 (http://trustee.ietf.org/license-info). 1116 This version of this YANG module is part of 1117 draft-ietf-i2rs-yang-network-topo-11; 1118 see the RFC itself for full legal notices. 1120 NOTE TO RFC EDITOR: Please replace above reference to 1121 draft-ietf-i2rs-yang-network-topo-11 with RFC 1122 number when published (i.e. RFC xxxx)."; 1124 revision 2017-02-16 { 1125 description 1126 "Initial revision. 1127 NOTE TO RFC EDITOR: Please replace the following reference 1128 to draft-ietf-i2rs-yang-network-topo-11 with 1129 RFC number when published (i.e. RFC xxxx)."; 1130 reference 1131 "draft-ietf-i2rs-yang-network-topo-11"; 1132 } 1133 typedef link-id { 1134 type inet:uri; 1135 description 1136 "An identifier for a link in a topology. 1137 The precise structure of the link-id 1138 will be up to the implementation. 1139 The identifier SHOULD be chosen such that the same link in a 1140 real network topology will always be identified through the 1141 same identifier, even if the model is instantiated in 1142 separate datastores. An implementation MAY choose to capture 1143 semantics in the identifier, for example to indicate the type 1144 of link and/or the type of topology that the link is a part 1145 of."; 1146 } 1148 typedef tp-id { 1149 type inet:uri; 1150 description 1151 "An identifier for termination points (TPs) on a node. 1152 The precise structure of the tp-id 1153 will be up to the implementation. 1154 The identifier SHOULD be chosen such that the same termination 1155 point in a real network topology will always be identified 1156 through the same identifier, even if the model is instantiated 1157 in separate datastores. An implementation MAY choose to 1158 capture semantics in the identifier, for example to indicate 1159 the type of termination point and/or the type of node 1160 that contains the termination point."; 1161 } 1163 grouping link-ref { 1164 description 1165 "References a link in a specific network."; 1166 leaf link-ref { 1167 type leafref { 1168 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1169 "network-ref]/lnk:link/lnk:link-id"; 1170 require-instance false; 1171 } 1172 description 1173 "A type for an absolute reference a link instance. 1174 (This type should not be used for relative references. 1175 In such a case, a relative path should be used instead.)"; 1176 } 1177 uses nd:network-ref; 1178 } 1180 grouping tp-ref { 1181 description 1182 "References a termination point in a specific node."; 1183 leaf tp-ref { 1184 type leafref { 1185 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1186 "network-ref]/nd:node[nd:node-id=current()/../"+ 1187 "node-ref]/lnk:termination-point/lnk:tp-id"; 1188 require-instance false; 1189 } 1190 description 1191 "A type for an absolute reference to a termination point. 1192 (This type should not be used for relative references. 1193 In such a case, a relative path should be used instead.)"; 1194 } 1195 uses nd:node-ref; 1196 } 1198 augment "/nd:networks/nd:network" { 1199 description 1200 "Add links to the network model."; 1201 list link { 1202 key "link-id"; 1203 description 1204 "A network link connects a local (source) node and 1205 a remote (destination) node via a set of 1206 the respective node's termination points. 1207 It is possible to have several links between the same 1208 source and destination nodes. Likewise, a link could 1209 potentially be re-homed between termination points. 1210 Therefore, in order to ensure that we would always know 1211 to distinguish between links, every link is identified by 1212 a dedicated link identifier. Note that a link models a 1213 point-to-point link, not a multipoint link."; 1214 container source { 1215 description 1216 "This container holds the logical source of a particular 1217 link."; 1218 leaf source-node { 1219 type leafref { 1220 path "../../../nd:node/nd:node-id"; 1221 require-instance false; 1222 } 1223 description 1224 "Source node identifier, must be in same topology."; 1225 } 1226 leaf source-tp { 1227 type leafref { 1228 path "../../../nd:node[nd:node-id=current()/../"+ 1229 "source-node]/termination-point/tp-id"; 1230 require-instance false; 1231 } 1232 description 1233 "Termination point within source node that terminates 1234 the link."; 1235 } 1236 } 1237 container destination { 1238 description 1239 "This container holds the logical destination of a 1240 particular link."; 1241 leaf dest-node { 1242 type leafref { 1243 path "../../../nd:node/nd:node-id"; 1244 require-instance false; 1245 } 1246 description 1247 "Destination node identifier, must be in the same 1248 network."; 1249 } 1250 leaf dest-tp { 1251 type leafref { 1252 path "../../../nd:node[nd:node-id=current()/../"+ 1253 "dest-node]/termination-point/tp-id"; 1254 require-instance false; 1255 } 1256 description 1257 "Termination point within destination node that 1258 terminates the link."; 1259 } 1260 } 1261 leaf link-id { 1262 type link-id; 1263 description 1264 "The identifier of a link in the topology. 1265 A link is specific to a topology to which it belongs."; 1266 } 1267 list supporting-link { 1268 key "network-ref link-ref"; 1269 description 1270 "Identifies the link, or links, that this link 1271 is dependent on."; 1272 leaf network-ref { 1273 type leafref { 1274 path "../../../nd:supporting-network/nd:network-ref"; 1275 require-instance false; 1276 } 1277 description 1278 "This leaf identifies in which underlay topology 1279 the supporting link is present."; 1280 } 1281 leaf link-ref { 1282 type leafref { 1283 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1284 "../network-ref]/link/link-id"; 1285 require-instance false; 1286 } 1287 description 1288 "This leaf identifies a link which is a part 1289 of this link's underlay. Reference loops in which 1290 a link identifies itself as its underlay, either 1291 directly or transitively, are not allowed."; 1292 } 1293 } 1294 } 1295 } 1296 augment "/nd:networks/nd:network/nd:node" { 1297 description 1298 "Augment termination points which terminate links. 1299 Termination points can ultimately be mapped to interfaces."; 1300 list termination-point { 1301 key "tp-id"; 1302 description 1303 "A termination point can terminate a link. 1304 Depending on the type of topology, a termination point 1305 could, for example, refer to a port or an interface."; 1306 leaf tp-id { 1307 type tp-id; 1308 description 1309 "Termination point identifier."; 1310 } 1311 list supporting-termination-point { 1312 key "network-ref node-ref tp-ref"; 1313 description 1314 "This list identifies any termination points that 1315 the termination point is dependent on, or maps onto. 1316 Those termination points will themselves be contained 1317 in a supporting node. 1318 This dependency information can be inferred from 1319 the dependencies between links. For this reason, 1320 this item is not separately configurable. Hence no 1321 corresponding constraint needs to be articulated. 1322 The corresponding information is simply provided by the 1323 implementing system."; 1324 leaf network-ref { 1325 type leafref { 1326 path "../../../nd:supporting-node/nd:network-ref"; 1327 require-instance false; 1328 } 1329 description 1330 "This leaf identifies in which topology the 1331 supporting termination point is present."; 1332 } 1333 leaf node-ref { 1334 type leafref { 1335 path "../../../nd:supporting-node/nd:node-ref"; 1336 require-instance false; 1337 } 1338 description 1339 "This leaf identifies in which node the supporting 1340 termination point is present."; 1341 } 1342 leaf tp-ref { 1343 type leafref { 1344 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1345 "../network-ref]/nd:node[nd:node-id=current()/../"+ 1346 "node-ref]/termination-point/tp-id"; 1347 require-instance false; 1348 } 1349 description 1350 "Reference to the underlay node, must be in a 1351 different topology"; 1352 } 1353 } 1354 } 1355 } 1356 } 1358 1360 7. IANA Considerations 1362 This document registers the following namespace URIs in the "IETF XML 1363 Registry" [RFC3688]: 1365 URI: urn:ietf:params:xml:ns:yang:ietf-network 1366 Registrant Contact: The IESG. 1367 XML: N/A; the requested URI is an XML namespace. 1369 URI:urn:ietf:params:xml:ns:yang:ietf-network-topology 1370 Registrant Contact: The IESG. 1371 XML: N/A; the requested URI is an XML namespace. 1373 This document registers the following YANG modules in the "YANG 1374 Module Names" registry [RFC6020]: 1376 Name: ietf-network 1377 Namespace: urn:ietf:params:xml:ns:yang:ietf-network 1378 Prefix: nd 1379 Reference: draft-ietf-i2rs-yang-network-topo-11.txt (RFC form) 1381 Name: ietf-network-topology 1382 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology 1383 Prefix: lnk 1384 Reference: draft-ietf-i2rs-yang-network-topo-11.txt (RFC form) 1386 8. Security Considerations 1388 The YANG module defined in this memo is independent of a particular 1389 protocol and can be accessed via a number of protocols that need to 1390 access YANG-defined data. This includes but is not limited to the 1391 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 1392 transport layer and the mandatory-to-implement secure transport is 1393 Secure Shell (SSH) [RFC6242]. 1395 The NETCONF access control model (NACM) [RFC6536] provides the means 1396 to restrict access for particular NETCONF users to a pre-configured 1397 subset of all available NETCONF protocol operations and content. 1398 However, NACM can be applied analogously also to other protocols that 1399 attempt access to YANG-defined data. In fact, it needs to be applied 1400 in the same way and should, like YANG, thus be considered independent 1401 of any particular protocol that is used to access YANG-defined data. 1402 Otherwise, access control rules defined by NACM could be very easily 1403 circumvented simply by using another access mechanism which does not 1404 enforce NACM. The alternative of mandating the introduction of 1405 mechanisms parallel to NACM that specify the same access control 1406 rules for other transports is clearly undesirable, as this would not 1407 only inhibit ease-of-use of systems that implement multiple protocols 1408 to access YANG data, but also open the specter of security holes due 1409 to inconsistencies in articulation and enforcement of rules across 1410 mechanisms that are essentially redundant. 1412 The YANG module defines information that can be configurable in 1413 certain instances, for example in the case of overlay topologies that 1414 can be created by client applications. In such cases, a malicious 1415 client could introduce topologies that are undesired. Specifically, 1416 a malicious client could attempt to do the following: 1418 o Remove or add a node, a link, a termination point, by creating or 1419 deleting corresponding elements in the node, link, and termination 1420 point lists, respectively. In the case of a topology that is 1421 server-provided, the server will automaticaly correct such 1422 misconfiguration attempts. In the case of a topology that is 1423 configured, the services provided via this topology might be 1424 disrupted. For example, the topology could be "cut" or be 1425 configured in a suboptimal way, leading to degradation of service 1426 levels and possibly disruption of service. 1428 o Modify the underlay information, i.e. the configuration of 1429 supporting-node, supporting-link, and supporting-termination- 1430 point, respectively. Again, in the case of a topology that is 1431 server-provided, the server will automaticaly correct such 1432 misconfiguration attempts. However, in the case of a topology 1433 that is configured, this will affect the vertical layering and the 1434 way in which the overlay maps onto an overlay. This could be 1435 exploited to severely disrupt the overlay network by degrading 1436 service levels. In addition, it could be exploited to result in 1437 increased consumption of resources in the underlay network, for 1438 example by disrupting congruence between overlay and underlay 1439 nodes which would result in routing and bandwidth utilization 1440 inefficiencies. 1442 For those reasons, it is important that the NETCONF access control 1443 model is vigorously applied to prevent topology misconfiguration by 1444 unauthorized clients. 1446 Topologies that are server-provided and that provide ephemeral 1447 topology information are less vulnerable, as they provide read-only 1448 access to clients. 1450 9. Contributors 1452 The model presented in this paper was contributed to by more people 1453 than can be listed on the author list. Additional contributors 1454 include: 1456 o Vishnu Pavan Beeram, Juniper 1458 o Ken Gray, Cisco Systems 1460 o Tom Nadeau, Brocade 1462 o Tony Tkacik 1464 o Kent Watsen, Juniper 1466 o Aleksandr Zhdankin, Cisco 1468 10. Acknowledgements 1470 We wish to acknowledge the helpful contributions, comments, and 1471 suggestions that were received from Alia Atlas, Andy Bierman, Martin 1472 Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka, 1473 Carlos Pignataro, Juergen Schoenwaelder, and Xian Zhang. 1475 11. References 1477 11.1. Normative References 1479 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 1480 requirement levels", RFC 2119, March 1997. 1482 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 1483 2004. 1485 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1486 Network Configuration Protocol (NETCONF)", RFC 6020, 1487 October 2010. 1489 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1490 Bierman, "Network Configuration Protocol (NETCONF)", 1491 RFC 6241, June 2011. 1493 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1494 Shell (SSH)", RFC 6242, June 2011. 1496 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1497 Protocol (NETCONF) Access Control Model", RFC 6536, March 1498 2012. 1500 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1501 July 2013. 1503 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 1504 RFC 7950, August 2016. 1506 11.2. Informative References 1508 [I-D.draft-ietf-i2rs-ephemeral-state] 1509 Haas, J. and S. Hares, "I2RS Ephemeral State 1510 Requirements", I-D draft-ietf-i2rs-ephemeral-state-23, 1511 November 2016. 1513 [I-D.draft-ietf-i2rs-usecase-reqs-summary] 1514 Hares, S. and M. Chen, "Summary of I2RS Use Case 1515 Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- 1516 30, November 2016. 1518 [I-D.draft-ietf-netconf-yang-push] 1519 Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., 1520 Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, 1521 "Subscribing to YANG datastore push updates", I-D draft- 1522 ietf-netconf-yang-push-04, October 2016. 1524 [I-D.draft-ietf-netmod-revised-datastores] 1525 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1526 and R. Wilton, "A Revised Conceptual Model for YANG 1527 Datastores", I-D draft-ietf-netmod-revised-datastores-00, 1528 December 2016. 1530 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1531 Dual Environments", RFC 1195, December 1990. 1533 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1535 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1536 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1537 Tunnels", RFC 3209, December 2001. 1539 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1540 Management", RFC 7223, May 2014. 1542 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1543 RFC 7952, August 2016. 1545 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 1546 Management", RFC 8022, November 2016. 1548 Authors' Addresses 1550 Alexander Clemm 1551 Huawei 1553 EMail: ludwig@clemm.org 1555 Jan Medved 1556 Cisco 1558 EMail: jmedved@cisco.com 1559 Robert Varga 1560 Pantheon Technologies SRO 1562 EMail: robert.varga@pantheon.sk 1564 Nitin Bahadur 1565 Bracket Computing 1567 EMail: nitin_bahadur@yahoo.com 1569 Hariharan Ananthakrishnan 1570 Packet Design 1572 EMail: hari@packetdesign.com 1574 Xufeng Liu 1575 Ericsson 1577 EMail: xliu@kuatrotech.com