idnits 2.17.1 draft-ietf-i2rs-yang-network-topo-06.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 570: '... SHOULD validate whether supporting ...' RFC 2119 keyword, line 573: '... existence SHOULD be rejected. It i...' RFC 2119 keyword, line 713: '... [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 (September 19, 2016) is 2769 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 680, but not defined == Missing Reference: 'D2' is mentioned on line 680, but not defined == Unused Reference: 'RFC6241' is defined on line 1365, 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: March 23, 2017 Cisco 6 T. Tkacik 8 N. Bahadur 9 Bracket Computing 10 H. Ananthakrishnan 11 Packet Design 12 X. Liu 13 Ericsson 14 September 19, 2016 16 A Data Model for Network Topologies 17 draft-ietf-i2rs-yang-network-topo-06.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 March 23, 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 [RFC7950]. 567 It is the responsibility of the application maintaining the overlay 568 to deal with the possibility of churn in the underlay network. When 569 a server receives a request to configure an overlay network, it 570 SHOULD validate whether supporting nodes/links/tps refer to nodes in 571 the underlay are actually in existence. Configuration requests in 572 which supporting nodes/links/tps refer to objects currently not in 573 existence SHOULD be rejected. It is the responsibility of the 574 application to update the overlay when a supporting node/link/tp is 575 deleted at a later point in time. For this purpose, an application 576 might subscribe to updates when changes to the underlay occur, for 577 example using mechanisms defined in 578 [I-D.draft-ietf-netconf-yang-push]. 580 3.4.4. Use of groupings 582 The model makes use of groupings, instead of simply defining data 583 nodes "in-line". This allows to more easily include the 584 corresponding data nodes in notifications, which then do not need to 585 respecify each data node that is to be included. The tradeoff for 586 this is that it makes the specification of constraints more complex, 587 because constraints involving data nodes outside the grouping need to 588 be specified in conjunction with a "uses" statement where the 589 grouping is applied. This also means that constraints and XPath- 590 statements need to specified in such a way that they navigate "down" 591 first and select entire sets of nodes, as opposed to being able to 592 simply specify them against individual data nodes. 594 3.4.5. Cardinality and directionality of links 596 The topology model includes links that are point-to-point and 597 unidirectional. It does not directly support multipoint and 598 bidirectional links. While this may appear as a limitation, it does 599 keep the model simple, generic, and allows it to very easily be 600 subjected to applications that make use of graph algorithms. Bi- 601 directional connections can be represented through pairs of 602 unidirectional links. Multipoint networks can be represented through 603 pseudo-nodes (similar to IS-IS, for example). By introducing 604 hierarchies of nodes, with nodes at one level mapping onto a set of 605 other nodes at another level, and introducing new links for nodes at 606 that level, topologies with connections representing non-point-to- 607 point communication patterns can be represented. 609 3.4.6. Multihoming and link aggregation 611 Links are terminated by a single termination point, not sets of 612 termination points. Connections involving multihoming or link 613 aggregation schemes need to be represented using multiple point-to- 614 point links, then defining a link at a higher layer that is supported 615 by those individual links. 617 3.4.7. Mapping redundancy 619 In a hierarchy of networks, there are nodes mapping to nodes, links 620 mapping to links, and termination points mapping to termination 621 points. Some of this information is redundant. Specifically, if the 622 link-to-links mapping known, and the termination points of each link 623 known, termination point mapping information can be derived via 624 transitive closure and does not have to be explicitly configured. 625 Nonetheless, in order to not constrain applications regarding which 626 mappings they want to configure and which should be derived, the 627 model does provide for the option to configure this information 628 explicitly. The model includes integrity constraints to allow for 629 validating for consistency. 631 3.4.8. Typing 633 A network's network types are represented using a container which 634 contains a data node for each of its network types. A network can 635 encompass several types of network simultaneously, hence a container 636 is used instead of a case construct, with each network type in turn 637 represented by a dedicated presence container itself. The reason for 638 not simply using an empty leaf, or even simpler, do away even with 639 the network container and just use a leaf-list of network-type 640 instead, is to be able to represent "class hierarchies" of network 641 types, with one network type refining the other. Network-type 642 specific containers are to be defined in the network-specific 643 modules, augmenting the network-types container. 645 3.4.9. Representing the same device in multiple networks 647 One common requirement concerns the ability to represent that the 648 same device can be part of multiple networks and topologies. 649 However, the model defines a node as relative to the network that it 650 is contained in. The same node cannot be part of multiple 651 topologies. In many cases, a node will be the abstraction of a 652 particular device in a network. To reflect that the same device is 653 part of multiple topologies, the following approach might be chosen: 655 A new type of network to represent a "physical" (or "device") network 656 is introduced, with nodes representing devices. This network forms 657 an underlay network for logical networks above it, with nodes of the 658 logical network mapping onto nodes in the physical network. 660 This scenario is depicted in the following figure. It depicts three 661 networks with two nodes each. A physical network P consists of an 662 inventory of two nodes, D1 and D2, each representing a device. A 663 second network, X, has a third network, Y, as its underlay. Both X 664 and Y also have the physical network P as underlay. X1 has both Y1 665 and D1 as underlay nodes, while Y1 has D1 as underlay node. 666 Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as 667 underlay node. The fact that X1 and Y1 are both instantiated on the 668 same physical node D1 can be easily derived. 670 +---------------------+ 671 / [X1]____[X2] / X(Service Overlay) 672 +----:--:----:--------+ 673 ..: :..: : 674 ........: ....: : :.... 675 +-----:-------------:--+ : :... 676 / [Y1]____[Y2]....: / :.. : 677 +------|-------|-------+ :.. :... 678 Y(L3) | +---------------------:-----+ : 679 | +----:----|-:----------+ 680 +------------------------/---[D1] [D2] / 681 +----------------------+ 682 P (Physical network) 684 Figure 6: Topology hierarchy example - multiple underlays 686 In the case of a physical network, nodes represent physical devices 687 and termination points physical ports. It should be noted that it is 688 also conceivable to augment the model for a physical network-type, 689 defining augmentations that have nodes reference system information 690 and termination points reference physical interfaces, in order to 691 provide a bridge between network and device models. 693 3.5. Supporting client-configured and server-provided network topology 695 YANG requires data nodes to be designated as either configuration or 696 operational data, but not both, yet it is important to have all 697 network information, including vertical cross-network dependencies, 698 captured in one coherent model. In most cases, network topology 699 information is discovered about a network; the topology is considered 700 a property of the network that is reflected in the model. That said, 701 it is conceivable that certain types of topology need to also be 702 configurable by an application. The model needs to support both 703 cases. 705 There are several alternatives in which this can be addressed. The 706 alternative chosen in this draft does not restrict network topology 707 information as read-only, but includes a state "server-provided" that 708 indicates for each network whether it is populated by the server or 709 by a client application. Client applications that do attempt to 710 modify network topology may simply see their actions reverted, not 711 unlike other client applications that compete with one another, each 712 wanting to "own" the same data. When Netconf Access Control Model 713 [RFC6536] is supported, node access rules SHOULD be automatically 714 maintained by a server to deny client write access to network and 715 topology instances for which "server-provided" is true. 717 It should be noted that this solution stretches its use of the 718 configuration concept slightly. Configuration information in general 719 is subject to backup and restore, which is not applicable to server- 720 provided information. Perhaps more noteworthy is the potential 721 ability of a client to lock a configuration and thus prevent changes 722 to server-provided network topology while the lock is in effect. As 723 a result it would potentially incur a time lag until topology changes 724 that occur in the meantime are reflected, unless implementations 725 choose to provide special treatment for network topology information. 727 Other alternatives had been considered. In one alternative, all 728 information about network topology is in effect is represented as 729 network state, i.e. as read-only information, regardless of how it 730 came into being. For cases where network topology needs to be 731 configured, a second branch for configurable topology information is 732 introduced. Any network topology configuration is mirrored by 733 network state information. A configurable network will thus be 734 represented twice: once in the read-only list of all networks, a 735 second time in a configuration sandbox. One implication of this 736 solution would have been significantly increased complexity of 737 augmentations due to multiple target branches. 739 Another alternative would make use of a YANG extension to tag 740 specific network instances as "server-provided" instead of defining a 741 leaf object, or rely on the concept of YANG metadata [RFC7952] for 742 the same effect. The tag would be automatically applied to any 743 topology data that comes into being (respectively is configured) by 744 an embedded application on the network, as opposed to e.g. a 745 controller application. 747 3.6. Identifiers of string or URI type 749 The current model defines identifiers of nodes, networks, links, and 750 termination points as URIs. An alternative would define them as 751 string. 753 The case for strings is that they will be easier to implement. The 754 reason for choosing URIs is that the topology/node/tp exists in a 755 larger context, hence it is useful to be able to correlate 756 identifiers across systems. While strings, being the universal data 757 type, are easier for human beings (a string is a string is a string), 758 they also muddle things. What typically happens is that strings have 759 some structure which is magically assigned and the knowledge of this 760 structure has to be communicated to each system working with the 761 data. A URI makes the structure explicit and also attaches 762 additional semantics: the URI, unlike a free-form string, can be fed 763 into a URI resolver, which can point to additional resources 764 associated with the URI. This property is important when the 765 topology data is integrated into a larger, more complex system. 767 4. YANG Modules 769 4.1. Defining the Abstract Network: network.yang 771 file "ietf-network@2016-09-19.yang" 772 module ietf-network { 773 yang-version 1.1; 774 namespace "urn:ietf:params:xml:ns:yang:ietf-network"; 775 prefix nd; 777 import ietf-inet-types { 778 prefix inet; 779 } 781 organization 782 "IETF I2RS (Interface to the Routing System) Working Group"; 784 contact 785 "WG Web: 786 WG List: 788 WG Chair: Susan Hares 789 791 WG Chair: Russ White 792 794 Editor: Alexander Clemm 795 797 Editor: Jan Medved 798 800 Editor: Robert Varga 801 803 Editor: Tony Tkacik 804 806 Editor: Nitin Bahadur 807 809 Editor: Hariharan Ananthakrishnan 810 812 Editor: Xufeng Liu 813 "; 815 description 816 "This module defines a common base model for a collection 817 of nodes in a network. Node definitions are further used 818 in network topologies and inventories. 820 Copyright (c) 2016 IETF Trust and the persons identified as 821 authors of the code. All rights reserved. 823 Redistribution and use in source and binary forms, with or 824 without modification, is permitted pursuant to, and subject 825 to the license terms contained in, the Simplified BSD License 826 set forth in Section 4.c of the IETF Trust's Legal Provisions 827 Relating to IETF Documents 828 (http://trustee.ietf.org/license-info). 830 This version of this YANG module is part of 831 draft-ietf-i2rs-yang-network-topo-06; 832 see the RFC itself for full legal notices. 834 NOTE TO RFC EDITOR: Please replace above reference to 835 draft-ietf-i2rs-yang-network-topo-06 with RFC 836 number when published (i.e. RFC xxxx)."; 838 revision 2016-09-19 { 839 description 840 "Initial revision. 841 NOTE TO RFC EDITOR: Please replace the following reference 842 to draft-ietf-i2rs-yang-network-topo-06 with 843 RFC number when published (i.e. RFC xxxx)."; 844 reference 845 "draft-ietf-i2rs-yang-network-topo-06"; 846 } 848 typedef node-id { 849 type inet:uri; 850 description 851 "Identifier for a node. The precise structure of the node-id 852 will be up to the implementation. Some implementations MAY 853 for example, pick a uri that includes the network-id as 854 part of the path. The identifier SHOULD be chosen such that 855 the same node in a real network topology will always be 856 identified through the same identifier, even if the model is 857 instantiated in separate datastores. An implementation MAY 858 choose to capture semantics in the identifier, for example to 859 indicate the type of node."; 860 } 862 typedef network-id { 863 type inet:uri; 864 description 865 "Identifier for a network. The precise structure of the 866 network-id will be up to an implementation. 867 The identifier SHOULD be chosen such that the same network 868 will always be identified through the same identifier, 869 even if the model is instantiated in separate datastores. 870 An implementation MAY choose to capture semantics in the 871 identifier, for example to indicate the type of network."; 872 } 874 grouping network-ref { 875 description 876 "Contains the information necessary to reference a network, 877 for example an underlay network."; 878 leaf network-ref { 879 type leafref { 880 path "/nd:networks/nd:network/nd:network-id"; 881 require-instance false; 882 } 883 description 884 "Used to reference a network, for example an underlay 885 network."; 886 } 887 } 889 grouping node-ref { 890 description 891 "Contains the information necessary to reference a node."; 892 leaf node-ref { 893 type leafref { 894 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 895 "network-ref]/nd:node/nd:node-id"; 896 require-instance false; 897 } 898 description 899 "Used to reference a node. 900 Nodes are identified relative to the network they are 901 contained in."; 902 } 903 uses network-ref; 904 } 906 container networks { 907 description 908 "Serves as top-level container for a list of networks."; 909 list network { 910 key "network-id"; 911 description 912 "Describes a network. 913 A network typically contains an inventory of nodes, 914 topological information (augmented through 915 network-topology model), as well as layering 916 information."; 917 container network-types { 918 description 919 "Serves as an augmentation target. 920 The network type is indicated through corresponding 921 presence containers augmented into this container."; 922 } 923 leaf network-id { 924 type network-id; 925 description 926 "Identifies a network."; 927 } 928 leaf server-provided { 929 type boolean; 930 config false; 931 description 932 "Indicates whether the information concerning this 933 particular network is populated by the server 934 (server-provided true, the general case for network 935 information discovered from the server), 936 or whether it is configured by a client 937 (server-provided true, possible e.g. for 938 service overlays managed through a controller). 940 Clients should not attempt to make modifications 941 to network instances with server-provided set to 942 true; when they do, they need to be aware that 943 any modifications they make are subject to be 944 reverted by the server. 945 For servers that support NACM (Netconf Access Control 946 Model), data node rules should ideally prevent 947 write access by other clients to the network instance 948 when server-provided is set to true."; 949 } 950 list supporting-network { 951 key "network-ref"; 952 description 953 "An underlay network, used to represent layered network 954 topologies."; 955 leaf network-ref { 956 type leafref { 957 path "/networks/network/network-id"; 958 require-instance false; 959 } 960 description 961 "References the underlay network."; 962 } 963 } 964 list node { 965 key "node-id"; 966 description 967 "The inventory of nodes of this network."; 968 leaf node-id { 969 type node-id; 970 description 971 "Identifies a node uniquely within the containing 972 network."; 973 } 974 list supporting-node { 975 key "network-ref node-ref"; 976 description 977 "Represents another node, in an underlay network, that 978 this node is supported by. Used to represent layering 979 structure."; 980 leaf network-ref { 981 type leafref { 982 path "../../../supporting-network/network-ref"; 983 require-instance false; 984 } 985 description 986 "References the underlay network that the 987 underlay node is part of."; 989 } 990 leaf node-ref { 991 type leafref { 992 path "/networks/network/node/node-id"; 993 require-instance false; 994 } 995 description 996 "References the underlay node itself."; 997 } 998 } 999 } 1000 } 1001 } 1002 } 1004 1006 4.2. Creating Abstract Network Topology: network-topology.yang 1008 file "ietf-network-topology@2016-09-19.yang" 1009 module ietf-network-topology { 1010 yang-version 1.1; 1011 namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; 1012 prefix lnk; 1014 import ietf-inet-types { 1015 prefix inet; 1016 } 1017 import ietf-network { 1018 prefix nd; 1019 } 1021 organization 1022 "IETF I2RS (Interface to the Routing System) Working Group"; 1024 contact 1025 "WG Web: 1026 WG List: 1028 WG Chair: Susan Hares 1029 1031 WG Chair: Russ White 1032 1034 Editor: Alexander Clemm 1035 1037 Editor: Jan Medved 1038 1040 Editor: Robert Varga 1041 1043 Editor: Tony Tkacik 1044 1046 Editor: Nitin Bahadur 1047 1049 Editor: Hariharan Ananthakrishnan 1050 1052 Editor: Xufeng Liu 1053 "; 1055 description 1056 "This module defines a common base model for network topology, 1057 augmenting the base network model with links to connect nodes, 1058 as well as termination points to terminate links on nodes. 1060 Copyright (c) 2016 IETF Trust and the persons identified as 1061 authors of the code. All rights reserved. 1063 Redistribution and use in source and binary forms, with or 1064 without modification, is permitted pursuant to, and subject 1065 to the license terms contained in, the Simplified BSD License 1066 set forth in Section 4.c of the IETF Trust's Legal Provisions 1067 Relating to IETF Documents 1068 (http://trustee.ietf.org/license-info). 1070 This version of this YANG module is part of 1071 draft-ietf-i2rs-yang-network-topo-06; 1072 see the RFC itself for full legal notices. 1074 NOTE TO RFC EDITOR: Please replace above reference to 1075 draft-ietf-i2rs-yang-network-topo-06 with RFC 1076 number when published (i.e. RFC xxxx)."; 1078 revision 2016-09-19 { 1079 description 1080 "Initial revision. 1081 NOTE TO RFC EDITOR: Please replace the following reference 1082 to draft-ietf-i2rs-yang-network-topo-06 with 1083 RFC number when published (i.e. RFC xxxx)."; 1084 reference 1085 "draft-ietf-i2rs-yang-network-topo-06"; 1086 } 1088 typedef link-id { 1089 type inet:uri; 1090 description 1091 "An identifier for a link in a topology. 1092 The precise structure of the link-id 1093 will be up to the implementation. 1094 The identifier SHOULD be chosen such that the same link in a 1095 real network topology will always be identified through the 1096 same identifier, even if the model is instantiated in 1097 separate datastores. An implementation MAY choose to capture 1098 semantics in the identifier, for example to indicate the type 1099 of link and/or the type of topology that the link is a part 1100 of."; 1101 } 1103 typedef tp-id { 1104 type inet:uri; 1105 description 1106 "An identifier for termination points (TPs) on a node. 1107 The precise structure of the tp-id 1108 will be up to the implementation. 1109 The identifier SHOULD be chosen such that the same termination 1110 point in a real network topology will always be identified 1111 through the same identifier, even if the model is instantiated 1112 in separate datastores. An implementation MAY choose to 1113 capture semantics in the identifier, for example to indicate 1114 the type of termination point and/or the type of node 1115 that contains the termination point."; 1116 } 1118 grouping link-ref { 1119 description 1120 "References a link in a specific network."; 1121 leaf link-ref { 1122 type leafref { 1123 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1124 "network-ref]/lnk:link/lnk:link-id"; 1125 require-instance false; 1126 } 1127 description 1128 "A type for an absolute reference a link instance. 1129 (This type should not be used for relative references. 1130 In such a case, a relative path should be used instead.)"; 1131 } 1132 uses nd:network-ref; 1134 } 1136 grouping tp-ref { 1137 description 1138 "References a termination point in a specific node."; 1139 leaf tp-ref { 1140 type leafref { 1141 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1142 "network-ref]/nd:node[nd:node-id=current()/../"+ 1143 "node-ref]/lnk:termination-point/lnk:tp-id"; 1144 require-instance false; 1145 } 1146 description 1147 "A type for an absolute reference to a termination point. 1148 (This type should not be used for relative references. 1149 In such a case, a relative path should be used instead.)"; 1150 } 1151 uses nd:node-ref; 1152 } 1154 augment "/nd:networks/nd:network" { 1155 description 1156 "Add links to the network model."; 1157 list link { 1158 key "link-id"; 1159 description 1160 "A network link connects a local (source) node and 1161 a remote (destination) node via a set of 1162 the respective node's termination points. 1163 It is possible to have several links between the same 1164 source and destination nodes. Likewise, a link could 1165 potentially be re-homed between termination points. 1166 Therefore, in order to ensure that we would always know 1167 to distinguish between links, every link is identified by 1168 a dedicated link identifier. Note that a link models a 1169 point-to-point link, not a multipoint link. 1170 Layering dependencies on links in underlay topologies are 1171 not represented, as the layering information of nodes and of 1172 termination points is sufficient."; 1173 container source { 1174 description 1175 "This container holds the logical source of a particular 1176 link."; 1177 leaf source-node { 1178 type leafref { 1179 path "../../../nd:node/nd:node-id"; 1180 require-instance false; 1181 } 1182 description 1183 "Source node identifier, must be in same topology."; 1184 } 1185 leaf source-tp { 1186 type leafref { 1187 path "../../../nd:node[nd:node-id=current()/../"+ 1188 "source-node]/termination-point/tp-id"; 1189 require-instance false; 1190 } 1191 description 1192 "Termination point within source node that terminates 1193 the link."; 1194 } 1195 } 1196 container destination { 1197 description 1198 "This container holds the logical destination of a 1199 particular link."; 1200 leaf dest-node { 1201 type leafref { 1202 path "../../../nd:node/nd:node-id"; 1203 require-instance false; 1204 } 1205 description 1206 "Destination node identifier, must be in the same 1207 network."; 1208 } 1209 leaf dest-tp { 1210 type leafref { 1211 path "../../../nd:node[nd:node-id=current()/../"+ 1212 "dest-node]/termination-point/tp-id"; 1213 require-instance false; 1214 } 1215 description 1216 "Termination point within destination node that 1217 terminates the link."; 1218 } 1219 } 1220 leaf link-id { 1221 type link-id; 1222 description 1223 "The identifier of a link in the topology. 1224 A link is specific to a topology to which it belongs."; 1225 } 1226 list supporting-link { 1227 key "network-ref link-ref"; 1228 description 1229 "Identifies the link, or links, that this link 1230 is dependent on."; 1231 leaf network-ref { 1232 type leafref { 1233 path "../../../nd:supporting-network/nd:network-ref"; 1234 require-instance false; 1235 } 1236 description 1237 "This leaf identifies in which underlay topology 1238 the supporting link is present."; 1239 } 1240 leaf link-ref { 1241 type leafref { 1242 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1243 "../network-ref]/link/link-id"; 1244 require-instance false; 1245 } 1246 description 1247 "This leaf identifies a link which is a part 1248 of this link's underlay. Reference loops in which 1249 a link identifies itself as its underlay, either 1250 directly or transitively, are not allowed."; 1251 } 1252 } 1253 } 1254 } 1255 augment "/nd:networks/nd:network/nd:node" { 1256 description 1257 "Augment termination points which terminate links. 1258 Termination points can ultimately be mapped to interfaces."; 1259 list termination-point { 1260 key "tp-id"; 1261 description 1262 "A termination point can terminate a link. 1263 Depending on the type of topology, a termination point 1264 could, for example, refer to a port or an interface."; 1265 leaf tp-id { 1266 type tp-id; 1267 description 1268 "Termination point identifier."; 1269 } 1270 list supporting-termination-point { 1271 key "network-ref node-ref tp-ref"; 1272 description 1273 "This list identifies any termination points that 1274 the termination point is dependent on, or maps onto. 1275 Those termination points will themselves be contained 1276 in a supporting node. 1277 This dependency information can be inferred from 1278 the dependencies between links. For this reason, 1279 this item is not separately configurable. Hence no 1280 corresponding constraint needs to be articulated. 1281 The corresponding information is simply provided by the 1282 implementing system."; 1283 leaf network-ref { 1284 type leafref { 1285 path "../../../nd:supporting-node/nd:network-ref"; 1286 require-instance false; 1287 } 1288 description 1289 "This leaf identifies in which topology the 1290 supporting termination point is present."; 1291 } 1292 leaf node-ref { 1293 type leafref { 1294 path "../../../nd:supporting-node/nd:node-ref"; 1295 require-instance false; 1296 } 1297 description 1298 "This leaf identifies in which node the supporting 1299 termination point is present."; 1300 } 1301 leaf tp-ref { 1302 type leafref { 1303 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1304 "../network-ref]/nd:node[nd:node-id=current()/../"+ 1305 "node-ref]/termination-point/tp-id"; 1306 require-instance false; 1307 } 1308 description 1309 "Reference to the underlay node, must be in a 1310 different topology"; 1311 } 1312 } 1313 } 1314 } 1315 } 1317 1319 5. Security Considerations 1321 The transport protocol used for sending the topology data MUST 1322 support authentication and SHOULD support encryption. The data-model 1323 by itself does not create any security implications. 1325 6. Contributors 1327 The model presented in this paper was contributed to by more people 1328 than can be listed on the author list. Additional contributors 1329 include: 1331 o Ken Gray, Cisco Systems 1333 o Tom Nadeau, Brocade 1335 o Aleksandr Zhdankin, Cisco 1337 7. Acknowledgements 1339 We wish to acknowledge the helpful contributions, comments, and 1340 suggestions that were received from Alia Atlas, Vishnu Pavan Beeram, 1341 Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan 1342 Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Kent 1343 Watsen, and Xian Zhang. 1345 8. References 1347 8.1. Normative References 1349 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1350 Dual Environments", RFC 1195, December 1990. 1352 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1354 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1355 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1356 Tunnels", RFC 3209, December 2001. 1358 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1359 Network Configuration Protocol (NETCONF)", RFC 6020, 1360 October 2010. 1362 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 1363 October 2010. 1365 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1366 Bierman, "Network Configuration Protocol (NETCONF)", 1367 RFC 6241, June 2011. 1369 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1370 Protocol (NETCONF) Access Control Model", RFC 6536, March 1371 2012. 1373 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1374 Management", RFC 7223, May 2014. 1376 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 1377 RFC 7950, August 2016. 1379 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1380 RFC 7952, August 2016. 1382 8.2. Informative References 1384 [I-D.draft-ietf-netconf-yang-push] 1385 Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., 1386 and E. Nilsen-Nygaard, "Subscribing to YANG datastore push 1387 updates", I-D draft-ietf-netconf-yang-push-03, June 2016. 1389 [topology-use-cases] 1390 Medved, J., Previdi, S., Lopez, V., and S. Amante, 1391 "Topology API Use Cases", I-D draft-amante-i2rs-topology- 1392 use-cases-01, October 2013. 1394 Authors' Addresses 1396 Alexander Clemm 1397 Cisco 1399 EMail: ludwig@clemm.org 1401 Jan Medved 1402 Cisco 1404 EMail: jmedved@cisco.com 1406 Robert Varga 1407 Cisco 1409 EMail: rovarga@cisco.com 1411 Tony Tkacik 1413 EMail: tony.tkacik@gmail.com 1414 Nitin Bahadur 1415 Bracket Computing 1417 EMail: nitin_bahadur@yahoo.com 1419 Hariharan Ananthakrishnan 1420 Packet Design 1422 EMail: hari@packetdesign.com 1424 Xufeng Liu 1425 Ericsson 1427 EMail: xliu@kuatrotech.com