idnits 2.17.1 draft-dong-i2rs-network-inventory-00.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2015) is 3340 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6021' is defined on line 535, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-clemm-i2rs-yang-network-topo-02 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 4, 2015 March 3, 2015 7 A Data Model for Network Inventories 8 draft-dong-i2rs-network-inventory-00 10 Abstract 12 This document defines a YANG data model for network inventories. 14 Requirements Language 16 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 17 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 18 document are to be interpreted as described in RFC 2119 [RFC2119]. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 4, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Network Inventory Model Structure . . . . . . . . . . . . . . 3 56 3. Network Inventory Yang Module . . . . . . . . . . . . . . . . 4 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 60 7. Normative References . . . . . . . . . . . . . . . . . . . . 12 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 63 1. Introduction 65 This document defines the Yang [RFC6020] data model for network 66 inventory information. It augments the abstract (base) network Yang 67 model defined in [I-D.clemm-i2rs-yang-network-topo] with inventory 68 information of the network entities. This inventory model also 69 describes the protocol independent features, functions and 70 capabilities of the network entities and their components. This 71 network inventory data model may be augmented to describe detailed 72 inventory information and characteristics. 74 This network inventory data model can be used by applications in 75 several ways, such as: 77 o to obtain a complete view of the network inventory information; 79 o to enable/disable some protocol independent functions with the 80 characteristics specified in the data model; 82 o to receive notifications of the changes in the network 83 inventories. 85 The relationship between the inventory model and the abstract network 86 model is shown in the diagram below: 88 +------------------------+ 89 | | 90 | Abstract Network Model | 91 | | 92 +------------------------+ 93 | 94 +-------+-------+ 95 | | 96 V V 97 +------------+ +------------+ 98 | Abstract | | Network | 99 | Topology | | Inventory | 100 | Model | | Model | 101 +------------+ +------------+ 102 Figure 1. Relationship of network inventory model and network model 104 2. Network Inventory Model Structure 106 Network inventory refers to the network entities used in building the 107 network. Normally each network entity consists of a series of cards 108 and interfaces, both the network entity and its components have a set 109 of features and support a set of functions. Those protocol 110 independent features and functions are described in this inventory 111 model. For the interface part, some contents of the ietf-interfaces 112 module as defined in [RFC7223] are reused. 114 The structure of "network-inventory" data model is depicted in the 115 following diagram. Brackets enclose list keys, "rw" means 116 configuration data, "ro" means operational state data, "?" designates 117 optional nodes, "*" designates nodes that can have multiple 118 instances. Parentheses enclose choice and case nodes. 120 module: network-inventory 121 augment /ntw:network/ntw:node: 122 +--rw node-name? string 123 +--rw node-description? string 124 +--rw hardware-version? string 125 +--rw software-version? string 126 +--ro capability-supported* node-capability 127 +--rw capability-enabled* node-capability 128 +--rw node-status? node-status 129 +--rw power-consumption? uint32 130 +--rw card* [card-id] 131 | +--rw card-id inet:uri 132 | +--rw card-description? string 133 | +--rw card-type? identityref 134 | +--rw card-capability* card-capability 135 | +--rw admin-status? card-status 136 +--rw interface* [if-name] 137 +--rw if-name if:interface-ref 138 +--rw description? string 139 +--rw card-ref? leafref 140 +--rw if-type? identityref 141 +--rw phys-address? yang:phys-address 142 +--rw transceiver? identityref 143 +--rw throughput? uint64 144 +--rw admin-status? enumeration 145 +--ro oper-status? enumeration 147 3. Network Inventory Yang Module 149 module network-inventory { 150 yang-version 1; 151 namespace "urn:TBD:params:xml:ns:yang:network-inventory"; 152 // replace with IANA namespace when assigned 154 prefix "netinv"; 156 import ietf-yang-types { 157 prefix yang; 158 } 160 import ietf-inet-types { 161 prefix inet; 162 } 164 import ietf-interfaces { 165 prefix if; 166 } 167 import iana-if-type { 168 prefix ift; 169 } 171 import network { 172 prefix ntw; 173 } 175 organization "TBD"; 176 contact "I-D editor: jie.dong@huawei.com"; 177 description 178 "This module defines a model for the network inventory. 179 Key design considerations are as follows: 180 A network consists of a set of network nodes. 181 A network node can support a set of functions & capabilities. 182 A network node consists of a set of cards and interfaces. 183 A network node has a set of parameters to reflect its status."; 185 revision "2015-02-10" { 186 description "Initial revision"; 187 reference "TBD"; 188 } 190 /* 191 * Typedefs 192 */ 194 typedef node-capability { 195 type enumeration { 196 enum ip-unicast { 197 value 1; 198 } 199 enum ip-multicast { 200 value 2; 201 } 202 enum mpls { 203 value 3; 204 } 205 enum mpls-traffic-engineering { 206 value 4; 207 } 208 enum ethernet-bridging { 209 value 5; 210 } 211 enum cgn { 212 value 6; 213 } 215 } 216 } 218 typedef node-status { 219 type enumeration { 220 enum other { 221 value 0; 222 } 223 enum operating { 224 value 1; 225 } 226 enum idle { 227 value 2; 228 } 229 enum dormant { 230 value 3; 231 } 232 } 233 } 235 typedef card-capability { 236 type enumeration { 237 enum ip-forwarding { 238 value 1; 239 } 240 enum ethernet-bridging { 241 value 2; 242 } 243 enum mpls-forwarding { 244 value 3; 245 } 246 enum traffic-accounting { 247 value 4; 248 } 249 enum caching { 250 value 5; 251 } 252 enum cgn { 253 value 6; 254 } 255 } 256 } 258 typedef card-status { 259 type enumeration { 260 enum operating { 261 value 1; 262 } 263 enum idle { 264 value 2; 265 } 266 enum dormant { 267 value 3; 268 } 269 } 270 } 272 /* 273 * Features 274 */ 276 /* 277 * Identities 278 */ 280 identity card-type { 281 description 282 "Base identity from which specific card types are 283 derived."; 284 } 286 identity control-card { 287 base card-type; 288 description 289 "control-card"; 290 } 292 identity line-card { 293 base card-type; 294 description 295 "line-card"; 296 } 298 identity fabric-card { 299 base card-type; 300 description 301 "fabric-card"; 302 } 304 identity transceiver-type { 305 description 306 "Base identity from which specific 307 transceiver types are derived."; 308 } 310 /* 311 * Data nodes 312 */ 314 augment "/ntw:network/ntw:node" { 316 leaf node-name { 317 type string; 318 description 319 "The name of the node"; 320 } 322 leaf node-description { 323 type string; 324 } 326 leaf hardware-version { 327 type string; 328 } 330 leaf software-version { 331 type string; 332 } 334 leaf-list capability-supported { 335 config false; 336 type node-capability; 337 description 338 "A list of capabilities the node can support."; 339 } 341 leaf-list capability-enabled { 342 type node-capability; 343 description 344 "A list of capabilities that has enabled."; 345 } 347 leaf node-status { 348 type node-status; 349 } 351 leaf power-consumption { 352 type uint32; 353 units "watt"; 354 } 356 list card { 357 key "card-id"; 358 leaf card-id { 359 type inet:uri; 360 } 362 leaf card-description { 363 type string; 364 description 365 "The description of the card"; 366 } 368 leaf card-type { 369 type identityref { 370 base card-type; 371 } 372 } 374 leaf-list card-capability { 375 type card-capability; 376 description 377 "A list of capabilities the card supports."; 378 } 380 leaf admin-status { 381 type card-status; 382 } 383 } //list-card 385 list interface { 386 key "if-name"; 388 leaf if-name { 389 type if:interface-ref; 390 description 391 "A reference to an interface"; 392 } 394 leaf description { 395 type string; 396 } 398 leaf card-ref { 399 type leafref { 400 path "/ntw:network/ntw:node/card/netinv:card-id"; 401 } 402 description 403 "A reference to the card which the interface belongs to."; 404 } 405 leaf if-type { 406 type identityref { 407 base ift:iana-interface-type; 408 } 409 } 411 leaf phys-address { 412 type yang:phys-address; 413 description 414 "The inteface's physical address."; 415 } 417 leaf transceiver { 418 type identityref { 419 base transceiver-type; 420 } 421 description 422 "The interface's transceiver type"; 423 } 425 leaf throughput { 426 description 427 "The maximum throughput of the interface."; 428 type uint64; 429 units "bits/second"; 430 } 432 leaf admin-status { 433 type enumeration { 434 enum up { 435 value 1; 436 description 437 "Ready to pass packets."; 438 } 439 enum down { 440 value 2; 441 description 442 "Not ready to pass packets and not in test mode."; 443 } 444 enum testing { 445 value 3; 446 description 447 "In some test mode."; 448 } 449 } 450 } 452 leaf oper-status { 453 config false; 454 type enumeration { 455 enum up { 456 value 1; 457 description 458 "Ready to pass packets."; 459 } 460 enum down { 461 value 2; 462 description 463 "The interface does not pass any packets."; 464 } 465 enum testing { 466 value 3; 467 description 468 "In some test mode. No operational packets can 469 be passed."; 470 } 471 enum unknown { 472 value 4; 473 description 474 "Status cannot be determined for some reason."; 475 } 476 enum dormant { 477 value 5; 478 description 479 "Waiting for some external event."; 480 } 481 enum not-present { 482 value 6; 483 description 484 "Some component (typically hardware) is missing."; 485 } 486 enum lower-layer-down { 487 value 7; 488 description 489 "Down due to state of lower-layer interface(s)."; 490 } 491 } 492 } 494 }//list interface 495 } 497 /* 498 * Notifications: to be added 499 */ 501 } //module 503 4. IANA Considerations 505 This document makes no request of IANA. 507 Note to RFC Editor: this section may be removed on publication as an 508 RFC. 510 5. Security Considerations 512 The transport protocol used for sending information of this data 513 model MUST support authentication and SHOULD support encryption. The 514 data-model by itself does not create any security implications. 516 6. Acknowledgements 518 TBD 520 7. Normative References 522 [I-D.clemm-i2rs-yang-network-topo] 523 Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., 524 and H. Ananthakrishnan, "A Data Model for Network 525 Topologies", draft-clemm-i2rs-yang-network-topo-02 (work 526 in progress), December 2014. 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 532 Network Configuration Protocol (NETCONF)", RFC 6020, 533 October 2010. 535 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 536 October 2010. 538 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 539 Management", RFC 7223, May 2014. 541 Authors' Addresses 542 Jie Dong 543 Huawei Technologies 544 Huawei Campus, No. 156 Beiqing Rd. 545 Beijing 100095 546 China 548 Email: jie.dong@huawei.com 550 Mach(Guoyi) Chen 551 Huawei Technologies 552 Huawei Campus, No. 156 Beiqing Rd. 553 Beijing 100095 554 China 556 Email: mach.chen@huawei.com