idnits 2.17.1 draft-ietf-teas-actn-info-model-07.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 (February 5, 2018) is 2269 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: August 5, 2018 7 Dhruv Dhody 8 Huawei 10 Daniele Ceccarelli 11 Ericsson 13 Bin Yeong Yoon 14 ETRI 16 February 5, 2018 18 Information Model for Abstraction and Control of TE Networks (ACTN) 20 draft-ietf-teas-actn-info-model-07.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 August 5, 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 4. Traffic Engineering (TE) primitives............................8 76 4.1. TE Instantiate............................................9 77 4.2. TE Modify.................................................9 78 4.3. TE Delete.................................................9 79 4.4. TE Topology Update (for TE resources).....................9 80 4.5. Path Compute.............................................10 81 5. VN Objects....................................................10 82 5.1. VN Identifier............................................10 83 5.2. VN Service Characteristics...............................10 84 5.3. VN End-Point.............................................13 85 5.4. VN Objective Function....................................14 86 5.5. VN Action Status.........................................14 87 5.6. VN Topology..............................................15 88 5.7. VN Member................................................15 89 5.7.1. VN Computed Path....................................16 90 5.7.2. VN Service Preference...............................16 91 6. TE Objects....................................................17 92 6.1. TE Tunnel Characteristic.................................17 93 7. Mapping of VN Primitives with VN Objects......................19 94 8. Mapping of TE Primitives with TE Objects......................20 95 9. Security Considerations.......................................21 96 10. IANA Considerations..........................................22 97 11. References...................................................22 98 11.1. Normative References....................................22 99 11.2. Informative References..................................22 100 12. Contributors.................................................23 101 Contributors' Addresses..........................................23 102 Authors' Addresses...............................................23 104 1. Introduction 106 This draft provides an information model for Abstraction and Control 107 of Traffic Engineered Networks (ACTN). The information model 108 described in this document covers the requirements identified in the 109 ACTN requirements document [ACTN-REQ] and the interfaces identified 110 in the ACTN architecture and framework document [ACTN-Frame]. 112 The ACTN reference architecture [ACTN-Frame] identifies a three-tier 113 control hierarchy comprising the following as depicted in Figure 1: 115 - Customer Network Controllers (CNCs) 116 - Multi-Domain Service Coordinator (MDSC) 117 - Provisioning Network Controllers (PNCs). 119 +-------+ +-------+ +-------+ 120 | CNC-A | | CNC-B | | CNC-C | 121 +-------+ +-------+ +-------+ 122 \ | / 123 ------------ | CMI ------------- 124 \ | / 125 +-----------------------+ 126 | MDSC | 127 +-----------------------+ 128 / | \ 129 ------------ | MPI ------------- 130 / | \ 131 +-------+ +-------+ +-------+ 132 | PNC | | PNC | | PNC | 133 +-------+ +-------+ +-------+ 135 Figure 1: A Three-tier ACTN control hierarchy 137 The two interfaces with respect to the MDSC, one north of the MDSC 138 and the other south of the MDSC are referred to as CMI (CNC-MDSC 139 Interface) and MPI (MDSC-PNC Interface), respectively. This document 140 models these two interfaces and derivative interfaces there of 141 (e.g., MDSC to MSDC in a hierarchy of MDSCs) as a single common 142 interface. 144 1.1. Terminology 146 The terms "Virtual Network (VN)" and "Virtual Network Service (VNS)" 147 are defined in [ACTN-Frame] and the terms "abstraction" and 148 "abstract topology" are defined in [RFC7926]. 150 2. ACTN Common Interfaces Information Model 152 This section provides ACTN common interface information model to 153 describe in terms of primitives, objects, their properties 154 (represented as attributes), their relationships, and the resources 155 for the service applications needed in the ACTN context. 157 The standard interface is described between a client controller and 158 a server controller. A client-server relationship is recursive 159 between a CNC and an MDSC and between an MDSC and a PNC. In the CMI, 160 the client is a CNC while the server is an MDSC. In the MPI, the 161 client is an MDSC and the server is a PNC. There may also be MDSC- 162 MDSC interface(s) that need to be supported. This may arise in a 163 hierarchy of MDSCs in which workloads may need to be partitioned to 164 multiple MDSCs. 166 Basic primitives (messages) are required between the CNC-MDSC and 167 MDSC-PNC controllers. These primitives can then be used to support 168 different ACTN network control functions like network topology 169 request/query, VN service request, path computation and connection 170 control, VN service policy negotiation, enforcement, routing 171 options, etc. 173 There are two different types of primitives depending on the type of 174 interface: 176 - Virtual Network primitives at CMI 177 - Traffic Engineering primitives at MPI 179 As well described in [ACTN-Frame], at the CMI level, there is no 180 need for detailed TE information since the basic functionality is to 181 translate customer service information into virtual network service 182 operation. 184 At the MPI level, MDSC has the main scope for multi-domain 185 coordination and creation of a single e2e abstracted network view 186 which is strictly related to TE information. 188 As for topology, this document employs two types of topology: 190 - The first type is referred to as virtual network topology which 191 is associated with a VN. Virtual network topology is a 192 customized topology for view and control by the customer. See 193 Section 3.1 for details. 195 - The second type is referred to as TE topology which is 196 associated with provider network operation on which we can 197 apply policy to obtain the required level of abstraction to 198 represent the underlying physical network topology. 200 3. Virtual Network primitives 202 This section provides a list of main VN primitives related to 203 virtual network which are necessary to satisfy ACTN requirements 204 specified in [ACTN-REQ] 205 At a minimum, the following VN Action primitives should be 206 supported: 208 - VN Instantiate 210 - VN Modify 212 - VN Delete 214 - VN Update 216 - VN Path Compute 218 - VN Query 220 VN Action is an object describing the main VN primitives. 222 VN Action can assume one of the mentioned above primitives values. 224 ::= | 226 | 228 | 230 | 232 | 234 236 All these actions will solely happen at CMI level between Customer 237 Network Controller (CNC) and Multi Domain Service Coordinator 238 (MDSC). 240 3.1. VN Instantiate 242 VN Instantiate refers to an action from customers/applications to 243 request the creation of VNs. Depending on the agreement between 244 client and provider, VN instantiate can imply different VN 245 operations. There are two types of VN instantiation: 247 VN type 1: VN is viewed as a set of edge-to-edge links (VN members). 249 VN type 2: VN is viewed as a VN-topology comprising virtual nodes 250 and virtual links. 252 Please see [ACTN-Frame] for full details regarding the types of VN. 254 3.2. VN Modify 256 VN Modify refers to an action issued from customers/applications to 257 modify an existing VN (i.e., an instantiated VN). 259 3.3. VN Delete 261 VN Delete refers to an action issued from customers/applications to 262 delete an existing VN. 264 3.4. VN Update 266 VN Update refers to any update to the VN that needs to be updated to 267 the customers. VN Update fulfills a push model at CMI level, to make 268 customers aware of any specific changes in the topology details 269 related to the instantiated VN. 271 VN Update, depending of the type of VN instantiated, can be an 272 update of VN members (edge-to-edge links) in case of VN type 1, or 273 an update of virtual topology in case of VN type 2. 275 The connection-related information (e.g., LSPs) update association 276 with VNs will be part of the "translation" function that happens in 277 MDSC to map/translate VN request into TE semantics. This information 278 will be provided in case customer optionally wants to have more 279 detailed TE information associated with the instantiated VN. 281 3.5. VN Compute 283 VN Compute consists of Request and Reply. Request refers to an 284 action from customers/applications to request a VN computation. 286 VN Compute Reply refers to the reply in response to VN Compute 287 Request. 289 VN Compute Request/Reply is to be differentiated from a VN 290 Instantiate. The purpose of VN Compute is a priori exploration to 291 compute network resources availability and getting a possible VN 292 view in which path details can be specified matching 293 customer/applications constraints. This a priori exploration may not 294 guarantee the availability of the computed network resources at the 295 time of instantiation. 297 3.6. VN Query 299 VN Query refers to inquiry pertaining to the VN that has been 300 already instantiated. VN Query fulfills a pull model and permit to 301 get topology view. 303 VN Query Reply refers to the reply in response to VN Query. 305 4. Traffic Engineering (TE) primitives 307 This section provides a list of main TE primitives necessary to 308 satisfy ACTN requirements specified in [ACTN-REQ] related to typical 309 TE operations supported at MPI level. 311 At a minimum, the following TE action primitives should be 312 supported: 314 - TE Instantiate/Modify/Delete 316 - TE Topology Update (See Section 4.4. for the description) 318 - Path Compute 320 TE Action is an object describing the main TE primitives. 322 TE Action can assume one of the mentioned above primitives values. 324 ::= | 326 | 328 | 330 | 332 | 334 All these actions will solely happen at MPI level between Multi 335 Domain Service Coordinator (MDSC) and Provisioning Network 336 Controller (PNC). 338 4.1. TE Instantiate 340 TE Instantiate refers to an action issued from MDSC to PNC to 341 instantiate new TE tunnels. 343 4.2. TE Modify 345 TE Modify refers to an action issued from MDSC to PNC to modify 346 existing TE tunnels. 348 4.3. TE Delete 350 TE Delete refers to an action issued from MDSC to PNC to delete 351 existing TE tunnels. 353 4.4. TE Topology Update (for TE resources) 355 TE Topology Update is a primitive specifically related to MPI to 356 provide TE resource update between any domain controller towards 357 MDSC regarding the entire content of any "domain controller" actual 358 TE topology or an abstracted filtered view of TE topology depending 359 on negotiated policy. 361 See [TE-TOPO] for detailed YANG implementation of TE topology 362 update. 364 ::= 366 ::= [] 368 ::= [] 371 ::= [] 373 ::= 375 ::= [] 377 ::= [] 379 Where 381 Abstraction provides information on level of abstraction (as 382 determined a priori). 384 TE-topology-identifier is an identifier that identifies a specific 385 te-topology, e.g., te-types:te-topology-id [TE-TOPO]. 387 Node-list is detailed information related to a specific node 388 belonging to a te-topology, e.g., te-node-attributes [TE-TOPO]. 390 Link-list is information related to the specific link related 391 belonging to a te-topology, e.g., te-link-attributes [TE-TOPO]. 393 TE Termination Point-list is detailed information associated with 394 the termination points of te-link related to a specific node, e.g., 395 interface-switching-capability [TE-TOPO]. 397 4.5. Path Compute 399 Path Compute consists of Request and Reply. Request refers to an 400 action from MDSC to PNC to request a path computation. 402 Path Compute Reply refers to the reply in response to Path Compute 403 Request. 405 The context of Path Compute is described in [Path-Compute]. 407 5. VN Objects 409 This section provides a list of objects associated to VN action 410 primitives. 412 5.1. VN Identifier 414 VN Identifier is a unique identifier of the VN. 416 5.2. VN Service Characteristics 418 VN Service Characteristics describes the customer/application 419 requirements against the VNs to be instantiated. 421 ::= 423 (...) 425 427 Where 429 ::= |||| 432 The Connectivity Type identifies the type of required VN Service. In 433 addition to the classical type of services (e.g. P2P/P2MP etc.), 434 ACTN defines the "multi-destination" service that is a new P2P 435 service where the end points are not fixed. They can be chosen among 436 a list of pre-configured end points or dynamically provided by the 437 CNC. 439 ::= 441 [] 443 The VN Traffic Matrix represents the traffic matrix parameters for 444 the required the service connectivity. Bandwidth is a mandatory 445 parameter and a number of optional constrains can be specified in 446 the VN Constrains (e.g. diversity, cost). They can include objective 447 functions and TE metrics bounds as specified in [RFC5541]. 449 Further details on the VN constraints are specified below: 451 ::= [] 453 [] 455 [] 457 ( | ) 459 Where: 461 Layer Protocol identifies the layer topology at which the VN 462 service is requested. It could be for example MPLS, ODU, and OCh. 464 Diversity allows asking for diversity constraints for a VN 465 Instantiate/Modify or a VN Path Compute. For example, a new VN or 466 a path is requested in total diversity from an existing one (e.g. 467 diversity exclusion). 469 ::= ( (...)) | 471 ( (...)) 473 Shared Risk is used to get the SRLG associated with the different 474 tunnels composing a VN. Based on the realization of VN required, 475 group of physical resources can be impacted by the same risk. VN 476 member (i.e., edge-to-edge link) can be impacted by this shared 477 risk. 479 Metric can include all the Metrics (cost, delay, delay variation, 480 latency), bandwidth utilization parameters defined and referenced 481 by [RFC3630] and [RFC7471]. 483 As for VN Objective Function See Section 5.4. 485 VN Survivability describes all attributes related to the VN recovery 486 level and its survivability policy enforced by the 487 customers/applications. 489 ::= 491 [] 493 [] 495 Where: 497 VN Recovery Level is a value representing the requested level 498 of resiliency required against the VN. The following values 499 are defined: 501 . Unprotected VN 502 . VN with per tunnel recovery: The recovery level is defined 503 against the tunnels composing the VN and it is specified in 504 the VN Tunnel Recovery Level. 506 ::= <0:1>|<1+1>|<1:1>|<1:N>|| 508 510 The VN Tunnel Recovery Level indicates the type of protection 511 or restoration mechanism applied to the VN. It augments the 512 recovery types defined in [RFC4427]. 514 ::= [] 516 [] 518 [] 520 [] 522 Where: 524 Local Reroute Allowed is a delegation policy to the Server to 525 allow or not a local reroute fix upon a failure of the 526 primary LSP. 528 Domain Preference is only applied on the MPI where the MDSC 529 (client) provides a domain preference to each PNC (server), 530 e.g., when an inter-domain link fails, then PNC can choose 531 the alternative peering with this info. 533 Push Allowed is a policy that allows a server to trigger an 534 updated VN topology upon failure without an explicit request 535 from the client. Push action can be set as default unless 536 otherwise specified. 538 Incremental Update is another policy that triggers an 539 incremental update from the server since the last period of 540 update. Incremental update can be set as default unless 541 otherwise specified. 543 5.3. VN End-Point 545 VN End-Point Object describes the VN's customer end-point 546 characteristics. 548 ::= ( 550 [] 552 [])... 554 Where: 556 Access point identifier represents a unique identifier of the 557 client end-point. They are used by the customer to ask for the 558 setup of a virtual network creation. A VN End-Point is defined 559 against each AP in the network and is shared between customer and 560 provider. Both the customer and the provider will map it against 561 his own physical resources. 563 Access Link Capability identifies the capabilities of the access 564 link related to the given access point. (e.g., max-bandwidth, 565 bandwidth availability, etc.) 567 Source Indicator indicates if an end-point is source or not. 569 5.4. VN Objective Function 571 The VN Objective Function applies to each VN member (i.e., each E2E 572 tunnel) of a VN. 574 The VN Objective Function can reuse objective functions defined in 575 [RFC5541] section 4. 577 For a single path computation, the following objective functions are 578 defined: 580 o MCP is the Minimum Cost Path with respect to a specific 581 metric (e.g. shortest path). 582 o MLP is the Minimum Load Path, that means find a path 583 composted by te-link least loaded. 584 o MBP is the Maximum residual Bandwidth Path. 586 For a concurrent path computation, the following objective functions 587 are defined: 589 o MBC is to Minimize aggregate Bandwidth Consumption. 590 o MLL is to Minimize the Load of the most loaded Link. 591 o MCC is to Minimize the Cumulative Cost of a set of paths. 593 5.5. VN Action Status 595 VN Action Status is the status indicator whether the VN has been 596 successfully instantiated, modified, or deleted in the server 597 network or not in response to a particular VN action. 599 Note that this action status object can be implicitly indicated and 600 thus not included in any of the VN primitives discussed in Section 601 3. 603 5.6. VN Topology 605 When a VN is seen by the customer as a topology, it is referred to 606 as VN topology. This is associated with VN Type 2, which is 607 comprised of virtual nodes virtual and links. 609 ::= 611 ::= [] 613 :: = [] 615 5.7. VN Member 617 VN Member describes details of a VN Member which is a list of a set 618 of VN Members represented as VN_Member_List. 620 ::= [] 622 Where ::= 624 [] 626 628 Ingress VN End-Point is the VN End-Point information for the ingress 629 portion of the AP. See Section 5.3 for VN End-Point details. 631 Egress VN End-Point is the VN End-Point information for the egress 632 portion of the AP. See Section 5.3 for VN End-Point details. 634 VN Associated LSP describes the instantiated LSPs in the Provider's 635 network for the VN Type 1. It describes the instantiated LSPs over 636 the VN topology for VN Type 2. 638 5.7.1. VN Computed Path 640 The VN Computed Path is the list of paths obtained after the VN path 641 computation request from higher controller. Note that the computed 642 path is to be distinguished from the LSP. When the computed path is 643 signaled in the network (and thus the resource is reserved for that 644 path), it becomes an LSP. 646 ::= (...) 648 5.7.2. VN Service Preference 650 This section provides VN Service preference. VN Service is defined 651 in Section 2. 653 ::= [] 655 [] 657 [] 659 Where 661 Location Service Preference describes the End-Point Location's 662 (e.g. Data Centers) support for certain Virtual Network Functions 663 (VNFs) (e.g., security function, firewall capability, etc.) and 664 is used to find the path that satisfies the VNF constraint. 666 Client-specific Preference describes any preference related to 667 Virtual Network Service (VNS) that application/client can enforce 668 via CNC towards lower level controllers. For example, permission 669 the correct selection from the network of the destination related 670 to the indicated VNF It is e.g. the case of VM migration among 671 data center and CNC can enforce specific policy that can permit 672 MDSC/PNC to calculate the correct path for the connectivity 673 supporting the data center interconnection required by 674 application. 676 End-Point Dynamic Selection Preference describes if the End-Point 677 (e.g. Data Center) can support load balancing, disaster recovery 678 or VM migration and so can be part of the selection by MDSC 679 following service Preference enforcement by CNC. 681 6. TE Objects 683 6.1. TE Tunnel Characteristics 685 Tunnel Characteristics describes the parameters needed to configure 686 TE tunnel. 688 ::= [] 690 692 [] 694 [] 696 [] 698 700 [] 702 Where 704 ::= ||| 706 The Tunnel Type identifies the type of required tunnel. In this 707 draft, only P2P model is provided. 709 Tunnel Id is the TE tunnel identifier. 711 Tunnel Layer represents the layer technology of the LSPs 712 supporting the tunnel. 714 ::= 716 ::= ||||prot | 719 Tunnel Constraints are the base tunnel configuration constraints 720 parameters. 722 Where ::= [] 724 [] 726 [] 728 [] 730 [] 732 [] 734 [] 736 Topology Id references the topology used to compute the tunnel path. 738 Bandwidth is the bandwidth used as parameter in path computation 740 ::= | | 742 Disjointness provides the type of resources from which the tunnel 743 has to be disjointed 745 SRLG is a group of physical resources impacted by the same risk from 746 which an E2E tunnel is required to be disjointed. 748 ::= 750 where 752 Setup Priority indicates the level of priority to taking resources 753 from another tunnel [RFC3209] 755 Holding Priority indicates the level of priority to hold resources 756 avoiding preemption from another tunnel [RFC3209] 758 Affinities represent structure to validate link belonging to path 759 of the tunnel [RFC3209] 761 ::= | 763 Metric can include all the Metrics (cost, delay, delay variation, 764 latency), bandwidth utilization parameters defined and referenced by 765 [RFC3630] and [RFC7471]. 767 ::= 769 ::= | | | | 770 | 771 See chapter 5.4 for objective function type description. 773 7. Mapping of VN Primitives with VN Objects 775 This section describes the mapping of VN Primitives with VN Objects 776 based on Section 5. 778 ::= 780 782 [] 784 [] 786 ::= 788 790 792 [] 794 [] 796 ::= 798 :: = 800 [] 802 [] 804 ::= 805 807 [] 809 ::= 811 ::= 813 ::= 815 817 [] 819 8. Mapping of TE Primitives with TE Objects 821 This section describes the mapping of TE Primitives with TE Objects 822 based on Section 6. 824 ::= 826 ::= 828 ::= 830 :: = 832 ::= 833 ::= 835 837 9. Security Considerations 839 The ACTN information model described in this document defines key 840 interfaces for managed traffic engineered networks. Securing the 841 request and control of resources, confidentially of the information, 842 and availability of function are critical security considerations 843 when deploying and operating ACTN platforms. 845 Several distributed ACTN functional components are required, and 846 implementations should consider encrypting data that flows between 847 components, especially when they are implemented at remote nodes, 848 regardless these data flows are on external or internal network 849 interfaces. 851 From a security and reliability perspective, ACTN may encounter many 852 risks such as malicious attack and rogue elements attempting to 853 connect to various ACTN components. Furthermore, some ACTN 854 components represent a single point of failure and threat vector, 855 and must also manage policy conflicts, and eavesdropping of 856 communication between different ACTN components. 858 The conclusion is that all data models and protocols used to realize 859 the ACTN info model should have rich security features, and 860 customer, application and network data should be stored in encrypted 861 data stores. Additional security risks may still exist. Therefore, 862 discussion and applicability of specific security functions and 863 protocols will be better described in documents that are use case 864 and environment specific. 866 10. IANA Considerations 868 This document has no actions for IANA. 870 11. References 872 11.1. Normative References 874 [ACTN-REQ] Y. Lee, et al., "Requirements for Abstraction and Control 875 of Transport Networks", draft-ietf-teas-actn-requirements, 876 work in progress. 878 [ACTN-Frame] D. Ceccarelli and Y. Lee, "Framework for Abstraction 879 and Control of Transport Networks, draft-ietf-teas-actn- 880 framework, work in progress. 882 11.2. Informative References 884 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 885 draft-ietf-teas-yang-te-topo, work in progress. 887 [RFC3209] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP 888 Tunnels", RFC 3209, December 2001. 890 [RFC3630] D. Katz, K. Kompella, D. Yeung, "Traffic Engineering (TE) 891 Extensions to OSPF Version 2", RFC 3630, September 2003. 893 [RFC4427] E. Mannie, D. Papadimitriou (Editors), "Recovery 894 (Protection and Restoration) Terminology for Generalized 895 Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 896 2006. 898 [RFC5541] JL. Le Roux, JP. Vasseur and Y. Lee, "Encoding of 899 Objective Functions in the Path Computation Element 900 Communication Protocol (PCEP)", RFC 5541, June 2009. 902 [RFC7471] S. Giacalone, et al, "OSPF Traffic Engineering (TE) Metric 903 Extensions", RFC 7471, March 2015. 905 [RFC7926] A. Farrel, et al., "Problem Statement and Architecture for 906 Information Exchange between Interconnected Traffic- 907 Engineered Networks", RFC 7926, July 2016. 909 [Path-Compute] I. Busi, S. Belotti, et al., "Yang model for 910 requesting Path Computation", draft-ietf-teas-yang-path- 911 computation", work in progress. 913 12. Contributors 915 Contributors' Addresses 917 Haomian Zheng 918 Huawei Technologies 919 Email: zhenghaomian@huawei.com 921 Xian Zhang 922 Huawei Technologies 923 Email: zhang.xian@huawei.com 925 Authors' Addresses 927 Young Lee (Editor) 928 Huawei Technologies 929 5340 Legacy Drive 930 Plano, TX 75023, USA 931 Phone: (469)277-5838 932 Email: leeyoung@huawei.com 934 Sergio Belotti (Editor) 935 Alcatel Lucent 936 Via Trento, 30 937 Vimercate, Italy 938 Email: sergio.belotti@alcatel-lucent.com 940 Dhruv Dhody 941 Huawei Technologies, 942 Divyashree Technopark, Whitefield 943 Bangalore, India 944 Email: dhruv.ietf@gmail.com 945 Daniele Ceccarelli 946 Ericsson 947 Torshamnsgatan,48 948 Stockholm, Sweden 949 Email: daniele.ceccarelli@ericsson.com 951 Bin Yeong Yoon 952 ETRI 953 Email: byyun@etri.re.kr