idnits 2.17.1 draft-clemm-i2rs-yang-network-topo-03.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 336: '.... Network types SHOULD always be repr...' RFC 2119 keyword, line 750: '... The identifier SHOULD be chosen such...' RFC 2119 keyword, line 753: '...n implementation MAY choose to capture...' RFC 2119 keyword, line 763: '... The identifier SHOULD be chosen such...' RFC 2119 keyword, line 766: '...n implementation MAY choose to capture...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 314 has weird spacing: '...ork-ref lea...' == Line 318 has weird spacing: '...ork-ref lea...' == Line 399 has weird spacing: '...ork-ref lea...' == Line 403 has weird spacing: '...ork-ref lea...' == Line 409 has weird spacing: '...ork-ref lea...' == (3 more instances...) == 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 (March 5, 2015) is 3341 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Z' is mentioned on line 206, but not defined == Missing Reference: 'Y5' is mentioned on line 231, but not defined == Missing Reference: 'Z5' is mentioned on line 231, but not defined == Missing Reference: 'Z3' is mentioned on line 231, but not defined == Missing Reference: 'Y4' is mentioned on line 235, but not defined == Missing Reference: 'Y1' is mentioned on line 235, but not defined == Missing Reference: 'Z2' is mentioned on line 235, but not defined == Missing Reference: 'X5' is mentioned on line 244, but not defined == Missing Reference: 'D1' is mentioned on line 577, but not defined == Missing Reference: 'D2' is mentioned on line 577, but not defined == Unused Reference: 'RFC6241' is defined on line 1004, 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) Summary: 4 errors (**), 0 flaws (~~), 19 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: Experimental R. Varga 5 Expires: September 6, 2015 T. Tkacik 6 Cisco 7 N. Bahadur 8 Bracket Computing 9 H. Ananthakrishnan 10 Packet Design 11 March 5, 2015 13 A Data Model for Network Topologies 14 draft-clemm-i2rs-yang-network-topo-03.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 September 6, 2015. 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 . . . . . . . . . . . . . . . 9 74 3.3. Discussion and selected design decisions . . . . . . . . 11 75 3.3.1. Container structure . . . . . . . . . . . . . . . . . 11 76 3.3.2. Underlay hierarchies and mappings . . . . . . . . . . 11 77 3.3.3. Use of groupings . . . . . . . . . . . . . . . . . . 11 78 3.3.4. Cardinality and directionality of links . . . . . . . 12 79 3.3.5. Multihoming and link aggregation . . . . . . . . . . 12 80 3.3.6. Mapping redundancy . . . . . . . . . . . . . . . . . 12 81 3.3.7. Typing . . . . . . . . . . . . . . . . . . . . . . . 12 82 3.3.8. Representing the same device in multiple networks . . 13 83 3.4. Items for further discussion . . . . . . . . . . . . . . 14 84 4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 14 85 4.1. Defining the Abstract Network: network.yang . . . . . . . 14 86 4.2. Creating Abstract Network Topology: network-topology.yang 16 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 92 8.2. Informative References . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 This document introduces an abstract (base) YANG [RFC6020] [RFC6021] 98 data model to represent networks and topologies. The data model is 99 divided into two parts. The first part of the model defines a 100 network model that allows to define network hierarchies (i.e. network 101 stacks) and to maintain an inventory of nodes contained in a network. 102 The second part of the model augments the basic network model with 103 information to describe topology information. Specifically, it adds 104 the concepts of links and termination points to describe how nodes in 105 a network are connected to each other. Moreover the model introduces 106 vertical layering relationships between networks that can be 107 augmented to cover both network inventories and network/service 108 topologies. 110 The model can be augmented to describe specifics of particular types 111 of networks and topologies. For example, an augmenting model can 112 provide network node information with attributes that are specific to 113 a particular network type. Examples of augmenting models include 114 models for Layer 2 network topologies, Layer 3 network topologies, 115 such as Unicast IGP, IS-IS [RFC1195] and OSPF [RFC2328], traffic 116 engineering (TE) data [RFC3209], or any of the variety of transport 117 and service topologies. Information specific to particular network 118 types will be captured in separate, technology-specific models. 120 The basic data models introduced in this document are generic in 121 nature and can be applied to many network and service topologies and 122 inventories. The models allow applications to operate on an 123 inventory or topology of any network at a generic level, where 124 specifics of particular inventory/topology types are not required. 125 At the same time, where data specific to a network type does comes 126 into play and the model is augmented, the instantiated data still 127 adheres to the same structure and is represented in consistent 128 fashion. This also facilitates the representation of network 129 hierarchies and dependencies between different network components and 130 network types. 132 The abstract (base) network YANG module introduced in this document, 133 entitled "network.yang", contains a list of abstract network nodes 134 and defines the concept of network hierarchy (network stack). The 135 abstract network node can be augmented in inventory and topology 136 models with inventory and topology specific attributes. Network 137 hierarchy (stack) allows any given network to have one or more 138 "supporting networks". The relationship of the base network model, 139 the inventory models and the topology models is shown in the 140 following figure (dotted lines in the figure denote possible 141 augmentations to models defined in this document). 143 +------------------------+ 144 | | 145 | Abstract Network Model | 146 | | 147 +------------------------+ 148 | 149 +-------+-------+ 150 | | 151 V V 152 +------------+ .............. 153 | Abstract | : Inventory : 154 | Topology | : Model(s) : 155 | Model | : : 156 +------------+ '''''''''''''' 157 | 158 +-------------+-------------+ 159 | | | 160 V V V 161 ............ ............ ............ 162 : L2 : : L3 : : Service : 163 : Topology : : Topology : : Topology : 164 : Model : : Model : : Model : 165 '''''''''''' '''''''''''' '''''''''''' 167 Figure 1: The network model structure 169 The network-topology YANG module introduced in this document, 170 entitled "network-topology.yang", defines a generic topology model at 171 its most general level of abstraction. The module defines a topology 172 graph and components from which it is composed: nodes, edges and 173 termination points. Nodes (from the network.yang module) represent 174 graph vertices and links represent graph edges. Nodes also contain 175 termination points that anchor the links. A network can contain 176 multiple topologies, for example topologies at different layers and 177 overlay topologies. The model therefore allows to capture 178 relationships between topologies, as well as dependencies between 179 nodes and termination points across topologies. An example of a 180 topology stack is shown in the following figure. 182 +---------------------------------------+ 183 / _[X1]_ "Service" / 184 / _/ : \_ / 185 / _/ : \_ / 186 / _/ : \_ / 187 / / : \ / 188 / [X2]__________________[X3] / 189 +---------:--------------:------:-------+ 190 : : : 191 +----:--------------:----:--------------+ 192 / : : : "L3" / 193 / : : : / 194 / : : : / 195 / [Y1]_____________[Y2] / 196 / * * * / 197 / * * * / 198 +--------------*-------------*--*-------+ 199 * * * 200 +--------*----------*----*--------------+ 201 / [Z1]_______________[Z1] "Optical" / 202 / \_ * _/ / 203 / \_ * _/ / 204 / \_ * _/ / 205 / \ * / / 206 / [Z] / 207 +---------------------------------------+ 209 Figure 2: Topology hierarchy (stack) example 211 The figure shows three topology levels. At top, the "Service" 212 topology shows relationships between service entities, such as 213 service functions in a service chain. The "L3" topology shows 214 network elements at Layer 3 (IP) and the "Optical" topology shows 215 network elements at Layer 1. Service functions in the "Service" 216 topology are mapped onto network elements in the "L3" topology, which 217 in turn are mapped onto network elements in the "Optical" topology. 218 The figure shows two Service Functions - X1 and X2 - mapping onto a 219 single L3 network element; this could happen, for example, if two 220 service functions reside in the same VM (or server) and share the 221 same set of network interfaces. The figure shows a single "L3" 222 network element mapped onto multiple "Optical" network elements. 223 This could happen, for example, if a single IP router attaches to 224 multiple ROADMs in the optical domain. 226 Another example of a service topology stack is shown in the following 227 figure. 229 VPN1 VPN2 230 +---------------------+ +---------------------+ 231 / [Y5]... / / [Z5]______[Z3] / 232 / / \ : / / : \_ / : / 233 / / \ : / / : \_ / : / 234 / / \ : / / : \ / : / 235 / [Y4]____[Y1] : / / : [Z2] : / 236 +------:-------:---:--+ +---:---------:-----:-+ 237 : : : : : : 238 : : : : : : 239 : +-------:---:-----:------------:-----:-----+ 240 : / [X1]__:___:___________[X2] : / 241 :/ / \_ : : _____/ / : / 242 : / \_ : _____/ / : / 243 /: / \: / / : / 244 / : / [X5] / : / 245 / : / __/ \__ / : / 246 / : / ___/ \__ / : / 247 / : / ___/ \ / : / 248 / [X4]__________________[X3]..: / 249 +------------------------------------------+ 250 L3 Topology 252 Figure 3: Topology hierarchy (stack) example 254 The figure shows two VPN service topologies (VPN1 and VPN2) 255 instantiated over a common L3 topology. Each VPN service topology is 256 mapped onto a subset of nodes from the common L3 topology. 258 There are multiple applications for such a data model. For example, 259 within the context of I2RS, nodes within the network can use the data 260 model to capture their understanding of the overall network topology 261 and expose it to a network controller. A network controller can then 262 use the instantiated topology data to compare and reconcile its own 263 view of the network topology with that of the network elements that 264 it controls. Alternatively, nodes within the network could propagate 265 this understanding to compare and reconcile this understanding either 266 among themselves or with help of a controller. Beyond the network 267 element and the immediate context of I2RS itself, a network 268 controller might even use the data model to represent its view of the 269 topology that it controls and expose it to applications north of 270 itself. Further use cases that the data model can be applied to are 271 described in [topology-use-cases]. 273 2. Definitions and Acronyms 275 Datastore: A conceptual store of instantiated management information, 276 with individual data items represented by data nodes which are 277 arranged in hierarchical manner. 279 Data subtree: An instantiated data node and the data nodes that are 280 hierarchically contained within it. 282 HTTP: Hyper-Text Transfer Protocol 284 IGP: Interior Gateway Protocol 286 IS-IS: Intermediate System to Intermediate System protocol 288 NETCONF: Network Configuration Protocol 290 OSPF: Open Shortest Path First, a link state routing protocol 292 URI: Uniform Resource Identifier 294 ReST: Representational State Transfer, a style of stateless interface 295 and protocol that is generally carried over HTTP 297 YANG: A data definition language for NETCONF 299 3. Model Structure Details 301 3.1. Base Network Model 303 The abstract (base) network model is defined in the network.yang 304 module. Its structure is shown in the following figure. Brackets 305 enclose list keys, "rw" means configuration data, "ro" means 306 operational state data, and "?" designates optional nodes. 308 module: network 309 +--rw network* [network-id] 310 +--rw network-id network-id 311 +--ro server-provided? boolean 312 +--rw network-types 313 +--rw supporting-network* [network-ref] 314 | +--rw network-ref leafref 315 +--rw node* [node-id] 316 +--rw node-id node-id 317 +--rw supporting-node* [network-ref node-ref] 318 +--rw network-ref leafref 319 +--rw node-ref leafref 321 Figure 4: The structure of the abstract (base) network model 323 The model contains a list of networks, contained underneath a root 324 container for this module, "network". Each network is captured in 325 its own list entry, distinguished via a network-id. 327 A network has a certain type, such as L2, L3, OSPF or IS-IS. A 328 network can even have multiple types simultaneously. The type, or 329 types, are captured underneath the container "network-types". In 330 this module it serves merely as an augmentation target; network- 331 specific modules will later introduce new data nodes to represent new 332 network types below this target, i.e. insert them below "network- 333 types" by ways of yang augmentation. 335 When a network is of a certain type, it will contain a corresponding 336 data node. Network types SHOULD always be represented using presence 337 containers, not leafs of empty type. This allows to represent 338 hierarchies of network subtypes within the instance information. For 339 example, an instance of an OSPF network (which, at the same time, is 340 a layer 3 unicast IGP network) would contain underneath "network- 341 types" another container "l3-unicast-igp-network", which in turn 342 would contain a container "ospf-network". 344 A network can in turn be part of a hierarchy of networks, building on 345 top of other networks. Any such networks are captured in the list 346 "supporting-network". A supporting network is in effect an underlay 347 network. 349 Furthermore, a network contains an inventory of nodes that are part 350 of the network. The nodes of a network are captured in their own 351 list. Each node is identified relative to its containing network by 352 a node-id. 354 It should be noted that a node does not exist independently of a 355 network; instead it is a part of the network that it is contained in. 357 In cases where the same entity takes part in multiple networks, or at 358 multiple layers of a networking stack, the same entity will be 359 represented by multiple nodes, one for each network. In other words, 360 the node represents an abstraction of the device for the particular 361 network that it a is part of. To represent that the same entity or 362 same device is part of multiple topologies or networks, it is 363 possible to create one "physical" network with a list of nodes for 364 each of the devices or entities. This (physical) network, 365 respectively the (entities) nodes in that network, can then be 366 referred to as underlay network and nodes from the other (logical) 367 networks and nodes, respectively. Note that the model allows to 368 define more than one underlay network (and node), allowing for 369 simultaneous representation of layered network- and service 370 topologies and physical instantiation. 372 Similar to a network, a node can be supported by other nodes, and map 373 onto one or more other nodes in an underlay network. This is 374 captured in the list "supporting-node". The resulting hierarchy of 375 nodes allows also to represent device stacks, where a node at one 376 level is supported by a set of nodes at an underlying level. For 377 example, a "router" node might be supported by a node representing a 378 route processor and separate nodes for various line cards and service 379 modules, a virtual router might be supported or hosted on a physical 380 device represented by a separate node, and so on. 382 3.2. Base Network Topology Model 384 The abstract (base) network topology model is defined in the 385 "network-topology.yang" module. It builds on the network model 386 defined in the "network.yang" module, augmenting it with links 387 (defining how nodes are connected) and termination-points (which 388 anchor the links and are contained in nodes). The structure of the 389 network topology module is shown in the following figure. Brackets 390 enclose list keys, "rw" means configuration data, "ro" means 391 operational state data, and "?" designates optional nodes. 393 module: network 394 +--rw network* [network-id] 395 +--rw network-id network-id 396 +--ro server-provided? boolean 397 +--rw network-types 398 +--rw supporting-network* [network-ref] 399 | +--rw network-ref leafref 400 +--rw node* [node-id] 401 | +--rw node-id node-id 402 | +--rw supporting-node* [network-ref node-ref] 403 | | +--rw network-ref leafref 404 | | +--rw node-ref leafref 405 | +--rw lnk:termination-point* [tp-id] 406 | +--rw lnk:tp-id tp-id 407 | +--rw lnk:supporting-termination-point* 408 [network-ref node-ref tp-ref] 409 | +--rw lnk:network-ref leafref 410 | +--rw lnk:node-ref leafref 411 | +--rw lnk:tp-ref leafref 412 +--rw lnk:link* [link-id] 413 +--rw lnk:link-id link-id 414 +--rw lnk:source 415 | +--rw lnk:source-node leafref 416 | +--rw lnk:source-tp? leafref 417 +--rw lnk:destination 418 | +--rw lnk:dest-node leafref 419 | +--rw lnk:dest-tp? leafref 420 +--rw lnk:supporting-link* [network-ref link-ref] 421 +--rw lnk:network-ref leafref 422 +--rw lnk:link-ref leafref 424 Figure 5: The structure of the abstract (base) network topology model 426 A node has a list of termination points that are used to terminate 427 links. An example of a termination point might be a physical or 428 logical port or, more generally, an interface. 430 Like a node, a termination point can in turn be supported by an 431 underlying termination point, contained in the supporting node of the 432 underlay network. 434 A link is identified by a link-id that uniquely identifies the link 435 within a given topology. Links are point-to-point and 436 unidirectional. Accordingly, a link contains a source and a 437 destination. Both source and destination reference a corresponding 438 node, as well as a termination point on that node. Similar to a 439 node, a link can map onto one or more links in an underlay topology 440 (which are terminated by the corresponding underlay termination 441 points). This is captured in the list "supporting-link". 443 3.3. Discussion and selected design decisions 445 3.3.1. Container structure 447 Rather than maintaining lists in separate containers, the model is 448 kept relatively flat in terms of its containment structure. Lists of 449 nodes, links, termination-points, and supporting-nodes, supporting- 450 links, and supporting-termination-points are not kept in separate 451 containers. Therefore, path specifiers used to refer to specific 452 nodes, be it in management operations or in specifications of 453 constraints, can remain relatively compact. Of course, this means 454 there is no separate structure in instance information that separates 455 elements of different lists from one another. Such structure is 456 semantically not required, although it might enhance human 457 readability in some cases. 459 3.3.2. Underlay hierarchies and mappings 461 To minimize assumptions of what a particular entity might actually 462 represent, mappings between networks, nodes, links, and termination 463 points are kept strictly generic. For example, no assumptions are 464 made whether a termination point actually refers to an interface, or 465 whether a node refers to a specific "system" or device; the model at 466 this generic level makes no provisions for that. 468 Where additional specifics about mappings between upper and lower 469 layers are required, those can be captured in augmenting modules. 470 For example, to express that a termination point in a particular 471 network type maps to an interface, an augmenting module can introduce 472 an augmentation to the termination point which introduces a leaf of 473 type ifref that references the corresponding interface [RFC7223]. 474 Similarly, if a node maps to a particular device or network element, 475 an augmenting module can augment the node data with a leaf that 476 references the network element. 478 3.3.3. Use of groupings 480 The model makes use of groupings, instead of simply defining data 481 nodes "in-line". This allows to more easily include the 482 corresponding data nodes in notifications, which then do not need to 483 respecify each data node that is to be included. The tradeoff for 484 this is that it makes the specification of constraints more complex, 485 because constraints involving data nodes outside the grouping need to 486 be specified in conjunction with a "uses" statement where the 487 grouping is applied. This also means that constraints and XPath- 488 statements need to specified in such a way that they navigate "down" 489 first and select entire sets of nodes, as opposed to being able to 490 simply specify them against individual data nodes. 492 3.3.4. Cardinality and directionality of links 494 The topology model includes links that are point-to-point and 495 unidirectional. It does not directly support multipoint and 496 bidirectional links. While this may appear as a limitation, it does 497 keep the model simple, generic, and allows it to very easily be 498 subjected to applications that make use of graph algorithms. Bi- 499 directional connections can be represented through pairs of 500 unidirectional links. Multipoint networks can be represented through 501 pseudo-nodes (similar to IS-IS, for example). By introducing 502 hierarchies of nodes, with nodes at one level mapping onto a set of 503 other nodes at another level, and introducing new links for nodes at 504 that level, topologies with connections representing non-point-to- 505 point communication patterns can be represented. 507 3.3.5. Multihoming and link aggregation 509 Links are terminated by a single termination point, not sets of 510 termination points. Connections involving multihoming or link 511 aggregation schemes need to be represented using multiple point-to- 512 point links, then defining a link at a higher layer that is supported 513 by those individual links. 515 3.3.6. Mapping redundancy 517 In a hierarchy of networks, there are nodes mapping to nodes, links 518 mapping to links, and termination points mapping to termination 519 points. Some of this information is redundant. Specifically, if the 520 link-to-links mapping known, and the termination points of each link 521 known, termination point mapping information can be derived via 522 transitive closure and does not have to be explicitly configured. 523 Nonetheless, in order to not constrain applications regarding which 524 mappings they want to configure and which should be derived, the 525 model does provide for the option to configure this information 526 explicitly. The model includes integrity constraints to allow for 527 validating for consistency. 529 3.3.7. Typing 531 A network's network types are represented using a container which 532 contains a data node for each of its network types. A network can 533 encompass several types of network simultaneously, hence a container 534 is used instead of a case construct, with each network type in turn 535 represented by a dedicated presence container itself. The reason for 536 not simply using an empty leaf, or even simpler, do away even with 537 the network container and just use a leaf-list of network-type 538 instead, is to be able to represent "class hierarchies" of network 539 types, with one network type refining the other. Network-type 540 specific containers are to be defined in the network-specific 541 modules, augmenting the network-types container. 543 3.3.8. Representing the same device in multiple networks 545 One common requirement concerns the ability to represent that the 546 same device can be part of multiple networks and topologies. 547 However, the model defines a node as relative to the network that it 548 is contained in. The same node cannot be part of multiple 549 topologies. In many cases, a node will be the abstraction of a 550 particular device in a network. To reflect that the same device is 551 part of multiple topologies, the following approach might be chosen: 552 A "physical" (or "device") network is introduced, with nodes 553 representing devices. This network forms an underlay network for 554 logical networks above it, with nodes of the logical network mapping 555 onto nodes in the physical network. 557 This scenario is depicted in the following figure. It depicts three 558 networks with two nodes each. A physical network P consists of an 559 inventory of two nodes, D1 and D2, each representing a device. A 560 second network, X, has a third network, Y, as its underlay. Both X 561 and Y also have the physical network P as underlay. X1 has both Y1 562 and D1 as underlay nodes, while Y1 has D1 as underlay node. 563 Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as 564 underlay node. The fact that X1 and Y1 are both instantiated on the 565 same physical node D1 can be easily derived. 567 +---------------------+ 568 / [X1]____[X2] / X(Service Overlay) 569 +----:--:----:--------+ 570 ..: :..: : 571 ........: ....: : :.... 572 +-----:-------------:--+ : :... 573 / [Y1]____[Y2]....: / :.. : 574 +------|-------|-------+ :.. :... 575 Y(L3) | +---------------------:-----+ : 576 | +----:----|-:----------+ 577 +------------------------/---[D1] [D2] / 578 +----------------------+ 579 P (Physical network) 581 Figure 6: Topology hierarchy example - multiple underlays 583 3.4. Items for further discussion 585 YANG requires data needs to be designated as either configuration or 586 operational data, but not both, yet it is important to have all 587 network information, including vertical cross-network dependencies, 588 captured in one coherent model. In most cases network topology 589 information is discovered about a network; the topology is considered 590 a property of the network that is reflected in the model. That said, 591 it is conceivable that certain types of topology need to also be 592 configurable by an application. 594 There are several alternatives in which this can be addressed. The 595 alternative chosen in this draft does not restrict network topology 596 information as read-only, but includes a flag that indicates for each 597 network whether it should be considered as read-only or configurable 598 by applications. 600 An alternative would be to designate network list elements as read 601 only. The read-only network list includes each network; it is the 602 complete reference. In parallel a second network list is introduced. 603 This list serves the purpose of being able to configure networks 604 which are then mirrored in the read-only list. The configurable 605 network list adheres to the same structure and uses the same 606 groupings as its read-only counterpart. As most data is defined in 607 those groupings, the amount of additional definitions required will 608 be limited. A configurable network will thus be represented twice: 609 once in the read-only list of all networks, a second time in a 610 configuration sandbox. 612 Similar considerations apply to scenarios in which data is subject to 613 configuration, but implementations want to be smart enough require 614 only some mapping information, such as which link is supported by 615 which other links, while automatically deriving other mapping 616 information where possible, such as which termination points are 617 supported by which underlay termination points. To accommodate such 618 cases, separate provision may again be made by including another 619 "server-provided" option. 621 4. YANG Modules 623 4.1. Defining the Abstract Network: network.yang 625 file "network.yang" 626 module network { 627 yang-version 1; 628 namespace "urn:TBD:params:xml:ns:yang:nodes"; 629 prefix nd; 630 import ietf-inet-types { prefix inet; } 632 organization "TBD"; 633 contact 634 "WILL-BE-DEFINED-LATER"; 635 description 636 "This module defines a common base model for a collection 637 of nodes in a network. Node definitions s are further used 638 in network topologies and inventories."; 640 revision 2014-3-5 { 641 description 642 "Initial revision."; 643 reference "draft-clemm-i2rs-yang-network-topo-03"; 644 } 646 typedef node-id { 647 type inet:uri; 648 } 650 typedef network-id { 651 type inet:uri; 652 } 654 grouping network-ref { 655 leaf network-ref { 656 type leafref { 657 path "/network/topology-id"; 658 } 659 } 660 } 662 grouping node-ref { 663 uses network-ref; 664 leaf node-ref { 665 type leafref { 666 path "/network[network-id=current()" + 667 "/../network-ref]/node/node-id"; 668 } 669 } 670 } 672 list network { 673 key "network-id"; 675 leaf network-id { 676 type network-id; 677 } 678 leaf server-provided { 679 type boolean; 680 config false; 681 } 683 container network-types { 684 } 686 list supporting-network { 687 key "network-ref"; 688 leaf network-ref { 689 type leafref { 690 path "/network/network-id"; 691 } 692 } 693 } 695 list node { 696 key "node-id"; 697 leaf node-id { 698 type node-id; 699 } 700 list supporting-node { 701 key "network-ref node-ref"; 702 leaf network-ref { 703 type leafref { 704 path "../../../supporting-network/network-ref"; 705 } 706 } 707 leaf node-ref { 708 type leafref { 709 // path "/network[network-id=current()" + 710 // "/../network-ref]/node/node-id"; 711 path "/network/node/node-id"; 712 } 713 } 714 } 715 } 716 } 718 } 719 721 4.2. Creating Abstract Network Topology: network-topology.yang 723 file "network-topology.yang" 724 module network-topology { 725 yang-version 1; 726 namespace "urn:TBD:params:xml:ns:yang:links"; 727 prefix lnk; 729 import ietf-inet-types { prefix inet; } 730 import nodes { prefix nd; } 732 organization "TBD"; 733 contact 734 "WILL-BE-DEFINED-LATER"; 735 description 736 "This module defines a common base model for a collection of links 737 connecting nodes."; 739 revision 2014-3-5 { 740 description 741 "Initial revision."; 742 reference "draft-clemm-i2rs-yang-network-topo-03"; 743 } 745 typedef link-id { 746 type inet:uri; 747 description 748 "An identifier for a link in a topology. 749 The identifier may be opaque. 750 The identifier SHOULD be chosen such that the same link in a 751 real network topology will always be identified through the 752 same identifier, even if the model is instantiated in separate 753 datastores. An implementation MAY choose to capture semantics 754 in the identifier, for example to indicate the type of link 755 and/or the type of topology that the link is a part of."; 756 } 758 typedef tp-id { 759 type inet:uri; 760 description 761 "An identifier for termination points on a node. 762 The identifier may be opaque. 763 The identifier SHOULD be chosen such that the same TP in a 764 real network topology will always be identified through the 765 same identifier, even if the model is instantiated in separate 766 datastores. An implementation MAY choose to capture semantics 767 in the identifier, for example to indicate the type of TP 768 and/or the type of node and topology that the TP is a part 769 of."; 770 } 772 grouping link-ref { 773 description 774 "A type for an absolute reference a link instance. 775 (This type should not be used for relative references. 776 In such a case, a relative path should be used instead.)"; 777 uses nd:network-ref; 778 leaf link-ref { 779 type leafref { 780 path "/nd:network[nd:network-id=current()" + 781 "/../nd:network-ref]/link/link-id"; 782 } 783 } 784 } 786 grouping tp-ref { 787 description 788 "A type for an absolute reference to a termination point. 789 (This type should not be used for relative references. 790 In such a case, a relative path should be used instead.)"; 791 uses nd:node-ref; 792 leaf tp-ref { 793 type leafref { 794 path "/nd:network[nd:network-id=current()" + 795 "/../nd:network-ref]/nd:node[nd:node-id=current()" + 796 "/../nd:node-ref]/termination-point/tp-id"; 797 } 798 } 799 } 801 augment "/nd:network" { 802 list link { 803 key "link-id"; 804 leaf link-id { 805 type link-id; 806 description 807 "The identifier of a link in the topology. 808 A link is specific to a topology to which it belongs."; 809 } 810 description 811 "A Network Link connects a by Local (Source) node and 812 a Remote (Destination) Network Nodes via a set of the 813 nodes' termination points. 814 As it is possible to have several links between the same 815 source and destination nodes, and as a link could 816 potentially be re-homed between termination points, to 817 ensure that we would always know to distinguish between 818 links, every link is identified by a dedicated link 819 identifier. 820 Note that a link models a point-to-point link, not a 821 multipoint link. 823 Layering dependencies on links in underlay topologies are 824 not represented as the layering information of nodes and of 825 termination points is sufficient."; 826 container source { 827 description 828 "This container holds the logical source of a particular 829 link."; 830 leaf source-node { 831 type leafref { 832 path "../../../nd:node/nd:node-id"; 833 } 834 mandatory true; 835 description 836 "Source node identifier, must be in same topology."; 837 } 838 leaf source-tp { 839 type leafref { 840 path "../../../nd:node[nd:node-id=current()/.." + 841 "/source-node]/termination-point/tp-id"; 842 } 843 description 844 "Termination point within source node that terminates 845 the link."; 846 } 847 } 848 container destination { 849 description 850 "This container holds the logical destination of a 851 particular link."; 852 leaf dest-node { 853 type leafref { 854 path "../../../nd:node/nd:node-id"; 855 } 856 mandatory true; 857 description 858 "Destination node identifier, must be in the same 859 network."; 860 } 861 leaf dest-tp { 862 type leafref { 863 path "../../../nd:node[nd:node-id=current()/.." + 864 "/dest-node]/termination-point/tp-id"; 865 } 866 description 867 "Termination point within destination node that 868 terminates the link."; 869 } 870 } 871 list supporting-link { 872 key "network-ref link-ref"; 873 description 874 "Identifies the link, or links, that this link 875 is dependent on."; 876 leaf network-ref { 877 type leafref { 878 path "../../../nd:supporting-network/nd:network-ref"; 879 } 880 description 881 "This leaf identifies in which underlay topology 882 supporting link is present."; 883 } 884 leaf link-ref { 885 type leafref { 886 path "/nd:network[nd:network-id=" + 887 "current()/../network-ref]/link/link-id"; 888 } 889 description 890 "This leaf identifies a link which is forms a part 891 of this link's underlay. Reference loops, where 892 a link identifies itself as its underlay, either 893 directly or transitively, are not allowed."; 894 } 895 } 896 } 897 } 899 augment "/nd:network/nd:node" { 900 list termination-point { 901 key "tp-id"; 902 description 903 "A termination point can terminate a link. 904 Depending on the type of topology, a termination point 905 could, for example, refer to a port or an interface."; 906 leaf tp-id { 907 type tp-id; 908 description 909 "Termination point identifier."; 910 } 911 list supporting-termination-point { 912 key "network-ref node-ref tp-ref"; 913 description 914 "The leaf list identifies any termination points that 915 the termination point is dependent on, or maps onto. 916 Those termination points will themselves be contained 917 in a supporting node. 918 This dependency information can be inferred from 919 the dependencies between links. For this reason, 920 this item is not separately configurable. Hence no 921 corresponding constraint needs to be articulated. 922 The corresponding information is simply provided by the 923 implementing system."; 924 leaf network-ref { 925 type leafref { 926 path "../../../nd:supporting-node/nd:network-ref"; 927 } 928 description 929 "This leaf identifies in which topology the 930 supporting termination point is present."; 931 } 932 leaf node-ref { 933 type leafref { 934 path "../../../nd:supporting-node/nd:node-ref"; 935 } 936 description 937 "This leaf identifies in which node the supporting 938 termination point is present."; 939 } 940 leaf tp-ref { 941 type leafref { 942 path "/nd:network[nd:network-id=" + 943 "current()/../network-ref]/nd:node[nd:node-id=" + 944 "current()/../node-ref]/termination-point" + 945 "/tp-id"; 946 } 947 description 948 "Reference to the underlay node, must be in a 949 different topology"; 950 } 951 } 952 } 953 } 954 } 956 958 5. Security Considerations 960 The transport protocol used for sending the topology data MUST 961 support authentication and SHOULD support encryption. The data-model 962 by itself does not create any security implications. 964 6. Contributors 966 The model presented in this paper was contributed to by more people 967 than can be listed on the author list. Additional contributors 968 include: 970 o Ken Gray, Cisco Systems 972 o Tom Nadeau, Brocade 974 o Aleksandr Zhdankin, Cisco 976 7. Acknowledgements 978 We wish to acknowledge the helpful contributions, comments, and 979 suggestions that were received from Alia Atlas, Vishna Pavan Beeram, 980 Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan 981 Hares, Xufeng Liu, Ladislav Lhotka, Carlos Pignataro, and Juergen 982 Schoenwaelder. 984 8. References 986 8.1. Normative References 988 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 989 dual environments", RFC 1195, December 1990. 991 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 993 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 994 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 995 Tunnels", RFC 3209, December 2001. 997 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 998 Network Configuration Protocol (NETCONF)", RFC 6020, 999 October 2010. 1001 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 1002 October 2010. 1004 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1005 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1006 6241, June 2011. 1008 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1009 Management", RFC 7223, May 2014. 1011 8.2. Informative References 1013 [restconf] 1014 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1015 Protocol", I-D draft-ietf-netconf-restconf-04, January 1016 2015. 1018 [topology-use-cases] 1019 Medved, J., Previdi, S., Lopez, V., and S. Amante, 1020 "Topology API Use Cases", I-D draft-amante-i2rs-topology- 1021 use-cases-01, October 2013. 1023 [yang-json] 1024 Lhotka, L., "JSON Encoding of Data Modeled with YANG", I-D 1025 draft-ietf-netmod-yang-json-03, February 2015. 1027 Authors' Addresses 1029 Alexander Clemm 1030 Cisco 1032 EMail: alex@cisco.com 1034 Jan Medved 1035 Cisco 1037 EMail: jmedved@cisco.com 1039 Robert Varga 1040 Cisco 1042 EMail: rovarga@cisco.com 1044 Tony Tkacik 1045 Cisco 1047 EMail: ttkacik@cisco.com 1049 Nitin Bahadur 1050 Bracket Computing 1052 EMail: nitin_bahadur@yahoo.com 1053 Hariharan Ananthakrishnan 1054 Packet Design 1056 EMail: hari@packetdesign.com