idnits 2.17.1 draft-ietf-i2rs-yang-network-topo-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2017) is 2492 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 220, but not defined == Missing Reference: 'Y5' is mentioned on line 245, but not defined == Missing Reference: 'Z5' is mentioned on line 245, but not defined == Missing Reference: 'Z3' is mentioned on line 245, but not defined == Missing Reference: 'Y4' is mentioned on line 249, but not defined == Missing Reference: 'Y1' is mentioned on line 249, but not defined == Missing Reference: 'Z2' is mentioned on line 249, but not defined == Missing Reference: 'X5' is mentioned on line 258, but not defined == Missing Reference: 'D1' is mentioned on line 740, but not defined == Missing Reference: 'D2' is mentioned on line 740, but not defined == Unused Reference: 'RFC7952' is defined on line 1533, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-02 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-06 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Clemm 3 Internet-Draft Huawei 4 Intended status: Standards Track J. Medved 5 Expires: January 1, 2018 Cisco 6 R. Varga 7 Pantheon Technologies SRO 8 N. Bahadur 9 Bracket Computing 10 H. Ananthakrishnan 11 Packet Design 12 X. Liu 13 Jabil 14 June 30, 2017 16 A Data Model for Network Topologies 17 draft-ietf-i2rs-yang-network-topo-14.txt 19 Abstract 21 This document defines an abstract (generic) YANG data model for 22 network/service topologies and inventories. The model serves as a 23 base model which is augmented with technology-specific details in 24 other, more specific topology and inventory models. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 1, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 8 63 4. Model Structure Details . . . . . . . . . . . . . . . . . . . 8 64 4.1. Base Network Model . . . . . . . . . . . . . . . . . . . 8 65 4.2. Base Network Topology Model . . . . . . . . . . . . . . . 11 66 4.3. Extending the model . . . . . . . . . . . . . . . . . . . 12 67 4.4. Discussion and selected design decisions . . . . . . . . 13 68 4.4.1. Container structure . . . . . . . . . . . . . . . . . 13 69 4.4.2. Underlay hierarchies and mappings . . . . . . . . . . 13 70 4.4.3. Dealing with changes in underlay networks . . . . . . 14 71 4.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 14 72 4.4.5. Cardinality and directionality of links . . . . . . . 15 73 4.4.6. Multihoming and link aggregation . . . . . . . . . . 15 74 4.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 15 75 4.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.4.9. Representing the same device in multiple networks . . 16 77 4.4.10. Supporting client-configured and server-provided 78 network topology . . . . . . . . . . . . . . . . . . 17 79 4.4.11. Identifiers of string or URI type . . . . . . . . . . 17 80 5. Interactions with Other YANG Modules . . . . . . . . . . . . 18 81 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 82 6.1. Defining the Abstract Network: network.yang . . . . . . . 18 83 6.2. Creating Abstract Network Topology: network-topology.yang 23 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 90 11.2. Informative References . . . . . . . . . . . . . . . . . 32 91 Appendix A. Appendix: Model Use Cases . . . . . . . . . . . . . 34 92 A.1. Fetching Topology from a Network Element . . . . . . . . 34 93 A.2. Modifying TE Topology Imported from an Optical Controller 34 94 A.3. Annotating Topology for Local Computation . . . . . . . . 35 95 A.4. SDN Controller-Based Configuration of Overlays on Top of 96 Underlays . . . . . . . . . . . . . . . . . . . . . . . . 35 97 Appendix B. Appendix: Companion YANG models for non-NMDA 98 compliant implementations . . . . . . . . . . . . . 35 99 B.1. YANG Model for Network State . . . . . . . . . . . . . . 36 100 B.2. YANG Model for Network Topology State . . . . . . . . . . 40 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 103 1. Introduction 105 This document introduces an abstract (base) YANG [RFC7950] [RFC6991] 106 data model to represent networks and topologies. The data model is 107 divided into two parts. The first part of the model defines a 108 network model that allows to define network hierarchies (i.e. network 109 stacks) and to maintain an inventory of nodes contained in a network. 110 The second part of the model augments the basic network model with 111 information to describe topology information. Specifically, it adds 112 the concepts of links and termination points to describe how nodes in 113 a network are connected to each other. Moreover the model introduces 114 vertical layering relationships between networks that can be 115 augmented to cover both network inventories and network/service 116 topologies. 118 While it would be possible to combine both parts into a single model, 119 the separation facilitates integration of network topology and 120 network inventory models, by allowing to augment network inventory 121 information separately and without concern for topology into the 122 network model. 124 The model can be augmented to describe specifics of particular types 125 of networks and topologies. For example, an augmenting model can 126 provide network node information with attributes that are specific to 127 a particular network type. Examples of augmenting models include 128 models for Layer 2 network topologies, Layer 3 network topologies, 129 such as Unicast IGP, IS-IS [RFC1195] and OSPF [RFC2328], traffic 130 engineering (TE) data [RFC3209], or any of the variety of transport 131 and service topologies. Information specific to particular network 132 types will be captured in separate, technology-specific models. 134 The basic data models introduced in this document are generic in 135 nature and can be applied to many network and service topologies and 136 inventories. The models allow applications to operate on an 137 inventory or topology of any network at a generic level, where 138 specifics of particular inventory/topology types are not required. 139 At the same time, where data specific to a network type does comes 140 into play and the model is augmented, the instantiated data still 141 adheres to the same structure and is represented in consistent 142 fashion. This also facilitates the representation of network 143 hierarchies and dependencies between different network components and 144 network types. 146 The abstract (base) network YANG module introduced in this document, 147 entitled "network.yang", contains a list of abstract network nodes 148 and defines the concept of network hierarchy (network stack). The 149 abstract network node can be augmented in inventory and topology 150 models with inventory and topology specific attributes. Network 151 hierarchy (stack) allows any given network to have one or more 152 "supporting networks". The relationship of the base network model, 153 the inventory models and the topology models is shown in the 154 following figure (dotted lines in the figure denote possible 155 augmentations to models defined in this document). 157 +------------------------+ 158 | | 159 | Abstract Network Model | 160 | | 161 +------------------------+ 162 | 163 +-------+-------+ 164 | | 165 V V 166 +------------+ .............. 167 | Abstract | : Inventory : 168 | Topology | : Model(s) : 169 | Model | : : 170 +------------+ '''''''''''''' 171 | 172 +-------------+-------------+-------------+ 173 | | | | 174 V V V V 175 ............ ............ ............ ............ 176 : L1 : : L2 : : L3 : : Service : 177 : Topology : : Topology : : Topology : : Topology : 178 : Model : : Model : : Model : : Model : 179 '''''''''''' '''''''''''' '''''''''''' '''''''''''' 181 Figure 1: The network model structure 183 The network-topology YANG module introduced in this document, 184 entitled "network-topology.yang", defines a generic topology model at 185 its most general level of abstraction. The module defines a topology 186 graph and components from which it is composed: nodes, edges and 187 termination points. Nodes (from the network.yang module) represent 188 graph vertices and links represent graph edges. Nodes also contain 189 termination points that anchor the links. A network can contain 190 multiple topologies, for example topologies at different layers and 191 overlay topologies. The model therefore allows to capture 192 relationships between topologies, as well as dependencies between 193 nodes and termination points across topologies. An example of a 194 topology stack is shown in the following figure. 196 +---------------------------------------+ 197 / _[X1]_ "Service" / 198 / _/ : \_ / 199 / _/ : \_ / 200 / _/ : \_ / 201 / / : \ / 202 / [X2]__________________[X3] / 203 +---------:--------------:------:-------+ 204 : : : 205 +----:--------------:----:--------------+ 206 / : : : "L3" / 207 / : : : / 208 / : : : / 209 / [Y1]_____________[Y2] / 210 / * * * / 211 / * * * / 212 +--------------*-------------*--*-------+ 213 * * * 214 +--------*----------*----*--------------+ 215 / [Z1]_______________[Z1] "Optical" / 216 / \_ * _/ / 217 / \_ * _/ / 218 / \_ * _/ / 219 / \ * / / 220 / [Z] / 221 +---------------------------------------+ 223 Figure 2: Topology hierarchy (stack) example 225 The figure shows three topology levels. At top, the "Service" 226 topology shows relationships between service entities, such as 227 service functions in a service chain. The "L3" topology shows 228 network elements at Layer 3 (IP) and the "Optical" topology shows 229 network elements at Layer 1. Service functions in the "Service" 230 topology are mapped onto network elements in the "L3" topology, which 231 in turn are mapped onto network elements in the "Optical" topology. 232 The figure shows two Service Functions - X1 and X2 - mapping onto a 233 single L3 network element; this could happen, for example, if two 234 service functions reside in the same VM (or server) and share the 235 same set of network interfaces. The figure shows a single "L3" 236 network element mapped onto multiple "Optical" network elements. 237 This could happen, for example, if a single IP router attaches to 238 multiple ROADMs in the optical domain. 240 Another example of a service topology stack is shown in the following 241 figure. 243 VPN1 VPN2 244 +---------------------+ +---------------------+ 245 / [Y5]... / / [Z5]______[Z3] / 246 / / \ : / / : \_ / : / 247 / / \ : / / : \_ / : / 248 / / \ : / / : \ / : / 249 / [Y4]____[Y1] : / / : [Z2] : / 250 +------:-------:---:--+ +---:---------:-----:-+ 251 : : : : : : 252 : : : : : : 253 : +-------:---:-----:------------:-----:-----+ 254 : / [X1]__:___:___________[X2] : / 255 :/ / \_ : : _____/ / : / 256 : / \_ : _____/ / : / 257 /: / \: / / : / 258 / : / [X5] / : / 259 / : / __/ \__ / : / 260 / : / ___/ \__ / : / 261 / : / ___/ \ / : / 262 / [X4]__________________[X3]..: / 263 +------------------------------------------+ 264 L3 Topology 266 Figure 3: Topology hierarchy (stack) example 268 The figure shows two VPN service topologies (VPN1 and VPN2) 269 instantiated over a common L3 topology. Each VPN service topology is 270 mapped onto a subset of nodes from the common L3 topology. 272 There are multiple applications for such a data model. For example, 273 within the context of I2RS, nodes within the network can use the data 274 model to capture their understanding of the overall network topology 275 and expose it to a network controller. A network controller can then 276 use the instantiated topology data to compare and reconcile its own 277 view of the network topology with that of the network elements that 278 it controls. Alternatively, nodes within the network could propagate 279 this understanding to compare and reconcile this understanding either 280 among themselves or with help of a controller. Beyond the network 281 element and the immediate context of I2RS itself, a network 282 controller might even use the data model to represent its view of the 283 topology that it controls and expose it to applications north of 284 itself. Further use cases that the data model can be applied to are 285 described in [I-D.draft-ietf-i2rs-usecase-reqs-summary]. 287 In this data model, a network is categorized as either server- 288 provided or not. If a network is server-provided, then it is 289 dynamically learned information that can be read from the operational 290 data-store. For example, as mentioned above, when a network 291 controller reads a router's topology, that network is server- 292 provided. This data model can also be used to create or modify 293 network topologies such as might be associated with an inventory or 294 with an overlay network. Such a network is not server-provided but 295 configured. This data model allows a network to refer to a 296 supporting-network, supporting-nodes, supporting-links, etc. 298 The model does allow to layer a network that is configured on top of 299 one that is server-provided. This permits the configuration of 300 overlay networks on top of networks that are discovered. 301 Specifically, this data model is structured to support being 302 implemented as part of the ephemeral data-store 303 [I-D.draft-ietf-netmod-revised-datastores], defined as requirement 304 Ephemeral-REQ-03 in [I-D.draft-ietf-i2rs-ephemeral-state]. This 305 allows a written (e.g. not server-provided) network topology to refer 306 to a dynamically learned server-provided network. A simple use case 307 might involve creating an overlay network that is supported by the 308 dynamically discovered IP routed network topology. When an 309 implementation places written data for this data model in the 310 ephemeral data store, then such a network MAY refer to another 311 network that is server-provided. 313 An implementation's security policy MAY further restrict what 314 information the server-provided model is allowed to access in 315 standard configuration data-stores, or what server-provided network 316 an ephemeral data store may access. These security policies are 317 outside the scope of the standardization of this model. 319 Finally, it should be noted that the model is still subject to update 320 per ongoing discussions that are related to design decisions 321 regarding the fact that some layers of the network topology may be 322 server provided while others may be configured. These issues are 323 outlined in section 4.4.10. 325 2. Key Words 327 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 328 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 329 document are to be interpreted as described in [RFC2119]. 331 3. Definitions and Acronyms 333 Datastore: A conceptual store of instantiated management information, 334 with individual data items represented by data nodes which are 335 arranged in hierarchical manner. 337 Data subtree: An instantiated data node and the data nodes that are 338 hierarchically contained within it. 340 HTTP: Hyper-Text Transfer Protocol 342 IGP: Interior Gateway Protocol 344 IS-IS: Intermediate System to Intermediate System protocol 346 NETCONF: Network Configuration Protocol 348 OSPF: Open Shortest Path First, a link state routing protocol 350 URI: Uniform Resource Identifier 352 ReST: Representational State Transfer, a style of stateless interface 353 and protocol that is generally carried over HTTP 355 YANG: A data definition language for NETCONF 357 4. Model Structure Details 359 4.1. Base Network Model 361 The abstract (base) network model is defined in the network.yang 362 module. Its structure is shown in the following figure. Brackets 363 enclose list keys, "rw" means configuration data, "ro" means 364 operational state data, and "?" designates optional nodes. A "+" 365 indicates a line break. 367 module: ietf-network 368 +--rw networks 369 +--rw network* [network-id] 370 +--rw network-types 371 +--rw network-id network-id 372 +--rw supporting-network* [network-ref] 373 | +--rw network-ref -> /networks/network/network-id 374 +--rw node* [node-id] 375 +--rw node-id node-id 376 +--rw supporting-node* [network-ref node-ref] 377 +--rw network-ref -> ../../../supporting-network/ + 378 | network-ref 379 +--rw node-ref -> /networks/network/node/node-id 381 Figure 4: The structure of the abstract (base) network model 383 The model contains a container with a list of networks. Each network 384 is captured in its own list entry, distinguished via a network-id. 386 A network has a certain type, such as L2, L3, OSPF or IS-IS. A 387 network can even have multiple types simultaneously. The type, or 388 types, are captured underneath the container "network-types". In 389 this module it serves merely as an augmentation target; network- 390 specific modules will later introduce new data nodes to represent new 391 network types below this target, i.e. insert them below "network- 392 types" by ways of YANG augmentation. 394 When a network is of a certain type, it will contain a corresponding 395 data node. Network types SHOULD always be represented using presence 396 containers, not leafs of empty type. This allows to represent 397 hierarchies of network subtypes within the instance information. For 398 example, an instance of an OSPF network (which, at the same time, is 399 a layer 3 unicast IGP network) would contain underneath "network- 400 types" another container "l3-unicast-igp-network", which in turn 401 would contain a container "ospf-network". 403 A network can in turn be part of a hierarchy of networks, building on 404 top of other networks. Any such networks are captured in the list 405 "supporting-network". A supporting network is in effect an underlay 406 network. 408 Furthermore, a network contains an inventory of nodes that are part 409 of the network. The nodes of a network are captured in their own 410 list. Each node is identified relative to its containing network by 411 a node-id. 413 It should be noted that a node does not exist independently of a 414 network; instead it is a part of the network that it is contained in. 415 In cases where the same entity takes part in multiple networks, or at 416 multiple layers of a networking stack, the same entity will be 417 represented by multiple nodes, one for each network. In other words, 418 the node represents an abstraction of the device for the particular 419 network that it a is part of. To represent that the same entity or 420 same device is part of multiple topologies or networks, it is 421 possible to create one "physical" network with a list of nodes for 422 each of the devices or entities. This (physical) network, 423 respectively the (entities) nodes in that network, can then be 424 referred to as underlay network and nodes from the other (logical) 425 networks and nodes, respectively. Note that the model allows to 426 define more than one underlay network (and node), allowing for 427 simultaneous representation of layered network- and service 428 topologies and physical instantiation. 430 Similar to a network, a node can be supported by other nodes, and map 431 onto one or more other nodes in an underlay network. This is 432 captured in the list "supporting-node". The resulting hierarchy of 433 nodes allows also to represent device stacks, where a node at one 434 level is supported by a set of nodes at an underlying level. For 435 example, a "router" node might be supported by a node representing a 436 route processor and separate nodes for various line cards and service 437 modules, a virtual router might be supported or hosted on a physical 438 device represented by a separate node, and so on. 440 Network data of a network at a particular layer can come into being 441 in one of two ways. In one way, network data is configured by client 442 applications, for example in case of overlay networks that are 443 configured by an SDN Controller application. In another way, it is 444 automatically populated by the server, in case of networks that can 445 be discovered. It is possible for a configured (overlay) network to 446 refer to a (discovered) underlay network. 448 The revised datastore architecture 449 [I-D.draft-ietf-netmod-revised-datastores] is used to account for 450 those possibilities. Specifically, for each network, the origin of 451 its data is indicated per the origin metadata annotation - "intended" 452 for data that was configured by a client application, "learned" for 453 data that is discovered. Network data that is discovered is 454 automatically populated as part of the operational datastore. 455 Network data that is configured is part of the configuration and 456 intended datastores, respectively. Configured network data that is 457 actually in effect is in addition reflected in the operational 458 datastore. Data in the operational datastore will always have 459 complete referential integrity. Should a configured data item (such 460 as a node) have a dangling reference that refers to a non-existing 461 data item (such as a supporting node), the configured data item will 462 automatically be removed from the operational datastore and show up 463 only in the intended datastore. It will be up to the client 464 application to resolve the situation and ensure that the reference to 465 the supporting resources is configured properly. 467 4.2. Base Network Topology Model 469 The abstract (base) network topology model is defined in the 470 "network-topology.yang" module. It builds on the network model 471 defined in the "network.yang" module, augmenting it with links 472 (defining how nodes are connected) and termination-points (which 473 anchor the links and are contained in nodes). The structure of the 474 network topology module is shown in the following figure. Brackets 475 enclose list keys, "rw" means configuration data, "ro" means 476 operational state data, and "?" designates optional nodes. A "+" 477 indicates a line break. 479 module: ietf-network-topology 480 augment /nd:networks/nd:network: 481 +--rw link* [link-id] 482 +--rw source 483 | +--rw source-node? -> ../../../nd:node/node-id 484 | +--rw source-tp? -> ../../../nd:node[nd:node-id=current()/+ 485 | ../source-node]/termination-point/tp-id 486 +--rw destination 487 | +--rw dest-node? -> ../../../nd:node/node-id 488 | +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+ 489 | ../dest-node]/termination-point/tp-id 490 +--rw link-id link-id 491 +--rw supporting-link* [network-ref link-ref] 492 +--rw network-ref -> ../../../nd:supporting-network/+ 493 | network-ref 494 +--rw link-ref -> /nd:networks/network+ 495 [nd:network-id=current()/../network-ref]/+ 496 link/link-id 497 augment /nd:networks/nd:network/nd:node: 498 +--rw termination-point* [tp-id] 499 +--rw tp-id tp-id 500 +--rw supporting-termination-point* [network-ref node-ref tp-ref] 501 +--rw network-ref -> ../../../nd:supporting-node/network-ref 502 +--rw node-ref -> ../../../nd:supporting-node/node-ref 503 +--rw tp-ref -> /nd:networks/network[nd:network-id=+ 504 current()/../network-ref]/node+ 505 [nd:node-id=current()/../node-ref]/+ 506 termination-point/tp-id 508 Figure 5: The structure of the abstract (base) network topology model 509 A node has a list of termination points that are used to terminate 510 links. An example of a termination point might be a physical or 511 logical port or, more generally, an interface. 513 Like a node, a termination point can in turn be supported by an 514 underlying termination point, contained in the supporting node of the 515 underlay network. 517 A link is identified by a link-id that uniquely identifies the link 518 within a given topology. Links are point-to-point and 519 unidirectional. Accordingly, a link contains a source and a 520 destination. Both source and destination reference a corresponding 521 node, as well as a termination point on that node. Similar to a 522 node, a link can map onto one or more links in an underlay topology 523 (which are terminated by the corresponding underlay termination 524 points). This is captured in the list "supporting-link". 526 4.3. Extending the model 528 In order to derive a model for a specific type of network, the base 529 model can be extended. This can be done roughly as follows: for the 530 new network type, a new YANG module is introduced. In this module, a 531 number of augmentations are defined against the network and network- 532 topology YANG modules. 534 We start with augmentations against the network.yang module. First, 535 a new network type needs to be defined. For this, a presence 536 container that resembles the new network type is defined. It is 537 inserted by means of augmentation below the network-types container. 538 Subsequently, data nodes for any network-type specific node 539 parameters are defined and augmented into the node list. The new 540 data nodes can be defined as conditional ("when") on the presence of 541 the corresponding network type in the containing network. In cases 542 where there are any requirements or restrictions in terms of network 543 hierarchies, such as when a network of a new network-type requires a 544 specific type of underlay network, it is possible to define 545 corresponding constraints as well and augment the supporting-network 546 list accordingly. However, care should be taken to avoid excessive 547 definitions of constraints. 549 Subsequently, augmentations are defined against network- 550 topology.yang. Data nodes are defined both for link parameters, as 551 well as termination point parameters, that are specific to the new 552 network type. Those data nodes are inserted by way of augmentation 553 into the link and termination-point lists, respectively. Again, data 554 nodes can be defined as conditional on the presence of the 555 corresponding network-type in the containing network, by adding a 556 corresponding "when"-statement. 558 It is possible, but not required, to group data nodes for a given 559 network-type under a dedicated container. Doing so introduces 560 further structure, but lengthens data node path names. 562 In cases where a hierarchy of network types is defined, augmentations 563 can in turn against augmenting modules, with the module of a network 564 "sub-type" augmenting the module of a network "super-type". 566 4.4. Discussion and selected design decisions 568 4.4.1. Container structure 570 Rather than maintaining lists in separate containers, the model is 571 kept relatively flat in terms of its containment structure. Lists of 572 nodes, links, termination-points, and supporting-nodes, supporting- 573 links, and supporting-termination-points are not kept in separate 574 containers. Therefore, path specifiers used to refer to specific 575 nodes, be it in management operations or in specifications of 576 constraints, can remain relatively compact. Of course, this means 577 there is no separate structure in instance information that separates 578 elements of different lists from one another. Such structure is 579 semantically not required, although it might enhance human 580 readability in some cases. 582 4.4.2. Underlay hierarchies and mappings 584 To minimize assumptions of what a particular entity might actually 585 represent, mappings between networks, nodes, links, and termination 586 points are kept strictly generic. For example, no assumptions are 587 made whether a termination point actually refers to an interface, or 588 whether a node refers to a specific "system" or device; the model at 589 this generic level makes no provisions for that. 591 Where additional specifics about mappings between upper and lower 592 layers are required, those can be captured in augmenting modules. 593 For example, to express that a termination point in a particular 594 network type maps to an interface, an augmenting module can introduce 595 an augmentation to the termination point which introduces a leaf of 596 type ifref that references the corresponding interface [RFC7223]. 597 Similarly, if a node maps to a particular device or network element, 598 an augmenting module can augment the node data with a leaf that 599 references the network element. 601 It is possible for links at one level of a hierarchy to map to 602 multiple links at another level of the hierarchy. For example, a VPN 603 topology might model VPN tunnels as links. Where a VPN tunnel maps 604 to a path that is composed of a chain of several links, the link will 605 contain a list of those supporting links. Likewise, it is possible 606 for a link at one level of a hierarchy to aggregate a bundle of links 607 at another level of the hierarchy. 609 4.4.3. Dealing with changes in underlay networks 611 It is possible for a network to undergo churn even as other networks 612 are layered on top of it. When a supporting node, link, or 613 termination point is deleted, the supporting leafrefs in the overlay 614 will be left dangling. To allow for this possibility, the model 615 makes use of the "require-instance" construct of YANG 1.1 [RFC7950]. 617 A dangling leafref of a configured object leaves the corresponding 618 instance in a state in which it lacks referential integrity, 619 rendering it in effect inoperational. Any corresponding object 620 instance is therefore removed from the operational datastore until 621 the situation has been resolved, i.e. until either the supporting 622 object is added to the operational datastore, or until the instance 623 is reconfigured to refer to another object that is actually reflected 624 in the operational datastore. It does remain part of the intended 625 datastore. 627 It is the responsibility of the application maintaining the overlay 628 to deal with the possibility of churn in the underlay network. When 629 a server receives a request to configure an overlay network, it 630 SHOULD validate whether supporting nodes/links/tps refer to nodes in 631 the underlay are actually in existence, i.e. nodes which are 632 reflected in the operational datastore. Configuration requests in 633 which supporting nodes/links/tps refer to objects currently not in 634 existence SHOULD be rejected. It is the responsibility of the 635 application to update the overlay when a supporting node/link/tp is 636 deleted at a later point in time. For this purpose, an application 637 might subscribe to updates when changes to the underlay occur, for 638 example using mechanisms defined in 639 [I-D.draft-ietf-netconf-yang-push]. 641 4.4.4. Use of groupings 643 The model makes use of groupings, instead of simply defining data 644 nodes "in-line". This allows to more easily include the 645 corresponding data nodes in notifications, which then do not need to 646 respecify each data node that is to be included. The tradeoff for 647 this is that it makes the specification of constraints more complex, 648 because constraints involving data nodes outside the grouping need to 649 be specified in conjunction with a "uses" statement where the 650 grouping is applied. This also means that constraints and XPath- 651 statements need to specified in such a way that they navigate "down" 652 first and select entire sets of nodes, as opposed to being able to 653 simply specify them against individual data nodes. 655 4.4.5. Cardinality and directionality of links 657 The topology model includes links that are point-to-point and 658 unidirectional. It does not directly support multipoint and 659 bidirectional links. While this may appear as a limitation, it does 660 keep the model simple, generic, and allows it to very easily be 661 subjected to applications that make use of graph algorithms. Bi- 662 directional connections can be represented through pairs of 663 unidirectional links. Multipoint networks can be represented through 664 pseudo-nodes (similar to IS-IS, for example). By introducing 665 hierarchies of nodes, with nodes at one level mapping onto a set of 666 other nodes at another level, and introducing new links for nodes at 667 that level, topologies with connections representing non-point-to- 668 point communication patterns can be represented. 670 4.4.6. Multihoming and link aggregation 672 Links are terminated by a single termination point, not sets of 673 termination points. Connections involving multihoming or link 674 aggregation schemes need to be represented using multiple point-to- 675 point links, then defining a link at a higher layer that is supported 676 by those individual links. 678 4.4.7. Mapping redundancy 680 In a hierarchy of networks, there are nodes mapping to nodes, links 681 mapping to links, and termination points mapping to termination 682 points. Some of this information is redundant. Specifically, if the 683 link-to-links mapping known, and the termination points of each link 684 known, termination point mapping information can be derived via 685 transitive closure and does not have to be explicitly configured. 686 Nonetheless, in order to not constrain applications regarding which 687 mappings they want to configure and which should be derived, the 688 model does provide for the option to configure this information 689 explicitly. The model includes integrity constraints to allow for 690 validating for consistency. 692 4.4.8. Typing 694 A network's network types are represented using a container which 695 contains a data node for each of its network types. A network can 696 encompass several types of network simultaneously, hence a container 697 is used instead of a case construct, with each network type in turn 698 represented by a dedicated presence container itself. The reason for 699 not simply using an empty leaf, or even simpler, do away even with 700 the network container and just use a leaf-list of network-type 701 instead, is to be able to represent "class hierarchies" of network 702 types, with one network type refining the other. Network-type 703 specific containers are to be defined in the network-specific 704 modules, augmenting the network-types container. 706 4.4.9. Representing the same device in multiple networks 708 One common requirement concerns the ability to represent that the 709 same device can be part of multiple networks and topologies. 710 However, the model defines a node as relative to the network that it 711 is contained in. The same node cannot be part of multiple 712 topologies. In many cases, a node will be the abstraction of a 713 particular device in a network. To reflect that the same device is 714 part of multiple topologies, the following approach might be chosen: 715 A new type of network to represent a "physical" (or "device") network 716 is introduced, with nodes representing devices. This network forms 717 an underlay network for logical networks above it, with nodes of the 718 logical network mapping onto nodes in the physical network. 720 This scenario is depicted in the following figure. It depicts three 721 networks with two nodes each. A physical network P consists of an 722 inventory of two nodes, D1 and D2, each representing a device. A 723 second network, X, has a third network, Y, as its underlay. Both X 724 and Y also have the physical network P as underlay. X1 has both Y1 725 and D1 as underlay nodes, while Y1 has D1 as underlay node. 726 Likewise, X2 has both Y2 and D2 as underlay nodes, while Y2 has D2 as 727 underlay node. The fact that X1 and Y1 are both instantiated on the 728 same physical node D1 can be easily derived. 730 +---------------------+ 731 / [X1]____[X2] / X(Service Overlay) 732 +----:--:----:--------+ 733 ..: :..: : 734 ........: ....: : :.... 735 +-----:-------------:--+ : :... 736 / [Y1]____[Y2]....: / :.. : 737 +------|-------|-------+ :.. :... 738 Y(L3) | +---------------------:-----+ : 739 | +----:----|-:----------+ 740 +------------------------/---[D1] [D2] / 741 +----------------------+ 742 P (Physical network) 744 Figure 6: Topology hierarchy example - multiple underlays 746 In the case of a physical network, nodes represent physical devices 747 and termination points physical ports. It should be noted that it is 748 also conceivable to augment the model for a physical network-type, 749 defining augmentations that have nodes reference system information 750 and termination points reference physical interfaces, in order to 751 provide a bridge between network and device models. 753 4.4.10. Supporting client-configured and server-provided network 754 topology 756 YANG requires data nodes to be designated as either configuration or 757 operational data, but not both, yet it is important to have all 758 network information, including vertical cross-network dependencies, 759 captured in one coherent model. In most cases, network topology 760 information is discovered about a network; the topology is considered 761 a property of the network that is reflected in the model. That said, 762 certain types of topology need to also be configurable by an 763 application, such as in the case of overlay topologies. 765 Network topology data that is discovered is automatically populated 766 as part of the operational datastore. Network topology that is 767 configured is instantiated as part of a configuration datastore, e.g. 768 the datastore. Only when it has actually taken effect, it 769 is also instantiated as part of the operational datastore. 771 Configured network topology will in general refer to an underlay 772 topology and include layering information, such as the supporting 773 node(s) underlying a node, supporting link(s) underlying a link, and 774 supporting termination point(s) underlying a termination point. The 775 supporting objects must be instantiated in the operational datastore 776 in order for the dependent overlay object to be reflected in the 777 operational datastore. Should a configured data item (such as a 778 node) have a dangling reference that refers to a non-existing data 779 item (such as a supporting node), the configured data item will 780 automatically be removed from the operational datastore and show up 781 only in the intended datastore. It will be up to the client 782 application to resolve the situation and ensure that the reference to 783 the supporting resources is configured properly. 785 For each network, the origin of its data is indicated per the 786 "origin" metadata annotation defined in 787 [I-D.draft-ietf-netmod-revised-datastores]. In general, the origin 788 of discovered network data is "learned"; the origin of configured 789 network data is "intended". 791 4.4.11. Identifiers of string or URI type 793 The current model defines identifiers of nodes, networks, links, and 794 termination points as URIs. An alternative would define them as 795 string. 797 The case for strings is that they will be easier to implement. The 798 reason for choosing URIs is that the topology/node/tp exists in a 799 larger context, hence it is useful to be able to correlate 800 identifiers across systems. While strings, being the universal data 801 type, are easier for human beings (a string is a string is a string), 802 they also muddle things. What typically happens is that strings have 803 some structure which is magically assigned and the knowledge of this 804 structure has to be communicated to each system working with the 805 data. A URI makes the structure explicit and also attaches 806 additional semantics: the URI, unlike a free-form string, can be fed 807 into a URI resolver, which can point to additional resources 808 associated with the URI. This property is important when the 809 topology data is integrated into a larger, more complex system. 811 5. Interactions with Other YANG Modules 813 The model makes use of data types that have been defined in 814 [RFC6991]. 816 This is a protocol independent yang model with topology information. 817 It is separate from and not linked with data models that are used to 818 configure routing protocols or routing information. This includes 819 e.g. model "ietf-routing" [RFC8022]. 821 The model obeys the requirements for the ephemeral state found in the 822 document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral 823 topology data that is server provided, the process tasked with 824 maintaining topology information will load information from the 825 routing process (such as OSPF) into the data model without relying on 826 a configuration datastore. 828 6. YANG Modules 830 6.1. Defining the Abstract Network: network.yang 832 file "ietf-network@2017-06-30.yang" 833 module ietf-network { 834 yang-version 1.1; 835 namespace "urn:ietf:params:xml:ns:yang:ietf-network"; 836 prefix nd; 838 import ietf-inet-types { 839 prefix inet; 840 } 842 organization 843 "IETF I2RS (Interface to the Routing System) Working Group"; 845 contact 846 "WG Web: 847 WG List: 849 WG Chair: Susan Hares 850 852 WG Chair: Russ White 853 855 Editor: Alexander Clemm 856 858 Editor: Jan Medved 859 861 Editor: Robert Varga 862 864 Editor: Nitin Bahadur 865 867 Editor: Hariharan Ananthakrishnan 868 870 Editor: Xufeng Liu 871 "; 873 description 874 "This module defines a common base model for a collection 875 of nodes in a network. Node definitions are further used 876 in network topologies and inventories. 878 Copyright (c) 2017 IETF Trust and the persons identified as 879 authors of the code. All rights reserved. 881 Redistribution and use in source and binary forms, with or 882 without modification, is permitted pursuant to, and subject 883 to the license terms contained in, the Simplified BSD License 884 set forth in Section 4.c of the IETF Trust's Legal Provisions 885 Relating to IETF Documents 886 (http://trustee.ietf.org/license-info). 888 This version of this YANG module is part of 889 draft-ietf-i2rs-yang-network-topo-14; 890 see the RFC itself for full legal notices. 892 NOTE TO RFC EDITOR: Please replace above reference to 893 draft-ietf-i2rs-yang-network-topo-14 with RFC 894 number when published (i.e. RFC xxxx)."; 896 revision 2017-06-30 { 897 description 898 "Initial revision. 899 NOTE TO RFC EDITOR: Please replace the following reference 900 to draft-ietf-i2rs-yang-network-topo-14 with 901 RFC number when published (i.e. RFC xxxx)."; 902 reference 903 "draft-ietf-i2rs-yang-network-topo-14"; 904 } 906 typedef node-id { 907 type inet:uri; 908 description 909 "Identifier for a node. The precise structure of the node-id 910 will be up to the implementation. Some implementations MAY 911 for example, pick a uri that includes the network-id as 912 part of the path. The identifier SHOULD be chosen such that 913 the same node in a real network topology will always be 914 identified through the same identifier, even if the model is 915 instantiated in separate datastores. An implementation MAY 916 choose to capture semantics in the identifier, for example to 917 indicate the type of node."; 918 } 920 typedef network-id { 921 type inet:uri; 922 description 923 "Identifier for a network. The precise structure of the 924 network-id will be up to an implementation. 925 The identifier SHOULD be chosen such that the same network 926 will always be identified through the same identifier, 927 even if the model is instantiated in separate datastores. 928 An implementation MAY choose to capture semantics in the 929 identifier, for example to indicate the type of network."; 930 } 932 grouping network-ref { 933 description 934 "Contains the information necessary to reference a network, 935 for example an underlay network."; 936 leaf network-ref { 937 type leafref { 938 path "/nd:networks/nd:network/nd:network-id"; 939 require-instance false; 940 } 941 description 942 "Used to reference a network, for example an underlay 943 network."; 944 } 945 } 947 grouping node-ref { 948 description 949 "Contains the information necessary to reference a node."; 950 leaf node-ref { 951 type leafref { 952 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 953 "network-ref]/nd:node/nd:node-id"; 954 require-instance false; 955 } 956 description 957 "Used to reference a node. 958 Nodes are identified relative to the network they are 959 contained in."; 960 } 961 uses network-ref; 962 } 964 container networks { 965 description 966 "Serves as top-level container for a list of networks."; 967 list network { 968 key "network-id"; 969 description 970 "Describes a network. 971 A network typically contains an inventory of nodes, 972 topological information (augmented through 973 network-topology model), as well as layering 974 information."; 975 container network-types { 976 description 977 "Serves as an augmentation target. 978 The network type is indicated through corresponding 979 presence containers augmented into this container."; 980 } 981 leaf network-id { 982 type network-id; 983 description 984 "Identifies a network."; 985 } 986 list supporting-network { 987 key "network-ref"; 988 description 989 "An underlay network, used to represent layered network 990 topologies."; 991 leaf network-ref { 992 type leafref { 993 path "/networks/network/network-id"; 994 require-instance false; 995 } 996 description 997 "References the underlay network."; 998 } 999 } 1000 list node { 1001 key "node-id"; 1002 description 1003 "The inventory of nodes of this network."; 1004 leaf node-id { 1005 type node-id; 1006 description 1007 "Identifies a node uniquely within the containing 1008 network."; 1009 } 1010 list supporting-node { 1011 key "network-ref node-ref"; 1012 description 1013 "Represents another node, in an underlay network, that 1014 this node is supported by. Used to represent layering 1015 structure."; 1016 leaf network-ref { 1017 type leafref { 1018 path "../../../supporting-network/network-ref"; 1019 require-instance false; 1020 } 1021 description 1022 "References the underlay network that the 1023 underlay node is part of."; 1024 } 1025 leaf node-ref { 1026 type leafref { 1027 path "/networks/network/node/node-id"; 1028 require-instance false; 1029 } 1030 description 1031 "References the underlay node itself."; 1032 } 1033 } 1034 } 1035 } 1036 } 1038 } 1040 1042 6.2. Creating Abstract Network Topology: network-topology.yang 1044 file "ietf-network-topology@2017-06-30.yang" 1045 module ietf-network-topology { 1046 yang-version 1.1; 1047 namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; 1048 prefix lnk; 1050 import ietf-inet-types { 1051 prefix inet; 1052 } 1053 import ietf-network { 1054 prefix nd; 1055 } 1057 organization 1058 "IETF I2RS (Interface to the Routing System) Working Group"; 1060 contact 1061 "WG Web: 1062 WG List: 1064 WG Chair: Susan Hares 1065 1067 WG Chair: Russ White 1068 1070 Editor: Alexander Clemm 1071 1073 Editor: Jan Medved 1074 1076 Editor: Robert Varga 1077 1079 Editor: Nitin Bahadur 1080 1082 Editor: Hariharan Ananthakrishnan 1083 1085 Editor: Xufeng Liu 1086 "; 1088 description 1089 "This module defines a common base model for network topology, 1090 augmenting the base network model with links to connect nodes, 1091 as well as termination points to terminate links on nodes. 1093 Copyright (c) 2017 IETF Trust and the persons identified as 1094 authors of the code. All rights reserved. 1096 Redistribution and use in source and binary forms, with or 1097 without modification, is permitted pursuant to, and subject 1098 to the license terms contained in, the Simplified BSD License 1099 set forth in Section 4.c of the IETF Trust's Legal Provisions 1100 Relating to IETF Documents 1101 (http://trustee.ietf.org/license-info). 1103 This version of this YANG module is part of 1104 draft-ietf-i2rs-yang-network-topo-14; 1105 see the RFC itself for full legal notices. 1107 NOTE TO RFC EDITOR: Please replace above reference to 1108 draft-ietf-i2rs-yang-network-topo-14 with RFC 1109 number when published (i.e. RFC xxxx)."; 1111 revision 2017-06-30 { 1112 description 1113 "Initial revision. 1114 NOTE TO RFC EDITOR: Please replace the following reference 1115 to draft-ietf-i2rs-yang-network-topo-14 with 1116 RFC number when published (i.e. RFC xxxx)."; 1117 reference 1118 "draft-ietf-i2rs-yang-network-topo-14"; 1119 } 1121 typedef link-id { 1122 type inet:uri; 1123 description 1124 "An identifier for a link in a topology. 1125 The precise structure of the link-id 1126 will be up to the implementation. 1127 The identifier SHOULD be chosen such that the same link in a 1128 real network topology will always be identified through the 1129 same identifier, even if the model is instantiated in 1130 separate datastores. An implementation MAY choose to capture 1131 semantics in the identifier, for example to indicate the type 1132 of link and/or the type of topology that the link is a part 1133 of."; 1135 } 1137 typedef tp-id { 1138 type inet:uri; 1139 description 1140 "An identifier for termination points (TPs) on a node. 1141 The precise structure of the tp-id 1142 will be up to the implementation. 1143 The identifier SHOULD be chosen such that the same termination 1144 point in a real network topology will always be identified 1145 through the same identifier, even if the model is instantiated 1146 in separate datastores. An implementation MAY choose to 1147 capture semantics in the identifier, for example to indicate 1148 the type of termination point and/or the type of node 1149 that contains the termination point."; 1150 } 1152 grouping link-ref { 1153 description 1154 "References a link in a specific network."; 1155 leaf link-ref { 1156 type leafref { 1157 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1158 "network-ref]/lnk:link/lnk:link-id"; 1159 require-instance false; 1160 } 1161 description 1162 "A type for an absolute reference a link instance. 1163 (This type should not be used for relative references. 1164 In such a case, a relative path should be used instead.)"; 1165 } 1166 uses nd:network-ref; 1167 } 1169 grouping tp-ref { 1170 description 1171 "References a termination point in a specific node."; 1172 leaf tp-ref { 1173 type leafref { 1174 path "/nd:networks/nd:network[nd:network-id=current()/../"+ 1175 "network-ref]/nd:node[nd:node-id=current()/../"+ 1176 "node-ref]/lnk:termination-point/lnk:tp-id"; 1177 require-instance false; 1178 } 1179 description 1180 "A type for an absolute reference to a termination point. 1181 (This type should not be used for relative references. 1182 In such a case, a relative path should be used instead.)"; 1184 } 1185 uses nd:node-ref; 1186 } 1188 augment "/nd:networks/nd:network" { 1189 description 1190 "Add links to the network model."; 1191 list link { 1192 key "link-id"; 1193 description 1194 "A network link connects a local (source) node and 1195 a remote (destination) node via a set of 1196 the respective node's termination points. 1197 It is possible to have several links between the same 1198 source and destination nodes. Likewise, a link could 1199 potentially be re-homed between termination points. 1200 Therefore, in order to ensure that we would always know 1201 to distinguish between links, every link is identified by 1202 a dedicated link identifier. Note that a link models a 1203 point-to-point link, not a multipoint link."; 1204 container source { 1205 description 1206 "This container holds the logical source of a particular 1207 link."; 1208 leaf source-node { 1209 type leafref { 1210 path "../../../nd:node/nd:node-id"; 1211 require-instance false; 1212 } 1213 description 1214 "Source node identifier, must be in same topology."; 1215 } 1216 leaf source-tp { 1217 type leafref { 1218 path "../../../nd:node[nd:node-id=current()/../"+ 1219 "source-node]/termination-point/tp-id"; 1220 require-instance false; 1221 } 1222 description 1223 "Termination point within source node that terminates 1224 the link."; 1225 } 1226 } 1227 container destination { 1228 description 1229 "This container holds the logical destination of a 1230 particular link."; 1231 leaf dest-node { 1232 type leafref { 1233 path "../../../nd:node/nd:node-id"; 1234 require-instance false; 1235 } 1236 description 1237 "Destination node identifier, must be in the same 1238 network."; 1239 } 1240 leaf dest-tp { 1241 type leafref { 1242 path "../../../nd:node[nd:node-id=current()/../"+ 1243 "dest-node]/termination-point/tp-id"; 1244 require-instance false; 1245 } 1246 description 1247 "Termination point within destination node that 1248 terminates the link."; 1249 } 1250 } 1251 leaf link-id { 1252 type link-id; 1253 description 1254 "The identifier of a link in the topology. 1255 A link is specific to a topology to which it belongs."; 1256 } 1257 list supporting-link { 1258 key "network-ref link-ref"; 1259 description 1260 "Identifies the link, or links, that this link 1261 is dependent on."; 1262 leaf network-ref { 1263 type leafref { 1264 path "../../../nd:supporting-network/nd:network-ref"; 1265 require-instance false; 1266 } 1267 description 1268 "This leaf identifies in which underlay topology 1269 the supporting link is present."; 1270 } 1271 leaf link-ref { 1272 type leafref { 1273 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1274 "../network-ref]/link/link-id"; 1275 require-instance false; 1276 } 1277 description 1278 "This leaf identifies a link which is a part 1279 of this link's underlay. Reference loops in which 1280 a link identifies itself as its underlay, either 1281 directly or transitively, are not allowed."; 1282 } 1283 } 1284 } 1285 } 1286 augment "/nd:networks/nd:network/nd:node" { 1287 description 1288 "Augment termination points which terminate links. 1289 Termination points can ultimately be mapped to interfaces."; 1290 list termination-point { 1291 key "tp-id"; 1292 description 1293 "A termination point can terminate a link. 1294 Depending on the type of topology, a termination point 1295 could, for example, refer to a port or an interface."; 1296 leaf tp-id { 1297 type tp-id; 1298 description 1299 "Termination point identifier."; 1300 } 1301 list supporting-termination-point { 1302 key "network-ref node-ref tp-ref"; 1303 description 1304 "This list identifies any termination points that 1305 the termination point is dependent on, or maps onto. 1306 Those termination points will themselves be contained 1307 in a supporting node. 1308 This dependency information can be inferred from 1309 the dependencies between links. For this reason, 1310 this item is not separately configurable. Hence no 1311 corresponding constraint needs to be articulated. 1312 The corresponding information is simply provided by the 1313 implementing system."; 1314 leaf network-ref { 1315 type leafref { 1316 path "../../../nd:supporting-node/nd:network-ref"; 1317 require-instance false; 1318 } 1319 description 1320 "This leaf identifies in which topology the 1321 supporting termination point is present."; 1322 } 1323 leaf node-ref { 1324 type leafref { 1325 path "../../../nd:supporting-node/nd:node-ref"; 1326 require-instance false; 1327 } 1328 description 1329 "This leaf identifies in which node the supporting 1330 termination point is present."; 1331 } 1332 leaf tp-ref { 1333 type leafref { 1334 path "/nd:networks/nd:network[nd:network-id=current()/"+ 1335 "../network-ref]/nd:node[nd:node-id=current()/../"+ 1336 "node-ref]/termination-point/tp-id"; 1337 require-instance false; 1338 } 1339 description 1340 "Reference to the underlay node, must be in a 1341 different topology"; 1342 } 1343 } 1344 } 1345 } 1346 } 1348 1350 7. IANA Considerations 1352 This document registers the following namespace URIs in the "IETF XML 1353 Registry" [RFC3688]: 1355 URI: urn:ietf:params:xml:ns:yang:ietf-network 1356 Registrant Contact: The IESG. 1357 XML: N/A; the requested URI is an XML namespace. 1359 URI:urn:ietf:params:xml:ns:yang:ietf-network-topology 1360 Registrant Contact: The IESG. 1361 XML: N/A; the requested URI is an XML namespace. 1363 URI: urn:ietf:params:xml:ns:yang:ietf-network-state 1364 Registrant Contact: The IESG. 1365 XML: N/A; the requested URI is an XML namespace. 1367 URI:urn:ietf:params:xml:ns:yang:ietf-network-topology-state 1368 Registrant Contact: The IESG. 1369 XML: N/A; the requested URI is an XML namespace. 1371 This document registers the following YANG modules in the "YANG 1372 Module Names" registry [RFC6020]: 1374 Name: ietf-network 1375 Namespace: urn:ietf:params:xml:ns:yang:ietf-network 1376 Prefix: nd 1377 Reference: draft-ietf-i2rs-yang-network-topo-14.txt (RFC form) 1379 Name: ietf-network-topology 1380 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology 1381 Prefix: lnk 1382 Reference: draft-ietf-i2rs-yang-network-topo-14.txt (RFC form) 1384 Name: ietf-network-state 1385 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state 1386 Prefix: nd-s 1387 Reference: draft-ietf-i2rs-yang-network-topo-14.txt (RFC form) 1389 Name: ietf-network-topology-state 1390 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state 1391 Prefix: lnk-s 1392 Reference: draft-ietf-i2rs-yang-network-topo-14.txt (RFC form) 1394 8. Security Considerations 1396 The YANG module defined in this memo is independent of a particular 1397 protocol and can be accessed via a number of protocols that need to 1398 access YANG-defined data. This includes but is not limited to the 1399 NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure 1400 transport layer and the mandatory-to-implement secure transport is 1401 Secure Shell (SSH) [RFC6242]. 1403 The NETCONF access control model (NACM) [RFC6536] provides the means 1404 to restrict access for particular NETCONF users to a pre-configured 1405 subset of all available NETCONF protocol operations and content. 1406 However, NACM can be applied analogously also to other protocols that 1407 attempt access to YANG-defined data. In fact, it needs to be applied 1408 in the same way and should, like YANG, thus be considered independent 1409 of any particular protocol that is used to access YANG-defined data. 1410 Otherwise, access control rules defined by NACM could be very easily 1411 circumvented simply by using another access mechanism which does not 1412 enforce NACM. The alternative of mandating the introduction of 1413 mechanisms parallel to NACM that specify the same access control 1414 rules for other transports is clearly undesirable, as this would not 1415 only inhibit ease-of-use of systems that implement multiple protocols 1416 to access YANG data, but also open the specter of security holes due 1417 to inconsistencies in articulation and enforcement of rules across 1418 mechanisms that are essentially redundant. 1420 The YANG module defines information that can be configurable in 1421 certain instances, for example in the case of overlay topologies that 1422 can be created by client applications. In such cases, a malicious 1423 client could introduce topologies that are undesired. Specifically, 1424 a malicious client could attempt to remove or add a node, a link, a 1425 termination point, by creating or deleting corresponding elements in 1426 the node, link, and termination point lists, respectively. In the 1427 case of a topology that is learned, the server will automatically 1428 prohibit such misconfiguration attempts. In the case of a topology 1429 that is configured, i.e. whose origin is "intended", the undesired 1430 configuration could become effective and be reflected in the 1431 operational datastore, leading to disruption of services provided via 1432 this topology might be disrupted. For example, the topology could be 1433 "cut" or be configured in a suboptimal way, leading to increased 1434 consumption of resources in the underlay network due to resulting 1435 routing and bandwidth utilization inefficiencies. Likewise, it could 1436 lead to degradation of service levels as well as possibly disruption 1437 of service. For those reasons, it is important that the NETCONF 1438 access control model is vigorously applied to prevent topology 1439 misconfiguration by unauthorized clients. 1441 9. Contributors 1443 The model presented in this paper was contributed to by more people 1444 than can be listed on the author list. Additional contributors 1445 include: 1447 o Vishnu Pavan Beeram, Juniper 1449 o Ken Gray, Cisco 1451 o Tom Nadeau, Brocade 1453 o Tony Tkacik 1455 o Kent Watsen, Juniper 1457 o Aleksandr Zhdankin, Cisco 1459 10. Acknowledgements 1461 We wish to acknowledge the helpful contributions, comments, and 1462 suggestions that were received from Alia Atlas, Andy Bierman, Martin 1463 Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka, 1464 Carlos Pignataro, Juergen Schoenwaelder, Robert Wilton, and Xian 1465 Zhang. 1467 11. References 1468 11.1. Normative References 1470 [I-D.draft-ietf-netmod-revised-datastores] 1471 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1472 and R. Wilton, "A Revised Conceptual Model for YANG 1473 Datastores", I-D draft-ietf-netmod-revised-datastores-02, 1474 May 2017. 1476 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 1477 requirement levels", RFC 2119, March 1997. 1479 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 1480 2004. 1482 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1483 Network Configuration Protocol (NETCONF)", RFC 6020, 1484 October 2010. 1486 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1487 Bierman, "Network Configuration Protocol (NETCONF)", 1488 RFC 6241, June 2011. 1490 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1491 Shell (SSH)", RFC 6242, June 2011. 1493 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1494 Protocol (NETCONF) Access Control Model", RFC 6536, March 1495 2012. 1497 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 1498 July 2013. 1500 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 1501 RFC 7950, August 2016. 1503 11.2. Informative References 1505 [I-D.draft-ietf-i2rs-ephemeral-state] 1506 Haas, J. and S. Hares, "I2RS Ephemeral State 1507 Requirements", I-D draft-ietf-i2rs-ephemeral-state-23, 1508 November 2016. 1510 [I-D.draft-ietf-i2rs-usecase-reqs-summary] 1511 Hares, S. and M. Chen, "Summary of I2RS Use Case 1512 Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- 1513 03, November 2016. 1515 [I-D.draft-ietf-netconf-yang-push] 1516 Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., 1517 Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, 1518 "Subscribing to YANG datastore push updates", I-D draft- 1519 ietf-netconf-yang-push-06, April 2017. 1521 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1522 Dual Environments", RFC 1195, December 1990. 1524 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1526 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1527 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1528 Tunnels", RFC 3209, December 2001. 1530 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 1531 Management", RFC 7223, May 2014. 1533 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1534 RFC 7952, August 2016. 1536 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 1537 Management", RFC 8022, November 2016. 1539 Appendix A. Appendix: Model Use Cases 1541 A.1. Fetching Topology from a Network Element 1543 In its simplest form, topology is learned by a network element (e.g., 1544 a router) through its participation in peering protocols (IS-IS, BGP, 1545 etc.). This learned topology can then be exported (e.g., to an NMS) 1546 for external utilization. Typically, any network element in a domain 1547 can be queried for its topology and expected to return the same 1548 result. 1550 In a slightly more complex form, the network element may be a 1551 controller, either by nature of it having satellite or subtended 1552 devices hanging off of it, or in the more classical sense, such as 1553 special device designated to orchestrate the activities of a number 1554 of other devices (e.g., an optical controller). In this case, the 1555 controller device is logically a singleton and must be queried 1556 distinctly. 1558 It is worth noting that controllers can be built on top of 1559 controllers to establish a topology incorporating of all the domains 1560 within an entire network. 1562 In all of the cases above, the topology learned by the network 1563 element is considered to be operational state data. That is, the 1564 data is accumulated purely by the network element's interactions with 1565 other systems and is subject to change dynamically without input or 1566 consent. 1568 A.2. Modifying TE Topology Imported from an Optical Controller 1570 Consider a scenario where an Optical Transport Controller presents 1571 its topology in abstract TE Terms to a Client Packet Controller. 1572 This Customized Topology (that gets merged into the Client's native 1573 topology) contains sufficient information for the path computing 1574 client to select paths across the optical domain according to its 1575 policies. If the Client determines (at any given point in time) that 1576 this imported topology does not exactly cater to its requirements, it 1577 may decide to request modifications to the topology. Such 1578 customization requests may include addition or deletion of topoogical 1579 elements or modification of attributes associated with existing 1580 topological elements. From the perspective of the Optical 1581 Controller, these requests translate into configuration changes to 1582 the exported abstract topology. 1584 A.3. Annotating Topology for Local Computation 1586 In certain scenarios, the topology learned by a controller needs to 1587 be augmented with additional attributes before running a computation 1588 algorithm on it. Consider the case where a path-computation 1589 application on the controller needs to take the geographic 1590 coordinates of the nodes into account while computing paths on the 1591 learned topology. If the learned topology does not contain these 1592 coordinates, then these additional attributes must be configured on 1593 the corresponding topological elements. 1595 A.4. SDN Controller-Based Configuration of Overlays on Top of Underlays 1597 In this scenario, an SDN controller (for example, Open Daylight) 1598 maintains a view of the topology of the network that it controls 1599 based on information that it discovers from the network. In 1600 addition, it provides an application in which it configures and 1601 maintains an overlay topology. 1603 The SDN Controller thus maintains two roles: 1605 o It is a client to the network. 1607 o It is a server to its own northbound applications and clients, 1608 e.g. an OSS. 1610 In other words, one system's client (or controller, in this case) may 1611 be another system's server (or "uber-network device"). 1613 In this scenario, the SDN controller maintains a consolidated model 1614 of multiple layers of topology. This includes the lower layers of 1615 the network topology, built from information that is discovered from 1616 the network. It also includes upper layers of topology overlay, 1617 configurable by the controller's client, i.e. the OSS. To the OSS, 1618 the lower topology layers constitute "read-only" information. The 1619 upper topology layers need to be read-writable. 1621 Appendix B. Appendix: Companion YANG models for non-NMDA compliant 1622 implementations 1624 The YANG modules defined in this document are designed to be used in 1625 conjunction with implementations that support the Network Management 1626 Datastore Architecture (NMDA) defined in 1627 [I-D.draft-ietf-netmod-revised-datastores]. In order to allow 1628 implementations to use the model even in cases when NMDA is not 1629 supported, in the following two companion modules are defined that 1630 represent a state model of networks and network topologies. The 1631 modules, ietf-network-state and ietf-network-topology-state, mirror 1632 modules ietf-network and ietf-network-topology defined earlier in 1633 this document. However, all data nodes are non-configurable. They 1634 represent state that comes into being by either learning topology 1635 information from the network, or by applying configuration from the 1636 mirrored modules. 1638 The companion modules, ietf-network-state and ietf-network-topology- 1639 state, are redundant and SHOULD NOT be supported by implementations 1640 that support NMDA. It is for this reason that the definitions are 1641 defined in an appendix. 1643 As the structure of both modules mirrors that of their underlying 1644 modules, the YANG tree is not depicted separately. 1646 B.1. YANG Model for Network State 1648 file "ietf-network-state@2017-06-30.yang" 1649 module ietf-network-state { 1650 yang-version 1.1; 1651 namespace "urn:ietf:params:xml:ns:yang:ietf-network-state"; 1652 prefix nd-s; 1654 import ietf-network { 1655 prefix nd; 1656 } 1658 organization 1659 "IETF I2RS (Interface to the Routing System) Working Group"; 1661 contact 1662 "WG Web: 1663 WG List: 1665 WG Chair: Susan Hares 1666 1668 WG Chair: Russ White 1669 1671 Editor: Alexander Clemm 1672 1674 Editor: Jan Medved 1675 1677 Editor: Robert Varga 1678 1680 Editor: Nitin Bahadur 1681 1683 Editor: Hariharan Ananthakrishnan 1684 1686 Editor: Xufeng Liu 1687 "; 1689 description 1690 "This module defines a common base model for for a collection 1691 of nodes in a network. Node definitions are further used 1692 in network topologies and inventories. It represents 1693 information that is either learned and automatically populated, 1694 or information that results from applying configured netwok 1695 information configured per the ietf-network model, mirroring 1696 the corresponding data nodes in this model. 1698 The model mirrors ietf-network, but contains only 1699 read-only state data. The model is not needed when the 1700 underlying implementation infrastructure supports the Network 1701 Management Datastore Architecture (NMDA). 1703 Copyright (c) 2017 IETF Trust and the persons identified as 1704 authors of the code. All rights reserved. 1706 Redistribution and use in source and binary forms, with or 1707 without modification, is permitted pursuant to, and subject 1708 to the license terms contained in, the Simplified BSD License 1709 set forth in Section 4.c of the IETF Trust's Legal Provisions 1710 Relating to IETF Documents 1711 (http://trustee.ietf.org/license-info). 1713 This version of this YANG module is part of 1714 draft-ietf-i2rs-yang-network-topo-14; 1715 see the RFC itself for full legal notices. 1717 NOTE TO RFC EDITOR: Please replace above reference to 1718 draft-ietf-i2rs-yang-network-topo-14 with RFC 1719 number when published (i.e. RFC xxxx)."; 1721 revision 2017-06-30 { 1722 description 1723 "Initial revision. 1724 NOTE TO RFC EDITOR: Please replace the following reference 1725 to draft-ietf-i2rs-yang-network-topo-14 with 1726 RFC number when published (i.e. RFC xxxx)."; 1727 reference 1728 "draft-ietf-i2rs-yang-network-topo-14"; 1729 } 1731 grouping network-ref { 1732 description 1733 "Contains the information necessary to reference a network, 1734 for example an underlay network."; 1735 leaf network-ref { 1736 type leafref { 1737 path "/nd-s:networks/nd-s:network/nd-s:network-id"; 1738 require-instance false; 1739 } 1740 description 1741 "Used to reference a network, for example an underlay 1742 network."; 1743 } 1744 } 1746 grouping node-ref { 1747 description 1748 "Contains the information necessary to reference a node."; 1749 leaf node-ref { 1750 type leafref { 1751 path "/nd-s:networks/nd-s:network[nd-s:network-id=current()"+ 1752 "/../network-ref]/nd-s:node/nd-s:node-id"; 1753 require-instance false; 1754 } 1755 description 1756 "Used to reference a node. 1757 Nodes are identified relative to the network they are 1758 contained in."; 1759 } 1760 uses network-ref; 1761 } 1763 container networks { 1764 config false; 1765 description 1766 "Serves as top-level container for a list of networks."; 1767 list network { 1768 key "network-id"; 1769 description 1770 "Describes a network. 1771 A network typically contains an inventory of nodes, 1772 topological information (augmented through 1773 network-topology model), as well as layering 1774 information."; 1775 container network-types { 1776 description 1777 "Serves as an augmentation target. 1778 The network type is indicated through corresponding 1779 presence containers augmented into this container."; 1780 } 1781 leaf network-id { 1782 type nd:network-id; 1783 description 1784 "Identifies a network."; 1785 } 1786 list supporting-network { 1787 key "network-ref"; 1788 description 1789 "An underlay network, used to represent layered network 1790 topologies."; 1791 leaf network-ref { 1792 type leafref { 1793 path "/networks/network/network-id"; 1794 require-instance false; 1795 } 1796 description 1797 "References the underlay network."; 1798 } 1799 } 1800 list node { 1801 key "node-id"; 1802 description 1803 "The inventory of nodes of this network."; 1804 leaf node-id { 1805 type nd:node-id; 1806 description 1807 "Identifies a node uniquely within the containing 1808 network."; 1809 } 1810 list supporting-node { 1811 key "network-ref node-ref"; 1812 description 1813 "Represents another node, in an underlay network, that 1814 this node is supported by. Used to represent layering 1815 structure."; 1816 leaf network-ref { 1817 type leafref { 1818 path "../../../supporting-network/network-ref"; 1819 require-instance false; 1820 } 1821 description 1822 "References the underlay network that the 1823 underlay node is part of."; 1825 } 1826 leaf node-ref { 1827 type leafref { 1828 path "/networks/network/node/node-id"; 1829 require-instance false; 1830 } 1831 description 1832 "References the underlay node itself."; 1833 } 1834 } 1835 } 1836 } 1837 } 1838 } 1839 1841 B.2. YANG Model for Network Topology State 1843 file "ietf-network-topology-state@2017-06-30.yang" 1844 module ietf-network-topology-state { 1845 yang-version 1.1; 1846 namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state"; 1847 prefix lnk-s; 1849 import ietf-network-state { 1850 prefix nd-s; 1851 } 1852 import ietf-network-topology { 1853 prefix lnk; 1854 } 1856 organization 1857 "IETF I2RS (Interface to the Routing System) Working Group"; 1859 contact 1860 "WG Web: 1861 WG List: 1863 WG Chair: Susan Hares 1864 1866 WG Chair: Russ White 1867 1869 Editor: Alexander Clemm 1870 1872 Editor: Jan Medved 1873 1875 Editor: Robert Varga 1876 1878 Editor: Nitin Bahadur 1879 1881 Editor: Hariharan Ananthakrishnan 1882 1884 Editor: Xufeng Liu 1885 "; 1887 description 1888 "This module defines a common base model for network topology 1889 state, representing topology that is either learned, or topology 1890 that results from applying topology that has been configured per 1891 the ietf-network-topology model, mirroring the corresponding 1892 data nodes in this model. It augments the base network state 1893 model with links to connect nodes, as well as termination 1894 points to terminate links on nodes. 1896 The model mirrors ietf-network-topology, but contains only 1897 read-only state data. The model is not needed when the 1898 underlying implementation infrastructure supports the Network 1899 Management Datastore Architecture (NMDA). 1901 Copyright (c) 2017 IETF Trust and the persons identified as 1902 authors of the code. All rights reserved. 1904 Redistribution and use in source and binary forms, with or 1905 without modification, is permitted pursuant to, and subject 1906 to the license terms contained in, the Simplified BSD License 1907 set forth in Section 4.c of the IETF Trust's Legal Provisions 1908 Relating to IETF Documents 1909 (http://trustee.ietf.org/license-info). 1911 This version of this YANG module is part of 1912 draft-ietf-i2rs-yang-network-topo-14; 1913 see the RFC itself for full legal notices. 1915 NOTE TO RFC EDITOR: Please replace above reference to 1916 draft-ietf-i2rs-yang-network-topo-14 with RFC 1917 number when published (i.e. RFC xxxx)."; 1919 revision 2017-06-30 { 1920 description 1921 "Initial revision. 1922 NOTE TO RFC EDITOR: Please replace the following reference 1923 to draft-ietf-i2rs-yang-network-topo-14 with 1924 RFC number when published (i.e. RFC xxxx)."; 1925 reference 1926 "draft-ietf-i2rs-yang-network-topo-14"; 1927 } 1929 grouping link-ref { 1930 description 1931 "References a link in a specific network."; 1932 leaf link-ref { 1933 type leafref { 1934 path "/nd-s:networks/nd-s:network[nd-s:network-id=current()"+ 1935 "/../network-ref]/lnk-s:link/lnk-s:link-id"; 1936 require-instance false; 1937 } 1938 description 1939 "A type for an absolute reference a link instance. 1940 (This type should not be used for relative references. 1941 In such a case, a relative path should be used instead.)"; 1942 } 1943 uses nd-s:network-ref; 1944 } 1946 grouping tp-ref { 1947 description 1948 "References a termination point in a specific node."; 1949 leaf tp-ref { 1950 type leafref { 1951 path "/nd-s:networks/nd-s:network[nd-s:network-id=current()"+ 1952 "/../network-ref]/nd-s:node[nd-s:node-id=current()/../"+ 1953 "node-ref]/lnk-s:termination-point/lnk-s:tp-id"; 1954 require-instance false; 1955 } 1956 description 1957 "A type for an absolute reference to a termination point. 1958 (This type should not be used for relative references. 1959 In such a case, a relative path should be used instead.)"; 1960 } 1961 uses nd-s:node-ref; 1962 } 1964 augment "/nd-s:networks/nd-s:network" { 1965 description 1966 "Add links to the network model."; 1967 list link { 1968 key "link-id"; 1969 description 1970 "A network link connects a local (source) node and 1971 a remote (destination) node via a set of 1972 the respective node's termination points. 1973 It is possible to have several links between the same 1974 source and destination nodes. Likewise, a link could 1975 potentially be re-homed between termination points. 1976 Therefore, in order to ensure that we would always know 1977 to distinguish between links, every link is identified by 1978 a dedicated link identifier. Note that a link models a 1979 point-to-point link, not a multipoint link."; 1980 container source { 1981 description 1982 "This container holds the logical source of a particular 1983 link."; 1984 leaf source-node { 1985 type leafref { 1986 path "../../../nd-s:node/nd-s:node-id"; 1987 require-instance false; 1988 } 1989 description 1990 "Source node identifier, must be in same topology."; 1991 } 1992 leaf source-tp { 1993 type leafref { 1994 path "../../../nd-s:node[nd-s:node-id=current()/../"+ 1995 "source-node]/termination-point/tp-id"; 1996 require-instance false; 1997 } 1998 description 1999 "Termination point within source node that terminates 2000 the link."; 2001 } 2002 } 2003 container destination { 2004 description 2005 "This container holds the logical destination of a 2006 particular link."; 2007 leaf dest-node { 2008 type leafref { 2009 path "../../../nd-s:node/nd-s:node-id"; 2010 require-instance false; 2011 } 2012 description 2013 "Destination node identifier, must be in the same 2014 network."; 2015 } 2016 leaf dest-tp { 2017 type leafref { 2018 path "../../../nd-s:node[nd-s:node-id=current()/../"+ 2019 "dest-node]/termination-point/tp-id"; 2020 require-instance false; 2021 } 2022 description 2023 "Termination point within destination node that 2024 terminates the link."; 2025 } 2026 } 2027 leaf link-id { 2028 type lnk:link-id; 2029 description 2030 "The identifier of a link in the topology. 2031 A link is specific to a topology to which it belongs."; 2032 } 2033 list supporting-link { 2034 key "network-ref link-ref"; 2035 description 2036 "Identifies the link, or links, that this link 2037 is dependent on."; 2038 leaf network-ref { 2039 type leafref { 2040 path "../../../nd-s:supporting-network/nd-s:network-ref"; 2041 require-instance false; 2042 } 2043 description 2044 "This leaf identifies in which underlay topology 2045 the supporting link is present."; 2046 } 2047 leaf link-ref { 2048 type leafref { 2049 path "/nd-s:networks/nd-s:network[nd-s:network-id="+ 2050 "current()/../network-ref]/link/link-id"; 2051 require-instance false; 2052 } 2053 description 2054 "This leaf identifies a link which is a part 2055 of this link's underlay. Reference loops in which 2056 a link identifies itself as its underlay, either 2057 directly or transitively, are not allowed."; 2058 } 2059 } 2060 } 2061 } 2062 augment "/nd-s:networks/nd-s:network/nd-s:node" { 2063 description 2064 "Augment termination points which terminate links. 2066 Termination points can ultimately be mapped to interfaces."; 2067 list termination-point { 2068 key "tp-id"; 2069 description 2070 "A termination point can terminate a link. 2071 Depending on the type of topology, a termination point 2072 could, for example, refer to a port or an interface."; 2073 leaf tp-id { 2074 type lnk:tp-id; 2075 description 2076 "Termination point identifier."; 2077 } 2078 list supporting-termination-point { 2079 key "network-ref node-ref tp-ref"; 2080 description 2081 "This list identifies any termination points that 2082 the termination point is dependent on, or maps onto. 2083 Those termination points will themselves be contained 2084 in a supporting node. 2085 This dependency information can be inferred from 2086 the dependencies between links. For this reason, 2087 this item is not separately configurable. Hence no 2088 corresponding constraint needs to be articulated. 2089 The corresponding information is simply provided by the 2090 implementing system."; 2091 leaf network-ref { 2092 type leafref { 2093 path "../../../nd-s:supporting-node/nd-s:network-ref"; 2094 require-instance false; 2095 } 2096 description 2097 "This leaf identifies in which topology the 2098 supporting termination point is present."; 2099 } 2100 leaf node-ref { 2101 type leafref { 2102 path "../../../nd-s:supporting-node/nd-s:node-ref"; 2103 require-instance false; 2104 } 2105 description 2106 "This leaf identifies in which node the supporting 2107 termination point is present."; 2108 } 2109 leaf tp-ref { 2110 type leafref { 2111 path "/nd-s:networks/nd-s:network[nd-s:network-id="+ 2112 "current()/../network-ref]/nd-s:node[nd-s:node-id="+ 2113 "current()/../node-ref]/termination-point/tp-id"; 2115 require-instance false; 2116 } 2117 description 2118 "Reference to the underlay node, must be in a 2119 different topology"; 2120 } 2121 } 2122 } 2123 } 2124 } 2125 2127 Authors' Addresses 2129 Alexander Clemm 2130 Huawei 2132 EMail: ludwig@clemm.org 2134 Jan Medved 2135 Cisco 2137 EMail: jmedved@cisco.com 2139 Robert Varga 2140 Pantheon Technologies SRO 2142 EMail: robert.varga@pantheon.sk 2144 Nitin Bahadur 2145 Bracket Computing 2147 EMail: nitin_bahadur@yahoo.com 2149 Hariharan Ananthakrishnan 2150 Packet Design 2152 EMail: hari@packetdesign.com 2154 Xufeng Liu 2155 Jabil 2157 EMail: Xufeng_Liu@jabil.com