Teas Working Group Young LeeInternetDraftEngineering Task Force (IETF) Y. Lee Request for Comments: 8454 HuaweiIntended status:Category: InformationalSergioS. Belotti ISSN: 2070-1721 NokiaExpires: December 21, 2018 DhruvD. Dhody HuaweiDanieleD. Ceccarelli EricssonBin YeongB. Yoon ETRIJune 21,September 2018 Information Model for Abstraction and Control of TE Networks (ACTN)draft-ietf-teas-actn-info-model-10.txtAbstract Thisdraftdocument provides an information model for Abstraction and Control ofTraffic EngineeredTE Networks (ACTN). Status ofthisThis Memo ThisInternet-Draftdocument issubmitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force(IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum(IETF). It represents the consensus ofsix monthsthe IETF community. It has received public review andmay be updated, replaced, or obsoletedhas been approved for publication byotherthe Internet Engineering Steering Group (IESG). Not all documentsatapproved by the IESG are candidates for anytime. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listlevel of Internet Standard; see Section 2 of RFC 7841. Information about the currentInternet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The liststatus ofInternet-Draft Shadow Directories canthis document, any errata, and how to provide feedback on it may beaccessedobtained athttp://www.ietf.org/shadow.html. This Internet-Draft will expire on December 21, 2018.https://www.rfc-editor.org/info/rfc8454. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents(http://trustee.ietf.org/license-info)(https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1.Introduction...................................................3Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.Terminology...............................................4Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. ACTN Common Interfaces InformationModel.......................4Model . . . . . . . . . . 5 3. Virtual Networkprimitives.....................................5Primitives . . . . . . . . . . . . . . . . . 6 3.1. VNInstantiate............................................6Instantiate . . . . . . . . . . . . . . . . . . . . . 7 3.2. VNModify.................................................7Modify . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. VNDelete.................................................7 3.4. VN Update.................................................7 3.5.Delete . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. VNCompute................................................7Update . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. VN Compute . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. VNQuery..................................................8Query . . . . . . . . . . . . . . . . . . . . . . . . 8 4.Traffic Engineering (TE) primitives............................8TE Primitives . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. TEInstantiate............................................9Instantiate . . . . . . . . . . . . . . . . . . . . . 9 4.2. TEModify.................................................9Modify . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. TEDelete.................................................9Delete . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. TE Topology Update (for TEresources).....................9Resources) . . . . . . . . . . 9 4.5. PathCompute.............................................10Compute . . . . . . . . . . . . . . . . . . . . . . 10 5. VNObjects....................................................10Objects . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. VNIdentifier............................................11Identifier . . . . . . . . . . . . . . . . . . . . . . 11 5.2. VN ServiceCharacteristics...............................11Characteristics . . . . . . . . . . . . . . . 11 5.3. VNEnd-Point.............................................13Endpoint . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. VN ObjectiveFunction....................................14Function . . . . . . . . . . . . . . . . . . 14 5.5. VN ActionStatus.........................................15Status . . . . . . . . . . . . . . . . . . . . 14 5.6. VNTopology..............................................15Topology . . . . . . . . . . . . . . . . . . . . . . . 15 5.7. VNMember................................................15Member . . . . . . . . . . . . . . . . . . . . . . . . 15 5.7.1. VN ComputedPath....................................16Path . . . . . . . . . . . . . . . . . . 15 5.7.2. VN ServicePreference...............................16Preference . . . . . . . . . . . . . . . . 16 6. TEObjects....................................................17Objects . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. TE TunnelCharacteristics................................17Characteristics . . . . . . . . . . . . . . . . 17 7. Mapping of VNprimitivesPrimitives with VNObjects......................19Objects . . . . . . . . . . 19 8. Mapping of TEprimitivesPrimitives with TEObjects......................20Objects . . . . . . . . . . 20 9. SecurityConsiderations.......................................21Considerations . . . . . . . . . . . . . . . . . . . 20 10. IANAConsiderations..........................................22Considerations . . . . . . . . . . . . . . . . . . . . . 21 11.References...................................................22References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. NormativeReferences....................................22References . . . . . . . . . . . . . . . . . . 21 11.2. InformativeReferences..................................22 12. Contributors.................................................23 Contributors' Addresses..........................................23References . . . . . . . . . . . . . . . . . 21 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors'Addresses...............................................23Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Thisdraftdocument provides an information model for Abstraction and Control ofTraffic EngineeredTE Networks (ACTN). The information model described in this document covers the interface requirements identified in the ACTNarchitecture and frameworkFramework document[ACTN- Frame].[RFC8453]. The ACTN reference architecture[ACTN-Frame][RFC8453] identifies a three-tier control hierarchy comprising the following as depicted in Figure 1:-o Customer Network Controllers (CNCs)-o Multi-Domain Service Coordinator (MDSC)-o Provisioning Network Controllers(PNCs).(PNCs) +-------+ +-------+ +-------+ | CNC-A | | CNC-B | | CNC-C | +-------+ +-------+ +-------+ \ | / ------------ | CMI ------------- \ | / +----------------------+ | MDSC | +----------------------+ / | \ ------------ | MPI ------------- / | \ +-------+ +-------+ +-------+ | PNC | | PNC | | PNC | +-------+ +-------+ +-------+ Figure 1: AThree-tierThree-Tier ACTNcontrol hierarchyControl Hierarchy The two interfaces with respect to the MDSC, one north of the MDSC and the other south of theMDSCMDSC, are referred to asCMI"CMI" (CNC-MDSC Interface) andMPI"MPI" (MDSC-PNC Interface), respectively. This document models these two interfaces and derivative interfaces thereof (e.g.,MDSC to MDSCMDSC-to-MDSC in a hierarchy of MDSCs) as a single common interface. 1.1. Terminology The terms "Virtual Network (VN)" and "Virtual Network Service (VNS)" are defined in[ACTN-Frame] and the other[RFC8453]. Other key termssuch as "abstraction", "abstract topology", "Path", "VN node",and"VN link" are definedconcepts, for example, "abstraction", can be found in [RFC7926]. 2. ACTN Common Interfaces Information Model This section provides an ACTN common interface information model to describe primitives, objects, their properties (represented as attributes), their relationships, and the resources for the service applications needed in the ACTN context. The standard interface is described between a client controller and a server controller. A client-server relationship is recursive between a CNC and an MDSC and between an MDSC and a PNC. In the CMI, the client is a CNC while the server is an MDSC. In the MPI, the client is an MDSC and the server is a PNC. There may also beMDSC- MDSC interface(s)MDSC-MDSC interfaces that need to be supported. This may arise in a hierarchy of MDSCs in which workloads may need to be partitioned to multiple MDSCs. Basic primitives (messages) are required between the CNC-MDSC and MDSC-PNC controllers. These primitives can then be used to support different ACTN network control functions like network topologyrequest/query,requests/queries, VN servicerequest,requests, path computation and connection control, VN service policy negotiation, enforcement, routing options, etc. There are two different types of primitives depending on the type of interface:-o Virtual Network primitives at CMI-o Traffic Engineering primitives at MPI As well described in[ACTN-Frame],[RFC8453], at the CMI level, there is no need for detailed TE information since the basic functionality is to translate customer service information intovirtual network serviceVNS operation. At the MPI level, MDSC has the main scope for multi-domain coordination and creation of a singlee2eend-to-end (E2E) abstracted network viewwhichthat is strictly related to TE information. As for topology, this document employs two types oftopology: -topology. o The first type is referred to asvirtual"virtual networktopology whichtopology" and is associated with a VN. Virtual network topology is a customized topology for view and control by the customer. See Section 3.1 for details.-o The second type is referred to asTE topology which"TE topology" and is associated with provider network operation on which we can apply policy to obtain the required level of abstraction to represent the underlying physical network topology. 3. Virtual NetworkprimitivesPrimitives This section provides a list of main VN primitives related tovirtual network whichVNs and that are necessary to satisfy the ACTN requirements specified in[ACTN-REQ][ACTN-REQ]. The following VN Action primitives are supported:-o VN Instantiate-o VN Modify-o VN Delete-o VN Update-o VN Path Compute-o VN Query VN Action is an object describing the main VN primitives. VN Action can assume one of the mentioned above primitives values. <VN Action> ::= <VN Instantiate> | <VN Modify> | <VN Delete> | <VN Update> | <VN Path Compute> | <VN Query> All these actions will solely happen at CMI level betweenCustomer Network Controller (CNC)CNC andMulti Domain Service Coordinator (MDSC).MDSC. 3.1. VN Instantiate VN Instantiate refers to an action from customers/applications to request the creation of VNs. VN Instantiate is for CNC-to-MDSC communication. Depending on the agreement between client and provider, VN instantiate can imply different VN operations. There are two types of VN instantiation: VNtypeType 1: VN is viewed as a set of edge-to-edge links (VN members). VNtypeType 2: VN is viewed as a VN-topology comprising virtual nodes and virtual links. Please see[ACTN-Frame][RFC8453] for full details regarding the types of VN. 3.2. VN Modify VN Modify refers to an action issued from customers/applications to modify an existing VN (i.e., an instantiated VN). VN Modify is for CNC-to-MDSC communication. VN Modify, depending of the type of VN instantiated, canbebe: 1. a modification of the characteristics of VN members (edge-to-edge links) in the case of VNtypeType 1, or 2. a modification of an existing virtual topology (e.g.,adding/deletingadding/ deleting virtual nodes/links) in the case of VNtypeType 2. 3.3. VN Delete VN Delete refers to an action issued from customers/applications to delete an existing VN. VN Delete is for CNC-to-MDSC communication. 3.4. VN UpdateVN Update"VN Update" refers to any update to the VN that needs to be updated to the customers. VN Update is MDSC-to-CNC communication. VN Update fulfills a push model at the CMI level,to makemaking customers aware of any specific changes in the topology details related to the instantiated VN. VN Update, depending of the type of VN instantiated, canbebe: 1. an update of VN members (edge-to-edge links) in case of VNtypeType 1, or 2. an update of virtual topology in case of VNtypeType 2. The connection-related information (e.g.,LSPs)Label Switched Paths (LSPs)) update association with VNs will be part of the "translation" function that happens in MDSC to map/translate VN request into TE semantics. This information will be provided in case the customer optionally wants to havemore detailedmore-detailed TE information associated with the instantiated VN. 3.5. VN Compute VN Compute consists of a Request and Reply.Request"VN Compute Request" refers to an action from customers/applications to request a VN computation.VN"VN ComputeReplyReply" refers to the reply in response to VN Compute Request. A VN Compute Request/Reply is to be differentiated from a VN Instantiate. The purpose of VN Compute is a priori exploration to compute network resources availability and getting a possible VN view in which path details can be specified matching customer/applications constraints. This a priori exploration may not guarantee the availability of the computed network resources at the time of instantiation. 3.6. VN QueryVN Query"VN Query" refers to an inquiry pertaining to a VN that has already been instantiated. VN Query fulfills a pull model that permits getting a topology view.VN"VN QueryReplyReply" refers to the reply in response to a VN Query. The topology view returned by a VN Query Reply would be consistent with the topology type instantiated for any specific VN. 4.Traffic Engineering (TE) primitivesTE Primitives This section provides a list of the main TE primitives necessary to satisfy ACTN requirements specified in [ACTN-REQ] related to typical TE operations supported at the MPI level. The TE action primitives defined in this section should be supported at the MPI consistently with the type of topology defined at the CMI. The following TE action primitives are supported:-o TE Instantiate/Modify/Delete-o TE Topology Update(See(see Section 4.4. for the description)-o Path Compute TE Action is an object describing the main TE primitives. TE Action can assume one of the mentioned above primitives values. <TE Action> ::= <TE Instantiate> | <TE Modify> | <TE Delete> | <TE Topology Update> | <Path Compute> | All these actions will solely happen at MPI level betweenMulti Domain Service Coordinator (MDSC)MDSC andProvisioning Network Controller (PNC).PNC. 4.1. TE InstantiateTE Instantiate"TE Instantiate" refers to an action issued from MDSC to PNC to instantiate new TE tunnels. 4.2. TE ModifyTE Modify"TE Modify" refers to an action issued from MDSC to PNC to modify existing TE tunnels. 4.3. TE DeleteTE Delete"TE Delete" refers to an action issued from MDSC to PNC to delete existing TE tunnels. 4.4. TE Topology Update (for TEresources)Resources) TE Topology Update is a primitive specifically related to MPI used to provide a TE resource update between any domain controllertowardsand MDSC regarding the entire content of any"domain controller"actual TE topology of a domain controller or an abstracted filtered view of TE topology depending on negotiated policy. See [TE-TOPO] for detailed YANG implementation of TE topology update. <TE Topology Update> ::= <TE-topology-list> <TE-topology-list> ::= <TE-topology> [<TE-topology-list>] <TE-topology> ::= [<Abstraction>] <TE-Topology-identifier> <Node- list> <Link-list> <Node-list> ::= <Node>[<Node-list>] <Node> ::= <Node> <TE Termination Point-list> <TE Termination Point-list> ::= <TE Termination Point> [<TE- Termination Point-list>] <Link-list> ::= <Link>[<Link-list>] Where Abstraction provides information on the level of abstraction (as determined a priori). TE-topology-identifier is an identifier that identifies a specific te-topology, e.g., te-types:te-topology-id [TE-TOPO]. Node-list is detailed information related to a specific node belonging to a te-topology, e.g., te-node-attributes [TE-TOPO]. Link-list is information related to the specific link related belonging to a te-topology, e.g., te-link-attributes [TE-TOPO]. TE Termination Point-list is detailed information associated with the termination points of a te-link related to a specific node, e.g., interface-switching-capability [TE-TOPO]. 4.5. Path Compute Path Compute consists of Request and Reply.Request"Path Compute Request" refers to an action from MDSC to PNC to request a path computation.Path"Path ComputeReplyReply" refers to the reply in response to the Path Compute Request. The context of Path Compute is described in [Path-Compute]. 5. VN Objects This section provides a list of objects associated to VN action primitives. 5.1. VN Identifier A VN Identifier is a unique identifier of the VN. 5.2. VN Service Characteristics VN Service Characteristics describes the customer/application requirements against the VNs to be instantiated. <VN Service Characteristics> ::= <VN Connectivity Type> <VN Directionality> (<VN Traffic Matrix>...) <VN Survivability> Where <VN Connectivity Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P>|<Multi- destination> The Connectivity Type identifies the type of required VN Service. In addition to the classicaltypetypes of services(e.g. P2P/P2MP(e.g., P2P/P2MP, etc.), ACTN defines the "multi-destination" service that is a new P2P service where theend pointsendpoints are not fixed. They can be chosen among a list ofpre-configured end pointspreconfigured endpoints or dynamically provided by the CNC. VN Directionality indicates if a VN is unidirectional or bidirectional. This implies that each VN member that belongs to the VN has the same directionality as the VN. <VN Traffic Matrix> ::= <Bandwidth> [<VN Constraints>] The VN Traffic Matrix represents the traffic matrix parameters for the required service connectivity. Bandwidth is a mandatoryparameterparameter, and a number of optional constraints can be specified in the VN Constraints(e.g.(e.g., diversity, cost). They can include objective functions and TEmetricsmetric bounds as specified in [RFC5541]. Further details on the VN constraints are specified below: <VN Constraints> ::= [<Layer Protocol>] [<Diversity>] ( <Metric> | <VN Objective Function> ) Where: Layer Protocol identifies the layer topology at which the VN service is requested. It couldbebe, forexampleexample, MPLS,ODU,Optical Data Unit (ODU), andOCh.Optical Channel (OCh). Diversity allows asking for diversity constraints for a VN Instantiate/Modify or a VN Path Compute. For example, a new VN or a path is requested in total diversity from an existing one(e.g.(e.g., diversity exclusion). <Diversity> ::= (<VN-exclusion> (<VN-id>...)) | (<VN-Member-exclusion> (<VN-Member-id>...)) Metric can include all the Metrics (cost, delay, delay variation,latency),latency) and bandwidth utilization parameters defined and referenced by [RFC3630] and [RFC7471]. As for VN ObjectiveFunction SeeFunction, see Section 5.4. VN Survivability describes all attributes related to the VN recovery level and its survivability policy enforced by thecustomers/applications.customers/ applications. <VN Survivability> ::= <VN Recovery Level> [<VN Tunnel Recovery Level>] [<VN Survivability Policy>] Where: VN Recovery Level is a value representing the requested level of resiliency required against the VN. The following values are defined:.o Unprotected VN.o VN with per tunnel recovery: The recovery level is defined against the tunnels composing theVNVN, and it is specified in the VN Tunnel Recovery Level. <VN Tunnel Recovery Level> ::= <0:1>|<1+1>|<1:1>|<1:N>|<M:N>| <On the fly restoration> The VN Tunnel Recovery Level indicates the type of protection or restoration mechanism applied to the VN. It augments the recovery types defined in [RFC4427]. <VN Survivability Policy> ::= [<Local Reroute Allowed>] [<Domain Preference>] [<Push Allowed>] [<Incremental Update>] Where: Local Reroute Allowed is a delegation policy to the Serverto allowon whether or not to allow a local reroute fix upon a failure of the primary LSP. Domain Preference is only applied on the MPI where the MDSC (client) provides a domain preference to each PNC (server), e.g., when an inter-domain link fails, then PNC can choose the alternative peering with this info. Push Allowed is a policy that allows a server to trigger an updated VN topology upon failure without an explicit request from the client. Push action can be set as default unless otherwise specified. Incremental Update is another policy that triggers an incremental update from the server since the last period of update. Incremental update can be set as default unless otherwise specified. 5.3. VNEnd-PointEndpoint VN End-Point Object describes the VN's customerend-pointendpoint characteristics. <VN End-Point> ::= (<Access Point Identifier> [<Access Link Capability>] [<Source Indicator>])... Where: Access Point Identifier represents a unique identifier of the clientend-point.endpoint. They are used by the customer to ask for the setup of a virtual network instantiation. A VN End-Point is defined against each AP in the network and is shared between customer and provider. Both the customer and the provider will map it against their own physical resources. Access Link Capability identifies the capabilities of the access link related to the given accesspoint.point (e.g., max-bandwidth, bandwidth availability,etc.)etc.). Source Indicator indicatesifwhether or not anend-pointendpoint issource or not.the source. 5.4. VN Objective Function The VN Objective Function applies to each VN member (i.e., each E2E tunnel) of a VN. The VN Objective Function can reuse objective functions defined in[RFC5541] section 4.Section 4 of [RFC5541]. For a single path computation, the following objective functions are defined: o MCP is the Minimum Cost Path with respect to a specific metric(e.g.(e.g., shortest path). o MLP is the Minimum Load Path,that meansmeaning find a path composted byte-linkte- link least loaded. o MBP is the Maximum residual Bandwidth Path. For a concurrent path computation, the following objective functions are defined: o MBC is to Minimize aggregate Bandwidth Consumption. o MLL is to Minimize the Load of the most loaded Link. o MCC is to Minimize the Cumulative Cost of a set of paths. 5.5. VN Action Status VN Action Status is the status indicator whether or not the VN has been successfully instantiated, modified, or deleted in the server networkor notin response to a particular VN action. Note that this action status object can be implicitly indicatedand thusand, thus, not included in any of the VN primitives discussed in Section 3. 5.6. VN Topology When a VN is seen by the customer as a topology, it is referred to asVN topology."VN topology". This is associated with VN Type 2, which is composed of virtual nodes and virtual links. <VN Topology> ::=<VN<Virtual node list><VN<Virtual link list><VN<Virtual node list> ::=<VN<Virtual node>[<VN[<Virtual node list>]<VN<Virtual link list> :: =<VN<Virtual link>[<VN[<Virtual link list>] 5.7. VN Member VN Member describes details of a VN Memberwhichthat is a list of a set of VN Members represented as VN_Member_List. <VN_Member_List> ::= <VN Member> [<VN_Member_List>] Where <VN Member> ::= <Ingress VN End-Point> [<VN Associated LSP>] <Egress VN End-Point> Ingress VN End-Point is the VN End-Point information for the ingress portion of the AP. See Section 5.3 for VN End-Point details. Egress VN End-Point is the VN End-Point information for the egress portion of the AP. See Section 5.3 for VN End-Point details. VN Associated LSP describes the instantiated LSPs in the Provider's network for the VN Type 1. It describes the instantiated LSPs over the VN topology for VN Type 2. 5.7.1. VN Computed Path The VN Computed Path is the list of paths obtained after the VN path computation request from a higher controller. Note that the computed path is to be distinguished from the LSP. When the computed path is signaled in the network (and thus the resource is reserved for that path), it becomes an LSP. <VN Computed Path> ::= (<Path>...) 5.7.2. VN Service Preference This section provides the VN Service preference. VN Service is defined in Section 2. <VN Service Preference> ::= [<Location Service Preference >] [<Client-specific Preference >] [<End-Point Dynamic Selection Preference >] Where Location Service Preference describes the End-Point Location's(e.g. Data Centers)(e.g., data centers (DCs)) support for certain Virtual Network Functions (VNFs) (e.g., security function, firewall capability, etc.) and is used to find the path that satisfies the VNF constraint. Client-specific Preference describes any preference related toVirtual Network Service (VNS)VNS that an application/client can enforce via CNC towardslower levellower-level controllers. For example, CNC can enforce client-specific preferences, e.g., selection of a destinationdata centerDC from the set of candidatedata centersDCs based on some criteria in the context ofVMVirtual Machine (VM) migration. MSDC/PNC should then provide thedata centerDC interconnection that supports theclient-specific preference.Client-specific Preference. End-Point Dynamic Selection Preference describes if theEnd-Point (e.g. Data Center)endpoint (e.g., DC) can supportload balancing,load-balancing, disasterrecoveryrecovery, or VM migration and so can be part of the selection by MDSC following service Preference enforcement by CNC. 6. TE Objects 6.1. TE Tunnel Characteristics Tunnel Characteristics describes the parameters needed to configure TE tunnel. <TE Tunnel Characteristics> ::= [<Tunnel Type>] <Tunnel Id> [<Tunnel Layer>] [<Tunnel end-point>] [<Tunnel protection-restoration>] <Tunnel Constraints> [<Tunnel Optimization>] Where <Tunnel Type> ::= <P2P>|<P2MP>|<MP2MP>|<MP2P> The Tunnel Type identifies the type of required tunnel. In thisdraft,document, only the P2P model is provided. Tunnel Id is the TE tunnel identifier Tunnel Layer represents the layer technology of the LSPs supporting the tunnel <Tunnel End Points> ::= <Source> <Destination> <Tunnel protection-restoration> ::= <prot 0:1>|<prot 1+1>|<prot 1:1>|<prot 1:N>|prot <M:N>|<restoration> Tunnel Constraints are the base tunnel configuration constraints parameters. Where <Tunnel Constraints> ::= [<Topology Id>] [<Bandwidth>] [<Disjointness>] [<SRLG>] [<Priority>] [<Affinities>] [<Tunnel Optimization>] [<Objective Function>] Topology Id references the topology used to compute the tunnel path. Bandwidth is the bandwidth used as a parameter in pathcomputationcomputation. <Disjointness> ::= <node> | <link> | <srlg> Disjointness provides the type of resources from which the tunnel has to bedisjointed SRLGdisjointed. Shared Risk Link Group (SRLG) is a group of physical resources impacted by the same risk from which an E2E tunnel is required to be disjointed. <Priority> ::= <Holding Priority> <Setup Priority> where Setup Priority indicates the level of priority for taking resources from another tunnel[RFC3209][RFC3209]. Holding Priority indicates the level of priority to hold resources avoiding preemption from another tunnel[RFC3209][RFC3209]. Affinitiesit representrepresents the structure to validate a link belonging to the path of the tunnel[RFC3209][RFC3209]. <Tunnel Optimization> ::= <Metric> | <Objective Function> Metric can include all the Metrics (cost, delay, delay variation,latency),latency) and bandwidth utilization parameters defined and referenced by [RFC3630] and [RFC7471]. <Objective Function> ::= <objective function type> <objective function type> ::= <MCP> | <MLP> | <MBP> | <MBC> | <MLL> | <MCC> SeechapterSection 5.4 for a description of objective functiontype description.type. 7. Mapping of VNprimitivesPrimitives with VN Objects This section describes the mapping of VN primitives with VN Objects based on Section 5. <VN Instantiate> ::= <VN Service Characteristics> <VN Member-List> [<VN Service Preference>] [<VN Topology>] <VN Modify> ::= <VN identifier> <VN Service Characteristics> <VN Member-List> [<VN Service Preference>] [<VN Topology>] <VN Delete> ::= <VN Identifier> <VN Update> :: = <VN Identifier> [<VN Member-List>] [<VN Topology>] <VN Path Compute Request> ::= <VN Service Characteristics> <VN Member-List> [<VN Service Preference>] <VN Path Compute Reply> ::= <VN Computed Path> <VN Query> ::= <VN Identifier> <VN Query Reply> ::= <VN Identifier> <VN Associated LSP> [<TE Topology Reference>] 8. Mapping of TEprimitivesPrimitives with TE Objects This section describes the mapping of TE primitives with TE Objects based on Section 6. <TE Instantiate> ::= <TE Tunnel Characteristics> <TE Modify> ::= <TE Tunnel Characteristics> <TE Delete> ::= <Tunnel Id> <TE Topology Update> ::= <TE-topology-list> <Path Compute Request> ::= <TE Tunnel Characteristics> <Path Compute Reply> ::= <TE Computed Path> <TE Tunnel Characteristics> 9. Security Considerations The ACTN information model is not directly relevant when considering potential security issues. Rather, it defines a set of interfaces fortraffic engineeredTE networks. The underlying protocols, procedures, and implementations used to exchange the information model described in thisdraftdocument will need to secure the request and control of resources with proper authentication and authorization mechanisms. In addition, the data exchanged over the ACTN interfaces discussed in this document requires verification of data integrity. Backup or redundancies should also be available to restore the affected data to its correct state. Implementations of the ACTN framework will have distributed functional components that will exchangea concretean instantiation that adheres to this information model. Implementations should encrypt data that flows between them, especially when they are implemented at remote nodes and irrespective of whether these data flows are on external or internal network interfaces. The information model may contain customer,applicationapplication, and network datathatthat, for business or privacyreasonsreasons, may be considered sensitive. It should be stored only in an encrypted data store. The ACTN security discussion is further split into two specific interfaces:-o Interface between theCustomer Network ControllerCNC andMulti Domain Service Coordinator (MDSC),MDSC, CNC-MDSC Interface (CMI)-o Interface between theMulti Domain Service CoordinatorMDSC andProvisioning Network Controller (PNC),PNC, MDSC-PNC Interface(MPI)(MPI). See the detailed discussion of the CMI and MPI in Sections 9.1 and9.2, respectively9.2 (respectively) in[ACTN-Frame].[RFC8453]. The conclusion is that all data models and protocols used to realize the ACTNinfoinformation model should have rich securityfeaturesfeatures, as discussed in this section. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific. 10. IANA Considerations This document has noactions for IANA.IANA actions. 11. References 11.1. Normative References[ACTN-Frame] D.[RFC8453] Ceccarelli,et al.,D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control ofTransport Networks", draft-ietf-teas-actn- framework, work in progress.TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>. 11.2. Informative References[TE-TOPO] Liu, X. et al., "YANG Data Model[ACTN-REQ] Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. Lee, "Requirements for Abstraction and Control of TETopologies", draft-ietf-teas-yang-te-topo, workNetworks", Work in Progress, draft-ietf-teas-actn-requirements-09, March 2018. [Path-Compute] Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., Sharma, A., Shi, Y., Vilata, R., and K. Sethuraman, "Yang model for requesting Path Computation", Work inprogress.Progress, draft-ietf-teas-yang-path-computation-02, June 2018. [RFC3209]D.Awduche,et al,D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December2001.2001, <https://www.rfc-editor.org/info/rfc3209>. [RFC3630]D.Katz,K.D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September2003.2003, <https://www.rfc-editor.org/info/rfc3630>. [RFC4427]E.Mannie, E., Ed. and D.Papadimitriou (Editors),Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March2006.2006, <https://www.rfc-editor.org/info/rfc4427>. [RFC5541]JL.Le Roux,JP. VasseurJL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June2009.2009, <https://www.rfc-editor.org/info/rfc5541>. [RFC7471]S.Giacalone,et al,S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March2015.2015, <https://www.rfc-editor.org/info/rfc7471>. [RFC7926]A.Farrel,et al.,A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between InterconnectedTraffic- EngineeredTraffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July2016. [Path-Compute] I. Busi, S. Belotti, et al., "Yang model2016, <https://www.rfc-editor.org/info/rfc7926>. [TE-TOPO] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Dios, "YANG Data Model forrequesting Path Computation", draft-ietf-teas-yang-path- computation", workTraffic Engineering (TE) Topologies", Work inprogress. 13.Progress, draft-ietf-teas-yang-te-topo-18, June 2018. ContributorsContributors' AddressesHaomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Authors' Addresses Young Lee (Editor) Huawei Technologies 5340 Legacy Drive Plano, TX 75023, USA Phone: (469)277-5838 Email: leeyoung@huawei.com Sergio Belotti (Editor)Alcatel LucentNokia Via Trento, 30 Vimercate, Italy Email:sergio.belotti@alcatel-lucent.comsergio.belotti@nokia.com Dhruv Dhody Huawei Technologies, Divyashree Technopark, Whitefield Bangalore, India Email: dhruv.ietf@gmail.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden Email: daniele.ceccarelli@ericsson.com Bin Yeong Yoon ETRI Email: byyun@etri.re.kr