Traffic Engineering and Service Mapping Yang Model
draft-lee-teas-te-service-mapping-yang-09
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Young Lee , Dhruv Dhody , Daniele Ceccarelli , Jeff Tantsura , Giuseppe Fioccola , Qin Wu | ||
| Last updated | 2018-06-28 | ||
| Replaced by | draft-ietf-teas-te-service-mapping-yang, draft-ietf-teas-te-service-mapping-yang, draft-ietf-teas-te-service-mapping-yang, draft-ietf-teas-te-service-mapping-yang | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lee-teas-te-service-mapping-yang-09
TEAS WG Young Lee
Internet Draft Dhruv Dhody
Intended status: standard track Huawei
Expires: December 28, 2018
Daniele Ceccarelli
Ericsson
Jeff Tantsura
Nuage
Giuseppe Fioccola
Telecom Italia
Qin Wu
Huawei
June 29, 2018
Traffic Engineering and Service Mapping Yang Model
draft-lee-teas-te-service-mapping-yang-09
Abstract
This document provides a YANG data model to map service model (e.g.,
L3SM) and Traffic Engineering model (e.g., TE Tunnel or ACTN VN
model). This model is referred to as TE service Mapping Model. This
model is applicable to the operation's need for a seamless control
and management of their VPN services with TE tunnel support.
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
Lee, et al. Expires December 2018 [Page 1]
Internet-Draft TE & Service Mapping June 2018
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 December 29, 2018.
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
2. TE-Service Mapping Model.......................................4
2.1. VN/Tunnel Selection Requirements..........................5
2.2. Availability Requirements.................................6
3. L3VPN Architecture in ACTN context.............................6
4. YANG Data Tree.................................................9
5. Yang Data Model...............................................10
6. Security......................................................17
7. IANA Considerations...........................................18
8. Acknowledgements..............................................18
9. References....................................................18
9.1. Informative References...................................18
10. Contributors.................................................19
Authors' Addresses...............................................20
Lee, et al. Expires December 2018 [Page 2]
Internet-Draft TE & Service Mapping June 2018
1. Introduction
Data models are a representation of objects that can be configured
or monitored within a system. Within the IETF, YANG [RFC6020] is the
language of choice for documenting data models, and YANG models have
been produced to allow configuration or modeling of a variety of
network devices, protocol instances, and network services. YANG data
models have been classified in [Netmod-Yang-Model-Classification]
and [RFC8309].
[RFC4110] provides a framework for Layer 3 Provider-Provisioned
Virtual Private Networks (PPVPNs). [L3SM-YANG] provides a L3VPN
service delivery YANG model for PE-based VPNs. The scope of this
draft is limited to a set of domain under the same network operators
to deliver services requiring TE tunnels.
[ACTN-VN-YANG] describes how customers or end to end orchestrators
can request and/or instantiate a generic virtual network service.
[ACTN-Applicability] describes a connection between IETF YANG model
classifications to ACTN interfaces. In particular, it describes the
customer service model can be mapped into the CMI (CNC-MDSC
Interface) of the ACTN architecture.
While IP/MPLS PNC is responsible for provisioning the VPN service on
the PE nodes, the MDSC can coordinate how to map the VPN services
with TE tunnels. This is consistent with the two of the core
functions of the MDSC specified in [ACTN-Frame]:
. Customer mapping/translation function: This function is to map
customer requests/commands into network provisioning requests
that can be sent to the Physical Network Controller (PNC)
according to business policies provisioned statically or
dynamically. Specifically, it provides mapping and translation
of a customer's service request into a set of parameters that
are specific to a network type and technology such that network
configuration process is made possible.
. Virtual service coordination function: This function translates
customer service-related information into virtual network
service operations in order to seamlessly operate virtual
networks while meeting a customer's service requirements. In
the context of ACTN, service/virtual service coordination
includes a number of service orchestration functions such as
multi-destination load balancing, guarantees of service
quality, bandwidth and throughput. It also includes
notifications for service fault and performance degradation and
so forth.
Lee, et al. Expires December 2018 [Page 3]
Internet-Draft TE & Service Mapping June 2018
The YANG model described in this document provides an ACTN TE-
service mapping model that enables a seamless service mapping across
L1/2/3 VPN, ACTN VN and TE-Topology/TE-tunnel models at the
controllers.
2. TE-Service Mapping Model
The role of TE-service Mapping model is to create a mapping
relationship between service models and TE models so that VN/VPN
service instantiation would be seamlessly provided by the underlying
TE networks. It also allows for the customers to access operational
state information as to how their services are instantiated with the
underlying TE topology or TE tunnels. This mapping will facilitate a
seamless service management operation with underlay-TE network
visibility.
Figure 1 shows TE-Service Mapping Model's scope.
+---------+ +-------------+ +----------+
| L3SM | <------> | | <-----> | ACTN VN |
+---------+ | | | Model |
| | +-----^----+
| | |
+---------+ | TE-Service | +-----v----+
| L2SM | <------> |Mapping Model| <-----> | TE-Topo |
+---------+ | | | Model |
| | +----------+
| |
+---------+ | | +----------+
| L1CSM | <------> | | <-----> | TE-Tunnel|
+---------+ | | | Model |
. . . +-------------+ +----------+
Figure 1. TE-Service Mapping
As seen in Figure 1, the TE-Service Mapping Model provides a mapping
between the LxSM and the ACTN VN YANG model which allows customers
(internal or external) to create a VN that meets the customer's
service objective with various constraints via TE-topology model
[TE-topo]. The model also supports a direct mapping between LxSM to
TE-topology or TE-tunnel.
The TE-service model developed in this document can also be extended
to support other services beyond L3SM, L2SM and L1CSM.
Lee, et al. Expires December 2018 [Page 4]
Internet-Draft TE & Service Mapping June 2018
Moreover, the TE-Service Mapping model provides additional service
parameters and policies that are not included in the respective
service models such as L3SM [RFC8299], L2SM [L2SM-YANG] and L1CSM
[L1CSM-YANG]. For example, how VN/TE tunnel should be created (e.g.,
with an isolation level) for a certain service instance is described
in the TE-Service Mapping model.
2.1. VN/Tunnel Selection Requirements
In some cases, under the confines of service policy, TE network
slicing isolation requirement may need to be supported for the VPN
service. This may occur when there are no suitable existing TE
tunnels that can support VPN service requirements. Or the operator
would like to dynamically create and bind tunnels to the VPN, which
could not be shared for network slicing.
To summarize there are three modes of VN/Tunnel selection operations
to be supported, but not limited to:
o New VN/Tunnel Binding - Customer could request an L3VPN
service [L3SM-YANG] with a new VN/Tunnel not shared with
other existing services. This is to meet VPN isolation
requirement. Further the mapping yang model described in
Section 5 of this document is used to set this mapping
between the L3VPN service and the ACTN VN. Note that this
could be done dynamically. The VN (and TE tunnels) could be
bound to the L3VPN and not used for any other VPN.
Under this mode, the following sub-categories can be
supported:
1. Hard Isolation with deterministic characteristics:
Customer would request an LxVPN service using a set of TE
Tunnels with a deterministic characteristics requirement
(e.g., no latency variation) and that cannot be not shared
with other LxVPN services nor compete for bandwidth with
other Tunnels.
2. Hard Isolation: This is similar to the above case without
deterministic characteristics requirements.
3. Soft Isolation: Customer would request an LxVPN service
using a set of MPLS-TE tunnel which cannot be shared with
other LxVPN services.
Lee, et al. Expires December 2018 [Page 5]
Internet-Draft TE & Service Mapping June 2018
o VN/Tunnel Sharing - Customer could request an L3VPN service
[L3SM-Yang], and with this model as input, the PNC configures
the different network elements to deliver the service. Each
network element would select a tunnel based on the
configuration. With this mode, new tunnels (or VN) are not
created for each VPN. Thus, the tunnels can be shared across
multiple VPN. Further the mapping yang model described in
Section 5 of this document is used to get the mapping between
the L3VPN and the tunnels in use. No modification is allowed
when an existing tunnel is selected.
o VN/Tunnel Modify - This mode allows the modification of the
properties of the existing VN/tunnel (e.g., bandwidth) when
VN/Tunnel Selection Mode is applied.
Other mode of VN/Tunnel selection operations could be easily added
to the current model in the future.
2.2. Availability Requirement
Availability is another LxVPN's service requirement or intent that
needs to be conveyed by the TE & Service Mapping model. Availability
is a probabilistic measure of the length of time a VPN/VN or network
slice instance is functioning. The following level SHOULD be
supported.
o 99.9999%
o 99.999%
o 99.99%
o 99.9%
o 99%
The availability level will need to be translated into network
specific policy such as protection/reroute policy associated with a
VN or Tunnel, which is not in the scope of this draft.
3. L3VPN Architecture in ACTN context
Figure 1 shows the architectural context of this document.
Lee, et al. Expires December 2018 [Page 6]
Internet-Draft TE & Service Mapping June 2018
| L3SM + TE-Svc + VN
V
+------+
| MDSC |
+------+
|
+-------------------------------+
| | |
V V V
+--------+ +--------+ +--------+
|IP/MPLS | | Transp.| |IP/MPLS |
| PNC 1 | | PNC | | PNC 2 |
+--------+ +--------+ +--------+
CE CE
\ AS 100 AS 200 /
\ /
A----B----C----ASBR1------ASBR2----D----E----F
/: / /: /: /: /: /: /:
/ : / / : / : / : / : / : / :
CE----G--:-H----I--:-ASBR3-:----ASBR4-:--J--:-K--:-L--:---CE
: : : : : : : : : : : : : :
: : : : : : : : : : : : : :
: : : : : : : : : : : : : :
: M-:----:--P---:---S------:---U-----V-:--X-:--Y
: / : : / : / : / : / : /
:/ : :/ : / : / :/ :/
N----O----Q-------R----------T----------W----Z
Transport Network
Figure 1: L3VPN Architecture from the IP+Optical Network Perspective
There are three main entities in the architecture.
. MDSC: This entity is responsible for coordinating a L3VPN service
request (expressed in L3SM) with the IP PNC and the Transport PNC.
One of the key responsibilities of the MDSC for TE services is to
coordinate with both the IP PNC and the Transport PNC for the
mapping of L3VPN Service Model and ACTN VN model. With the VN/TE-
tunnel binding case, the MDSC will need to coordinate with the
Transport PNC to dynamically create the TE-tunnel(s) in the
Transport network as needed. These tunnels are added as links in
Lee, et al. Expires December 2018 [Page 7]
Internet-Draft TE & Service Mapping June 2018
the IP Layer topology. The MDSC coordinates with IP PNC to create
the TE-tunnel(s) in the IP layer, as part of the ACTN VN creation.
. IP/MPLS PNC: This entity is responsible for device configuration
to create PE-PE L3VPN tunnels for the VPN customer and for the
configuration of the L3VPN VRF on the PE nodes. Each network
element would select a tunnel based on the configuration.
. Transport PNC: This entity is responsible for device configuration
for TE tunnels in the transport networks.
High-Level Control Flows
1. Customer asks for a L3VPN between CE1 and CE2 with TE
constraints using L3SM model. The customer can provide tunnel
creation policy where it allows dynamic VN/TE tunnel creation
or not. Under this policy, dynamic VN/TE tunnels can be created
when there are no proper VN/TE-tunnels that can support L3VPN
tunnels or when there is a strict isolation requirement for the
VPN service, e.g., no sharing with other tunnels is allowed.
2. The MDSC determines if it needs to create a new VN, and if that
is the case, ACTN VN YANG [ACTN-VN-YANG] is used to configure a
new VN based on this VPN and map the VPN service to ACTN VN. In
case an existing tunnel is to be used, each device will select
which tunnel to use and populates this mapping information.
3. The MDSC interacts with both the IP/MPLS PNC and the Transport
PNC to create a PE-PE tunnel in the IP network mapped to a TE
tunnel in the transport network by providing the inter-layer
access points and tunnel requirements. The specific service
information are passed to the IP/MPLS PNC for the actual VPN
configuration and activation.
a. The Transport PNC creates the corresponding TE tunnel
matching with the access point and egress point.
b. The IP/MPLS PNC maps the VPN ID with the corresponding TE
tunnel ID to bind these two IDs.
4. The IP/MPLS PNC creates/updates a VRF instance for this VPN
customer. This is not in the scope of this document..
Lee, et al. Expires December 2018 [Page 8]
Internet-Draft TE & Service Mapping June 2018
4. YANG Data Tree
module: ietf-te-service-mapping
+--rw te-service-mapping
+--rw service-mapping
| +--rw mapping-list* [map-id]
| +--rw map-id uint32
| +--rw map-type? map-type
| +--rw (service)?
| | +--:(l3vpn)
| | | +--rw l3vpn-ref? -> /l3:l3vpn-svc/vpn-services/vpn-
service/vpn-id
| | +--:(l2vpn)
| | | +--rw l2vpn-ref? -> /l2:l2vpn-svc/vpn-services/vpn-
service/vpn-id
| | +--:(l1vpn)
| | +--rw l1vpn-ref? -> /l1:l1cs/service/service-
list/subscriber-l1vc-id
| +--rw (te)?
| +--:(actn-vn)
| | +--rw actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id
| +--:(te-topo)
| | +--rw vn-topology-id? te-types:te-topology-id
| | +--rw abstract-node? -> /nw:networks/network/node/node-
id
| +--:(te-tunnel)
| +--rw te-tunnel-list* te:tunnel-ref
+--rw site-mapping
+--rw mapping-list* [map-id]
+--rw map-id uint32
+--rw (service)?
| +--:(l3vpn)
| | +--rw l3vpn-ref? -> /l3:l3vpn-svc/sites/site/site-id
| +--:(l2vpn)
| | +--rw l2vpn-ref? -> /l2:l2vpn-svc/sites/site/site-id
| +--:(l1vpn)
| +--rw l1vpn-ref? -> /l1:l1cs/access/uni-list/UNI-ID
+--rw (te)?
+--:(actn-vn)
| +--rw actn-vn-ref? -> /vn:actn/ap/access-point-
list/access-point-id
+--:(te)
+--rw ltp? te-types:te-tp-id
Lee, et al. Expires December 2018 [Page 9]
Internet-Draft TE & Service Mapping June 2018
5. Yang Data Model
The YANG code is as follows:
<CODE BEGINS> file "ietf-te-service-mapping@2018-04-05.yang"
module ietf-te-service-mapping {
namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping";
prefix "tm";
import ietf-l3vpn-svc {
prefix "l3";
}
import ietf-l2vpn-svc {
prefix "l2";
}
import ietf-l1csm {
prefix "l1";
}
import ietf-te-types {
prefix "te-types";
}
import ietf-network {
prefix "nw";
}
import ietf-te {
prefix "te";
}
import ietf-actn-vn {
prefix "vn";
}
organization
Lee, et al. Expires December 2018 [Page 10]
Internet-Draft TE & Service Mapping June 2018
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"Editor: Young Lee <leeyoung@huawei.com>
Dhruv Dhody <dhruv.ietf@gmail.com>";
description
"This module contains a YANG module for the mapping of
service (e.g. L3VPN) to the TE tunnels or ACTN VN.";
revision 2018-04-05 {
description
"initial version.";
reference
"TBD";
}
/*
* Identities
*/
identity service-type {
description
"Base identity from which specific service types are
derived.";
}
identity l3vpn-service {
base service-type;
description
"L3VPN service type.";
}
identity l2vpn-service {
base service-type;
description
"L2VPN service type.";
}
identity l1vpn-service {
base service-type;
description
"L1VPN connectivity service type.";
}
/*
* Enum
Lee, et al. Expires December 2018 [Page 11]
Internet-Draft TE & Service Mapping June 2018
*/
typedef map-type {
type enumeration {
enum "new" {
description
"The new VN/tunnels are binded to the service";
}
enum "select" {
description
"The VPN service selects an existing tunnel with no
modification";
}
enum "modify" {
description
"The VPN service selects an existing tunnel and allows
to modify the properties of the tunnel (e.g., b/w) ";
}
}
description
"The map-type";
}
/*
* Groupings
*/
grouping service-ref{
description
"The reference to the service.";
choice service {
description
"The service";
case l3vpn {
leaf l3vpn-ref {
type leafref {
path "/l3:l3vpn-svc/l3:vpn-services/"
+ "l3:vpn-service/l3:vpn-id";
}
description
"The reference to L3VPN Service Yang Model";
}
}
case l2vpn {
leaf l2vpn-ref {
type leafref {
path "/l2:l2vpn-svc/l2:vpn-services/"
Lee, et al. Expires December 2018 [Page 12]
Internet-Draft TE & Service Mapping June 2018
+ "l2:vpn-service/l2:vpn-id";
}
description
"The reference to L2VPN Service Yang Model";
}
}
case l1vpn {
leaf l1vpn-ref {
type leafref {
path "/l1:l1cs/l1:service/"
+ "l1:service-list/l1:subscriber-l1vc-id";
}
description
"The reference to L1VPN Service Yang Model";
}
}
}
}
grouping site-ref {
description
"The reference to the site.";
choice service {
description
"The service choice";
case l3vpn {
leaf l3vpn-ref{
type leafref {
path "/l3:l3vpn-svc/l3:sites/l3:site/"
+ "l3:site-id";
}
description
"The reference to L3VPN Service Yang Model";
}
}
case l2vpn {
leaf l2vpn-ref{
type leafref {
path "/l2:l2vpn-svc/l2:sites/l2:site/"
+ "l2:site-id";
}
description
"The reference to L2VPN Service Yang Model";
Lee, et al. Expires December 2018 [Page 13]
Internet-Draft TE & Service Mapping June 2018
}
}
case l1vpn {
leaf l1vpn-ref{
type leafref {
path "/l1:l1cs/l1:access/l1:uni-list/"
+ "l1:UNI-ID";
}
description
"The reference to L1VPN Connectivity Service Yang
Model";
}
}
}
}
grouping te-ref {
description
"The reference to TE.";
choice te {
description
"The TE";
case actn-vn {
leaf actn-vn-ref {
type leafref {
path "/vn:actn/vn:vn/vn:vn-list/vn:vn-id";
}
description
"The reference to ACTN VN";
}
}
case te-topo {
leaf vn-topology-id{
type te-types:te-topology-id;
description
"An identifier to the TE Topology Model
where the abstract nodes and links of
the Topology can be found for Type 2
VNS";
}
leaf abstract-node {
type leafref {
Lee, et al. Expires December 2018 [Page 14]
Internet-Draft TE & Service Mapping June 2018
path "/nw:networks/nw:network/nw:node/"
+ "nw:node-id";
}
description
"a reference to the abstract node in TE
Topology";
}
}
case te-tunnel {
leaf-list te-tunnel-list {
type te:tunnel-ref;
description
"Reference to TE Tunnels";
}
}
}
}
grouping te-endpoint-ref {
description
"The reference to TE endpoints.";
choice te {
description
"The TE";
case actn-vn {
leaf actn-vn-ref {
type leafref {
path "/vn:actn/vn:ap/vn:access-point-list"
+ "/vn:access-point-id";
}
description
"The reference to ACTN VN";
}
}
case te {
leaf ltp {
type te-types:te-tp-id;
description
"Reference LTP in the TE-topology";
}
}
}
Lee, et al. Expires December 2018 [Page 15]
Internet-Draft TE & Service Mapping June 2018
}
grouping service-mapping {
description
"Mapping between Services and TE";
container service-mapping {
description
"Mapping between Services and TE";
list mapping-list {
key "map-id";
description
"Mapping identified via a map-id";
leaf map-id {
type uint32;
description
"a unique mapping identifier";
}
leaf map-type {
type map-type;
description
"Tunnel Bind or Tunnel Selection";
}
uses service-ref;
uses te-ref;
}
}
}
grouping site-mapping {
description
"Mapping between VPN access site and TE
endpoints or AP";
container site-mapping {
description
"Mapping between VPN access site and TE
endpoints or AP";
list mapping-list {
key "map-id";
description
"Mapping identified via a map-id";
leaf map-id {
type uint32;
description
Lee, et al. Expires December 2018 [Page 16]
Internet-Draft TE & Service Mapping June 2018
"a unique mapping identifier";
}
uses site-ref;
uses te-endpoint-ref;
}
}
}
/*
* Configuration data nodes
*/
container te-service-mapping {
description
"Mapping between Services and TE";
uses service-mapping;
uses site-mapping;
}
}
<CODE ENDS>
6. Security
The configuration, state, and action data defined in this document
are designed to be accessed via a management protocol with a secure
transport layer, such as NETCONF [RFC6241]. The NETCONF access
control model [RFC6536] provides the means to restrict access for
particular NETCONF users to a preconfigured subset of all available
NETCONF protocol operations and content.
A number of configuration data nodes defined in this document are
writable/deletable (i.e., "config true") These data nodes may be
considered sensitive or vulnerable in some network environments.
Lee, et al. Expires December 2018 [Page 17]
Internet-Draft TE & Service Mapping June 2018
7. IANA Considerations
This document registers the following namespace URIs in the IETF XML
registry [RFC3688]:
--------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
--------------------------------------------------------------------
This document registers the following YANG modules in the YANG
Module
Names registry [RFC7950]:
--------------------------------------------------------------------
name: ietf-te-service-mapping
namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping
reference: RFC XXXX (TDB)
--------------------------------------------------------------------
8. Acknowledgements
We thank Diego Caviglia and Igor Bryskin for useful discussions and
motivation for this work.
9. References
9.1. Informative References
[RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, July 2005.
[RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
Lee, et al. Expires December 2018 [Page 18]
Internet-Draft TE & Service Mapping June 2018
[RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained",
RFC 8309, January 2018.
[Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C.
Moberg, "YANG Module Classification", draft-ietf-netmod-
yang-model-classification, work in progress.
[Netconf] 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-Frame] D. Cecarelli 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.
[RFC8299] Q. Wu, S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data
Model for L3VPN service delivery", RFC 8299, January 2018.
[L2SM-YANG] B. Wen, et al, "A YANG Data Model for L2VPN Service
Delivery", draft-ietf-l2sm-l2vpn-service-model, work in
progress.
[L1CSM-YANG] G. Fioccola, et al, "A Yang Data Model for L1
Connectivity Service Model (L1CSM)", draft-ietf-ccamp-
l1csm-yang, work in progress.
10. Contributors
Lee, et al. Expires December 2018 [Page 19]
Internet-Draft TE & Service Mapping June 2018
Authors' Addresses
Young Lee
Huawei Technologies
5340 Legacy Drive
Plano, TX 75023, USA
Phone: (469)277-5838
Email: leeyoung@huawei.com
Dhruv Dhody
Huawei Technologies
Email: dhruv.ietf@gmail.com
Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com
Jeff Tantsura
Huawei
EMail: jefftant@gmail.com
Giuseppe Fioccola
Telecom Italia
Email: giuseppe.fioccola@telecomitalia.it
Qin Wu
Huawei
Email: bill.wu@huawei.com
Lee, et al. Expires December 2018 [Page 20]