idnits 2.17.1 draft-ietf-i2rs-yang-network-topo-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 351: '.... Network types SHOULD always be repr...' RFC 2119 keyword, line 409: '...ent applications SHOULD NOT modify con...' RFC 2119 keyword, line 571: '... SHOULD validate whether supporting ...' RFC 2119 keyword, line 574: '... existence SHOULD be rejected. It i...' RFC 2119 keyword, line 714: '... [RFC6536] is supported, node access rules SHOULD be automatically...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 29, 2016) is 2822 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 219, but not defined == Missing Reference: 'Y5' is mentioned on line 244, but not defined == Missing Reference: 'Z5' is mentioned on line 244, but not defined == Missing Reference: 'Z3' is mentioned on line 244, but not defined == Missing Reference: 'Y4' is mentioned on line 248, but not defined == Missing Reference: 'Y1' is mentioned on line 248, but not defined == Missing Reference: 'Z2' is mentioned on line 248, but not defined == Missing Reference: 'X5' is mentioned on line 257, but not defined == Missing Reference: 'D1' is mentioned on line 681, but not defined == Missing Reference: 'D2' is mentioned on line 681, but not defined == Unused Reference: 'RFC6241' is defined on line 1370, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-03 Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Clemm 3 Internet-Draft J. Medved 4 Intended status: Standards Track R. Varga 5 Expires: January 30, 2017 Cisco 6 T. Tkacik 8 N. Bahadur 9 Bracket Computing 10 H. Ananthakrishnan 11 Packet Design 12 X. Liu 13 Ericsson 14 July 29, 2016 16 A Data Model for Network Topologies 17 draft-ietf-i2rs-yang-network-topo-05.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 January 30, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 7 74 3. Model Structure Details . . . . . . . . . . . . . . . . . . . 7 75 3.1. Base Network Model . . . . . . . . . . . . . . . . . . . 7 76 3.2. Base Network Topology Model . . . . . . . . . . . . . . . 10 77 3.3. Extending the model . . . . . . . . . . . . . . . . . . . 11 78 3.4. Discussion and selected design decisions . . . . . . . . 12 79 3.4.1. Container structure . . . . . . . . . . . . . . . . . 12 80 3.4.2. Underlay hierarchies and mappings . . . . . . . . . . 12 81 3.4.3. Dealing with changes in underlay networks . . . . . . 13 82 3.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 13 83 3.4.5. Cardinality and directionality of links . . . . . . . 13 84 3.4.6. Multihoming and link aggregation . . . . . . . . . . 14 85 3.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 14 86 3.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 14 87 3.4.9. Representing the same device in multiple networks . . 14 88 3.5. Supporting client-configured and server-provided network 89 topology . . . . . . . . . . . . . . . . . . . . . . . . 15 90 3.6. Identifiers of string or URI type . . . . . . . . . . . . 17 91 4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 92 4.1. Defining the Abstract Network: network.yang . . . . . . . 17 93 4.2. Creating Abstract Network Topology: network-topology.yang 22 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 95 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 96 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 99 8.2. Informative References . . . . . . . . . . . . . . . . . 30 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 102 1. Introduction 104 This document introduces an abstract (base) YANG [RFC6020] [RFC6021] 105 data model to represent networks and topologies. The data model is 106 divided into two parts. The first part of the model defines a 107 network model that allows to define network hierarchies (i.e. network 108 stacks) and to maintain an inventory of nodes contained in a network. 109 The second part of the model augments the basic network model with 110 information to describe topology information. Specifically, it adds 111 the concepts of links and termination points to describe how nodes in 112 a network are connected to each other. Moreover the model introduces 113 vertical layering relationships between networks that can be 114 augmented to cover both network inventories and network/service 115 topologies. 117 While it would be possible to combine both parts into a single model, 118 the separation facilitates integration of network topology and 119 network inventory models, by allowing to augment network inventory 120 information separately and without concern for topology into the 121 network model. 123 The model can be augmented to describe specifics of particular types 124 of networks and topologies. For example, an augmenting model can 125 provide network node information with attributes that are specific to 126 a particular network type. Examples of augmenting models include 127 models for Layer 2 network topologies, Layer 3 network topologies, 128 such as Unicast IGP, IS-IS [RFC1195] and OSPF [RFC2328], traffic 129 engineering (TE) data [RFC3209], or any of the variety of transport 130 and service topologies. Information specific to particular network 131 types will be captured in separate, technology-specific models. 133 The basic data models introduced in this document are generic in 134 nature and can be applied to many network and service topologies and 135 inventories. The models allow applications to operate on an 136 inventory or topology of any network at a generic level, where 137 specifics of particular inventory/topology types are not required. 138 At the same time, where data specific to a network type does comes 139 into play and the model is augmented, the instantiated data still 140 adheres to the same structure and is represented in consistent 141 fashion. This also facilitates the representation of network 142 hierarchies and dependencies between different network components and 143 network types. 145 The abstract (base) network YANG module introduced in this document, 146 entitled "network.yang", contains a list of abstract network nodes 147 and defines the concept of network hierarchy (network stack). The 148 abstract network node can be augmented in inventory and topology 149 models with inventory and topology specific attributes. Network 150 hierarchy (stack) allows any given network to have one or more 151 "supporting networks". The relationship of the base network model, 152 the inventory models and the topology models is shown in the 153 following figure (dotted lines in the figure denote possible 154 augmentations to models defined in this document). 156 +------------------------+ 157 | | 158 | Abstract Network Model | 159 | | 160 +------------------------+ 161 | 162 +-------+-------+ 163 | | 164 V V 165 +------------+ .............. 166 | Abstract | : Inventory : 167 | Topology | : Model(s) : 168 | Model | : : 169 +------------+ '''''''''''''' 170 | 171 +-------------+-------------+-------------+ 172 | | | | 173 V V V V 174 ............ ............ ............ ............ 175 : L1 : : L2 : : L3 : : Service : 176 : Topology : : Topology : : Topology : : Topology : 177 : Model : : Model : : Model : : Model : 178 '''''''''''' '''''''''''' '''''''''''' '''''''''''' 180 Figure 1: The network model structure 182 The network-topology YANG module introduced in this document, 183 entitled "network-topology.yang", defines a generic topology model at 184 its most general level of abstraction. The module defines a topology 185 graph and components from which it is composed: nodes, edges and 186 termination points. Nodes (from the network.yang module) represent 187 graph vertices and links represent graph edges. Nodes also contain 188 termination points that anchor the links. A network can contain 189 multiple topologies, for example topologies at different layers and 190 overlay topologies. The model therefore allows to capture 191 relationships between topologies, as well as dependencies between 192 nodes and termination points across topologies. An example of a 193 topology stack is shown in the following figure. 195 +---------------------------------------+ 196 / _[X1]_ "Service" / 197 / _/ : \_ / 198 / _/ : \_ / 199 / _/ : \_ / 200 / / : \ / 201 / [X2]__________________[X3] / 202 +---------:--------------:------:-------+ 203 : : : 204 +----:--------------:----:--------------+ 205 / : : : "L3" / 206 / : : : / 207 / : : : / 208 / [Y1]_____________[Y2] / 209 / * * * / 210 / * * * / 211 +--------------*-------------*--*-------+ 212 * * * 213 +--------*----------*----*--------------+ 214 / [Z1]_______________[Z1] "Optical" / 215 / \_ * _/ / 216 / \_ * _/ / 217 / \_ * _/ / 218 / \ * / / 219 / [Z] / 220 +---------------------------------------+ 222 Figure 2: Topology hierarchy (stack) example 224 The figure shows three topology levels. At top, the "Service" 225 topology shows relationships between service entities, such as 226 service functions in a service chain. The "L3" topology shows 227 network elements at Layer 3 (IP) and the "Optical" topology shows 228 network elements at Layer 1. Service functions in the "Service" 229 topology are mapped onto network elements in the "L3" topology, which 230 in turn are mapped onto network elements in the "Optical" topology. 231 The figure shows two Service Functions - X1 and X2 - mapping onto a 232 single L3 network element; this could happen, for example, if two 233 service functions reside in the same VM (or server) and share the 234 same set of network interfaces. The figure shows a single "L3" 235 network element mapped onto multiple "Optical" network elements. 236 This could happen, for example, if a single IP router attaches to 237 multiple ROADMs in the optical domain. 239 Another example of a service topology stack is shown in the following 240 figure. 242 VPN1 VPN2 243 +---------------------+ +---------------------+ 244 / [Y5]... / / [Z5]______[Z3] / 245 / / \ : / / : \_ / : / 246 / / \ : / / : \_ / : / 247 / / \ : / / : \ / : / 248 / [Y4]____[Y1] : / / : [Z2] : / 249 +------:-------:---:--+ +---:---------:-----:-+ 250 : : : : : : 251 : : : : : : 252 : +-------:---:-----:------------:-----:-----+ 253 : / [X1]__:___:___________[X2] : / 254 :/ / \_ : : _____/ / : / 255 : / \_ : _____/ / : / 256 /: / \: / / : / 257 / : / [X5] / : / 258 / : / __/ \__ / : / 259 / : / ___/ \__ / : / 260 / : / ___/ \ / : / 261 / [X4]__________________[X3]..: / 262 +------------------------------------------+ 263 L3 Topology 265 Figure 3: Topology hierarchy (stack) example 267 The figure shows two VPN service topologies (VPN1 and VPN2) 268 instantiated over a common L3 topology. Each VPN service topology is 269 mapped onto a subset of nodes from the common L3 topology. 271 There are multiple applications for such a data model. For example, 272 within the context of I2RS, nodes within the network can use the data 273 model to capture their understanding of the overall network topology 274 and expose it to a network controller. A network controller can then 275 use the instantiated topology data to compare and reconcile its own 276 view of the network topology with that of the network elements that 277 it controls. Alternatively, nodes within the network could propagate 278 this understanding to compare and reconcile this understanding either 279 among themselves or with help of a controller. Beyond the network 280 element and the immediate context of I2RS itself, a network 281 controller might even use the data model to represent its view of the 282 topology that it controls and expose it to applications north of 283 itself. Further use cases that the data model can be applied to are 284 described in [topology-use-cases]. 286 2. Definitions and Acronyms 288 Datastore: A conceptual store of instantiated management information, 289 with individual data items represented by data nodes which are 290 arranged in hierarchical manner. 292 Data subtree: An instantiated data node and the data nodes that are 293 hierarchically contained within it. 295 HTTP: Hyper-Text Transfer Protocol 297 IGP: Interior Gateway Protocol 299 IS-IS: Intermediate System to Intermediate System protocol 301 NETCONF: Network Configuration Protocol 303 OSPF: Open Shortest Path First, a link state routing protocol 305 URI: Uniform Resource Identifier 307 ReST: Representational State Transfer, a style of stateless interface 308 and protocol that is generally carried over HTTP 310 YANG: A data definition language for NETCONF 312 3. Model Structure Details 314 3.1. Base Network Model 316 The abstract (base) network model is defined in the network.yang 317 module. Its structure is shown in the following figure. Brackets 318 enclose list keys, "rw" means configuration data, "ro" means 319 operational state data, and "?" designates optional nodes. A "+" 320 indicates a line break. 322 module: ietf-network 323 +--rw networks 324 +--rw network* [network-id] 325 +--rw network-types 326 +--rw network-id network-id 327 +--ro server-provided? boolean 328 +--rw supporting-network* [network-ref] 329 | +--rw network-ref -> /networks/network/network-id 330 +--rw node* [node-id] 331 +--rw node-id node-id 332 +--rw supporting-node* [network-ref node-ref] 333 +--rw network-ref -> ../../../supporting-network/ + 334 | network-ref 335 +--rw node-ref -> /networks/network/node/node-id 337 Figure 4: The structure of the abstract (base) network model 339 The model contains a container with a list of networks. Each network 340 is captured in its own list entry, distinguished via a network-id. 342 A network has a certain type, such as L2, L3, OSPF or IS-IS. A 343 network can even have multiple types simultaneously. The type, or 344 types, are captured underneath the container "network-types". In 345 this module it serves merely as an augmentation target; network- 346 specific modules will later introduce new data nodes to represent new 347 network types below this target, i.e. insert them below "network- 348 types" by ways of YANG augmentation. 350 When a network is of a certain type, it will contain a corresponding 351 data node. Network types SHOULD always be represented using presence 352 containers, not leafs of empty type. This allows to represent 353 hierarchies of network subtypes within the instance information. For 354 example, an instance of an OSPF network (which, at the same time, is 355 a layer 3 unicast IGP network) would contain underneath "network- 356 types" another container "l3-unicast-igp-network", which in turn 357 would contain a container "ospf-network". 359 A network can in turn be part of a hierarchy of networks, building on 360 top of other networks. Any such networks are captured in the list 361 "supporting-network". A supporting network is in effect an underlay 362 network. 364 Furthermore, a network contains an inventory of nodes that are part 365 of the network. The nodes of a network are captured in their own 366 list. Each node is identified relative to its containing network by 367 a node-id. 369 It should be noted that a node does not exist independently of a 370 network; instead it is a part of the network that it is contained in. 371 In cases where the same entity takes part in multiple networks, or at 372 multiple layers of a networking stack, the same entity will be 373 represented by multiple nodes, one for each network. In other words, 374 the node represents an abstraction of the device for the particular 375 network that it a is part of. To represent that the same entity or 376 same device is part of multiple topologies or networks, it is 377 possible to create one "physical" network with a list of nodes for 378 each of the devices or entities. This (physical) network, 379 respectively the (entities) nodes in that network, can then be 380 referred to as underlay network and nodes from the other (logical) 381 networks and nodes, respectively. Note that the model allows to 382 define more than one underlay network (and node), allowing for 383 simultaneous representation of layered network- and service 384 topologies and physical instantiation. 386 Similar to a network, a node can be supported by other nodes, and map 387 onto one or more other nodes in an underlay network. This is 388 captured in the list "supporting-node". The resulting hierarchy of 389 nodes allows also to represent device stacks, where a node at one 390 level is supported by a set of nodes at an underlying level. For 391 example, a "router" node might be supported by a node representing a 392 route processor and separate nodes for various line cards and service 393 modules, a virtual router might be supported or hosted on a physical 394 device represented by a separate node, and so on. 396 Finally, there is an object "server-provided". This object is state 397 that indicates how the network came into being. Network data can 398 come into being in one of two ways. In one way, network data is 399 configured by client applications, for example in case of overlay 400 networks that are configured by an SDN Controller application. In 401 annother way, it is populated by the server, in case of networks that 402 can be discovered. 404 If server-provided is set to false, the network was configured by a 405 client application, for example in the case of an overlay network 406 that is configured by a controller application. If server-provided 407 is set to true, the network was populated by the server itself, 408 respectively an application on the server that is able to discover 409 the network. Client applications SHOULD NOT modify configurations of 410 networks for which "server-provided" is true. When they do, they 411 need to be aware that any modifications they make are subject to be 412 reverted by the server. For servers that support NACM (Netconf 413 Access Control Model), data node rules should ideally prevent write 414 access by other clients to network instances for which server- 415 provided is set to true. 417 3.2. Base Network Topology Model 419 The abstract (base) network topology model is defined in the 420 "network-topology.yang" module. It builds on the network model 421 defined in the "network.yang" module, augmenting it with links 422 (defining how nodes are connected) and termination-points (which 423 anchor the links and are contained in nodes). The structure of the 424 network topology module is shown in the following figure. Brackets 425 enclose list keys, "rw" means configuration data, "ro" means 426 operational state data, and "?" designates optional nodes. A "+" 427 indicates a line break. 429 module: ietf-network-topology 430 augment /nd:networks/nd:network: 431 +--rw link* [link-id] 432 +--rw source 433 | +--rw source-node? -> ../../../nd:node/node-id 434 | +--rw source-tp? -> ../../../nd:node[nd:node-id=current()/+ 435 | ../source-node]/termination-point/tp-id 436 +--rw destination 437 | +--rw dest-node? -> ../../../nd:node/node-id 438 | +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+ 439 | ../dest-node]/termination-point/tp-id 440 +--rw link-id link-id 441 +--rw supporting-link* [network-ref link-ref] 442 +--rw network-ref -> ../../../nd:supporting-network/network-ref 443 +--rw link-ref -> /nd:networks/network+ 444 [nd:network-id=current()/../network-ref]/+ 445 link/link-id 446 augment /nd:networks/nd:network/nd:node: 447 +--rw termination-point* [tp-id] 448 +--rw tp-id tp-id 449 +--rw supporting-termination-point* [network-ref node-ref tp-ref] 450 +--rw network-ref -> ../../../nd:supporting-node/network-ref 451 +--rw node-ref -> ../../../nd:supporting-node/node-ref 452 +--rw tp-ref -> /nd:networks/network[nd:network-id=+ 453 current()/../network-ref]/node+ 454 [nd:node-id=current()/../node-ref]/+ 455 termination-point/tp-id 457 Figure 5: The structure of the abstract (base) network topology model 459 A node has a list of termination points that are used to terminate 460 links. An example of a termination point might be a physical or 461 logical port or, more generally, an interface. 463 Like a node, a termination point can in turn be supported by an 464 underlying termination point, contained in the supporting node of the 465 underlay network. 467 A link is identified by a link-id that uniquely identifies the link 468 within a given topology. Links are point-to-point and 469 unidirectional. Accordingly, a link contains a source and a 470 destination. Both source and destination reference a corresponding 471 node, as well as a termination point on that node. Similar to a 472 node, a link can map onto one or more links in an underlay topology 473 (which are terminated by the corresponding underlay termination 474 points). This is captured in the list "supporting-link". 476 3.3. Extending the model 478 In order to derive a model for a specific type of network, the base 479 model can be extended. This can be done roughly as follows: for the 480 new network type, a new YANG module is introduced. In this module, a 481 number of augmentations are defined against the network and network- 482 topology YANG modules. 484 We start with augmentations against the network.yang module. First, 485 a new network type needs to be defined. For this, a presence 486 container that resembles the new network type is defined. It is 487 inserted by means of augmentation below the network-types container. 488 Subsequently, data nodes for any network-type specific node 489 parameters are defined and augmented into the node list. The new 490 data nodes can be defined as conditional ("when") on the presence of 491 the corresponding network type in the containing network. In cases 492 where there are any requirements or restrictions in terms of network 493 hierarchies, such as when a network of a new network-type requires a 494 specific type of underlay network, it is possible to define 495 corresponding constraints as well and augment the supporting-network 496 list accordingly. However, care should be taken to avoid excessive 497 definitions of constraints. 499 Subsequently, augmentations are defined against network- 500 topology.yang. Data nodes are defined both for link parameters, as 501 well as termination point parameters, that are specific to the new 502 network type. Those data nodes are inserted by way of augmentation 503 into the link and termination-point lists, respectively. Again, data 504 nodes can be defined as conditional on the presence of the 505 corresponding network-type in the containing network, by adding a 506 corresponding "when"-statement. 508 It is possible, but not required, to group data nodes for a given 509 network-type under a dedicated container. Doing so introduces 510 further structure, but lengthens data node path names. 512 In cases where a hierarchy of network types is defined, augmentations 513 can in turn against augmenting modules, with the module of a network 514 "sub-type" augmenting the module of a network "super-type". 516 3.4. Discussion and selected design decisions 518 3.4.1. Container structure 520 Rather than maintaining lists in separate containers, the model is 521 kept relatively flat in terms of its containment structure. Lists of 522 nodes, links, termination-points, and supporting-nodes, supporting- 523 links, and supporting-termination-points are not kept in separate 524 containers. Therefore, path specifiers used to refer to specific 525 nodes, be it in management operations or in specifications of 526 constraints, can remain relatively compact. Of course, this means 527 there is no separate structure in instance information that separates 528 elements of different lists from one another. Such structure is 529 semantically not required, although it might enhance human 530 readability in some cases. 532 3.4.2. Underlay hierarchies and mappings 534 To minimize assumptions of what a particular entity might actually 535 represent, mappings between networks, nodes, links, and termination 536 points are kept strictly generic. For example, no assumptions are 537 made whether a termination point actually refers to an interface, or 538 whether a node refers to a specific "system" or device; the model at 539 this generic level makes no provisions for that. 541 Where additional specifics about mappings between upper and lower 542 layers are required, those can be captured in augmenting modules. 543 For example, to express that a termination point in a particular 544 network type maps to an interface, an augmenting module can introduce 545 an augmentation to the termination point which introduces a leaf of 546 type ifref that references the corresponding interface [RFC7223]. 547 Similarly, if a node maps to a particular device or network element, 548 an augmenting module can augment the node data with a leaf that 549 references the network element. 551 It is possible for links at one level of a hierarchy to map to 552 multiple links at another level of the hierarchy. For example, a VPN 553 topology might model VPN tunnels as links. Where a VPN tunnel maps 554 to a path that is composed of a chain of several links, the link will 555 contain a list of those supporting links. Likewise, it is possible 556 for a link at one level of a hierarchy to aggregate a bundle of links 557 at another level of the hierarchy. 559 3.4.3. Dealing with changes in underlay networks 561 It is possible for a network to undergo churn even as other networks 562 are layered on top of it. When a supporting node, link, or 563 termination point is deleted, the supporting leafrefs in the overlay 564 will be left dangling. To allow for this possibility, the model 565 makes use of the "require-instance" construct of YANG 1.1 566 [I.D.draft-ietf-netmod-rfc6020bis]. 568 It is the responsibility of the application maintaining the overlay 569 to deal with the possibility of churn in the underlay network. When 570 a server receives a request to configure an overlay network, it 571 SHOULD validate whether supporting nodes/links/tps refer to nodes in 572 the underlay are actually in existence. Configuration requests in 573 which supporting nodes/links/tps refer to objects currently not in 574 existence SHOULD be rejected. It is the responsibility of the 575 application to update the overlay when a supporting node/link/tp is 576 deleted at a later point in time. For this purpose, an application 577 might subscribe to updates when changes to the underlay occur, for 578 example using mechanisms defined in 579 [I-D.draft-ietf-netconf-yang-push]. 581 3.4.4. Use of groupings 583 The model makes use of groupings, instead of simply defining data 584 nodes "in-line". This allows to more easily include the 585 corresponding data nodes in notifications, which then do not need to 586 respecify each data node that is to be included. The tradeoff for 587 this is that it makes the specification of constraints more complex, 588 because constraints involving data nodes outside the grouping need to 589 be specified in conjunction with a "uses" statement where the 590 grouping is applied. This also means that constraints and XPath- 591 statements need to specified in such a way that they navigate "down" 592 first and select entire sets of nodes, as opposed to being able to 593 simply specify them against individual data nodes. 595 3.4.5. Cardinality and directionality of links 597 The topology model includes links that are point-to-point and 598 unidirectional. It does not directly support multipoint and 599 bidirectional links. While this may appear as a limitation, it does 600 keep the model simple, generic, and allows it to very easily be 601 subjected to applications that make use of graph algorithms. Bi- 602 directional connections can be represented through pairs of 603 unidirectional links. Multipoint networks can be represented through 604 pseudo-nodes (similar to IS-IS, for example). By introducing 605 hierarchies of nodes, with nodes at one level mapping onto a set of 606 other nodes at another level, and introducing new links for nodes at 607 that level, topologies with connections representing non-point-to- 608 point communication patterns can be represented. 610 3.4.6. Multihoming and link aggregation 612 Links are terminated by a single termination point, not sets of 613 termination points. Connections involving multihoming or link 614 aggregation schemes need to be represented using multiple point-to- 615 point links, then defining a link at a higher layer that is supported 616 by those individual links. 618 3.4.7. Mapping redundancy 620 In a hierarchy of networks, there are nodes mapping to nodes, links 621 mapping to links, and termination points mapping to termination 622 points. Some of this information is redundant. Specifically, if the 623 link-to-links mapping known, and the termination points of each link 624 known, termination point mapping information can be derived via 625 transitive closure and does not have to be explicitly configured. 626 Nonetheless, in order to not constrain applications regarding which 627 mappings they want to configure and which should be derived, the 628 model does provide for the option to configure this information 629 explicitly. The model includes integrity constraints to allow for 630 validating for consistency. 632 3.4.8. Typing 634 A network's network types are represented using a container which 635 contains a data node for each of its network types. A network can 636 encompass several types of network simultaneously, hence a container 637 is used instead of a case construct, with each network type in turn 638 represented by a dedicated presence container itself. The reason for 639 not simply using an empty leaf, or even simpler, do away even with 640 the network container and just use a leaf-list of network-type 641 instead, is to be able to represent "class hierarchies" of network 642 types, with one network type refining the other. Network-type 643 specific containers are to be defined in the network-specific 644 modules, augmenting the network-types container. 646 3.4.9. Representing the same device in multiple networks 648 One common requirement concerns the ability to represent that the 649 same device can be part of multiple networks and topologies. 650 However, the model defines a node as relative to the network that it 651 is contained in. The same node cannot be part of multiple 652 topologies. In many cases, a node will be the abstraction of a 653 particular device in a network. To reflect that the same device is 654 part of multiple topologies, the following approach might be chosen: 656 A new type of network to represent a "physical" (or "device") network 657 is introduced, with nodes representing devices. This network forms 658 an underlay network for logical networks above it, with nodes of the 659 logical network mapping onto nodes in the physical network. 661 This scenario is depicted in the following figure. It depicts three 662 networks with two nodes each. A physical network P consists of an 663 inventory of two nodes, D1 and D2, each representing a device. A 664 second network, X, has a third network, Y, as its underlay. Both X 665 and Y also have the physical network P as underlay. X1 has both Y1 666 and D1 as underlay nodes, while Y1 has D1 as underlay node. 667 Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as 668 underlay node. The fact that X1 and Y1 are both instantiated on the 669 same physical node D1 can be easily derived. 671 +---------------------+ 672 / [X1]____[X2] / X(Service Overlay) 673 +----:--:----:--------+ 674 ..: :..: : 675 ........: ....: : :.... 676 +-----:-------------:--+ : :... 677 / [Y1]____[Y2]....: / :.. : 678 +------|-------|-------+ :.. :... 679 Y(L3) | +---------------------:-----+ : 680 | +----:----|-:----------+ 681 +------------------------/---[D1] [D2] / 682 +----------------------+ 683 P (Physical network) 685 Figure 6: Topology hierarchy example - multiple underlays 687 In the case of a physical network, nodes represent physical devices 688 and termination points physical ports. It should be noted that it is 689 also conceivable to augment the model for a physical network-type, 690 defining augmentations that have nodes reference system information 691 and termination points reference physical interfaces, in order to 692 provide a bridge between network and device models. 694 3.5. Supporting client-configured and server-provided network topology 696 YANG requires data nodes to be designated as either configuration or 697 operational data, but not both, yet it is important to have all 698 network information, including vertical cross-network dependencies, 699 captured in one coherent model. In most cases, network topology 700 information is discovered about a network; the topology is considered 701 a property of the network that is reflected in the model. That said, 702 it is conceivable that certain types of topology need to also be 703 configurable by an application. The model needs to support both 704 cases. 706 There are several alternatives in which this can be addressed. The 707 alternative chosen in this draft does not restrict network topology 708 information as read-only, but includes a state "server-provided" that 709 indicates for each network whether it is populated by the server or 710 by a client application. Client applications that do attempt to 711 modify network topology may simply see their actions reverted, not 712 unlike other client applications that compete with one another, each 713 wanting to "own" the same data. When Netconf Access Control Model 714 [RFC6536] is supported, node access rules SHOULD be automatically 715 maintained by a server to deny client write access to network and 716 topology instances for which "server-provided" is true. 718 It should be noted that this solution stretches its use of the 719 configuration concept slightly. Configuration information in general 720 is subject to backup and restore, which is not applicable to server- 721 provided information. Perhaps more noteworthy is the potential 722 ability of a client to lock a configuration and thus prevent changes 723 to server-provided network topology while the lock is in effect. As 724 a result it would potentially incur a time lag until topology changes 725 that occur in the meantime are reflected, unless implementations 726 choose to provide special treatment for network topology information. 728 Other alternatives had been considered. In one alternative, all 729 information about network topology is in effect is represented as 730 network state, i.e. as read-only information, regardless of how it 731 came into being. For cases where network topology needs to be 732 configured, a second branch for configurable topology information is 733 introduced. Any network topology configuration is mirrored by 734 network state information. A configurable network will thus be 735 represented twice: once in the read-only list of all networks, a 736 second time in a configuration sandbox. One implication of this 737 solution would have been significantly increased complexity of 738 augmentations due to multiple target branches. 740 Another alternative would make use of a YANG extension to tag 741 specific network instances as "server-provided" instead of defining a 742 leaf object, or rely on the concept of YANG metadata 743 [I-D.draft-ietf-netmod-yang-metadata] for the same effect. The tag 744 would be automatically applied to any topology data that comes into 745 being (respectively is configured) by an embedded application on the 746 network, as opposed to e.g. a controller application. 748 3.6. Identifiers of string or URI type 750 The current model defines identifiers of nodes, networks, links, and 751 termination points as URIs. An alternative would define them as 752 string. 754 The case for strings is that they will be easier to implement. The 755 reason for choosing URIs is that the topology/node/tp exists in a 756 larger context, hence it is useful to be able to correlate 757 identifiers across systems. While strings, being the universal data 758 type, are easier for human beings (a string is a string is a string), 759 they also muddle things. What typically happens is that strings have 760 some structure which is magically assigned and the knowledge of this 761 structure has to be communicated to each system working with the 762 data. A URI makes the structure explicit and also attaches 763 additional semantics: the URI, unlike a free-form string, can be fed 764 into a URI resolver, which can point to additional resources 765 associated with the URI. This property is important when the 766 topology data is integrated into a larger, more complex system. 768 4. YANG Modules 770 4.1. Defining the Abstract Network: network.yang 772 file "ietf-network@2016-07-29.yang" 773 module ietf-network { 774 yang-version 1.1; 775 namespace "urn:ietf:params:xml:ns:yang:ietf-network"; 776 prefix nd; 778 import ietf-inet-types { 779 prefix inet; 780 } 782 organization 783 "IETF I2RS (Interface to the Routing System) Working Group"; 785 contact 786 "WG Web: 787 WG List: 789 WG Chair: Susan Hares 790 792 WG Chair: Russ White 793 795 Editor: Alexander Clemm 796 798 Editor: Jan Medved 799 801 Editor: Robert Varga 802 804 Editor: Tony Tkacik 805 807 Editor: Nitin Bahadur 808 810 Editor: Hariharan Ananthakrishnan 811 813 Editor: Xufeng Liu 814 "; 816 description 817 "This module defines a common base model for a collection 818 of nodes in a network. Node definitions are further used 819 in network topologies and inventories. 821 Copyright (c) 2016 IETF Trust and the persons identified as 822 authors of the code. All rights reserved. 824 Redistribution and use in source and binary forms, with or 825 without modification, is permitted pursuant to, and subject 826 to the license terms contained in, the Simplified BSD License 827 set forth in Section 4.c of the IETF Trust's Legal Provisions 828 Relating to IETF Documents 829 (http://trustee.ietf.org/license-info). 831 This version of this YANG module is part of 832 draft-ietf-i2rs-yang-network-topo-05; 833 see the RFC itself for full legal notices. 835 NOTE TO RFC EDITOR: Please replace above reference to 836 draft-ietf-i2rs-yang-network-topo-05 with RFC 837 number when published (i.e. RFC xxxx)."; 839 revision 2016-07-29 { 840 description 841 "Initial revision. 842 NOTE TO RFC EDITOR: Please replace the following reference 843 to draft-ietf-i2rs-yang-network-topo-05 with 844 RFC number when published (i.e. RFC xxxx)."; 845 reference 846 "draft-ietf-i2rs-yang-network-topo-05"; 847 } 849 typedef node-id { 850 type inet:uri; 851 description 852 "Identifier for a node. The precise structure of the node-id 853 will be up to the implementation. Some implementations MAY 854 for example, pick a uri that includes the network-id as 855 part of the path. The identifier SHOULD be chosen such that 856 the same node in a real network topology will always be 857 identified through the same identifier, even if the model is 858 instantiated in separate datastores. An implementation MAY 859 choose to capture semantics in the identifier, for example to 860 indicate the type of node."; 861 } 863 typedef network-id { 864 type inet:uri; 865 description 866 "Identifier for a network. The precise structure of the 867 network-id will be up to an implementation. 868 The identifier SHOULD be chosen such that the same network 869 will always be identified through the same identifier, 870 even if the model is instantiated in separate datastores. 871 An implementation MAY choose to capture semantics in the 872 identifier, for example to indicate the type of network."; 873 } 875 grouping network-ref { 876 description 877 "Contains the information necessary to reference a network, 878 for example an underlay network."; 879 leaf network-ref { 880 type leafref { 881 path "/nd:networks/nd:network/nd:network-id"; 882 require-instance false; 883 } 884 description 885 "Used to reference a network, for example an underlay 886 network."; 887 } 888 } 890 grouping node-ref { 891 description 892 "Contains the information necessary to reference a node."; 893 leaf node-ref { 894 type leafref { 895 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 896 "network-ref]/nd:node/nd:node-id"; 897 require-instance false; 898 } 899 description 900 "Used to reference a node. 901 Nodes are identified relative to the network they are 902 contained in."; 903 } 904 uses network-ref; 905 } 907 container networks { 908 description 909 "Serves as top-level container for a list of networks."; 910 list network { 911 key "network-id"; 912 description 913 "Describes a network. 914 A network typically contains an inventory of nodes, 915 topological information (augmented through 916 network-topology model), as well as layering 917 information."; 918 container network-types { 919 description 920 "Serves as an augmentation target. 921 The network type is indicated through corresponding 922 presence containers augmented into this container."; 923 } 924 leaf network-id { 925 type network-id; 926 description 927 "Identifies a network."; 928 } 929 leaf server-provided { 930 type boolean; 931 config false; 932 description 933 "Indicates whether the information concerning this 934 particular network is populated by the server 935 (server-provided true, the general case for network 936 information discovered from the server), 937 or whether it is configured by a client 938 (server-provided true, possible e.g. for 939 service overlays managed through a controller). 941 Clients should not attempt to make modifications 942 to network instances with server-provided set to 943 true; when they do, they need to be aware that 944 any modifications they make are subject to be 945 reverted by the server. 946 For servers that support NACM (Netconf Access Control 947 Model), data node rules should ideally prevent 948 write access by other clients to the network instance 949 when server-provided is set to true."; 950 } 951 list supporting-network { 952 key "network-ref"; 953 description 954 "An underlay network, used to represent layered network 955 topologies."; 956 leaf network-ref { 957 type leafref { 958 path "/networks/network/network-id"; 959 require-instance false; 960 } 961 description 962 "References the underlay network."; 963 } 964 } 965 list node { 966 key "node-id"; 967 description 968 "The inventory of nodes of this network."; 969 leaf node-id { 970 type node-id; 971 description 972 "Identifies a node uniquely within the containing 973 network."; 974 } 975 list supporting-node { 976 key "network-ref node-ref"; 977 description 978 "Represents another node, in an underlay network, that 979 this node is supported by. Used to represent layering 980 structure."; 981 leaf network-ref { 982 type leafref { 983 path "../../../supporting-network/network-ref"; 984 require-instance false; 985 } 986 description 987 "References the underlay network that the 988 underlay node is part of."; 990 } 991 leaf node-ref { 992 type leafref { 993 path "/networks/network/node/node-id"; 994 require-instance false; 995 } 996 description 997 "References the underlay node itself."; 998 } 999 } 1000 } 1001 } 1002 } 1003 } 1005 1007 4.2. Creating Abstract Network Topology: network-topology.yang 1009 file "ietf-network-topology@2016-07-29.yang" 1010 module ietf-network-topology { 1011 yang-version 1.1; 1012 namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; 1013 prefix lnk; 1015 import ietf-inet-types { 1016 prefix inet; 1017 } 1018 import ietf-network { 1019 prefix nd; 1020 } 1022 organization 1023 "IETF I2RS (Interface to the Routing System) Working Group"; 1025 contact 1026 "WG Web: 1027 WG List: 1029 WG Chair: Susan Hares 1030 1032 WG Chair: Russ White 1033 1035 Editor: Alexander Clemm 1036 1038 Editor: Jan Medved 1039 1041 Editor: Robert Varga 1042 1044 Editor: Tony Tkacik 1045 1047 Editor: Nitin Bahadur 1048 1050 Editor: Hariharan Ananthakrishnan 1051 1053 Editor: Xufeng Liu 1054 "; 1056 description 1057 "This module defines a common base model for network topology, 1058 augmenting the base network model with links to connect nodes, 1059 as well as termination points to terminate links on nodes. 1061 Copyright (c) 2016 IETF Trust and the persons identified as 1062 authors of the code. All rights reserved. 1064 Redistribution and use in source and binary forms, with or 1065 without modification, is permitted pursuant to, and subject 1066 to the license terms contained in, the Simplified BSD License 1067 set forth in Section 4.c of the IETF Trust's Legal Provisions 1068 Relating to IETF Documents 1069 (http://trustee.ietf.org/license-info). 1071 This version of this YANG module is part of 1072 draft-ietf-i2rs-yang-network-topo-05; 1073 see the RFC itself for full legal notices. 1075 NOTE TO RFC EDITOR: Please replace above reference to 1076 draft-ietf-i2rs-yang-network-topo-05 with RFC 1077 number when published (i.e. RFC xxxx)."; 1079 revision 2016-07-29 { 1080 description 1081 "Initial revision. 1082 NOTE TO RFC EDITOR: Please replace the following reference 1083 to draft-ietf-i2rs-yang-network-topo-05 with 1084 RFC number when published (i.e. RFC xxxx)."; 1085 reference 1086 "draft-ietf-i2rs-yang-network-topo-05"; 1087 } 1089 typedef link-id { 1090 type inet:uri; 1091 description 1092 "An identifier for a link in a topology. 1093 The precise structure of the link-id 1094 will be up to the implementation. 1095 The identifier SHOULD be chosen such that the same link in a 1096 real network topology will always be identified through the 1097 same identifier, even if the model is instantiated in 1098 separate datastores. An implementation MAY choose to capture 1099 semantics in the identifier, for example to indicate the type 1100 of link and/or the type of topology that the link is a part 1101 of."; 1102 } 1104 typedef tp-id { 1105 type inet:uri; 1106 description 1107 "An identifier for termination points (TPs) on a node. 1108 The precise structure of the tp-id 1109 will be up to the implementation. 1110 The identifier SHOULD be chosen such that the same termination 1111 point in a real network topology will always be identified 1112 through the same identifier, even if the model is instantiated 1113 in separate datastores. An implementation MAY choose to 1114 capture semantics in the identifier, for example to indicate 1115 the type of termination point and/or the type of node 1116 that contains the termination point."; 1117 } 1119 grouping link-ref { 1120 description 1121 "References a link in a specific network."; 1122 leaf link-ref { 1123 type leafref { 1124 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1125 "network-ref]/lnk:link/lnk:link-id"; 1126 require-instance false; 1127 } 1128 description 1129 "A type for an absolute reference a link instance. 1130 (This type should not be used for relative references. 1131 In such a case, a relative path should be used instead.)"; 1132 } 1133 uses nd:network-ref; 1135 } 1137 grouping tp-ref { 1138 description 1139 "References a termination point in a specific node."; 1140 leaf tp-ref { 1141 type leafref { 1142 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1143 "network-ref]/nd:node[nd:node-id=current()/../"+ 1144 "node-ref]/lnk:termination-point/lnk:tp-id"; 1145 require-instance false; 1146 } 1147 description 1148 "A type for an absolute reference to a termination point. 1149 (This type should not be used for relative references. 1150 In such a case, a relative path should be used instead.)"; 1151 } 1152 uses nd:node-ref; 1153 } 1155 augment "/nd:networks/nd:network" { 1156 description 1157 "Add links to the network model."; 1158 list link { 1159 key "link-id"; 1160 description 1161 "A network link connects a local (source) node and 1162 a remote (destination) node via a set of 1163 the respective node's termination points. 1164 It is possible to have several links between the same 1165 source and destination nodes. Likewise, a link could 1166 potentially be re-homed between termination points. 1167 Therefore, in order to ensure that we would always know 1168 to distinguish between links, every link is identified by 1169 a dedicated link identifier. Note that a link models a 1170 point-to-point link, not a multipoint link. 1171 Layering dependencies on links in underlay topologies are 1172 not represented, as the layering information of nodes and of 1173 termination points is sufficient."; 1174 container source { 1175 description 1176 "This container holds the logical source of a particular 1177 link."; 1178 leaf source-node { 1179 type leafref { 1180 path "../../../nd:node/nd:node-id"; 1181 require-instance false; 1182 } 1183 description 1184 "Source node identifier, must be in same topology."; 1185 } 1186 leaf source-tp { 1187 type leafref { 1188 path "../../../nd:node[nd:node-id=current()/../"+ 1189 "source-node]/termination-point/tp-id"; 1190 require-instance false; 1191 } 1192 description 1193 "Termination point within source node that terminates 1194 the link."; 1195 } 1196 } 1197 container destination { 1198 description 1199 "This container holds the logical destination of a 1200 particular link."; 1201 leaf dest-node { 1202 type leafref { 1203 path "../../../nd:node/nd:node-id"; 1204 require-instance false; 1205 } 1206 description 1207 "Destination node identifier, must be in the same 1208 network."; 1209 } 1210 leaf dest-tp { 1211 type leafref { 1212 path "../../../nd:node[nd:node-id=current()/../"+ 1213 "dest-node]/termination-point/tp-id"; 1214 require-instance false; 1215 } 1216 description 1217 "Termination point within destination node that 1218 terminates the link."; 1219 } 1220 } 1221 leaf link-id { 1222 type link-id; 1223 description 1224 "The identifier of a link in the topology. 1225 A link is specific to a topology to which it belongs."; 1226 } 1227 list supporting-link { 1228 key "network-ref link-ref"; 1229 description 1230 "Identifies the link, or links, that this link 1231 is dependent on."; 1232 leaf network-ref { 1233 type leafref { 1234 path "../../../nd:supporting-network/nd:network-ref"; 1235 require-instance false; 1236 } 1237 description 1238 "This leaf identifies in which underlay topology 1239 the supporting link is present."; 1240 } 1241 leaf link-ref { 1242 type leafref { 1243 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1244 "../network-ref]/link/link-id"; 1245 require-instance false; 1246 } 1247 description 1248 "This leaf identifies a link which is a part 1249 of this link's underlay. Reference loops in which 1250 a link identifies itself as its underlay, either 1251 directly or transitively, are not allowed."; 1252 } 1253 } 1254 } 1255 } 1256 augment "/nd:networks/nd:network/nd:node" { 1257 description 1258 "Augment termination points which terminate links. 1259 Termination points can ultimately be mapped to interfaces."; 1260 list termination-point { 1261 key "tp-id"; 1262 description 1263 "A termination point can terminate a link. 1264 Depending on the type of topology, a termination point 1265 could, for example, refer to a port or an interface."; 1266 leaf tp-id { 1267 type tp-id; 1268 description 1269 "Termination point identifier."; 1270 } 1271 list supporting-termination-point { 1272 key "network-ref node-ref tp-ref"; 1273 description 1274 "This list identifies any termination points that 1275 the termination point is dependent on, or maps onto. 1276 Those termination points will themselves be contained 1277 in a supporting node. 1278 This dependency information can be inferred from 1279 the dependencies between links. For this reason, 1280 this item is not separately configurable. Hence no 1281 corresponding constraint needs to be articulated. 1282 The corresponding information is simply provided by the 1283 implementing system."; 1284 leaf network-ref { 1285 type leafref { 1286 path "../../../nd:supporting-node/nd:network-ref"; 1287 require-instance false; 1288 } 1289 description 1290 "This leaf identifies in which topology the 1291 supporting termination point is present."; 1292 } 1293 leaf node-ref { 1294 type leafref { 1295 path "../../../nd:supporting-node/nd:node-ref"; 1296 require-instance false; 1297 } 1298 description 1299 "This leaf identifies in which node the supporting 1300 termination point is present."; 1301 } 1302 leaf tp-ref { 1303 type leafref { 1304 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1305 "../network-ref]/nd:node[nd:node-id=current()/../"+ 1306 "node-ref]/termination-point/tp-id"; 1307 require-instance false; 1308 } 1309 description 1310 "Reference to the underlay node, must be in a 1311 different topology"; 1312 } 1313 } 1314 } 1315 } 1316 } 1318 1320 5. Security Considerations 1322 The transport protocol used for sending the topology data MUST 1323 support authentication and SHOULD support encryption. The data-model 1324 by itself does not create any security implications. 1326 6. Contributors 1328 The model presented in this paper was contributed to by more people 1329 than can be listed on the author list. Additional contributors 1330 include: 1332 o Ken Gray, Cisco Systems 1334 o Tom Nadeau, Brocade 1336 o Aleksandr Zhdankin, Cisco 1338 7. Acknowledgements 1340 We wish to acknowledge the helpful contributions, comments, and 1341 suggestions that were received from Alia Atlas, Vishnu Pavan Beeram, 1342 Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan 1343 Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Kent 1344 Watsen, and Xian Zhang. 1346 8. References 1348 8.1. Normative References 1350 [I.D.draft-ietf-netmod-rfc6020bis] 1351 Bjorklund, M., "The YANG 1.1 Data Modeling Language", I-D 1352 draft-ietf-netmod-rfc6020bis-14, June 2016. 1354 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1355 Dual Environments", RFC 1195, December 1990. 1357 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1359 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1360 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1361 Tunnels", RFC 3209, December 2001. 1363 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1364 Network Configuration Protocol (NETCONF)", RFC 6020, 1365 October 2010. 1367 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 1368 October 2010. 1370 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1371 Bierman, "Network Configuration Protocol (NETCONF)", 1372 RFC 6241, June 2011. 1374 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1375 Protocol (NETCONF) Access Control Model", RFC 6536, March 1376 2012. 1378 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1379 Management", RFC 7223, May 2014. 1381 8.2. Informative References 1383 [I-D.draft-ietf-netconf-yang-push] 1384 Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., 1385 and E. Nilsen-Nygaard, "Subscribing to YANG datastore push 1386 updates", I-D draft-ietf-netconf-yang-push-03, June 2016. 1388 [I-D.draft-ietf-netmod-yang-metadata] 1389 Lhotka, L., "Defining and Using Metadata with YANG", I-D 1390 draft-ietf-netmod-yang-metadata-07, March 2016. 1392 [topology-use-cases] 1393 Medved, J., Previdi, S., Lopez, V., and S. Amante, 1394 "Topology API Use Cases", I-D draft-amante-i2rs-topology- 1395 use-cases-01, October 2013. 1397 Authors' Addresses 1399 Alexander Clemm 1400 Cisco 1402 EMail: alex@cisco.com 1404 Jan Medved 1405 Cisco 1407 EMail: jmedved@cisco.com 1409 Robert Varga 1410 Cisco 1412 EMail: rovarga@cisco.com 1414 Tony Tkacik 1416 EMail: tony.tkacik@gmail.com 1417 Nitin Bahadur 1418 Bracket Computing 1420 EMail: nitin_bahadur@yahoo.com 1422 Hariharan Ananthakrishnan 1423 Packet Design 1425 EMail: hari@packetdesign.com 1427 Xufeng Liu 1428 Ericsson 1430 EMail: xliu@kuatrotech.com