--- 1/draft-ietf-teas-actn-yang-00.txt 2018-02-28 09:13:59.545350609 -0800 +++ 2/draft-ietf-teas-actn-yang-01.txt 2018-02-28 09:13:59.585351555 -0800 @@ -1,35 +1,29 @@ TEAS WG Young Lee - Haomian Zheng -Internet Draft Huawei -Intended status: Informational - Daniel Ceccarrelli -Expires: May 12, 2018 Ericsson +Internet Draft Haomian Zheng +Intended status: Informational Huawei +Expires: August 28, 2018 + Daniel Ceccarelli + Ericsson Bin Yeong Yoon ETRI - Oscar Gonzalez de Dios - Telefonica - - Jong Yoon Shin - SKT - Sergio Belotti Nokia - November 12, 2017 + February 28, 2018 Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks - draft-ietf-teas-actn-yang-00 + draft-ietf-teas-actn-yang-01 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. @@ -34,28 +28,29 @@ 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." 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 May 12, 2017. + This Internet-Draft will expire on August 28, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + 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 @@ -81,27 +76,27 @@ Table of Contents 1. Introduction...................................................3 2. Abstraction and Control of TE Networks (ACTN) Architecture.....3 3. Service Models.................................................5 4. Service Model Mapping to ACTN..................................6 4.1. Customer Service Models in the ACTN Architecture (CMI)....7 4.2. Service Delivery Models in ACTN Architecture..............8 4.3. Network Configuration Models in ACTN Architecture (MPI)...8 4.4. Device Models in ACTN Architecture (SBI)..................9 - 5. Examples of Using Different Types of YANG Models..............10 - 5.1. Simple Connectivity Examples.............................10 - 5.2. VN service example.......................................10 - 5.3. Data Center-Interconnection Example......................11 - 5.3.1. CMI (CNC-MDSC Interface)............................13 - 5.3.2. MPI (MDSC-PNC Interface)............................13 - 5.3.3. PDI (PNC-Device interface)..........................13 + 5. Examples of Using Different Types of YANG Models...............9 + 5.1. Topology Collection.......................................9 + 5.2. Connectivity over Two Client Nodes.......................10 + 5.3. VN service example.......................................11 + 5.4. Data Center-Interconnection Example......................11 + 5.4.1. CMI (CNC-MDSC Interface)............................13 + 5.4.2. MPI (MDSC-PNC Interface)............................13 6. Security......................................................14 7. Acknowledgements..............................................14 8. References....................................................14 8.1. Informative References...................................14 9. Contributors..................................................16 Authors' Addresses...............................................17 1. Introduction Abstraction and Control of TE Networks (ACTN) describes a method for @@ -154,21 +149,21 @@ +-----------------------+ | MDSC | +-----------------------+ / | \ ------------ |MPI ---------------- / | \ +-------+ +-------+ +-------+ | PNC | | PNC | | PNC | +-------+ +-------+ +-------+ | GMPLS / | / \ - | trigger / |SBI / \ + | trigger / |SBI SBI / \ -------- ----- | / \ ( ) ( ) | / \ - - ( Phys. ) | / ----- ( GMPLS ) ( Net ) | / ( ) ( Physical ) ---- | / ( Phys. ) ( Network ) ----- ----- ( Net ) - - ( ) ( ) ----- ( ) ( Phys. ) ( Phys. ) -------- ( Net ) ( Net ) ----- ----- @@ -292,39 +286,48 @@ Among the key functions of Customer Service Models on the CMI is the service request. A request will include specific service properties, including: service type and its characteristics, bandwidth, constraint information, and end-point characteristics. The following table provides a list of functions needed to build the CMI. They are mapped with Customer Service Models. Function Yang Model ----------------------------------------------------------- - Transport Service Request [Transport-Service-Model] - VN Service Request & Instantiation [ACTN-VN-YANG] - VN Path Computation Request [ACTN-VN-YANG]* - VN Performance Monitoring Telemetry [ACTN-PM-Telemetry]** - Topology Abstraction [TE-topology] - *VN Path computation request in the CMI context means network path + VN Service Request [ACTN-VN-YANG] + VN Computation Request [ACTN-VN-YANG]* + TE & Service Mapping [TE-Service-Mapping]** + VN Performance Monitoring Telemetry [ACTN-PM-Telemetry]*** + Topology Abstraction [TE-topology]**** + + *VN computation request in the CMI context means network path computation request based on customer service connectivity request constraints prior to the instantiation of a VN creation. - **ietf-actn-te-kpi-telemetry model describes performance telemetry + **[TE-Service-Mapping] provides a mapping and cross-references + between service models (e.g., L3SM, L2SM, L1CSM) and TE model via + [ACTN-VN-YANG] and [TE-topology]. + + ***ietf-actn-te-kpi-telemetry model describes performance telemetry for ACTN VN model. This module also allows autonomic traffic engineering scaling intent configuration mechanism on the VN level. Scale in/out criteria might be used for network autonomics in order the controller to react to a certain set of variations in monitored parameters. Moreover, this module also provides mechanism to define aggregated telemetry parameters as a grouping of underlying VN level telemetry parameters. + ****TE-Topology's Connectivity Matrices/Matrix construct can be used + to instantiate VN Service via a suitable referencing and mapping + with [ACTN-VN-YANG]. + 4.2. Service Delivery Models in ACTN Architecture The Service Delivery Models where the service orchestration and the network orchestration could be implemented as separate components as seen in [Service-YANG]. This is also known as Network Service Models. On the other hand, from an ACTN architecture point of view, the service delivery model between the service orchestrator and the network orchestrator is an internal interface between sub-components of the MDSC in a single MDSC model. @@ -343,135 +346,152 @@ The Network Configuration Model captures the parameters which are network wide information. The following table provides a list of functions needed to build the MPI. They are mapped with Network Configuration Yang Models. Note that various Yang models are work in progress. Function Yang Model -------------------------------------------------------- Configuration Scheduling [Schedule] - Path computation [PATH_COMPUTATION-API]* - Path Provisioning [TE-Tunnel]** + Path computation [PATH_COMPUTATION-API] + Tunnel/LSP Provisioning [TE-Tunnel] Topology Abstraction [TE-topology] - Tunnel PM Telemetry [ACTN-PM-Telemetry]*** - Service Provisioning TBD**** + Client Signal Description [Client-signal] + Service Provisioning TBD* OTN Topology Abstraction [OTN-YANG] WSON Topology Abstraction [WSON-YANG] Flexi-grid Topology Abstraction [Flexi-YANG] - ODU Tunnel Model [ODU-Tunnel] + OTN Tunnel Model [OTN-Tunnel] WSON TE Tunnel Model [WSON-Tunnel] Flexi-grid Tunnel Model [Flexigrid-Tunnel] - * Related draft is presenting use cases for path computation API, - and Yang related model is foreseen to be added. - - ** Note that path provisioning function is provided by ietf-te - module in [TE-Tunnel]. - - ** ietf-actn-te-kpi-telemetry model describes performance telemetry - for TE-tunnel model. This module also allows autonomic traffic - engineering scaling intent configuration mechanism on the TE-tunnel - level. Various conditions can be set for auto-scaling based on the - telemetry data. - - **** This function needs to be investigated further. This can be a - part of [TE-Tunnel] which is to be determined. Service provisioning - is an optional function that builds on top the path provisioning - one. - - Path provisioning and Topology abstraction functions are mandatory - in any case, while Path Computation may be mandatory or optional - depending on the type of topology abstraction used. Details of this - topic are discussed in [ACTN-Abstraction]. + * This function needs to be investigated further. This can be a part + of [TE-Tunnel] which is to be determined. Service provisioning is an + optional function that builds on top the path provisioning one. - Telemetry may also be an optional function. + [T-NBI Applicability] provides a summary on the applicability of + existing YANG model usage in the current network configuration, + especially for transport network. 4.4. Device Models in ACTN Architecture (SBI) + Note that SBI is not in the scope of ACTN, as there are already + mature protocol solutions for various purpose on the device level of + ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The + interworking of such protocols and ACTN controller hierarchies can + be found in [gmpls-controller-inter-work]. + For the device YANG models are used for per-device configuration purpose, they can be used between the PNC and the physical - network/devices. Note that SBI is not in the scope of ACTN. This - section is provided to give some examples of YANG-based Device - Models. An example of Device Models is ietf-te-device yang module - defined in [TE-tunnel]. + network/devices. One example of Device Models is ietf-te-device yang + module defined in [TE-tunnel]. 5. Examples of Using Different Types of YANG Models -5.1. Simple Connectivity Examples + This section provides some examples on the usage of IETF YANG models + in the network operation. A few typical generic scenarios are + involved. In [T-NBI Applicability], there are more transport-related + scenarios and examples. - The data model in [Transport-Service-Model] provides an intent-like - connectivity service model which can be used in connection-oriented - networks. +5.1. Topology Collection + + Before any connection is requested and delivered, the controller + needs to understand the network topology. The topology information + is exchanged among controllers with topology models, such as [te- + topology]. Moreover, technology-specific topology reporting may use + the model described in [OTN-YANG] [WSON-YANG], and [Flexi-YANG] for + OTN, WSON and Flexi-grid, respectively. By collecting the network + topology, each controller can therefore construct a local database, + which can be used for the further service deployment. + + There can be different types of abstraction applied between each + pair of controllers as discussed in in [ACTN-frame]. The technology- + specific features may be hidden after abstraction to make the + network operation easier. + + When there are topology changes in the physical network, the PNC + should report the change to upper level of controllers via updating + messages using topology models. Accordingly, such changes are + propagated between different controllers for further + synchronization. + +5.2. Connectivity over Two Client Nodes + + The service models, such as described in [RFC8049], [L2SM] and + [L1CSM], provide a connectivity service model which can be used in + connection-oriented networks. It would be used as follows in the ACTN architecture: - . A CNC uses this service model to specify the two client nodes + . A CNC uses the service models to specify the two client nodes that are to be connected, and also indicates the amount of traffic (i.e., the bandwidth required) and payload type. What - may be additionally specified is the SLA that describes the - required quality and resilience of the service. + may be additionally specified is the SLA/Policy that describes + the required quality and resilience of the service especially + on TE binding with the service (e.g., soft isolation, hard + isolation, etc.) as defined in [TE-Service-Mapping]. . The MDSC uses the information in the request to pick the right network (domain) and also to select the provider edge nodes corresponding to the customer edge nodes. If there are multiple domains, then the MDSC needs to coordinate across domains to set up network tunnels to deliver a service. Thus coordination includes, but is not limited to, - picking the right domain sequence to deliver a service. Before - it can perform such functions, it needs to get the topology - information from each PNC, using topology YANG models such as - [te-topology]. The topology reported from PNC to MDSC can - either be abstract or non-abstract. + picking the right domain sequence to deliver a service. Additionally, an MDSC can initiate the creation of a tunnel (or tunnel segment) in order to fulfill the service request from CNC based on path computation upon the overall topology information it synthesized from different PNCs. The based model - that can cater this purpose is the te-tunnel model specified in - [te-tunnel]. + that can cater this purpose is the TE tunnel model specified in - . Then, the PNC needs to decide the explicit route of such a - tunnel or tunnel segment (in case of multiple domains), and - create such a tunnel using protocols such as PCEP and RSVP-TE - or using per-hop configuration. + [te-tunnel]. Technology-specific tunnel configuration may use + the model described in [OTN-Tunnel] [WSON-Tunnel], and + [Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively. -5.2. VN service example + . Then, the PNCs need to decide the explicit route of such a + tunnel or tunnel segment (in case of multiple domains) for each + domain, and then create such a tunnel using protocols such as + PCEP and RSVP-TE or using per-hop configuration. + +5.3. VN service example The service model defined in [ACTN-VN-YANG] describes a virtual network (VN) as a service which is a set of multiple connectivity services: . A CNC will request VN to the MDSC by specifying a list of VN members. Each VN member specifies either a single connectivity service, or a source with multiple potential destination points in the case that the precise destination sites are to be determined by MDSC. o In the first case, the procedure is the same as the connectivity service, except that in this case, there is a list of connections requested. o In the second case, where the CNC requests the MDSC to select the right destination out of a list of candidates, - the MDSC needs to choose the best candidate and reply with - the chosen destination for a given VN member. After this - is selected, the connectivity request setup procedure is - the same as in the connectivity-as-a-service example. + the MDSC needs to evaluate each candidate and then choose + the best one and reply with the chosen destination for a + given VN member. After this is selected, the connectivity + request setup procedure is the same as in the connectivity + example in section 5.2. After the VN is set up, a successful reply message is sent from MDSC to CNC, indicating the VN is ready. This message can also be achieved by using the model defined in [ACTN-VN-YANG]. -5.3. Data Center-Interconnection Example +5.4. Data Center-Interconnection Example This section describes more concretely how existing YANG models described in Section 4 map to an ACTN data center interconnection use case. Figure 3 shows a use-case which shows service policy- driven Data Center selection and is a reproduction of Figure A.1 from [ACTN-Info]. +----------------+ | CNC | | (Global DC | @@ -526,54 +546,43 @@ applications. Data Center selection problems arise for VM mobility, disaster recovery and load balancing cases. VN's policy plays an important role for virtual network operation. Policy can be static or dynamic. Dynamic policy for data center selection may be placed as a result of utilization of data center resources supporting VMs. The MDSC would then incorporate this information to meet the objective of this application. - 5.3.1. CMI (CNC-MDSC Interface) + 5.4.1. CMI (CNC-MDSC Interface) [ACTN-VN-YANG] is used to express the definition of a VN, its VN creation request, the service objectives (metrics, QoS parameters, etc.), dynamic service policy when VM needs to be moved from one Data Center to another Data Center, etc. This service model is used between the CNC and the MDSC (CMI). The CNC in this use-case is an external entity that wants to create a VN and operates on the VN. - 5.3.2. MPI (MDSC-PNC Interface) + 5.4.2. MPI (MDSC-PNC Interface) The Network Configuration Model is used between the MDSC and the PNCs. Based on the Customer Service Model's request, the MDSC will need to translate the service model into the network configuration model to instantiate a set of multi-domain connections between the - prescribed sources and the destinations. The MDSC will also need to - dynamically interact with the CNC for dynamic policy changes + prescribed DC sources and DC destinations. The MDSC will also need + to dynamically interact with the CNC for dynamic policy changes initiated by the CNC. Upon the determination of the multi-domain connections, the MDSC will need to use the network configuration model such as [TE-Tunnel] to interact with each PNC involved on the path. [TE-Topology] is used to for the purpose of underlying domain network abstraction from the PNC to the MDSC. - 5.3.3. PDI (PNC-Device interface) - - The Device Model can be used between the PNC and its underlying - devices that are controlled by the PNC. The PNC will need to trigger - signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to - provision its domain path segment. There can be a plethora of - choices how to control/manage its domain network. The PNC is - responsible to abstract its domain network resources and update it - to the MDSC. Note that this interface is not in the scope of ACTN. - This section is provided just for an illustration purpose. - 6. Security This document is an informational draft. When the models mentioned in this draft are implemented, detailed security consideration will be given in such work. How security fits into the whole architecture has the following components: - the use of Restconf security between components @@ -666,32 +675,47 @@ X. Zhang, "OTN Service YANG Model", draft-sharma-ccamp- otn-service-model, work in progress. [ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D. King, and D. Ceccarelli, "YANG models for ACTN TE Performance Monitoring Telemetry and Network Autonomics", draft-lee-teas-actn-pm-telemetry-autonomics, work in progress. [WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R. - Vilalta, "A Yang Data Model for WSON Tunnel", draft-lee- + Vilalta, "A Yang Data Model for WSON Tunnel", draft-ietf- ccamp-wson-tunnel-model, work in progress. [Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model - for Flexi-Grid media-channels", draft-vergara-ccamp- + for Flexi-Grid media-channels", draft-ietf-ccamp- flexigrid-media-channel-yang, work in progress. + [TE-Service-Mapping] Y. Lee, et al, "Traffic Engineering and Service + Mapping Yang Model", draft-lee-teas-te-service-mapping- + yang, work in progress. + + [Client-signal] H. Zheng, et al, "A YANG Data Model for Optical + Transport Network Client Signals", draft-zheng-ccamp-otn- + client-signal-yang, work in progress. + + [T-NBI Applicability] I. Busi, et al, "Transport Northbound + Interface Applicability Statement and Use Cases", draft- + ietf-ccamp-transport-nbi-app-statement, work in progress. + + [gmpls-controller-inter-work] H. Zheng, et al, "Interworking of + GMPLS Control and Centralized Controller System", draft- + zheng-ccamp-gmpls-controller-inter-work, work in progress. + 9. Contributors Contributor's Addresses - Dhruv Dhody Huawei Technologies Email: dhruv.ietf@gmail.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com