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