--- 1/draft-ietf-teas-actn-yang-01.txt 2018-08-22 13:13:12.129560749 -0700 +++ 2/draft-ietf-teas-actn-yang-02.txt 2018-08-22 13:13:12.177561918 -0700 @@ -1,29 +1,35 @@ TEAS WG Young Lee -Internet Draft Haomian Zheng -Intended status: Informational Huawei -Expires: August 28, 2018 - Daniel Ceccarelli - Ericsson + Haomian Zheng +Internet Draft Huawei +Intended status: Informational + Daniele Ceccarelli +Expires: February 23, 2019 Ericsson Bin Yeong Yoon ETRI + Oscar Gonzalez de Dios + Telefonica + + Jong Yoon Shin + SKT + Sergio Belotti Nokia - February 28, 2018 + August 22, 2018 Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks - draft-ietf-teas-actn-yang-01 + draft-ietf-teas-actn-yang-02 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. @@ -28,25 +34,24 @@ 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 August 28, 2018. + This Internet-Draft will expire on February 23, 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 @@ -71,88 +76,87 @@ how the ACTN architecture can be satisfied using classes of data model that have already been defined, and discusses the applicability of specific data models that are under development. It also highlights where new data models may need to be developed. 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. Service Model Mapping to ACTN..................................7 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...............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 + 5. Examples of Using Different Types of YANG Models..............10 + 5.1. Topology Collection......................................10 + 5.2. Connectivity over Two Nodes .............................10 + 5.3. VN Service Example.......................................11 + 5.4. Data Center-Interconnection Example......................12 + 5.4.1. CMI (CNC-MDSC Interface)............................14 + 5.4.2. MPI (MDSC-PNC Interface)............................14 + 5.4.3. SBI (Southbound interface between PNC and devices)..14 + 6. Security......................................................15 + 7. Acknowledgements..............................................15 + 8. References....................................................15 + 8.1. Informative References...................................15 + 9. Contributors..................................................18 + Authors' Addresses...............................................18 1. Introduction Abstraction and Control of TE Networks (ACTN) describes a method for operating a Traffic Engineered (TE) network (such as an MPLS-TE network or a layer 1 transport network) to provide connectivity and virtual network services for customers of the TE network. The services provided can be tuned to meet the requirements (such as traffic patterns, quality, and reliability) of the applications hosted by the customers. More details about ACTN can be found in Section 2. Data models are a representation of objects that can be configured - or monitored within a system. Within the IETF, YANG [RFC6020] is the + or monitored within a system. Within the IETF, YANG [RFC7950] is the language of choice for documenting data models, and YANG models have been produced to allow configuration or modelling of a variety of network devices, protocol instances, and network services. YANG data - models have been classified in [Netmod-Yang-Model-Classification] - and [Service-YANG]. + models have been classified in [RFC8199] and [RFC8309]. This document shows how the ACTN architecture can be satisfied using - classes of data model that have already been defined, and discusses - the applicability of specific data models that are under + various classes of data model that have already been defined, and + discusses the applicability of specific data models that are under development. It also highlights where new data models may need to be developed. 2. Abstraction and Control of TE Networks (ACTN) Architecture - [ACTN-Requirements] describes the high-level ACTN requirements. [ACTN-Frame] describes the architecture model for ACTN including the entities (Customer Network Controller (CNC), Multi-domain Service - Coordinator (MDSC), and Physical Network Controller (PNC)) and their - interfaces. + Coordinator (MDSC), and Provisioning Network Controller (PNC)) and + their interfaces. Figure 1 depicts a high-level control and interface architecture for ACTN and is a reproduction of Figure 3 from [ACTN-Frame]. A number of key ACTN interfaces exist for deployment and operation of ACTN- based networks. These are highlighted in Figure 1 (ACTN Interfaces) below: +--------------+ +---------------+ +--------------+ | CNC-A | | CNC-B | | CNC-C | |(DC provider) | | (ISP) | | (MVNO) | +--------------+ +---------------+ +--------------+ \ | / Business \ | / Boundary =======\========================|=========================/======= Between \ | CMI / Customer & ----------- | -------------- - Network Provider \ | / + Network Operator \ | / +-----------------------+ | MDSC | +-----------------------+ / | \ ------------ |MPI ---------------- / | \ +-------+ +-------+ +-------+ | PNC | | PNC | | PNC | +-------+ +-------+ +-------+ | GMPLS / | / \ @@ -166,63 +170,68 @@ - - ( ) ( ) ----- ( ) ( Phys. ) ( Phys. ) -------- ( Net ) ( Net ) ----- ----- Figure 1 : ACTN Interfaces The interfaces and functions are described below (without modifying the definitions) in [ACTN-Frame]: - . The CNC-MDSC Interface (CMI) is an interface between a Customer - Network Controller and a Multi Domain Service Controller. The - interface will communicate the service request or application - demand. A request will include specific service properties, for - example, services type, bandwidth and constraint information. - These constraints SHOULD be measurable by MDSC and therefore - visible to CNC via CMI. The CNC can also request the creation - of the virtual network based on underlying physical resources - to provide network services for the applications. The CNC can - provide the end-point information/characteristics, traffic - matrix specifying specific customer constraints. The MDSC may - also report potential network topology availability if queried - for current capability from the Customer Network Controller. + . The CNC-MDSC Interface (CMI) is an interface between a CNC and + an MDSC. This interface is used to communicate the service + request or application demand. A request will include specific + service properties, for example, services type, bandwidth and + constraint information. These constraints SHOULD be measurable + by MDSC and therefore visible to CNC via CMI. The CNC can also + request the creation of the virtual network service based on + underlying physical resources to provide network services for + the applications. The CNC can provide the end-point + information/characteristics together with traffic matrix + specifying specific customer constraints. The MDSC may also + report potential network topology availability if queried for + current capability from the Customer Network Controller. + Performance monitoring is also applicable in CMI, which enables + the MDSC to report network parameters/telemetries that may + guide the CNC to create/change their services. - . The MDSC-PNC Interface (MPI) is an interface between a Multi - Domain Service Coordinator and a Physical Network Controller. - It allows the MDSC to communicate requests to create/delete - connectivity or to modify bandwidth reservations in the - physical network. In multi-domain environments, each PNC is - responsible for a separate domain. The MDSC needs to establish - multiple MPIs, one for each PNC and perform coordination - between them to provide cross-domain connectivity. + . The MDSC-PNC Interface (MPI) is an interface between an MDSC + and a PNC. It allows the MDSC to communicate requests to + create/delete connectivity or to modify bandwidth reservations + in the physical network. In multi-domain environments, each PNC + is responsible for a separate domain. The MDSC needs to + establish multiple MPIs, one for each PNC and perform + coordination between them to provide cross-domain connectivity. + MPI plays an important role for multi-vendor operations; inter- + operability can be achieved by standardized interface modules. . The South-Bound Interface (SBI) is the provisioning interface for creating forwarding state in the physical network, - requested via the Physical Network Controller. The SBI is not - in the scope of ACTN, however, it is included in this document - so that it can be compared to models in [Service-Yang]. + requested via the PNC. The SBI is not in the scope of ACTN, + however, it is included in this document so that it can be + compared to models in [Service-Yang]. 3. Service Models - [Service-YANG] introduces a reference architecture to explain the - nature and usage of service YANG models in the context of service + [RFC8309] introduces a reference architecture to explain the nature + and usage of service YANG models in the context of service orchestration. Figure 2 below depicts this relationship and is a - reproduction of Figure 2 from [Service-YANG]. Four models depicted - in Figure 2 are defined as follows: + reproduction of Figure 2 from [RFC8309]. Four models depicted in + Figure 2 are defined as follows: . Customer Service Model: A customer service model is used to describe a service as offer or delivered to a customer by a network operator. . Service Delivery Model: A service delivery model is used by a network operator to define and configure how a service is provided by the network. + . Network Configuration Model: A network configuration model is used by a network orchestrator to provide network-level configuration model to a controller. . Device Configuration Model: A device configuration model is used by a controller to configure physical network elements. Customer ------------------ Service ---------- | | Model | | | Service |<-------->| Customer | @@ -256,21 +265,21 @@ --------- --------- --------- --------- --------- | Network | | Network | | Network | | Network | | Network | | Element | | Element | | Element | | Element | | Element | --------- --------- --------- --------- --------- Figure 2: An SDN Architecture with a Service Orchestrator 4. Service Model Mapping to ACTN YANG models coupled with the RESTCONF/NETCONF protocol - [Netconf][Restconf] provides solutions for the ACTN framework. This + [RFC6241][RFC8040] provides solutions for the ACTN framework. This section explains which types of YANG models apply to each of the ACTN interfaces. Refer to Figure 5 of [ACTN-Frame] for details of the mapping between ACTN functions and service models. In summary, the following mappings are held between and Service Yang Models and the ACTN interfaces. o Customer Service Model <-> CMI o Network Configuration Model <-> MPI @@ -286,57 +295,60 @@ 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 ----------------------------------------------------------- - 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]**** + Layer 1 Connectivity Service Model [L1CSM] + Layer 2 VPN Service Model [L2SM] + Layer 3 VPN Service Model [RFC8299] *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. **[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]. + between service models (e.g., L3SM, L2SM, L1CSM) and TE models via + [ACTN-VN-YANG] and [TE-topology]. This model can be used as either + Customer Service Models, or Service Delivery model described in + Section 4.2. - ***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. + ***[ACTN-PM-Telemetry] describes performance telemetry for e2e + tunnels and VNs. This module also allows autonomic traffic + engineering scaling intent configuration mechanism on both the e2e + tunnel and the VN level. Scale in/out criteria might be used for + network automation 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 Tunnel and 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. + seen in [RFC8309]. 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. In the MDSC hierarchical model where there are multiple MDSCs, the interface between the top MDSC and the bottom MDSC can be mapped to service delivery models. 4.3. Network Configuration Models in ACTN Architecture (MPI) The Network Configuration Models is used between the network orchestrator and the controller in [Service-YANG]. In ACTN, this model is used primarily between a MDSC and a PNC. The Network @@ -352,38 +363,41 @@ Function Yang Model -------------------------------------------------------- Configuration Scheduling [Schedule] Path computation [PATH_COMPUTATION-API] Tunnel/LSP Provisioning [TE-Tunnel] Topology Abstraction [TE-topology] Client Signal Description [Client-signal] Service Provisioning TBD* - OTN Topology Abstraction [OTN-YANG] - WSON Topology Abstraction [WSON-YANG] - Flexi-grid Topology Abstraction [Flexi-YANG] + OTN Topology Abstraction [OTN-topo] + WSON Topology Abstraction [WSON-topo] + Flexi-grid Topology Abstraction [Flexi-topo] + Microwave Topology Abstraction [MW-topo] OTN Tunnel Model [OTN-Tunnel] WSON TE Tunnel Model [WSON-Tunnel] Flexi-grid Tunnel Model [Flexigrid-Tunnel] * 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. - [T-NBI Applicability] provides a summary on the applicability of - existing YANG model usage in the current network configuration, - especially for transport network. + [TE-topo-tunnel] provides tutorials for the clarification and + example usage for TE topology model [TE-topology] and TE tunnel + model [TE-Tunnel]. [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 + Note that SBI is not in the scope of ACTN, as there is 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. One example of Device Models is ietf-te-device yang module defined in [TE-tunnel]. @@ -393,51 +407,49 @@ in the network operation. A few typical generic scenarios are involved. In [T-NBI Applicability], there are more transport-related scenarios and examples. 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 + the model described in [OTN-topo] [WSON-topo], and [Flexi-topo] 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. + pair of controllers, corresponding method can be found in [ACTN- + frame]. The technology-specific features may be hidden after + abstraction, to make the network easier for the user to operate. - When there are topology changes in the physical network, the PNC + When there is a topology change 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 + messages using topology models. Accordingly, such changes is propagated between different controllers for further synchronization. -5.2. Connectivity over Two Client Nodes +5.2. Connectivity over Two Nodes - The service models, such as described in [RFC8049], [L2SM] and - [L1CSM], provide a connectivity service model which can be used in + The service models, such as described in [RFC8299], [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 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/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]. + may be additionally specified is the SLA that describes the + required quality and resilience of the service. . 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. @@ -439,31 +451,30 @@ 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. 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]. Technology-specific tunnel configuration may use the model described in [OTN-Tunnel] [WSON-Tunnel], and [Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively. . 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 +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. @@ -561,28 +572,39 @@ 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.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 DC sources and DC destinations. The MDSC will also need - to dynamically interact with the CNC for dynamic policy changes + prescribed sources and the 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.4.3. SBI (Southbound interface between PNC and devices) + + 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 @@ -596,91 +618,93 @@ 7. Acknowledgements We thank Adrian Farrel for providing useful comments and suggestions for this draft. 8. References 8.1. Informative References - [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models - Explained", draft-wu-opsawg-service-model-explained, work - in progress. + [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", + RFC 8309. - [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. - Moberg, "YANG Module Classification", draft-ietf-netmod- - yang-model-classification, work in progress. + [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module + Classification", RFC 8199. - [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241. - [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF - Protocol", draft-ietf-netconf-restconf, work in progress. - - [ACTN-Requirements] Y. Lee, et al., "ACTN Requirements for - Abstraction and Control of TE Networks", draft-ietf-teas- - actn-requirements, work in progress. + [RFC8040] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF + Protocol", RFC 8040. - [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and - Control of Traffic Engineered Networks", draft-ietf-teas- - actn-framework, work in progress. + [ACTN-Frame] D. Ceccarelli and Y. Lee, "Framework for Abstraction + and Control of Traffic Engineered Networks", draft-ietf- + teas-actn-framework, work in progress. [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies", draft-ietf-teas-yang-te-topo, work in progress. [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang- te, work in progress. [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN Operation", draft-lee-teas-actn-vn-yang, work in progress. - [ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction - and Control of TE Networks (ACTN)", draft-leebelotti-teas- - actn-info, work in progress. + [L1CSM] G. Fioccola, K. Lee, Y. Lee, D. Dhody, O. Gonzalez de-Dios, + D. Ceccarelli, "A Yang Data Model for L1 Connectivity + Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work + in progress. - [Transport-Service-Model] X. Zhang (Editor), "A Service YANG Model - for Connection-oriented Transport Networks", draft-zhang- - teas-transport-service-model, work in progress. + [L2SM] B. Wen, G. Fioccola, C. Xie, L. Jalil, "A YANG Data Model for + L2VPN Service Delivery", draft-ietf-l2sm-l2vpn-service- + model, work in progress. + + [RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, K.Ogaki, "YANG Data + Model for L3VPN Service Delivery", RFC8299. + + [ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction + and Control of TE Networks (ACTN)", draft-ietf-teas-actn- + info, work in progress. [PATH-COMPUTATION-API] I.Busi/S.Belotti et al. "Path Computation - API", draft-busibel-ccamp-path-computation-api-00.txt, - work in progress + API", draft-ietf-teas-yang-path-computation, work in + progress [RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp, work in progress. [Schedule] X. Liu, et. al., "A YANG Data Model for Configuration Scheduling", draft-liu-netmod-yang-schedule, work in progress. - [ACTN-Abstraction] Y. Lee, D. Dhody, and D. Ceccarelli, "ACTN - Abstraction Methods", draft-lee-tease-actn-abstraction, - work in progress. - - [OTN-YANG] X. Zhang, A. Sharma, and X. Liu, "A YANG Data Model for - Optical Transport Network Topology", draft-zhang-ccamp-l1- - topo-yang, work in progress. + [OTN-topo] H. Zheng, et. al., "A YANG Data Model for Optical + Transport Network Topology", draft-ietf-ccamp-otn-topo- + yang, work in progress. - [WSON-YANG] Y. Lee, et. al., "A Yang Data Model for WSON Optical + [WSON-topo] Y. Lee, et. al., "A Yang Data Model for WSON Optical Networks", draft-ietf-ccamp-wson-yang, work in progress. - [Flexi-YANG] J.E. Lopez de Vergara, et. al., "YANG data model for + [Flexi-topo] J.E. Lopez de Vergara, et. al., "YANG data model for Flexi-Grid Optical Networks", draft-vergara-ccamp-flexigrid- - yang, work in progress.[ODU-Tunnel] Sharma, R. Rao, and - X. Zhang, "OTN Service YANG Model", draft-sharma-ccamp- - otn-service-model, work in progress. + yang, work in progress. + + [MW-topo] M. Ye, et. al., "A YANG Data Model for Microwave + Topology", draft-ye-ccamp-mw-topo-yang, work in progress. + + [OTN-Tunnel] H. Zheng, et. al., "OTN Tunnel YANG Model", draft- + ietf-ccamp-otn-tunnel-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-ietf- ccamp-wson-tunnel-model, work in progress. @@ -688,23 +712,27 @@ [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-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- + Transport Network Client Signals", draft-zheng-ccamp- client-signal-yang, work in progress. + [TE-topo-Tunnel] I.Bryskin, et. al., "TE Topology and Tunnel + Modeling for Transport Networks", draft-ietf-teas-te-topo- + and-tunnel-modeling, 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