idnits 2.17.1 draft-ietf-teas-actn-info-model-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2018) is 2134 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ACTN-REQ' is mentioned on line 320, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Teas Working Group Young Lee 2 Internet Draft Huawei 4 Intended status: Informational Sergio Belotti 5 Nokia 6 Expires: December 21, 2018 7 Dhruv Dhody 8 Huawei 10 Daniele Ceccarelli 11 Ericsson 13 Bin Yeong Yoon 14 ETRI 16 June 21, 2018 18 Information Model for Abstraction and Control of TE Networks (ACTN) 20 draft-ietf-teas-actn-info-model-10.txt 22 Abstract 24 This draft provides an information model for Abstraction and Control 25 of Traffic Engineered Networks (ACTN). 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with 30 the provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on December 21, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................3 67 1.1. Terminology...............................................4 68 2. ACTN Common Interfaces Information Model.......................4 69 3. Virtual Network primitives.....................................5 70 3.1. VN Instantiate............................................6 71 3.2. VN Modify.................................................7 72 3.3. VN Delete.................................................7 73 3.4. VN Update.................................................7 74 3.5. VN Compute................................................7 75 3.6. VN Query..................................................8 76 4. Traffic Engineering (TE) primitives............................8 77 4.1. TE Instantiate............................................9 78 4.2. TE Modify.................................................9 79 4.3. TE Delete.................................................9 80 4.4. TE Topology Update (for TE resources).....................9 81 4.5. Path Compute.............................................10 82 5. VN Objects....................................................10 83 5.1. VN Identifier............................................11 84 5.2. VN Service Characteristics...............................11 85 5.3. VN End-Point.............................................13 86 5.4. VN Objective Function....................................14 87 5.5. VN Action Status.........................................15 88 5.6. VN Topology..............................................15 89 5.7. VN Member................................................15 90 5.7.1. VN Computed Path....................................16 91 5.7.2. VN Service Preference...............................16 92 6. TE Objects....................................................17 93 6.1. TE Tunnel Characteristics................................17 94 7. Mapping of VN primitives with VN Objects......................19 95 8. Mapping of TE primitives with TE Objects......................20 96 9. Security Considerations.......................................21 97 10. IANA Considerations..........................................22 98 11. References...................................................22 99 11.1. Normative References....................................22 100 11.2. Informative References..................................22 101 12. Contributors.................................................23 102 Contributors' Addresses..........................................23 103 Authors' Addresses...............................................23 105 1. Introduction 107 This draft provides an information model for Abstraction and Control 108 of Traffic Engineered Networks (ACTN). The information model 109 described in this document covers the interface requirements 110 identified in the ACTN architecture and framework document [ACTN- 111 Frame]. 113 The ACTN reference architecture [ACTN-Frame] identifies a three-tier 114 control hierarchy comprising the following as depicted in Figure 1: 116 - Customer Network Controllers (CNCs) 117 - Multi-Domain Service Coordinator (MDSC) 118 - Provisioning Network Controllers (PNCs). 120 +-------+ +-------+ +-------+ 121 | CNC-A | | CNC-B | | CNC-C | 122 +-------+ +-------+ +-------+ 123 \ | / 124 ------------ | CMI ------------- 125 \ | / 126 +----------------------+ 127 | MDSC | 128 +----------------------+ 129 / | \ 130 ------------ | MPI ------------- 131 / | \ 132 +-------+ +-------+ +-------+ 133 | PNC | | PNC | | PNC | 134 +-------+ +-------+ +-------+ 136 Figure 1: A Three-tier ACTN control hierarchy 138 The two interfaces with respect to the MDSC, one north of the MDSC 139 and the other south of the MDSC are referred to as CMI (CNC-MDSC 140 Interface) and MPI (MDSC-PNC Interface), respectively. This document 141 models these two interfaces and derivative interfaces thereof (e.g., 142 MDSC to MDSC in a hierarchy of MDSCs) as a single common interface. 144 1.1. Terminology 146 The terms "Virtual Network (VN)" and "Virtual Network Service (VNS)" 147 are defined in [ACTN-Frame] and the other key terms such as 148 "abstraction", "abstract topology", "Path", "VN node", and "VN link" 149 are defined in [RFC7926]. 151 2. ACTN Common Interfaces Information Model 153 This section provides an ACTN common interface information model to 154 describe primitives, objects, their properties (represented as 155 attributes), their relationships, and the resources for the service 156 applications needed in the ACTN context. 158 The standard interface is described between a client controller and 159 a server controller. A client-server relationship is recursive 160 between a CNC and an MDSC and between an MDSC and a PNC. In the CMI, 161 the client is a CNC while the server is an MDSC. In the MPI, the 162 client is an MDSC and the server is a PNC. There may also be MDSC- 163 MDSC interface(s) that need to be supported. This may arise in a 164 hierarchy of MDSCs in which workloads may need to be partitioned to 165 multiple MDSCs. 167 Basic primitives (messages) are required between the CNC-MDSC and 168 MDSC-PNC controllers. These primitives can then be used to support 169 different ACTN network control functions like network topology 170 request/query, VN service request, path computation and connection 171 control, VN service policy negotiation, enforcement, routing 172 options, etc. 174 There are two different types of primitives depending on the type of 175 interface: 177 - Virtual Network primitives at CMI 178 - Traffic Engineering primitives at MPI 180 As well described in [ACTN-Frame], at the CMI level, there is no 181 need for detailed TE information since the basic functionality is to 182 translate customer service information into virtual network service 183 operation. 185 At the MPI level, MDSC has the main scope for multi-domain 186 coordination and creation of a single e2e abstracted network view 187 which is strictly related to TE information. 189 As for topology, this document employs two types of topology: 191 - The first type is referred to as virtual network topology which 192 is associated with a VN. Virtual network topology is a 193 customized topology for view and control by the customer. See 194 Section 3.1 for details. 196 - The second type is referred to as TE topology which is 197 associated with provider network operation on which we can 198 apply policy to obtain the required level of abstraction to 199 represent the underlying physical network topology. 201 3. Virtual Network primitives 203 This section provides a list of main VN primitives related to 204 virtual network which are necessary to satisfy ACTN requirements 205 specified in [ACTN-REQ] 207 The following VN Action primitives are supported: 209 - VN Instantiate 211 - VN Modify 213 - VN Delete 215 - VN Update 217 - VN Path Compute 219 - VN Query 221 VN Action is an object describing the main VN primitives. 223 VN Action can assume one of the mentioned above primitives values. 225 ::= | 227 | 229 | 231 | 233 | 235 237 All these actions will solely happen at CMI level between Customer 238 Network Controller (CNC) and Multi Domain Service Coordinator 239 (MDSC). 241 3.1. VN Instantiate 243 VN Instantiate refers to an action from customers/applications to 244 request the creation of VNs. VN Instantiate is for CNC-to-MDSC 245 communication. Depending on the agreement between client and 246 provider, VN instantiate can imply different VN operations. There 247 are two types of VN instantiation: 249 VN type 1: VN is viewed as a set of edge-to-edge links (VN members). 251 VN type 2: VN is viewed as a VN-topology comprising virtual nodes 252 and virtual links. 254 Please see [ACTN-Frame] for full details regarding the types of VN. 256 3.2. VN Modify 258 VN Modify refers to an action issued from customers/applications to 259 modify an existing VN (i.e., an instantiated VN). VN Modify is for 260 CNC-to-MDSC communication. 262 VN Modify, depending of the type of VN instantiated, can be a 263 modification of the characteristics of VN members (edge-to-edge 264 links) in case of VN type 1, or a modification of an existing 265 virtual topology (e.g., adding/deleting virtual nodes/links) in case 266 of VN type 2. 268 3.3. VN Delete 270 VN Delete refers to an action issued from customers/applications to 271 delete an existing VN. VN Delete is for CNC-to-MDSC communication. 273 3.4. VN Update 275 VN Update refers to any update to the VN that needs to be updated to 276 the customers. VN Update is MDSC-to-CNC communication. VN Update 277 fulfills a push model at CMI level, to make customers aware of any 278 specific changes in the topology details related to the instantiated 279 VN. 281 VN Update, depending of the type of VN instantiated, can be an 282 update of VN members (edge-to-edge links) in case of VN type 1, or 283 an update of virtual topology in case of VN type 2. 285 The connection-related information (e.g., LSPs) update association 286 with VNs will be part of the "translation" function that happens in 287 MDSC to map/translate VN request into TE semantics. This information 288 will be provided in case customer optionally wants to have more 289 detailed TE information associated with the instantiated VN. 291 3.5. VN Compute 293 VN Compute consists of Request and Reply. Request refers to an 294 action from customers/applications to request a VN computation. 296 VN Compute Reply refers to the reply in response to VN Compute 297 Request. 299 VN Compute Request/Reply is to be differentiated from a VN 300 Instantiate. The purpose of VN Compute is a priori exploration to 301 compute network resources availability and getting a possible VN 302 view in which path details can be specified matching 303 customer/applications constraints. This a priori exploration may not 304 guarantee the availability of the computed network resources at the 305 time of instantiation. 307 3.6. VN Query 309 VN Query refers to an inquiry pertaining to a VN that has already 310 been instantiated. VN Query fulfills a pull model that permits 311 getting a topology view. 313 VN Query Reply refers to the reply in response to VN Query. The 314 topology view returned by VN Query Reply would be consistent with 315 the topology type instantiated for any specific VN. 317 4. Traffic Engineering (TE) primitives 319 This section provides a list of the main TE primitives necessary to 320 satisfy ACTN requirements specified in [ACTN-REQ] related to typical 321 TE operations supported at the MPI level. 323 The TE action primitives defined in this section should be supported 324 at the MPI consistently with the type of topology defined at the 325 CMI. 327 The following TE action primitives are supported: 329 - TE Instantiate/Modify/Delete 331 - TE Topology Update (See Section 4.4. for the description) 333 - Path Compute 335 TE Action is an object describing the main TE primitives. 337 TE Action can assume one of the mentioned above primitives values. 339 ::= | 341 | 343 | 345 | 346 | 348 All these actions will solely happen at MPI level between Multi 349 Domain Service Coordinator (MDSC) and Provisioning Network 350 Controller (PNC). 352 4.1. TE Instantiate 354 TE Instantiate refers to an action issued from MDSC to PNC to 355 instantiate new TE tunnels. 357 4.2. TE Modify 359 TE Modify refers to an action issued from MDSC to PNC to modify 360 existing TE tunnels. 362 4.3. TE Delete 364 TE Delete refers to an action issued from MDSC to PNC to delete 365 existing TE tunnels. 367 4.4. TE Topology Update (for TE resources) 369 TE Topology Update is a primitive specifically related to MPI to 370 provide TE resource update between any domain controller towards 371 MDSC regarding the entire content of any "domain controller" actual 372 TE topology or an abstracted filtered view of TE topology depending 373 on negotiated policy. 375 See [TE-TOPO] for detailed YANG implementation of TE topology 376 update. 378 ::= 380 ::= [] 382 ::= [] 384 ::= [] 386 ::= 388 ::= [] 391 ::= [] 393 Where 395 Abstraction provides information on level of abstraction (as 396 determined a priori). 398 TE-topology-identifier is an identifier that identifies a specific 399 te-topology, e.g., te-types:te-topology-id [TE-TOPO]. 401 Node-list is detailed information related to a specific node 402 belonging to a te-topology, e.g., te-node-attributes [TE-TOPO]. 404 Link-list is information related to the specific link related 405 belonging to a te-topology, e.g., te-link-attributes [TE-TOPO]. 407 TE Termination Point-list is detailed information associated with 408 the termination points of te-link related to a specific node, e.g., 409 interface-switching-capability [TE-TOPO]. 411 4.5. Path Compute 413 Path Compute consists of Request and Reply. Request refers to an 414 action from MDSC to PNC to request a path computation. 416 Path Compute Reply refers to the reply in response to Path Compute 417 Request. 419 The context of Path Compute is described in [Path-Compute]. 421 5. VN Objects 423 This section provides a list of objects associated to VN action 424 primitives. 426 5.1. VN Identifier 428 VN Identifier is a unique identifier of the VN. 430 5.2. VN Service Characteristics 432 VN Service Characteristics describes the customer/application 433 requirements against the VNs to be instantiated. 435 ::= 437 439 (...) 441 443 Where 445 ::= |||| 448 The Connectivity Type identifies the type of required VN Service. In 449 addition to the classical type of services (e.g. P2P/P2MP etc.), 450 ACTN defines the "multi-destination" service that is a new P2P 451 service where the end points are not fixed. They can be chosen among 452 a list of pre-configured end points or dynamically provided by the 453 CNC. 455 VN Directionality indicates if a VN is unidirectional or 456 bidirectional. This implies that each VN member that belongs to the 457 VN has the same directionality as the VN. 459 ::= 461 [] 463 The VN Traffic Matrix represents the traffic matrix parameters for 464 the required service connectivity. Bandwidth is a mandatory 465 parameter and a number of optional constraints can be specified in 466 the VN Constraints (e.g. diversity, cost). They can include 467 objective functions and TE metrics bounds as specified in [RFC5541]. 469 Further details on the VN constraints are specified below: 471 ::= [] 473 [] 475 ( | ) 477 Where: 479 Layer Protocol identifies the layer topology at which the VN 480 service is requested. It could be for example MPLS, ODU, and OCh. 482 Diversity allows asking for diversity constraints for a VN 483 Instantiate/Modify or a VN Path Compute. For example, a new VN or 484 a path is requested in total diversity from an existing one (e.g. 485 diversity exclusion). 487 ::= ( (...)) | 489 ( (...)) 491 Metric can include all the Metrics (cost, delay, delay variation, 492 latency), bandwidth utilization parameters defined and referenced 493 by [RFC3630] and [RFC7471]. 495 As for VN Objective Function See Section 5.4. 497 VN Survivability describes all attributes related to the VN recovery 498 level and its survivability policy enforced by the 499 customers/applications. 501 ::= 503 [] 505 [] 507 Where: 509 VN Recovery Level is a value representing the requested level 510 of resiliency required against the VN. The following values 511 are defined: 513 . Unprotected VN 514 . VN with per tunnel recovery: The recovery level is defined 515 against the tunnels composing the VN and it is specified in 516 the VN Tunnel Recovery Level. 518 ::= <0:1>|<1+1>|<1:1>|<1:N>|| 519 521 The VN Tunnel Recovery Level indicates the type of protection 522 or restoration mechanism applied to the VN. It augments the 523 recovery types defined in [RFC4427]. 525 ::= [] 527 [] 529 [] 531 [] 533 Where: 535 Local Reroute Allowed is a delegation policy to the Server to 536 allow or not a local reroute fix upon a failure of the 537 primary LSP. 539 Domain Preference is only applied on the MPI where the MDSC 540 (client) provides a domain preference to each PNC (server), 541 e.g., when an inter-domain link fails, then PNC can choose 542 the alternative peering with this info. 544 Push Allowed is a policy that allows a server to trigger an 545 updated VN topology upon failure without an explicit request 546 from the client. Push action can be set as default unless 547 otherwise specified. 549 Incremental Update is another policy that triggers an 550 incremental update from the server since the last period of 551 update. Incremental update can be set as default unless 552 otherwise specified. 554 5.3. VN End-Point 556 VN End-Point Object describes the VN's customer end-point 557 characteristics. 559 ::= ( 561 [] 563 [])... 565 Where: 567 Access Point Identifier represents a unique identifier of the 568 client end-point. They are used by the customer to ask for the 569 setup of a virtual network instantiation. A VN End-Point is 570 defined against each AP in the network and is shared between 571 customer and provider. Both the customer and the provider will map 572 it against their own physical resources. 574 Access Link Capability identifies the capabilities of the access 575 link related to the given access point. (e.g., max-bandwidth, 576 bandwidth availability, etc.) 578 Source Indicator indicates if an end-point is source or not. 580 5.4. VN Objective Function 582 The VN Objective Function applies to each VN member (i.e., each E2E 583 tunnel) of a VN. 585 The VN Objective Function can reuse objective functions defined in 586 [RFC5541] section 4. 588 For a single path computation, the following objective functions are 589 defined: 591 o MCP is the Minimum Cost Path with respect to a specific 592 metric (e.g. shortest path). 593 o MLP is the Minimum Load Path, that means find a path 594 composted by te-link least loaded. 595 o MBP is the Maximum residual Bandwidth Path. 597 For a concurrent path computation, the following objective functions 598 are defined: 600 o MBC is to Minimize aggregate Bandwidth Consumption. 601 o MLL is to Minimize the Load of the most loaded Link. 602 o MCC is to Minimize the Cumulative Cost of a set of paths. 604 5.5. VN Action Status 606 VN Action Status is the status indicator whether the VN has been 607 successfully instantiated, modified, or deleted in the server 608 network or not in response to a particular VN action. 610 Note that this action status object can be implicitly indicated and 611 thus not included in any of the VN primitives discussed in Section 612 3. 614 5.6. VN Topology 616 When a VN is seen by the customer as a topology, it is referred to 617 as VN topology. This is associated with VN Type 2, which is composed 618 of virtual nodes and virtual links. 620 ::= 622 ::= [] 624 :: = [] 626 5.7. VN Member 628 VN Member describes details of a VN Member which is a list of a set 629 of VN Members represented as VN_Member_List. 631 ::= [] 633 Where ::= 635 [] 637 639 Ingress VN End-Point is the VN End-Point information for the ingress 640 portion of the AP. See Section 5.3 for VN End-Point details. 642 Egress VN End-Point is the VN End-Point information for the egress 643 portion of the AP. See Section 5.3 for VN End-Point details. 645 VN Associated LSP describes the instantiated LSPs in the Provider's 646 network for the VN Type 1. It describes the instantiated LSPs over 647 the VN topology for VN Type 2. 649 5.7.1. VN Computed Path 651 The VN Computed Path is the list of paths obtained after the VN path 652 computation request from a higher controller. Note that the computed 653 path is to be distinguished from the LSP. When the computed path is 654 signaled in the network (and thus the resource is reserved for that 655 path), it becomes an LSP. 657 ::= (...) 659 5.7.2. VN Service Preference 661 This section provides VN Service preference. VN Service is defined 662 in Section 2. 664 ::= [] 666 [] 668 [] 670 Where 672 Location Service Preference describes the End-Point Location's 673 (e.g. Data Centers) support for certain Virtual Network Functions 674 (VNFs) (e.g., security function, firewall capability, etc.) and 675 is used to find the path that satisfies the VNF constraint. 677 Client-specific Preference describes any preference related to 678 Virtual Network Service (VNS) that application/client can enforce 679 via CNC towards lower level controllers. For example, CNC can 680 enforce client-specific preferences, e.g., selection of a 681 destination data center from the set of candidate data centers 682 based on some criteria in the context of VM migration. MSDC/PNC 683 should then provide the data center interconnection that supports 684 the client-specific preference. 686 End-Point Dynamic Selection Preference describes if the End-Point 687 (e.g. Data Center) can support load balancing, disaster recovery 688 or VM migration and so can be part of the selection by MDSC 689 following service Preference enforcement by CNC. 691 6. TE Objects 693 6.1. TE Tunnel Characteristics 695 Tunnel Characteristics describes the parameters needed to configure 696 TE tunnel. 698 ::= [] 700 702 [] 704 [] 706 [] 708 710 [] 712 Where 714 ::= ||| 716 The Tunnel Type identifies the type of required tunnel. In this 717 draft, only P2P model is provided. 719 Tunnel Id is the TE tunnel identifier 721 Tunnel Layer represents the layer technology of the LSPs supporting 722 the tunnel 724 ::= 726 ::= ||||prot | 728 Tunnel Constraints are the base tunnel configuration constraints 729 parameters. 731 Where ::= [] 733 [] 735 [] 737 [] 739 [] 741 [] 743 [] 745 [] 747 Topology Id references the topology used to compute the tunnel path. 749 Bandwidth is the bandwidth used as parameter in path computation 751 ::= | | 753 Disjointness provides the type of resources from which the tunnel 754 has to be disjointed 756 SRLG is a group of physical resources impacted by the same risk from 757 which an E2E tunnel is required to be disjointed. 759 ::= 761 where 763 Setup Priority indicates the level of priority for taking resources 764 from another tunnel [RFC3209] 766 Holding Priority indicates the level of priority to hold resources 767 avoiding preemption from another tunnel [RFC3209] 769 Affinities it represent structure to validate link belonging to path 770 of the tunnel [RFC3209] 772 ::= | 773 Metric can include all the Metrics (cost, delay, delay variation, 774 latency), bandwidth utilization parameters defined and referenced by 775 [RFC3630] and [RFC7471]. 777 ::= 779 ::= | | | | 780 | 782 See chapter 5.4 for objective function type description. 784 7. Mapping of VN primitives with VN Objects 786 This section describes the mapping of VN primitives with VN Objects 787 based on Section 5. 789 ::= 791 793 [] 795 [] 797 ::= 799 801 803 [] 805 [] 807 ::= 809 :: = 811 [] 813 [] 815 ::= 817 819 [] 821 ::= 823 ::= 825 ::= 827 829 [] 831 8. Mapping of TE primitives with TE Objects 833 This section describes the mapping of TE primitives with TE Objects 834 based on Section 6. 836 ::= 838 ::= 840 ::= 841 ::= 843 ::= 845 ::= 847 849 9. Security Considerations 851 The ACTN information model is not directly relevant when considering 852 potential security issues. Rather, it defines a set of interfaces 853 for traffic engineered networks. The underlying protocols, 854 procedures, and implementations used to exchange the information 855 model described in this draft will need to secure the request and 856 control of resources with proper authentication and authorization 857 mechanisms. In addition, the data exchanged over the ACTN interfaces 858 discussed in this document requires verification of data integrity. 859 Backup or redundancies should also be available to restore the 860 affected data to its correct state. 862 Implementations of the ACTN framework will have distributed 863 functional components that will exchange a concrete instantiation 864 that adheres to this information model. Implementations should 865 encrypt data that flows between them, especially when they are 866 implemented at remote nodes and irrespective of whether these data 867 flows are on external or internal network interfaces. The 868 information model may contain customer, application and network data 869 that for business or privacy reasons may be considered sensitive. It 870 should be stored only in an encrypted data store. 872 The ACTN security discussion is further split into two specific 873 interfaces: 875 - Interface between the Customer Network Controller and Multi 876 Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI) 878 - Interface between the Multi Domain Service Coordinator and 879 Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI) 881 See the detailed discussion of the CMI and MPI in Sections 9.1 and 882 9.2, respectively in [ACTN-Frame]. 884 The conclusion is that all data models and protocols used to realize 885 the ACTN info model should have rich security features as discussed 886 in this section. Additional security risks may still exist. 887 Therefore, discussion and applicability of specific security 888 functions and protocols will be better described in documents that 889 are use case and environment specific. 891 10. IANA Considerations 893 This document has no actions for IANA. 895 11. References 897 11.1. Normative References 899 [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and 900 Control of Transport Networks", draft-ietf-teas-actn- 901 framework, work in progress. 903 11.2. Informative References 905 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 906 draft-ietf-teas-yang-te-topo, work in progress. 908 [RFC3209] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP 909 Tunnels", RFC 3209, December 2001. 911 [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) 912 Extensions to OSPF Version 2", RFC 3630, September 2003. 914 [RFC4427] E. Mannie, D. Papadimitriou (Editors), "Recovery 915 (Protection and Restoration) Terminology for Generalized 916 Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 917 2006. 919 [RFC5541] JL. Le Roux, JP. Vasseur and Y. Lee, "Encoding of 920 Objective Functions in the Path Computation Element 921 Communication Protocol (PCEP)", RFC 5541, June 2009. 923 [RFC7471] S. Giacalone, et al, "OSPF Traffic Engineering (TE) Metric 924 Extensions", RFC 7471, March 2015. 926 [RFC7926] A. Farrel, et al., "Problem Statement and Architecture for 927 Information Exchange between Interconnected Traffic- 928 Engineered Networks", RFC 7926, July 2016. 930 [Path-Compute] I. Busi, S. Belotti, et al., "Yang model for 931 requesting Path Computation", draft-ietf-teas-yang-path- 932 computation", work in progress. 934 13. Contributors 936 Contributors' Addresses 938 Haomian Zheng 939 Huawei Technologies 940 Email: zhenghaomian@huawei.com 942 Xian Zhang 943 Huawei Technologies 944 Email: zhang.xian@huawei.com 946 Authors' Addresses 948 Young Lee (Editor) 949 Huawei Technologies 950 5340 Legacy Drive 951 Plano, TX 75023, USA 952 Phone: (469)277-5838 953 Email: leeyoung@huawei.com 955 Sergio Belotti (Editor) 956 Alcatel Lucent 957 Via Trento, 30 958 Vimercate, Italy 959 Email: sergio.belotti@alcatel-lucent.com 961 Dhruv Dhody 962 Huawei Technologies, 963 Divyashree Technopark, Whitefield 964 Bangalore, India 965 Email: dhruv.ietf@gmail.com 966 Daniele Ceccarelli 967 Ericsson 968 Torshamnsgatan,48 969 Stockholm, Sweden 970 Email: daniele.ceccarelli@ericsson.com 972 Bin Yeong Yoon 973 ETRI 974 Email: byyun@etri.re.kr