idnits 2.17.1 draft-yg3bp-ccamp-network-inventory-yang-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 : ---------------------------------------------------------------------------- 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 (4 March 2022) is 783 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'TMF-MTOSI' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group C. Yu 3 Internet-Draft I. Busi 4 Intended status: Standards Track Huawei Technologies 5 Expires: 5 September 2022 A. Guo 6 Futurewei Technologies 7 S. Belotti 8 Nokia 9 J.-F. Bouquier 10 Vodafone 11 F. Peruzzini 12 TIM 13 O. Gonzalez de Dios 14 Telefonica 15 V. Lopez 16 Nokia 17 4 March 2022 19 A YANG Data Model for Network Hardware Inventory 20 draft-yg3bp-ccamp-network-inventory-yang-00 22 Abstract 24 This document defines a YANG data model for network hardware 25 inventory data information. 27 The YANG data model presented in this document is intended to be used 28 as the basis toward a generic YANG data model for network hardware 29 inventory data information which can be augmented, when required, 30 with technology-specific (e.g., optical) inventory data, to be 31 defined either in a future version of this document or in another 32 document. 34 The YANG data model defined in this document conforms to the Network 35 Management Datastore Architecture (NMDA). 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 5 September 2022. 54 Copyright Notice 56 Copyright (c) 2022 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Revised BSD License text as 65 described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Revised BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. Terminology and Notations . . . . . . . . . . . . . . . . 4 72 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 73 1.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 74 1.4. Prefix in Data Node Names . . . . . . . . . . . . . . . . 6 75 2. YANG Data Model for Network Hardware Inventory . . . . . . . 6 76 2.1. YANG Model Overview . . . . . . . . . . . . . . . . . . . 6 77 2.2. Efficiency Issue . . . . . . . . . . . . . . . . . . . . 9 78 3. Network Hardware Inventory Tree Diagram . . . . . . . . . . . 10 79 4. YANG Model for Network Hardware Inventory . . . . . . . . . . 11 80 5. Manageability Considerations . . . . . . . . . . . . . . . . 17 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 85 8.2. Informative References . . . . . . . . . . . . . . . . . 19 86 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 Network hardware inventory management is a key component in 92 operators' OSS architectures. 94 Network inventory is a fundamental functionality in network 95 management and was specified many years ago. Given the emerging of 96 data models and their deployment in operator's management and control 97 systems, the traditional function of inventory management is also 98 requested to be defined as a data model. 100 Network inventory management and monitoring is a critical part of 101 ensuring the network stays healthy, well-planned, and functioning in 102 the operator's network. Network inventory management allows the 103 operator to keep track of what physical network devices are staying 104 in the network including relevant software and hardware. 106 The network inventory management also helps the operator to know when 107 to acquire new assets and what is needed, or to decommission old or 108 faulty ones, which can help to improve network performance and 109 capacity planning. 111 In [I-D.ietf-teas-actn-poi-applicability] a gap was identified 112 regarding the lack of a YANG data model that could be used at ACTN 113 MPI interface level to report whole/partial hardware inventory 114 information available at PNC level towards north-bound systems (e.g., 115 MDSC or OSS layer). 117 [RFC8345] initial goal was to make possible the augmentation of the 118 YANG data model with network inventory data model but this was never 119 developed and the scope was kept limited to network topology data 120 only. 122 It is key for operators to drive the industry towards the use of a 123 standard YANG data model for network inventory data instead of using 124 vendors proprietary APIs (e.g., REST API). 126 In the ACTN architecture, this would bring also clear benefits at 127 MDSC level for packet over optical integration scenarios since this 128 would enable the correlation of the inventory information with the 129 links information reported in the network topology model. 131 The intention is to define a generic YANG data model that would be as 132 much as possible technology agnostic (valid for IP, optical and 133 microwave networks) and that could be augmented, when required, to 134 include some technology-specific inventory details. 136 [RFC8348] defines a YANG data model for the management of the 137 hardware on a single server and therefore it is more applicable to 138 the PNC South Bound Interface (SBI) towards the network elements 139 rather than at the PNC MPI. However, the YANG data model defined in 140 [RFC8348] has been used as a reference for defining the YANG network 141 hardware inventory data model. 143 For optical network hardware inventory, the network inventory YANG 144 data model should support the use cases (4a and 4b) and requirements 145 defined in [ONF_TR-547], in order to guarantee a seamless integration 146 at MDSC/OSS/orchestration layers. 148 The proposed YANG data model has been analyzed to cover the 149 requirements and use cases for Optical Network Hardware Inventory. 151 Being based on [RFC8348], this data model should be a good starting 152 point toward a generic data model and applicable to any technology. 153 However, further analysis of requirements and use cases is needed to 154 extend the applicability of this YANG data model to other types of 155 networks (IP and microwave) and to identify which aspects are generic 156 and which aspects are technology-specific for optical networks. 158 This document defines one YANG module: ietf-network-inventory.yang 159 (Section 4). 161 Note: review in future versions of this document the related modules, 162 depending on the augmentation relationship. 164 The YANG data model defined in this document conforms to the Network 165 Management Datastore Architecture [RFC8342]. 167 1.1. Terminology and Notations 169 The following terms are defined in [RFC7950] and are not redefined 170 here: 172 * client 174 * server 176 * augment 178 * data model 180 * data node 182 The following terms are defined in [RFC6241] and are not redefined 183 here: 185 * configuration data 187 * state data 189 The terminology for describing YANG data models is found in 190 [RFC7950]. 192 TBD: Recap the concept of chassis/slot/component/board/... in 193 [TMF-MTOSI]. 195 Following terms are used for the representation of the hierarchies in 196 the network hardware inventory. 198 Network Element: 200 a device installed on one or several chassis and can afford some 201 specific transmission function independently. 203 Rack: 205 a holder of the device and provides power supply for the device in 206 it. 208 Chassis: 210 a holder of the device installation. 212 Slot: 214 a holder of the board. 216 Component: 218 holders and equipments of the network element, including chassis, 219 slot, sub-slot, board and port. 221 Board/Card: 223 a pluggable equipment can be inserted into one or several slots/ 224 sub-slots and can afford a specific transmission function 225 independently. 227 Port: 229 an interface on board 231 1.2. Requirements Notation 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 235 "OPTIONAL" in this document are to be interpreted as described in BCP 236 14 [RFC2119] [RFC8174] when, and only when, they appear in all 237 capitals, as shown here. 239 1.3. Tree Diagram 241 A simplified graphical representation of the data model is used in 242 Section 3 of this document. The meaning of the symbols in these 243 diagrams is defined in [RFC8340]. 245 1.4. Prefix in Data Node Names 247 In this document, names of data nodes and other data model objects 248 are prefixed using the standard prefix associated with the 249 corresponding YANG imported modules, as shown in the following table. 251 +========+========================+===========+ 252 | Prefix | Yang Module | Reference | 253 +========+========================+===========+ 254 | ianahw | iana-hardware | [RFC8348] | 255 +--------+------------------------+-----------+ 256 | ni | ietf-network-inventory | RFCXXX | 257 +--------+------------------------+-----------+ 258 | yang | ietf-yang-types | [RFC6991] | 259 +--------+------------------------+-----------+ 261 Table 1: Prefixes and corresponding YANG 262 modules 264 RFC Editor Note: Please replace XXXX with the RFC number assigned to 265 this document. Please remove this note. 267 2. YANG Data Model for Network Hardware Inventory 269 2.1. YANG Model Overview 271 Based on TMF classification in [TMF-MTOSI], inventory objects can be 272 divided into two groups, holder group and equipment group. The 273 holder group contains rack, chassis, slot, sub-slot while the 274 equipment group contains network-element, board and port. With the 275 requirement of GIS and on-demand domain controller selection raised, 276 the equipment room becomes a new inventory object to be managed 277 besides TMF classification. 279 Logically, the relationship between these inventory objects can be 280 described by Figure 1 below: 282 +-------------+ 283 | inventory | 284 +-------------+ 285 // \\ 286 1:N // \\ 1:M 287 // \\ 288 +----------------+ +-----------------+ 289 | equipment room | | network element | 290 +----------------+ +-----------------+ 291 || || 292 || 1:N || 293 \/ || 294 +------------+ ||1:M 295 | rack | || 296 +------------+ || 297 || || 298 || 1:N \/ 299 ||______________\+------------+ 300 |---------------/| chassis | 301 +------------+ 302 || 303 ______1:N______||_____1:M_______ 304 ||------------------ ---------|| 305 \/ \/ 306 +--------------+ +-----------+ 307 | slot/subslot | | board | 308 +--------------+ +-----------+ 309 || 310 ||1:N 311 \/ 312 +-----------+ 313 | port | 314 +-----------+ 316 Figure 1: Relationship between inventory objects 318 In [RFC8348], rack, chassis, slot, sub-slot, board and port are 319 defined as components of network elements with generic attributes. 321 While [RFC8348] is used to manage the hardware of a single server 322 (e.g., a Network Element), the Network Inventory YANG data model is 323 used to retrieve the network hardware inventory information that a 324 controller discovers from multiple Network Elements under its 325 control. 327 However, the YANG data model defined in [RFC8348] has been used as a 328 reference for defining the YANG network inventory data model. This 329 approach can simplify the implementation of this network hardware 330 inventory model when the controller uses the YANG data model defined 331 in [RFC8348] to retrieve the hardware from the network elements under 332 its control. 334 Note: review in future versions of this document which attributes 335 from [RFC8348] are required also for network hardware inventory and 336 whether there are attributes not defined in [RFC8348] which are 337 required for network hardware inventory 339 Note: review in future versions of this document whether to re-use 340 definitions from [RFC8348] or use schema-mount. 342 +--ro network-inventory 343 +--ro equipment-rooms 344 | +--ro equipment-room* [uuid] 345 | +--ro uuid yang:uuid 346 | ................................... 347 | +--ro rack* [uuid] 348 | +--ro uuid yang:uuid 349 | ................................... 350 | +--ro chassis* [uuid] 351 | +--ro uuid yang:uuid 352 | ................................... 353 | +--ro chassis-ref 354 | +--ro ne-ref? leafref 355 | +--ro component-ref? leafref 356 +--ro network-elements 357 +--ro network-element* [uuid] 358 +--ro uuid yang:uuid 359 ................................... 360 +--ro components 361 +--ro component* [uuid] 362 +--ro uuid yang:uuid 363 ................................... 365 The YANG data model for network hardware inventory follows the same 366 approach of [RFC8348] and reports the network hardware inventory as a 367 list of components with different types (e.g., chassis, module, 368 port). 370 +--ro components 371 +--ro component* [uuid] 372 +--ro uuid yang:uuid 373 +--ro name? string 374 +--ro description? string 375 +--ro class? identityref 376 +--ro parent-rel-pos? int32 377 +--ro children* [child-ref] 378 | +--ro child-ref -> ../../uuid 379 +--ro parent 380 +--ro parent-ref? -> ../../uuid 382 Note: review in future versions of this document whether the 383 component list should be under the network-inventory instead of under 384 the network-element container 386 However, considering there are some special scenarios, the 387 relationship between the rack and network elements is not 1 to 1 nor 388 1 to n. The network element cannot be the direct parent node of the 389 rack. So there should be n to m relationship between racks and 390 network elements. And the chassis in the rack should have some 391 reference information to the component. 393 Note that in [RFC8345], topology and inventory are two subsets of 394 network information. However, considering the complexity of the 395 existing topology models and to have a better extension capability, 396 we define a separate root for the inventory model. We will consider 397 some other ways to do some associations between the topology model 398 and inventory model in the future. 400 Note: review in future versions of this document whether network 401 hardware inventory should be defined as an augmentation of the 402 network model defined in [RFC8345] instead of under a new network- 403 inventory root. 405 The proposed YANG data model has been analysed to cover the 406 requirements and use cases for Optical Network Inventory. 408 Further analysis of requirements and use cases is needed to extend 409 the applicability of this YANG data model to other types of networks 410 (IP and microwave) and to identify which aspects are generic and 411 which aspects are technology-specific for optical networks. 413 2.2. Efficiency Issue 415 During doing the design of integration with OSS, some efficiency 416 issues have been discovered. More discussion is needed to be done in 417 the future to address this issue. 419 Considering relational database is widely used by traditional OSS 420 systems and part of PNCs, the inventory objects are probably saved in 421 different tables. If the generic model is adopted, when doing a full 422 amount synchronization, PNC needs to convert all inventory objects of 423 each NE into component objects and mix them together into a list, and 424 then construct a response and send to OSS or MDSC. The OSS or MDSC 425 needs to classify the component list and devide them into different 426 groups, in order to save them in different tables. The mixing- 427 regrouping steps are actually waste of effort. 429 And this efficiency issue will be more serious in a larger scale of 430 network. 432 3. Network Hardware Inventory Tree Diagram 434 Figure 2 below shows the tree diagram of the YANG data model defined 435 in module ietf-network-inventory.yang (Section 4). 437 module: ietf-network-inventory 438 +--ro network-inventory 439 +--ro equipment-rooms 440 | +--ro equipment-room* [uuid] 441 | +--ro uuid yang:uuid 442 | +--ro name? string 443 | +--ro location? string 444 | +--ro rack* [uuid] 445 | +--ro uuid yang:uuid 446 | +--ro name? string 447 | +--ro row-number? uint32 448 | +--ro rack-number? uint32 449 | +--ro chassis* [uuid] 450 | +--ro uuid yang:uuid 451 | +--ro name? string 452 | +--ro chassis-number? uint8 453 | +--ro chassis-ref 454 | +--ro ne-ref? leafref 455 | +--ro component-ref? leafref 456 +--ro network-elements 457 +--ro network-element* [uuid] 458 +--ro uuid yang:uuid 459 +--ro name? string 460 +--ro components 461 +--ro component* [uuid] 462 +--ro uuid yang:uuid 463 +--ro name? string 464 +--ro description? string 465 +--ro class? identityref 466 +--ro parent-rel-pos? int32 467 +--ro children* [child-ref] 468 | +--ro child-ref -> ../../uuid 469 +--ro parent 470 +--ro parent-ref? -> ../../uuid 472 Figure 2: Network inventory tree diagram 474 4. YANG Model for Network Hardware Inventory 476 file "ietf-network-inventory@2022-03-04.yang" 477 module ietf-network-inventory { 478 yang-version 1.1; 479 namespace "urn:ietf:params:xml:ns:yang:ietf-network-inventory"; 480 prefix ni; 482 import ietf-yang-types { 483 prefix yang; 484 reference 485 "RFC6991: Common YANG Data Types."; 486 } 488 import iana-hardware { 489 prefix ianahw; 490 reference 491 "RFC 8348: A YANG Data Model for Hardware Management."; 492 } 494 organization 495 "IETF CCAMP Working Group"; 496 contact 497 "WG Web: 498 WG List: 500 Editor: Chaode Yu 501 503 Editor: Italo Busi 504 506 Editor: Aihua Guo 507 509 Editor: Sergio Belotti 510 512 Editor: Jean-Francois Bouquier 513 515 Editor: Fabio Peruzzini 516 "; 518 description 519 "This module defines a model for retrieving network inventory. 521 The model fully conforms to the Network Management 522 Datastore Architecture (NMDA). 524 Copyright (c) 2021 IETF Trust and the persons 525 identified as authors of the code. All rights reserved. 527 Redistribution and use in source and binary forms, with or 528 without modification, is permitted pursuant to, and subject 529 to the license terms contained in, the Simplified BSD License 530 set forth in Section 4.c of the IETF Trust's Legal Provisions 531 Relating to IETF Documents 532 (https://trustee.ietf.org/license-info). 534 This version of this YANG module is part of RFC XXXX; see 535 the RFC itself for full legal notices. 537 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 538 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 539 'MAY', and 'OPTIONAL' in this document are to be interpreted as 540 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 541 they appear in all capitals, as shown here."; 543 // RFC Ed.: replace XXXX with actual RFC number and remove this 544 // note. 545 // RFC Ed.: update the date below with the date of RFC publication 546 // and remove this note. 548 revision 2022-03-04 { 549 description 550 "Initial revision."; 551 reference 552 "draft-yg3bp-ccamp-inventory-yang-00: A YANG Data 553 Model for Network Inventory."; 554 } 556 container network-inventory { 557 config false; 558 description 559 "The top-level container for the network inventory 560 information."; 561 uses equipment-rooms-grouping; 562 uses network-elements-grouping; 563 } 565 grouping common-entity-attributes { 566 description 567 "A set of attributes which are common to all the entities 568 (e.g., component, equipment room) defined in this module."; 569 leaf uuid { 570 type yang:uuid; 571 description 572 "Uniquely identifies an entity (e.g., component)."; 573 } 574 leaf name { 575 type string; 576 description 577 "A name for an entity (e.g., component), as specified by 578 a network manager, that provides a non-volatile 'handle' 579 for the entity and that can be modified anytime during the 580 entity lifetime. 582 If no configured value exists, the server MAY set the value 583 of this node to a locally unique value in the operational 584 state."; 585 } 586 } 587 grouping network-elements-grouping { 588 description 589 "The attributes of the network elements."; 590 container network-elements { 591 description 592 "The container for the list of network elements."; 593 list network-element { 594 key uuid; 595 description 596 "The list of network elements within the network."; 597 uses common-entity-attributes; 598 uses components-grouping; 599 } 600 } 601 } 603 grouping equipment-rooms-grouping { 604 description 605 "The attributes of the equipment rooms."; 606 container equipment-rooms { 607 description 608 "The container for the list of equipment rooms."; 609 list equipment-room { 610 key uuid; 611 description 612 "The list of equipment rooms within the network."; 613 uses common-entity-attributes; 614 leaf location { 615 type string; 616 description 617 "compared with the location information of the other 618 inventory objects, a GIS address is preferred for 619 equipment room"; 620 } 621 list rack { 622 key uuid; 623 description 624 "The list of racks within an equipment room."; 625 uses common-entity-attributes; 626 leaf row-number { 627 type uint32; 628 description 629 "Identifies the row within the equipment room where 630 the rack is located."; 631 } 632 leaf rack-number { 633 type uint32; 634 description 635 "Identifies the physical location of the rack within 636 the row."; 637 } 638 list chassis { 639 key uuid; 640 description 641 "The list of chassis within a rack."; 642 uses common-entity-attributes; 643 leaf chassis-number { 644 type uint8; 645 description 646 "Identifies the location of the chassis within the 647 rack."; 648 } 649 container chassis-ref { 650 description 651 "The reference to the network element component 652 representing this chassis."; 653 leaf ne-ref { 654 type leafref { 655 path "/ni:network-inventory/ni:network-elements" 656 + "/ni:network-element/ni:uuid"; 657 } 658 description 659 "The reference to the network element containing 660 the component."; 661 } 662 leaf component-ref { 663 type leafref { 664 path "/ni:network-inventory/ni:network-elements" 665 + "/ni:network-element[ni:uuid" 666 + "=current()/../ne-ref]/ni:components" 667 + "/ni:component/ni:uuid"; 668 } 669 description 670 "The reference to the component within the network 671 element."; 672 } 673 } 674 } 675 } 676 } 677 } 679 } 681 grouping components-grouping { 682 description 683 "The attributes of the hardware components."; 684 container components { 685 description 686 "The container for the list of components."; 687 list component { 688 key uuid; 689 description 690 "The list of components within a network element."; 691 uses common-entity-attributes; 692 leaf description { 693 type string; 694 description 695 "A textual description of the component."; 696 reference 697 "RFC 8348: A YANG Data Model for Hardware Management."; 698 } 699 leaf class { 700 type identityref { 701 base ianahw:hardware-class; 702 } 703 description 704 "An indication of the general hardware type of the 705 component."; 706 reference 707 "RFC 8348: A YANG Data Model for Hardware Management."; 708 } 709 leaf parent-rel-pos { 710 type int32 { 711 range "0 .. 2147483647"; 712 } 713 description 714 "An indication of the relative position of this child 715 component among all its sibling components. Sibling 716 components are defined as components that: 718 o share the same value of the 'parent' node and 720 o share a common base identity for the 'class' node."; 721 reference 722 "RFC 8348: A YANG Data Model for Hardware Management."; 723 } 724 list children { 725 key child-ref; 726 description 727 "The child components that are physically contained by 728 this component."; 730 leaf child-ref { 731 type leafref { 732 path "../../ni:uuid"; 733 } 734 description 735 "The reference to the child component."; 736 } 737 } 738 container parent { 739 description 740 "The parent component that physically contains this 741 component. 743 If this container is not instantiated, it indicates 744 that this component is not contained in any other 745 component. 747 In the event that a physical component is contained by 748 more than one physical component (e.g., double-wide 749 modules), this container contains the data of one of 750 these components. An implementation MUST use the same 751 component every time this container is instantiated."; 752 leaf parent-ref { 753 type leafref { 754 path "../../ni:uuid"; 755 } 756 description 757 "The reference to the parent component."; 758 } 759 } 760 } 761 } 762 } 763 } 764 766 Figure 3: Network inventory YANG module 768 5. Manageability Considerations 770 772 6. Security Considerations 774 776 7. IANA Considerations 778 780 8. References 782 8.1. Normative References 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, 786 DOI 10.17487/RFC2119, March 1997, 787 . 789 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 790 and A. Bierman, Ed., "Network Configuration Protocol 791 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 792 . 794 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 795 RFC 6991, DOI 10.17487/RFC6991, July 2013, 796 . 798 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 799 RFC 7950, DOI 10.17487/RFC7950, August 2016, 800 . 802 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 803 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 804 May 2017, . 806 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 807 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 808 . 810 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 811 and R. Wilton, "Network Management Datastore Architecture 812 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 813 . 815 [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 816 YANG Data Model for Hardware Management", RFC 8348, 817 DOI 10.17487/RFC8348, March 2018, 818 . 820 [TMF-MTOSI] 821 TM Forum (TMF), "TMF MTOSI 4.0 Equipment Model", TMF 822 SD2-20_EquipmentModel , 2008, 823 . 825 8.2. Informative References 827 [I-D.ietf-teas-actn-poi-applicability] 828 Peruzzini, F., Bouquier, J., Busi, I., King, D., and D. 829 Ceccarelli, "Applicability of Abstraction and Control of 830 Traffic Engineered Networks (ACTN) to Packet Optical 831 Integration (POI)", Work in Progress, Internet-Draft, 832 draft-ietf-teas-actn-poi-applicability-04, 17 January 833 2022, . 836 [ONF_TR-547] 837 Open Networking Foundation (ONF), "TAPI v2.1.3 Reference 838 Implementation Agreement", ONF TR-547 TAPI RIA v1.0 , July 839 2020, . 843 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 844 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 845 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 846 2018, . 848 Acknowledgments 850 The authors of this document would like to thank the authors of 851 [I-D.ietf-teas-actn-poi-applicability] for having identified the gap 852 and requirements to trigger this work. 854 This document was prepared using kramdown. 856 Authors' Addresses 858 Chaode Yu 859 Huawei Technologies 860 Email: yuchaode@huawei.com 862 Italo Busi 863 Huawei Technologies 864 Email: italo.busi@huawei.com 865 Aihua Guo 866 Futurewei Technologies 867 Email: aihuaguo.ietf@gmail.com 869 Sergio Belotti 870 Nokia 871 Email: sergio.belotti@nokia.com 873 Jean-Francois Bouquier 874 Vodafone 875 Email: jeff.bouquier@vodafone.com 877 Fabio Peruzzini 878 TIM 879 Email: fabio.peruzzini@telecomitalia.it 881 Oscar Gonzalez de Dios 882 Telefonica 883 Email: oscar.gonzalezdedios@telefonica.com 885 Victor Lopez 886 Nokia 887 Email: victor.lopez@nokia.com