One document matched: draft-zhang-ccamp-transport-yang-gap-analysis-00.txt
CCAMP Working Group X. Zhang, Ed.
Internet-Draft Huawei Technologies
Intended status: Informational A. Sharma, Ed.
Expires: January 08, 2017 Infinera
S. Belotti
Nokia
T. Cummings
Ericsson
July 07, 2016
YANG Models for the Northbound Interface of a Transport Network
Controller: Requirements and Gap Analysis
draft-zhang-ccamp-transport-yang-gap-analysis-00
Abstract
A transport network is a lower-layer network designed to provide
connectivity services for a higher-layer network to carry the traffic
opaquely across the lower-layer network resources. A transport
network may be constructed from equipment utilizing any of a number
of different transport technologies such as the evolving optical
transport infrastructure (Synchronous Optical Networking (SONET) /
Synchronous Digital Hierarchy (SDH) and Optical Transport Network
(OTN)) or packet transport as epitomized by the MPLS Transport
Profile (MPLS-TP).
All transport networks have high benchmarks for reliability and
operational simplicity. This suggests a common, technology-
independent management/control paradigm that can be extended to
represent and configure specific technology attributes.
This document describes the high-level requirements facing transport
networks in order to provide open interfaces for resource
programmability and control/management automation. Furtheremore, gap
analysis against existing models are also provided so that it can
used as the guidance to separate efforts/drafts proposing new models
or augmentation models based on existing models.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Zhang, et al. Expires January 8, 2017 [Page 1]
Internet-Draft Transport NBI Gap Analysis July 2016
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."
This Internet-Draft will expire on January 8, 2017.
Copyright Notice
Copyright (c) 2016 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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. High-level Modeling Requirements . . . . . . . . . . . . . . 5
3.1. Generic Requirements . . . . . . . . . . . . . . . . . . 5
3.2. Transport Network and TE Topology Requirements . . . . . 5
3.2.1. Topological Link Requirements . . . . . . . . . . . . 6
3.2.2. Topology Node Requirements . . . . . . . . . . . . . 6
3.2.3. Termination Point Requirements . . . . . . . . . . . 6
3.3. Transport Service Requirements . . . . . . . . . . . . . 6
3.4. Tunnel/LSP Requirements . . . . . . . . . . . . . . . . . 7
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Single-domain Scenario . . . . . . . . . . . . . . . . . 7
4.2. Multi-domain Scenario . . . . . . . . . . . . . . . . . . 9
4.3. Multi-layer Scenario . . . . . . . . . . . . . . . . . . 11
4.4. Function Summary and Related YANG Models . . . . . . . . 11
5. Function Gap Analysis on YANG Model Level . . . . . . . . . . 12
5.1. Topology Related Functions . . . . . . . . . . . . . . . 12
5.1.1. Obtaining Access Point Info . . . . . . . . . . . . . 13
5.1.2. Obtaining Topology . . . . . . . . . . . . . . . . . 13
5.1.3. Virtual Network Operations . . . . . . . . . . . . . 13
5.2. Tunnel Operations . . . . . . . . . . . . . . . . . . . . 13
5.3. Service Requests . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
Zhang, et al. Expires January 8, 2017 [Page 2]
Internet-Draft Transport NBI Gap Analysis July 2016
8. Manageability Considerations . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
A transport network is a server-layer network designed to provide
connectivity services, or more advanced services like Virtual Private
Networks (VPN) for a client-layer network to carry the client traffic
opaquely across the server-layer network resources. It acts as a
pipe provider for upper-layer networks, such as IP network and mobile
networks.
Transport networks, such as Synchronous Optical Networking (SONET) /
Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN),
Wavelength Division Multiplexing (WDM), and flexi-grid networks, are
often built using equipment from a single vendor and are managed
using proprietary interfaces to dedicated Element Management Systems
(EMS) / Network Management Systems (NMS). All transport networks
have high benchmarks for reliability and operational simplicity.
This suggests a common, technology-independent management/control
paradigm that is extended to represent and configure specific
technology attributes.
Network providers need a common way to manage multi-vendor and multi-
domain transport networks (where each domain is an island of
equipment from a single supplier) and this requirement has been
further stressed by the expansion in network size. At the same time,
applications such as data center interconnection require larger and
more dynamic connectivities. Therefore, transport networks face new
challenges going beyond automatic provisioning of tunnel setup
enabled by GMPLS (Generalized Multi-Protocol Label Switching)
protocols to achieve automatic service provisioning, as well as
address opportunities enabled by partitioning the transport network
through the process of resource slicing. With a reduction in
operational expenditure (OPEX) and capital expenditure (CAPEX) as the
usual objectives, a common interface to transport network controllers
are considered by network providers as a way to meet the
requirements. The concept of Software Defined Networking (SDN)
leverages these ideas.
The YANG language [RFC6020] is currently the data modeling language
of choice within the IETF and has been adopted by a number of
industry-wide open management and control initiatives. YANG may be
Zhang, et al. Expires January 8, 2017 [Page 3]
Internet-Draft Transport NBI Gap Analysis July 2016
used to model both configuration and operational states; it is
vendor-neutral and supports extensible APIs for control and
management of elements.
This document first specifies the scope and provides high-level
requirements for transport network open interface modelling.
Furthermore, detailed gap analysis of the typical scenarios with the
existing model are provided. Thus, this document can used as a
reference of existing models, and provides information of the missing
ones which suggest further work.
2. Scope
For this draft, we use the domain controller as the reference point,
with South Bound Interface (SBI) to the transport devices and North
Bound Interface (NBI) to the orchestrator.
Transport networks have been evolving and deploying for decades,
making them very heterogeneous. New and legacy transport devices
support many of interface protocols like Path Computation Element
Protocol (PCEP), TL1, SNMP, CLI, XML, NETCONF, Openflow etc. Domain
controllers interfacing with transport devices need to support these
protocols on its SBI, making the southbound fragmented. Domain
controllers abstract the fragmented southbound view for its
northbound clients by normalizing the NBI across various
technologies, protocols, and vendors. The focus of this document is
not to go into various southbound protocols to interface with the
transport devices. Instead, this document focuses on the models that
can be used by the domain controller and the orchestrator for various
use cases identified in later sections of this document. This
document analyzes IETF models for various use cases, such as single-
domain network, multi-domain network, multi-layer network, etc. to
identify any modeling gaps.
YANG models are currently developed not only in IETF, but also in
other Standard Development Organizations (SDO) such as ONF and MEF,
which can be used on the interfaces of a domain controller and an
orchestrator. Each domain controller and orchestrator can use models
developed by different SDOs. Therefore it is important to ensure
that deployment use cases and related funcionalities are supported by
all models to allow a seamless translation/mediation between systems
using different models.
If the Abstraction and Control of Traffic-Engineered Networks (ACTN)
defined in [I-D.ceccarelli-teas-actn-framework] is used as a
reference architcture, then the focus is equivalent to MPI (MDSC-PNC
Interface) and CMI (CNC-MDSC Interface).
Zhang, et al. Expires January 8, 2017 [Page 4]
Internet-Draft Transport NBI Gap Analysis July 2016
3. High-level Modeling Requirements
This section covers various high-level modeling requirements for
transport networks.
3.1. Generic Requirements
The following are generic requirements for Transport models:
o User Intent: Transport models should maintain separation between
high level user intent and the operational state of the network.
For e.g., maintain separation between user service request,
including all constraints, and the actual service and connection
state in the network.
o State Management: Network and service objects should support the
following states: administrative state, operational state, and
lifecycle state. Administrative state and operational states are
well understood. Lifecycle state is defined in the ONF to model
the following entity lifecylce states: planned state, potential
state, installed state, in conflict state, and pending removal
state.
o Identifiers: Network and service objects should support the
following identifier:
* ID: A unique entity ID provided by the controller. The
identifier SHOULD be chosen such that the same entity in a real
network topology will always be identified through the same ID,
even if the model is instantiated in separate datastores.
Controller may choose to capture semantics in the identifier,
for example to indicate the type of entity and/or the type of
the parent identity.
* Name: A unique name provided by the client for the entity. The
name can be modified, if required, by the client.
* User Labels: A list of freeform strings that can be used as
alias for the entity by the client. Multiple user labels are
permitted for the entity, and client can edit these user
labels. User labels do not need to be unique.
3.2. Transport Network and TE Topology Requirements
Zhang, et al. Expires January 8, 2017 [Page 5]
Internet-Draft Transport NBI Gap Analysis July 2016
3.2.1. Topological Link Requirements
The model should support the following Topological Links:
o Physical Links
o Abstract Links [I-D.ietf-teas-interconnected-te-info-exchange]
o Compound Link which are are internally aggregated lower level
links
o Access Links which connect the router port to the client port of
the transport system
o Transitional Links which provide adaptation capability between
layers within a network element
The Link should support various link related attributes like cost,
latency, capacity, risk characteristics (including shared risk). The
model should provide clear association between Link and its topology
(including virtual topology), nodes and termination points.
The model should provide association between the Link and any
underlay circuit / service supporting the Link.
3.2.2. Topology Node Requirements
The model should support the following Topology Node:
o Physical Node
o Abstract Node
o Chassis / Forwarding Domain
[Editors' note: more details will be added later.]
3.2.3. Termination Point Requirements
[Editors' note: this will be added later.]
3.3. Transport Service Requirements
[Editors' note: this will be added later.]
Zhang, et al. Expires January 8, 2017 [Page 6]
Internet-Draft Transport NBI Gap Analysis July 2016
3.4. Tunnel/LSP Requirements
[Editors' note: this will be added later.]
4. Scenarios
There are several scenarios (a.k.a., use cases) where an open
interface via domain controller to access server-layer (transport)
network resources would be useful. Three scenarios are provided and
can be used for model instantiation exercise to identify missing
pieces of existing models.
4.1. Single-domain Scenario
The first scenario is depicted as below (Figure 1 ):
Zhang, et al. Expires January 8, 2017 [Page 7]
Internet-Draft Transport NBI Gap Analysis July 2016
/--\ +------+ +------+ /--\
| 1 ~~~| A +------------------| B |~~~~~ 3 |
\--/ +-----++ +--+---+ \--/
| |
| |
| |
++-----+ +---+--+
| F +------------+ C |
++-----+ +--+---+
| |
| |
| |
| |
| |
+---+-+ +---+-+ /---\
| E +---------------+ D |~~~~ 4 |
/--\~~~~~+-----+ +-----+ \---/
| 2 |
\--/
+----+ /--\
| | Transport NE | | DC
+----+ \--/
----- Transport Link ~~~ Transport-DC link
(a) Data Centers interconnected via a transport network
+---------------------+
| Data Center Network |
| Controller |
+---------+-----------+
|
|
|
| Open Interface
|
|
+---------+-----------+
| Transport Network |
| Controller |
+---------------------+
(b) The controller architecture for data center interconnection
Figure 1: Scenario 1: Data centers interconnected via a transport
network and the controller architecture
Zhang, et al. Expires January 8, 2017 [Page 8]
Internet-Draft Transport NBI Gap Analysis July 2016
For the data center operator, as a client of the transport network,
assuming the objective is to trigger the transport network to provide
connectivity on demand, the following capabilities, at a minimum,
would be required on the common interface between the two controllers
illustrated in Figure 1:
o The ability to obtain information about a set of access points of
the transport network, including information such as access point
identifiers, capabilities, etc.; for instance, transport-network-
side end point identifiers related to the access link between DC1
and Transport NE A.
o The capability to send a request for a service using the
aforementioned access point information, as well as the ability to
retrieve a list of service requests and their statuses. In this
request, it should at least be possible to include source node,
destination node, and requested bandwidth to request the transport
network to set up tunnels/paths so as to provide the requested
connectivitiy for the service request.
o Note that in this case, the acquisition of the topology, be it
physical or logical, of the transport network is not a compulsory
requirement, but it may indeed be able to give data center
providers more control over the transport resource usage.
Furtheremore, the client controller can impose a virtual network
of its own choice by requesting a slice of network resource with
its choice of network parameters (such as network topology type,
bandwidth etc.).
4.2. Multi-domain Scenario
The second scenario, more complicated than the first, is depicted as
below (Figure 2). In this example, we focus on the management and
control via common interfaces for multi-domain networks with
homogeneous technologies (such as OTN), but it can be extended
further to multi-domain networks with heterogeneous technologies with
higher complexity.
Zhang, et al. Expires January 8, 2017 [Page 9]
Internet-Draft Transport NBI Gap Analysis July 2016
+-------------------------------------------------+
| Orchestrator/Coordinator |
+---------+--------------+-------------------+----+
| | |
| | |
+------------+--+ | +----------+----------+
| Controller 1 | | | Controller 2 |
+---------+-----+ | +-------+-------------+
# +----------------+ #
#Qx | Controller 3 | #
# +----------------+ #TL1
# # #
----+----- # ----+-----
____/ \____ # ____/ \____
| | # | |
| | # | |
| Network Domain +***********+ Network Domain |
| 1 | # | 2 |
|____ ___| # |____ ___|
\ / #PCEP \ /
----------- # *----------
* * # * *
* * # * *
* * # * *
* * # * *
* * # * *
* * # * *
* *----+-----* *
* ____/ \____ *
*| |*
| |
| Network Domain |
| 3 |
|____ ___|
\ /
----------
***** inter-domain links
----- Open Interfaces
##### Controller-device interfaces
Figure 2: Scenario 2: Multi-domain network control and management
For the second scenario, the orchestrator controls and manages three
distinct network domains, each controlled/managed by their domain
controller. This scenario is of interest not only to transport-only
Zhang, et al. Expires January 8, 2017 [Page 10]
Internet-Draft Transport NBI Gap Analysis July 2016
networks, but also to heretegenous network orchestration such as
coordinating the transport, the radio (5G) and packet core domains.
But to keep the functions explanation later accurate, only transport-
only multi-domain networks are considered.
In order to orchestrate across domains/layers, besides the
capabilities mentioned for the first scenario, the orchestrator needs
its interface between domain controllers to be equipped with the
following additional functions:
o Access to the topologies reported by each domain controller,
including cross-domain links for the purpose of planning and
requesting the paths of end-to-end tunnels. Multiple technologies
within a domain (i.e., a multi-layer network), this might be
reflected in the reported topology. Depending on the abstraction
level of the reported topology, the orchestrator has different
control granularities.
o Alterntively, the capability for the orchestrator to request "path
computation" to a domain controller in order to create an end-to-
end tunnel stitched together by different connection contribution
obtained by consulting to each domain controller.
o The ability to set up, delete and modify tunnels, be it within one
domain or across multiple domains. Furthermore, it should have
the abilty to view the tunnels created within each domain as well
as those that cross domains as reported by each domain controller.
4.3. Multi-layer Scenario
[Editors' note: to be added later.]
4.4. Function Summary and Related YANG Models
For the common interface of a transport controller towards a
northbound client, five functions are derived from the scenarios
explained in the last section. They are summarized in the table
below and we also match these functions with YANG models that are
being developed in existing drafts.
Zhang, et al. Expires January 8, 2017 [Page 11]
Internet-Draft Transport NBI Gap Analysis July 2016
+-------------+-----------------------+-----------------------+
| Functions | Description | Related Existing |
| | | YANG Models |
|-------------+-----------------------+-----------------------+
| Obtaining |Getting the necessary | |
| Access |access points info | [TE-Topo] |
| Point Info | | |
+-------------+-----------------------+-----------------------+
| Obtaining |Getting the topology |[TE-Topo], [WDM-Topo] |
| Topology |info |[ODU-Topo] |
+-------------+-----------------------+-----------------------+
| Tunnel |Tunnel Setup, Deletion | |
| Operations |Modification and Info | [TE-Tunnel] |
| |Retrieval | |
+-------------+-----------------------+-----------------------+
| Service |Requesting connectivity| |
| Request |service and retrieval | NONE |
| |the list of service | |
| |request | |
+-------------+-----------------------+-----------------------+
|Path Comp. | Path Computation pre | |
| | service provisioning | NONE |
+-------------+-----------------------+-----------------------+
| Virtual |Requesting a virtual | |
| Network |network and related |[TE-Topo], [WDM topo] |
| Operations |control operations, |[ODU-Topo] |
| |(e.g.,update, deletion)| |
+-------------+-----------------------+-----------------------+
Analysis and descriptions of whether and how these functions are
supported by the YANG models are provided in more detail in
Section 5.
5. Function Gap Analysis on YANG Model Level
5.1. Topology Related Functions
As shown in the previous section, the functions of obtaining access
point information, obtaining topology, and imposing virtual network
operations can take advantages of the same set of topology YANG
models. These functions are briefly explained further in the
following sub-sections.
Zhang, et al. Expires January 8, 2017 [Page 12]
Internet-Draft Transport NBI Gap Analysis July 2016
5.1.1. Obtaining Access Point Info
For cases such as scenario 1, a client may have no interest in
directly controlling network resources, but might want an automated
common control interface for initiating service requests. In this
case, a transport domain controller may provide the access point
information. This information can then be used in service request
sent over the common interface.
The TE Topology YANG model provided in [TE-topo]
[I-D.ietf-teas-yang-te-topo] can be used to provide a list of links.
If the remote node and termination point information is unknown, it
is omitted from the reported information. If the client-side node
and termination point information is obtained via configuration or a
distributed discovery mechanism, then it can also be added into the
reported information. Technology-specific details might also be
needed to further express the constraints/attributes associated with
the access points. Note that all of this information is usually read
only.
5.1.2. Obtaining Topology
Refer to [I-D.ietf-teas-yang-te-topo] for explanations and examples
on how to obtain the topology. For technology specific topology
information, other models such as those provided in [WDM-Topo]
[I-D.ietf-ccamp-wson-yang] and [ODU-Topo]
[I-D.zhang-ccamp-l1-topo-yang] may be used.
5.1.3. Virtual Network Operations
There are two ways to request the creation of a virtual network. One
is to define the topology explicitly using the model provided in the
topology YANG drafts listed in previous section. The other way is to
provide an estimated traffic information (a traffic matrix) and ask
for a domain controller of the provider network to provide a virtual
network that can fulfill the demand. This second approach does not
have a supporting model and need further work.
5.2. Tunnel Operations
The current [TE-Tunnel] [I-D.ietf-teas-yang-te] provides a technology
agnostic Traffic-Engineered (TE) device tunnel. The model included
in that draft is currently being developed to make it generic for
both controller and device usage. In the latest version, it already
provides such a generic TE tunnel model that can cater to the base
requirementss for tunnel operations but it may need to be augmented
to support controller-specific operations.
Zhang, et al. Expires January 8, 2017 [Page 13]
Internet-Draft Transport NBI Gap Analysis July 2016
Furthermore, technology-specific augmentations of the base generic TE
tunnel models are needed. For example, for Optical Channel (OCh)
(note: ITU is updating this term as OTSi.) tunnels in WDM networks,
information such as the lambda resource usage is needed. Similarly,
for ODU tunnels, information such as ODU-specific client signal,
tributary slot information etc. is needed.
5.3. Service Requests
The service model is an important model that enables automated
operations between a client controller or an orchestrator and a
domain controller. The transport connectivity service model is
different from the model of a tunnel since the transport connectivity
service model hides technical details from a client.
6. IANA Considerations
This document requests no IANA actions.
7. Security Considerations
Clearly modifying server-layer resources will have a significant
impact on network infrastructure. More specifically they will
provide the services and applications running across client-layers,
which the server-layer is supporting. Therefore, security must be an
important consideration when implementing the architecture, models
and protocol mechanisms discussed in this document.
Communicating service and network information (including access point
identifiers, capabilities, topologies, etc.) across external
interfaces represents a security risk. Thus, mechanisms to encrypt
or preserve the domain topology confidentiality should be used.
A key consideration are the external protocols (those shown as
entering or leaving the orchestrator and controllers shown in
Figure 2 (Scenario 2: Multi-domain network control and management))
which must be appropriately secured. This security should include
authentication and authorization to control access to different
functions that the orchestrator may perform to modify or create state
in the server-layer, and the establishment and management of the
orchestrator to controller relationship.
The orchestrator will contain significant data about the network
domains, the services carried by each domain, and customer type
information. Therefore, access to information held in the
orchestrator must be secured. Since such access will be largely
through external mechanisms, it may be pertinent to apply policy-
based controls to restrict access and functions.
Zhang, et al. Expires January 8, 2017 [Page 14]
Internet-Draft Transport NBI Gap Analysis July 2016
8. Manageability Considerations
The core objectives of this document are to assist in the deployment
and operation of transport services across server-layer network
infrastructure. The model-driven management/control principles,
which are vendor-neutral and supported by extensible APIs, should be
utilized.
The open models described in this document are based on YANG
[RFC6020] and the RESTCONF [RESTCONF] messaging protocol, a REST-like
protocol running over HTTP for accessing data defined in YANG, may
also be used.
9. Acknowledgements
We would like to thank Young Lee, Igor Bryskin and Aihua Guo for
their comments and discussions.
10. Contributing Authors
The following people all contributed to this document and are listed
below:
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Yan Shi
China Unicom
Email: shiyan49@chinaunicom.cn
Jeong-dong Ryoo
ETRI
Email: ryoo@etri.re.kr
Yunbin Xu
CAICT
Email: xuyunbin@ritt.cn
Daniel King
Lancaster University
Email: d.king@lancaster.ac.uk
11. References
Zhang, et al. Expires January 8, 2017 [Page 15]
Internet-Draft Transport NBI Gap Analysis July 2016
11.1. Normative References
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-13 (work in
progress), April 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
11.2. Informative References
[I-D.ceccarelli-teas-actn-framework]
Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", draft-ceccarelli-
teas-actn-framework-02 (work in progress), April 2016.
[I-D.ietf-ccamp-wson-yang]
Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V.,
King, D., and B. Yoon, "A Yang Data Model for WSON Optical
Networks", draft-ietf-ccamp-wson-yang-01 (work in
progress), April 2016.
[I-D.ietf-teas-interconnected-te-info-exchange]
Farrel, A., Drake, J., Bitar, N., Swallow, G., Ceccarelli,
D., and X. Zhang, "Problem Statement and Architecture for
Information Exchange Between Interconnected Traffic
Engineered Networks", draft-ietf-teas-interconnected-te-
info-exchange-07 (work in progress), May 2016.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., Chen,
X., Jones, R., and B. Wen, "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te-02 (work in progress), October 2015.
[I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for TE Topologies", draft-ietf-
teas-yang-te-topo-04 (work in progress), March 2016.
Zhang, et al. Expires January 8, 2017 [Page 16]
Internet-Draft Transport NBI Gap Analysis July 2016
[I-D.zhang-ccamp-l1-topo-yang]
Zhang, X., Rao, B., and X. Liu, "A YANG Data Model for
Layer 1 Network Topology", draft-zhang-ccamp-l1-topo-
yang-01 (work in progress), December 2015.
Authors' Addresses
Xian Zhang (editor)
Huawei Technologies
F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
Email: zhang.xian@huawei.com
Anurag Sharma (editor)
Infinera
US
Email: ansharma@infinera.com
Sergio Belotti
Nokia
Italy
Email: sergio.belotti@nokia.com
Tara Cummings
Ericsson
Email: tara.cummings@ericsson.com
Zhang, et al. Expires January 8, 2017 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 06:24:50 |