TEAS Working Group Y. Lee Internet Draft Q. Wu Intended status: Informational I. Busi Expires: April 20, 2019 Huawei D. Cecarreli Ericsson J. Tantsura Apstra October 19, 2018 Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to VPN with the Integration of Packet and Optical Networks draft-lee-teas-actn-vpn-poi-00 Abstract This document outlines the applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to VPN with the integration of Packet and Optical Networks (POI). It also identifies a number of scenarios where the integration of packet and optical networks is necessary to support VPN service requirements. The role of optical underlay tunnels in the POI is to support certain applications that require a hard isolation with strict deterministic latency and guaranteed constant bandwidth. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents 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 of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Lee, et al. Expires April 2019 [Page 1] Internet-Draft ACTN Applicability to VPN with POI October 2018 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2019. 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) 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.................................................3 1.1. Requirements Language.....................................3 2. Background and Scope.........................................4 3. POI with L2/L3VPN Service Under Single Network Operator Control ................................................................5 3.1. POI with single packet and single optical domain..........5 3.2. POI with multiple packet domains and single optical domain8 3.3. POI with multiple packet domains and multiple optical domains.......................................................10 3.4. Transport of Tunnel and VPN information..................12 3.5. Virtual Switching Instance (VSI) Provisioning for L2VPN..13 3.6. Inter-domain Links Update................................13 3.7. End-to-end Tunnel Management.............................13 4. POI with VN Recursion Under Multiple Network Operators Control ...............................................................14 4.1. Service Request Process between Multiple Operators.......15 4.2. Service/Network Orchestration of Operator 2..............16 5. Security Considerations.....................................16 6. IANA Considerations.........................................17 7. References..................................................17 Lee, et al. Expires April 2019 [Page 2] Internet-Draft ACTN Applicability to VPN with POI October 2018 7.1. Normative References.....................................17 7.2. Informative References...................................17 8. Contributors................................................18 Authors' Addresses.............................................18 1. Introduction Abstraction and Control of Traffic Engineered Networks (ACTN) describes a set of management and control functions used to operate one or more TE networks to construct virtual networks that can be represented to customers and that are built from abstractions of the underlying TE networks so that, for example, a link in the customer's network is constructed from a path or collection of paths in the underlying networks [RFC8453]. This document outlines the applicability of ACTN to VPN with the integration of packet and optical networks which is known as the Packet and Optical Integration (POI). It also identifies a number of scenarios where the integration of packet and optical networks is necessary to support VPN service requirements. The role of optical underlay tunnels in the POI is to support certain applications that require a hard isolation with strict deterministic latency and guaranteed constant bandwidth. Note that there may be other transport technologies that can support the aforementioned service requirements such as TSN or Detnet to name a few. In this particular document, we are focusing on the currently available network settings where packet networks are a client layer to optical transport networks as a server layer. The principle discussed in this document can be applied to other transport technologies when they are available. As ACTN [RFC8453] introduces the role of controllers that facilitate network operations, the scope of this document is how controllers can facilitate L2/3VPN service provisioning in the packet and optical transport networks. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lee, et al. Expires April 2019 [Page 3] Internet-Draft ACTN Applicability to VPN with POI October 2018 2. Background and Scope One of the important functions the MDSC performs is to identify which TE Tunnels should carry the L3VPN traffic and to relay this information to the domain-level controllers to ensure proper Virtual routing and forwarding (VRF) table be populated according to the TE binding requirement for the L3VPN. This function is referred to as TE & service mapping function. The YANG model to provide TE & service mapping function is provided in [TSM]. The role of the TE-service Mapping model [TSM] is to expose the mapping relationship between service models and TE models so that VN/VPN service instantiations provided by the underlying TE networks can be viewed outside of the MDSC. The TE-Service Mapping model also provides service-TE binding information for each service instance so that proper TE tunnel should be created. The TE binding requirement types defined in [TSM] are: a) New VN/Tunnel Binding - A customer could request a VPN service based on VN/Tunnels that are not shared with other existing or future services. This might be to meet VPN isolation requirements. Under this mode, the following sub-categories can be supported: i. Hard Isolation with deterministic characteristics: A customer could request a VPN service using a set of TE Tunnels with deterministic characteristics requirements (e.g., no latency variation) and where that set of TE Tunnels must not be shared with other VPN services and must not compete for bandwidth or other network resources with other TE Tunnels. ii. Hard Isolation: This is similar to the above case but without the deterministic characteristics requirements. iii. Soft Isolation: The customer requests a VPN service using a set of TE tunnels which can be shared with other VPN services. b) VN/Tunnel Sharing - A customer could request a VPN service where new tunnels (or a VN) do not need to be created for each VPN and can be shared across multiple VPNs. Lee, et al. Expires April 2019 [Page 4] Internet-Draft ACTN Applicability to VPN with POI October 2018 c) VN/Tunnel Modify - This mode allows the modification of the properties of the existing VN/tunnel (e.g., bandwidth). This document addresses cases a)-i (hard isolation with deterministic latency) and a)-ii (hard isolation with non- deterministic latency). Both cases warrant consideration of optical undelay bypass tunnels to meet the service requirement. The optical bypass tunnel could be setup via RSVP-TE signaling and thus tunnel label allocation could be done during signaling. It is also possible that PNC and MDSC coordinates to exchange the TE tunnel label information to setup this optical bypass tunnel. This document focuses on the latter case. The multi-hop e-BGP session between ingress and egress for multi- domain case would be setup to exchange VPN routes. The rest of the forwarding action is as per the usual BGP L3VPN handling including the use of TE tunnel. 3. POI with L2/L3VPN Service Under Single Network Operator Control This section provides a set of specific deployment scenarios for POI under single network operator control. Specifically, the following deployment scenarios are discussed in this section: - One optical transport domain overarched by one packet domain (see Section 3.1); - One optical transport domain overarched by multiple packet domains (see Section 3.2); - multiple optical transport domains overarched by multiple packet domains (see Section 3.3). All scenarios are taking place in the context of an upper layer service configuration (e.g., L3VPN) in the packet and optical transport network. Since this document only addresses the procedure for creating optical underlay bypass tunnels, it does not affect MP-BGP MPLS operations for inter-AS scenarios as specified in [RFC4364]. 3.1. POI with single packet and single optical domain This section provides a specific deployment scenario for POI. Specifically, it provides a deployment scenario in which hierarchical controllers (an MDSC and two PNCs, one for packet and Lee, et al. Expires April 2019 [Page 5] Internet-Draft ACTN Applicability to VPN with POI October 2018 one for optical) facilitate optical bypass tunnel across the packet domain and the optical domain. Figure 1 shows this scenario. +----------+ | MDSC | +----------+ | --------- | | +--------+ +--------+ | P-PNC | | O-PNC | +--------+ +--------+ | | | | +----------------------+ CE / PE PE \ CE o--/---o o---\---o \ : : / \ : AS Domain : / +-:------------------:-+ : | : : | : +-:------------------:-+ / : : \ / o..................o \ \ Optical Domain / \ / +----------------------+ Figure 1. One Packet Domain and One Optical Domain The following control sequence describes the scenario depicted in Figure 1. a) The MDSC translates the service instance and its requirement (hard isolation with deterministic latency). b) The MDSC computes the path if there is any feasible path to meet the requirement based on the abstracted topology at hand. Note that there would not be any tunnel in the packet domain to meet this requirement (hard isolation with deterministic latency). c) The MDSC finds a feasible path in the optical domain. d) The MDSC asks the optical PNC to create a tunnel for this VPN instance whose endpoints are the ingress PE and the egress PE Lee, et al. Expires April 2019 [Page 6] Internet-Draft ACTN Applicability to VPN with POI October 2018 of the packet domain, respectively. The MDSC and Optical PNC need to maintain an instance ID for this VPN instance. e) The MDSC asks the Packet PNC to bind a TE-tunnel label (to be allocated by the egress PE to identify the underlay optical tunnel) with the VPN ID and the Ingress and Egress interfaces of the underlay optical tunnel. f) The PNC in turn asks the Egress PE to allocate a TE-tunnel label. The Egress PE allocates a TE-tunnel label, populates the VRF for this VPN instance, and updates the Packet PNC with the allocated TE-tunnel label. Please refer to the note below on the details of this procedure in regard to VPN binding. Note: There are two cases for binding network instance with the TE tunnel label: 1. VRF instance does not exist. 2. VRF instance has already been created. For case 1, the Egress PE needs to bind the TE-tunnel label and the VPN information (e.g., VPN instance name, VPN label, RD, RT, Destination IP address, etc.) and inform this binding information to the packet PNC. g) The packet PNC informs the MDSC the allocated TE-tunnel label for the VPN instance. h) The MDSC informs the optical PNC to bind the TE-tunnel label with the VPN instance, which has been created previously in step d). i) The optical PNC informs this binding information (i.e., ingress/egress interfaces from packet domain and the TE- tunnel label) to the optical ingress switch. j) The packet PNC informs the ingress PE to use the TE-label for this VPN instance. The Ingress PE populates the VRF for the VPN with the TE-label. (Note that the TE-label would need to be PUSHed over the VPN traffic). k) When the packet arrives at the ingress PE, it recognizes the VPN instance and PUSHes the VPN label and the TE-tunnel label and forward the traffic to optical ingress switch. l) The optical ingress switch recognizes the TE-tunnel label and encapsulate the whole data packet including TE-tunnel label into the OTN payload. m) The optical egress switch POPs the ODU label and forwards the data packet to the packet egress PE. n) The packet egress PE POPs the TE-tunnel label and forwards the VPN packets to the destination CE. Lee, et al. Expires April 2019 [Page 7] Internet-Draft ACTN Applicability to VPN with POI October 2018 Note: in steps k) - l), the assumption made was that the packet ingress PE is not OTN-capable router. If the packet ingress PE support channelized OTN interfaces, the data plane behavior in steps k) and l) would change as the following: k') When the packets arrives at the ingress PE, it recognizes the VPN instance and PUSHes the VPN label and the TE-tunnel label and the ODU label and forward the traffic to optical ingress switch. l') The optical ingress switch recognizes the incoming ODU label and swap it to outgoing ODU label. 3.2. POI with multiple packet domains and single optical domain This section provides a specific deployment scenario for POI. Specifically, it provides a deployment scenario in which hierarchical controllers (an MDSC and two packet PNCs and one optical PNC) facilitate optical bypass tunnel across the two packet domains and the optical domain. Figure 2 shows this scenario. +----------+ | MDSC | +----------+ | -------------------|------------------- | | | +--------+ +--------+ +--------+ | P-PNC 1| | O-PNC | | P-PNC 2| +--------+ +--------+ +--------+ | | | | | | +----------------------+ | +----------------------+ CE / PE ASBR \ | / ASBR PE \ CE o--/---o o---\-----|-----/---o o----\--o \ : / | \ : / \ : AS Domain 1 / | \ AS Domain 2 : / +-:--------------------+ | +-------------------:--+ : | : : | : +-:--------------------------------------------------------:--+ / : : \ / o........................................................o \ \ Optical Domain / \ / +-------------------------------------------------------------+ Lee, et al. Expires April 2019 [Page 8] Internet-Draft ACTN Applicability to VPN with POI October 2018 Figure 2. Two Packet Domains and One Optical Domain The control sequence depicted in Figure 2 is same as the control sequence a)-d) in Section 3.1 with the following differences: e) The MDSC asks the Packet PNC 2 to bind a TE-tunnel label (to be allocated by the egress PE to identify the underlay optical tunnel) with the VPN ID and the Ingress and Egress interfaces of the underlay optical tunnel. f) The packet PNC 2 in turn asks the Egress PE to allocate a TE- tunnel label. The Egress PE allocates a TE-tunnel label, populates the VRF for this VPN instance, and updates the packet PNC 2 with the allocated TE-tunnel label. Please refer to the note below on the details of this procedure in regard to VPN binding. Note: There are two cases for binding network instance with the TE tunnel label: 1. VRF instance does not exist. 2. VRF instance has already been created. For case 1, the Egress PE needs to bind the TE-tunnel label and the VPN information (e.g., VPN instance name, VPN label, RD, RT, Destination IP address, etc.) and inform this binding information to the packet PNC 2. g) The packet PNC 2 informs the MDSC the allocated TE-tunnel label for the VPN instance. h) The MDSC informs the packet PNC 1 the allocated TE-tunnel label for the VPN instance. i) The MDSC informs the optical PNC to bind the TE-tunnel label with the VPN instance, which has been created previously in step d). j) The optical PNC informs this binding information (i.e., ingress/egress interfaces from packet domain and the TE- tunnel label) to the optical ingress switch. k) The packet PNC 1 informs the ingress PE in Domain 1 to use the TE-tunnel label for this VPN instance. The Ingress PE in Domain 2 populates the VRF for the VPN and bind with the TE- tunnel label. (Note that the TE-tunnel label would need to be PUSHed over the VPN traffic). l) When the packets arrives at the ingress PE in Domain 1, it recognizes the VPN instance and PUSHes the VPN label and the TE-tunnel label and forward the traffic to optical ingress switch. Lee, et al. Expires April 2019 [Page 9] Internet-Draft ACTN Applicability to VPN with POI October 2018 m) The optical ingress switch recognizes the TE-tunnel label and encapsulate the whole data packet including TE-tunnel label into the OTN payload. n) The optical egress switch POPs the ODU label and forwards the data packet to the packet egress PE. o) The packet egress PE in Domain 2 POPs the TE-tunnel label and forwards the VPN packets to the destination CE. Note: in steps l) - m), the assumption made was that the packet ingress PE is not OTN-capable router. If the packet ingress PE supports channelized OTN interfaces, the data plane behavior in steps l) and m) would change as the following: l') When the packets arrives at the ingress PE, it recognizes the VPN instance and PUSHes the VPN label and the TE-tunnel label and the ODU label and forward the traffic to optical ingress switch. m') The optical ingress switch recognizes the incoming ODU label and swap it to outgoing ODU label. 3.3. POI with multiple packet domains and multiple optical domains This section provides a specific deployment scenario for POI. Specifically, it provides a deployment scenario in which hierarchical controllers (an MDSC and two packet PNCs and two optical PNCs) facilitate optical bypass tunnel across two packet domains and two optical domains. Figure 3 shows this scenario. +----------+ | MDSC | +----------+ | -------------------|------------------- | +--------+ | +--------+ +--------+ 2| +--------+ | P-PNC 1| | O-PNC 1|--+ | P-PNC 2| +--------+ +--------+| +--------+ | | | | | | | | +---------------------- | | +---------------------+ CE / PE ASBR \ | | / ASBR PE \ CE o--/---o o---\-|-------|--/---o o----\--o \ : / | | \ : / Lee, et al. Expires April 2019 [Page 10] Internet-Draft ACTN Applicability to VPN with POI October 2018 \ : AS Domain 1 / | | \ AS Domain 2 : / +-:--------------------+ | | +------------------:--+ : | | : : | | : +-:-------------------------+ +------------------------:--+ / : \ / : \ / o.......................o...\./...o......................o \ \ Optical Domain 1 / \ Optical Domain 2 / \ / \ / +---------------------------+ +---------------------------+ Figure 3. Two Packet Domains and One Optical Domain The control sequence depicted in Figure 3 is same as the control sequence a)-c) in Section 3.1 with the following differences: d) The MDSC asks the optical PNC 1 to create a tunnel for this VPN instance whose endpoints are the ingress PE of the packet domain 1 and the optical inter-domain interface toward optical domain 2; and the optical PNC 2 to create a tunnel for this VPN instance whose endpoints are the optical inter- domain interface from optical domain 1 and the egress PE of the packet domain 2. The MDSC and Optical PNC 1 and PNC 2 need to maintain an instance ID for this VPN instance. e) The MDSC asks the Packet PNC 2 to bind a TE-tunnel label with the VPN ID and the Ingress and Egress interfaces of the underlay optical tunnel. f) The packet PNC 2 in turn asks the Egress PE to allocate a TE- tunnel label. The Egress PE allocates a TE-tunnel label, populates the VRF for this VPN instance, and updates the packet PNC 2 with the allocated TE-tunnel label. Please refer to the note below on the details of this procedure in regard to VPN binding. Note: There are two cases for binding network instance with the TE tunnel label: 1. VRF instance does not exist. 2. VRF instance has already been created. For case 1, the Egress PE needs to bind the TE-tunnel label and the VPN information (e.g., VPN instance name, VPN label, RD, RT, Destination IP address, etc.) and inform this binding information to the packet PNC 2. g) The packet PNC 2 informs the MDSC the allocated TE-tunnel label for the VPN instance. Lee, et al. Expires April 2019 [Page 11] Internet-Draft ACTN Applicability to VPN with POI October 2018 h) The MDSC informs the packet PNC 1 the allocated TE-tunnel label for the VPN instance. i) The MDSC informs the optical PNC 1 and PNC 2 to bind the TE- tunnel label with the instance, which has been created previously in step d). j) The optical PNC 1 informs this binding information (i.e., ingress/egress interfaces from packet domain and the TE- tunnel label) to the optical ingress switch in Domain 1. Likewise, the optical PNC 2 to the optical egress switch in Domain 2. (Note we assume that the optical border switches in Domains 1 and 2 would do the normal OTN switching). k) The packet PNC 1 informs the ingress PE in Domain 1 to use the TE-tunnel label for this VPN instance. The Ingress PE in Domain 2 populates the VRF for the VPN with the TE-label. (Note that the TE-tunnel label would need to be PUSHed over the VPN traffic). l) When the VPN packet arrives at the ingress PE in Domain 1, it recognizes the VPN label and PUSHes the TE-tunnel label and forward the traffic to optical ingress switch in optical domain 1. m) The optical ingress switch in optical domain 1 recognizes the TE-tunnel label and encapsulate the whole data packets including TE-tunnel label into the OTN payload. n) The optical egress switch in optical domain 2 POPs the OTN label and forwards the data packet to the packet egress PE. o) The packet egress PE in Domain 2 POPs the TE-tunnel label and forwards the VPN packet to the destination CE. Note: in steps l) - m), the assumption made was that the packet ingress PE is not OTN-capable router. If the packet ingress PE supports channelized OTN interfaces, the data plane behavior in steps l) and m) would change as the following: l') When the packets arrives at the ingress PE, it recognizes the VPN instance and PUSHes the VPN label and the TE-tunnel label and the ODU label and forward the traffic to optical ingress switch in Domain 1. m') The optical ingress switch in Domain 1 recognizes the incoming ODU label and swap it to outgoing ODU label. 3.4. Transport of Tunnel and VPN information The discussions in Section 3 as to the transport mechanism of the TE-tunnel label used for the underlay bypass tunnel with the VPN instance information has the undertone of making use of the controllers. Note that other mechanisms may also be possible and Lee, et al. Expires April 2019 [Page 12] Internet-Draft ACTN Applicability to VPN with POI October 2018 that such mechanisms are not precluded when solutions are sought out. 3.5. Virtual Switching Instance (VSI) Provisioning for L2VPN The VSI provisioning for L2VPN is similar to the VPN/VRF provision for L3VPN. L2VPN service types include: . Point-to-point Virtual Private Wire Services (VPWSs) that use LDP-signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074]; . Multipoint Virtual Private LAN Services (VPLSs) that use LDP- signaled Pseudowires or L2TP-signaled Pseudowires [RFC6074]; . Multipoint Virtual Private LAN Services (VPLSs) that use a Border Gateway Protocol (BGP) control plane as described in [RFC4761] and [RFC6624]; . IP-Only LAN-Like Services (IPLSs) that are a functional subset of VPLS services [RFC7436]; . BGP MPLS-based Ethernet VPN Services as described in [RFC7432] and [RFC7209]; . Ethernet VPN VPWS specified in [RFC8214] and [RFC7432]. 3.6. Inter-domain Links Update In order to facilitate inter-domain links for the VPN, we assume that the service/network orchestrator would know the inter-domain link status and its resource information (e.g., bandwidth available, protection/restoration policy, etc.) via some mechanisms (which are beyond the scope of this document). We also assume that the inter-domain links are pre-configured prior to service instantiation. 3.7. End-to-end Tunnel Management It is foreseen that the MDSC should control and manage end-to-end tunnels for VPNs per VPN policy. As discussed in [ACTN-Telemetry], the MDSC is responsible to collect domain LSP-level performance monitoring data from domain controllers and to derive and report end-to-end tunnel performance monitoring information to the customer. Lee, et al. Expires April 2019 [Page 13] Internet-Draft ACTN Applicability to VPN with POI October 2018 4. POI with VN Recursion Under Multiple Network Operators Control [RFC8453] briefly introduces a case for the VN supplied to a customer may be built using resources from different technology layers operated by different operators. For example, one operator may run a packet TE network and use optical connectivity provided by another operator. Figure 4, extracted from [RFC8453], shows the case where a customer asks for end-to-end connectivity between CE A and CE B, a virtual network. The customer's CNC makes a request to Operator 1's MDSC. The MDSC works out which network resources need to be configured and sends instructions to the appropriate PNCs. However, the link between Q and R is a virtual link supplied by Operator 2: Operator 1 is a customer of Operator 2. To support this, Operator 1 has a CNC that communicates with Operator 2's MDSC. Note that Operator 1's CNC in Figure 10 is a functional component that does not dictate implementation: it may be embedded in a PNC. Virtual CE A o===============================o CE B Network ----- CNC wants to create a VN Customer | CNC | between CE A and CE B ----- : *********************************************** CMI : Operator 1 --------------------------- | MDSC | --------------------------- : : : : : : ----- ------------- ----- | PNC | | PNC | | PNC | ----- ------------- ----- : : : : : Higher v v : v v Layer CE A o---P-----Q===========R-----S---o CE B Network | : | | : | | ----- | | | CNC | | CNC wants to create a VN | ----- | between Q and R Lee, et al. Expires April 2019 [Page 14] Internet-Draft ACTN Applicability to VPN with POI October 2018 | : | *********************************************** CMI | : | Operator 2 | ------ | | | MDSC | | | ------ | | : | | ------- | | | PNC | | | ------- | \ : : : / Lower \v v v/ Layer X--Y--Z Network Where --- is a link === is a virtual link Figure 4: VN Recursion with Network Layers The CMI in Figure 4 interfaces Operator 1's CNC with Operator 2's MDSC. The functions to perform and the information carried over the inter-operator CMI are identical to those of the Customer's CNC and Operator 1's MDSC. In other words, the two CMIs depicted in Figure 4 are recursive in nature. From a data plane perspective, the interaction between operator 1 and operator 2 is similar to the POI case discussed in section 3.2 (See Figure 2) with an exception that the packet domains belong to operator 1 while optical domain to operator 2. The control interface depicted in Figure 4 (i.e., the CNC of operator 1 and the MDSC of operator 2) should behave similarly to 4.1. Service Request Process between Multiple Operators As discussed previously, the reclusiveness principle applies seamlessly over the two CMIs. This implies that Operator 1's MDSC needs to pass all customer service requirements transparently to Operator 2's MDSC so that Operator 2 should provision its underlay network tunnels to meet the service requirements of the original customer. The MDSC of Operator 1 should translate/map the original customer's intent and service requirements and pass down to the corresponding PNC(s) which is(are) responsible for interfacing another operator (in this example, Operator 2) that provides Lee, et al. Expires April 2019 [Page 15] Internet-Draft ACTN Applicability to VPN with POI October 2018 transport services for the segment of the customer's VN. The PNC in turn performs as a CNC when interfacing its southbound with Operator 2's MDSC. It is possible that additional recursive relationships may also exist between Operator 2 and other operators. 4.2. Service/Network Orchestration of Operator 2 Operator 2 that provides transport service for Operator 1 may also need to perform service/network orchestration function just as the case for Operator 1. From a data plane perspective, the interaction between operator 1 and operator 2 is similar to the POI case discussed in section 3.2 (See Figure 2) with an exception that the packet domains belong to operator 1 while optical domain to operator 2. The control interface depicted in Figure 4 (i.e., the CNC of operator 1 and the MDSC of operator 2) should behave similarly to that of the MDSC and the PNCs discussed in Section 3. 5. Security Considerations This document defines key components and interfaces for managed traffic engineered networks. Securing the request and control of resources, confidentially of the information, and availability of function, should all be critical security considerations when deploying and operating ACTN POI platforms. Several distributed ACTN functional components are required, and implementations should consider encrypting data that flows between components, especially when they are implemented at remote nodes, regardless these data flows are on external or internal network interfaces. From a security and reliability perspective, ACTN POI may encounter many risks such as malicious attack and rogue elements attempting to connect to various ACTN POI components. Furthermore, some ACTN POI components represent a single point of failure and threat vector, and must also manage policy conflicts, and eavesdropping of communication between different ACTN POI components. The conclusion is that all protocols used to realize the ACTN POI should have rich security features, and customer, application and network data should be stored in encrypted data stores. Additional Lee, et al. Expires April 2019 [Page 16] Internet-Draft ACTN Applicability to VPN with POI October 2018 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. 6. IANA Considerations This document has no actions for IANA. 7. References 7.1. Normative References [RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and Control of Transport Networks", RFC 8453, August 2018. 7.2. Informative References [DHODY] D. Dhody, et al., "Packet Optical Integration (POI) Use Cases for Abstraction and Control of Transport Networks (ACTN)", draft-dhody-actn-poi-use-case, work in progress. [bgp-l3vpn] D. Jain, et al. "Yang Data Model for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang, work in progress. [RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [ACTN-VN] Y. Lee, et al., "A Yang Data Model for ACTN VN Operation", draft-lee-teas-actn-vn-yang, work in progress. [TSM] Y. Lee, et al., "Traffic Engineering and Service Mapping Yang Model", draft-lee-teas-te-service-mapping-yang, work in progress. [TE-Topo] X. Liu, et al., "YANG Data Model for Traffic Engineering (TE) Topologies", draft-ietf-teas-yang-te-topo, work in progress. [RFC8309] Q. Wu, W. Liu, and A. Farrel, "Service Models Explained", RFC 8309, January 2018. [L3SM] Q. Wu, S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, January 2018. [L2SM] G. Fioccola (Ed), "A YANG Data Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn-service-model, work in progress. Lee, et al. Expires April 2019 [Page 17] Internet-Draft ACTN Applicability to VPN with POI October 2018 [ACTN-Telemetry] Y. Lee, et al.," YANG models for ACTN TE Performance Monitoring Telemetry and Network Autonomics", draft-lee-teas-actn-pm-telemetry-autonomics, work in progress. 8. Contributors Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Dhruv Dhody Huawei Email: dhruv.dhody@huawei.com Haomian Zheng Huawei Email: haomianzheng@hauwei.com Authors' Addresses Young Lee Huawei Technologies Email: leeyoung@huawei.com Qin Wu Huawei Technologies Email: bill.wu@huawei.com Italo Busi Huawei Technologies Email: Italo.Busi@huawei.com Daniele Ceccarelli Ericsson Email: daniele.ceccarelli@ericsson.com Jeff Tantsura Nuage Email: jefftant.ietf@gmail.com Lee, et al. Expires April 2019 [Page 18]