Network Working Group I. Bryskin
Internet-Draft Huawei Technologies
Intended status: Informational V. Beeram
Expires: May 9, 2019 Juniper Networks
T. Saad
Cisco Systems Inc
X. Liu
Volta Networks
Y. Lee
Huawei Technologies
November 5, 2018
Basic YANG Model for Steering Client Services To Server Tunnels
draft-bryskin-teas-service-tunnel-steering-model-01
Abstract
This document describes a YANG data model for managing pools of
transport tunnels and steering client services on them.
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 https://datatracker.ietf.org/drafts/current/.
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 May 9, 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
(https://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
Bryskin, et al. Expires May 9, 2019 [Page 1]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4
2. Explicit vs. Implicit Service2tunnel Mapping. Steering
Services to Transport Tunnel Pools . . . . . . . . . . . . . 4
3. The purpose of the model . . . . . . . . . . . . . . . . . . 5
4. Model Design . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 7
6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Client layer services/signals are normally mapped onto carrying them
across the network transport tunnels via client/server layer
adaptation relationships. Such relationships are usually modeled as
multi-layer topologies, whereas tunnels set up in underlay (server)
topologies support links in respective overlay (client) topologies.
In this respect having a link in a client topology means that the
client layer traffic could be forwarded between link termination
points (LTPs) terminating the link on opposite sides by the
supporting tunnel(s) configured in the server layer topology.
This said there are numerous use cases in which describing the client
service to server tunnel bindings via the topology formalism is
impractical. Below are some examples of such use cases:
o Mapping client services onto tunnels within the same network
layer, for example, mapping L3 VPNs or MPLS-SR services onto IP
MPLS tunnels;
o Mapping client services onto tunnels provisioned in the highest
layer topology supported by the network. For example, mapping
L2VPNs or E(V)PL services onto IP MPLS tunnels provisioned in IP
network;
Bryskin, et al. Expires May 9, 2019 [Page 2]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
o Mapping client services to tunnels configured in separate network
layers at the network's access points. Consider, for example, an
OTN/ODUk network that is used to carry client signals of, say, 20
different types (e.g. Ethernet, SDH, FKON, etc.) entering and
exiting the network over client facing interfaces. Although it is
possible to describe such a network as a 21-layer TE topology with
the OTN/ODUk topology serving each of the 20 client layer
topologies, such a description would be verbose, cumbersome,
difficult to expand to accommodate additional client signals and
unnecessary, because the client layer topologies would have zero
switching flexibility inside the network (i.e. contain only
unrelated links connecting access points across respective layer
networks), and all what is required to know from the point of view
of a management application is what ODUk tunnels are established
or required, which client signals the tunnels could carry and at
which network border nodes and how the client signals could be
bound (adopted) to the tunnels.
It is worth noting that such non-topological client-service-to-
server-tunnel mapping almost always happens on network border nodes.
However, there are also important use cases where such a mapping is
required in the middle of the network. One such use case is
controlling on IP/MPLS FRR PLRs which LSPs are mapped onto which
backup tunnels.
Service2tunnel mappings could be very complex: large number of
instances of services of the same or different types (possibly
governed by different models) could be mapped on the same set of
tunnels, which could be set in different network layers and could be
either TE or non-TE, P2P or P2MP or MP2MP. Furthermore, the mappings
could be hierarchical: tunnels carrying services could be clients of
other tunnels.
Despite of the differences of transport tunnels and of services they
carry the srvice2tunnel mappings could be described in a simple
uniform way. Access to a data store of such mappings could be
beneficial to network management applications. It would be possible,
for example, to discover which services depend on which tunnels,
which services will be affected if a given tunnel goes out of
service, how many more services could be placed onto a given TE
tunnel without the latter violating its TE commitments (e.g.
bandwidth, delay). It would be also possible to demand in a single
request moving numerous (ranges of) service instances from one set of
tunnels to another.
This document defines a YANG data model for such mappings.
Bryskin, et al. Expires May 9, 2019 [Page 3]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119].
The following terms are defined in [RFC7950] and are not redefined
here:
o augment
o data model
o data node
1.2. Tree Diagrams
A simplified graphical representation of the data model is presented
in this document, by using the tree format defined in [RFC8340].
1.3. Prefixes in Data Node Names
In this document, names of data nodes, actions, and other data model
objects are often used without a prefix, as long as it is clear from
the context in which YANG module each name is defined. Otherwise,
names are prefixed using the standard prefix associated with the
corresponding YANG module, as shown in Table 1.
+----------+-----------------+-------------------------+
| Prefix | YANG module | Reference |
+----------+-----------------+-------------------------+
| inet | ietf-inet-types | [RFC6991] |
| te-types | ietf-te-types | [I-D.ietf-teas-yang-te] |
+----------+-----------------+-------------------------+
Table 1: Prefixes and Corresponding YANG Modules
2. Explicit vs. Implicit Service2tunnel Mapping. Steering Services to
Transport Tunnel Pools
There are use cases in which client services require hard separation
of the transport carrying them from the transport carrying other
services. However, the environment in which the services may share
the same transport tunnels is far more common. For this reason the
model defined in this document suggests replacing (or at least
augmenting) the explicit service2tunnel mapping configuration (in
which the tunnels are referred to by their IDs/names) with implicit
Bryskin, et al. Expires May 9, 2019 [Page 4]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
mapping. Specifically, the model introduces the notion of tunnel
pool. A tunnel pool could be referred to by its network unique color
and requires service2tunnel mapping configuration to specify tunnel
pool color(s) instead of tunnel IDs/names. The model governs tunnel
pool data store independently from the services steered on them. It
is presumed (although not required) that the tunnels - components of
a tunnel pool - are of the same type, provisioned using a common
template and could be dynamically added to/removed from the pool
without necessitating service2tunnel mapping re-configuration. Such
a service to tunnel pool steering approach has the following
advantages:
o Scalability and efficiency: pool component bandwidth utilization
could be monitored, tunnels could be added to/removed from the
pool if/when it is detected that current component bandwidth
utilization has crossed certain thresholds. This allows for a
very efficient network resource utilization and obviates the
network management application from a very difficult task of
service to tunnel mapping planning;
o Automation and elasticity: pool component attributes could be
modified - bandwidth auto-adjusted, protection added, delay
constrained, etc.. The tunnels could be completely or partially
replaced with tunnels of different types (e.g. TE vs. non-TE, P2P
vs. P2MP, etc.) or even provisioned in different network layers
(OTN/ODUk tunnels replacing IP TE tunnels). All such
modifications do not require service2tunell mapping re-
configurations as long as the modified or new tunnels remain
within the same tunnel pool(s);
o Transparency: new service sites supported by additional PEs could
be added without service2tunnel mapping re-configuration.
3. The purpose of the model
To facilitate for network management applications, such as service
orchestrators, managing pools of transport tunnels and steering on
them client services independently of network technology/layer
specifics of the services and the tunnels. The model could be
applied to/implemented on physical devices, such as IP routers, as
well as on abstract topology nodes. Furthermore, the model could be
supported by a network (domain) controller, such as ACTN PNC, to act
as a proxy server on behalf of any network element/node (physical or
abstract) under its control.
Bryskin, et al. Expires May 9, 2019 [Page 5]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
4. Model Design
The data store described/governed by the model is comprised of a
single top level list - TunnelPools. A TunnelPool, list element, is
a container describing a set of transport tunnels (presumably with
similar characteristics) identified by a network unique ID (color).
The TunnelPool container has the following fields:
o Color [uint32 list key];
o Tunnels list;
o Services list.
The Tunnels list describes the pool constituents - active transport
tunnels. The list members - Tunnel containers - include the
following infoemation:
o tunnel type [e.g. P2P-TE, P2MP-TE, SR-TE, SR P2P, LDP P2P, LDP
MP2MP, GRE, PBB, etc]
o tunnel type specific tunnel ID [provided that a data store of the
tunnel type, e.g. TE tunnels, is supported, the tunnelID allows
for the management application to look up the tunnel in question
to obtain detailed information about the tunnel];
o topology ID [ identifies the topology over which the tunnel's
connection paths are defined];
o tunnel source topology node ID;
o tunnel destination topology node ID;
o tunnel layer ID;
o maximal and available/resolvable bandwidth;
o e2e cost;
o e2e one way and round trip delay metrics;
o tunnel protection/restoration capabilities;
o tunnel encapsulation [e.g. MPLS label stack, Ethernet STAGs, GRE
header, PBB header, etc].
Bryskin, et al. Expires May 9, 2019 [Page 6]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
The Services list describes services currently steered on the tunnel
pool. The list members - Service containers - have the following
attributes:
o service type [e.g. fixed/transparent, L3VPN, L2VPN, EVPN, ELINE,
EPL, EVPL, L1VPN, ACTN VN, etc.];
o service type specific service ID [provided that a data store of
the service type, e.g. L2VPN, is supported, the service ID allows
for the management application to look up the service in question
to obtain detailed information about the service];
o client ports (source/destination node LTPs over which the service
enters/exits the node/network, relevant only for fixed/transparent
services);
o service layer ID;
o minimal bandwidth expectations;
o maximal delay expectations;
o minimal protection requirements;
o service encapsulation [e.g. MPLS label stack, Ethernet CTAGs,
etc.] - for service multiplexing/de-multiplexing on/from a
statistically shared tunnel].
5. Tree Structure
module: ietf-tunnel-steering
+--rw tunnel-pools
+--rw tunnel-pool* [color]
+--rw color uint32
+--rw description? string
+--rw service* [service-type id]
| +--rw service-type identityref
| +--rw id string
| +--ro access-point* [node-address link-termination-point]
| | +--ro node-address inet:ip-address
| | +--ro link-termination-point string
| | +--ro direction? enumeration
| +--ro switching-type? identityref
| +--ro protection-type? identityref
| +--ro encapsulation? identityref
| +--ro performance-metric-one-way
| | +--ro one-way-delay? uint32
Bryskin, et al. Expires May 9, 2019 [Page 7]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
| | +--ro one-way-min-delay? uint32
| | +--ro one-way-max-delay? uint32
| | +--ro one-way-delay-variation? uint32
| | +--ro one-way-packet-loss? decimal64
| | +--ro one-way-residual-bandwidth?
| | | rt-types:bandwidth-ieee-float32
| | +--ro one-way-available-bandwidth?
| | | rt-types:bandwidth-ieee-float32
| | +--ro one-way-utilized-bandwidth?
| | rt-types:bandwidth-ieee-float32
| +--ro performance-metric-two-way
| +--ro two-way-delay? uint32
| +--ro two-way-min-delay? uint32
| +--ro two-way-max-delay? uint32
| +--ro two-way-delay-variation? uint32
| +--ro two-way-packet-loss? decimal64
+--rw tunnel*
[provider-id client-id topology-id source destination
tunnel-id]
+--rw provider-id te-types:te-global-id
+--rw client-id te-types:te-global-id
+--rw topology-id
| te-types:te-topology-id
+--rw source inet:ip-address
+--rw destination inet:ip-address
+--rw tunnel-id binary
+--ro tunnel-type? identityref
+--ro switching-type? identityref
+--ro protection-type? identityref
+--ro encapsulation? identityref
+--ro performance-metric-one-way
| +--ro one-way-delay? uint32
| +--ro one-way-min-delay? uint32
| +--ro one-way-max-delay? uint32
| +--ro one-way-delay-variation? uint32
| +--ro one-way-packet-loss? decimal64
| +--ro one-way-residual-bandwidth?
| | rt-types:bandwidth-ieee-float32
| +--ro one-way-available-bandwidth?
| | rt-types:bandwidth-ieee-float32
| +--ro one-way-utilized-bandwidth?
| rt-types:bandwidth-ieee-float32
+--ro performance-metric-two-way
+--ro two-way-delay? uint32
+--ro two-way-min-delay? uint32
+--ro two-way-max-delay? uint32
+--ro two-way-delay-variation? uint32
+--ro two-way-packet-loss? decimal64
Bryskin, et al. Expires May 9, 2019 [Page 8]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
6. YANG Modules
<CODE BEGINS> file "ietf-tunnel-steering@2018-11-03.yang"
module ietf-tunnel-steering {
yang-version 1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tunnel-steering";
prefix "tnl-steer";
import ietf-inet-types {
prefix inet;
}
import ietf-te-types {
prefix "te-types";
}
organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editors: Igor Bryskin
<mailto:Igor.Bryskin@huawei.com>
Editor: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net>
Editor: Tarek Saad
<mailto:tsaad@cisco.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>";
description
"This data model is for steering client service to server
tunnels.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
Bryskin, et al. Expires May 9, 2019 [Page 9]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).";
revision 2018-11-03 {
description "Initial revision";
reference "TBD";
}
/*
* Typedefs
*/
/*
* Identities
*/
identity service-type {
description "Base identity for client service type.";
}
identity service-type-l3vpn {
base service-type;
description
"L3VPN service.";
}
identity service-type-l2vpn {
base service-type;
description
"L2VPN service.";
}
identity service-type-evpn {
base service-type;
description
"EVPN service.";
}
identity service-type-eline {
base service-type;
description
"ELINE service.";
}
identity service-type-epl {
base service-type;
description
"EPL service.";
}
identity service-type-evpl {
base service-type;
description
"EVPL service.";
Bryskin, et al. Expires May 9, 2019 [Page 10]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
}
identity service-type-l1vpn {
base service-type;
description
"L1VPN service.";
}
identity service-type-actn-vn {
base service-type;
description
"ACTN VN service.";
}
identity service-type-transparent {
base service-type;
description
"Transparent LAN service.";
}
identity encapsulation-type {
description "Base identity for tunnel encapsulation.";
}
identity encapsulation-type-mpls-label {
base encapsulation-type;
description
"Encapsulated by MPLS label stack.";
}
identity encapsulation-type-ethernet-s-tag {
base encapsulation-type;
description
"Encapsulated by Ethernet S-TAG.";
}
identity encapsulation-type-pbb {
base encapsulation-type;
description
"Encapsulated by PBB header.";
}
identity encapsulation-type-gre {
base encapsulation-type;
description
"Encapsulated by GRE header.";
}
/*
* Groupings
*/
/*
* Configuration data and operational state data nodes
*/
Bryskin, et al. Expires May 9, 2019 [Page 11]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
container tunnel-pools {
description
"A list of mappings that steer client services to transport
tunnel pools. The tunnel pools are managed independently from
the services steered on them.";
list tunnel-pool {
key "color";
description
"A set of transport tunnels (presumably with similar
characteristics) identified by a network unique ID, named
'color'.";
leaf color {
type uint32;
description
"Unique ID of a tunnel pool.";
}
leaf description {
type string;
description
"Client provided description of the tunnel pool.";
}
list service {
key "service-type id";
description
"A list of client services that are steered on this tunnel
pool.";
leaf service-type {
type identityref {
base service-type;
}
description
"Service type required by the client.";
}
leaf id {
type string;
description
"Unique ID of a client service for the specified
service type.";
}
list access-point {
key "node-address link-termination-point";
config false;
description
"A list of client ports (Link Termination Points) for the
service to enter or exist.";
leaf node-address {
type inet:ip-address;
Bryskin, et al. Expires May 9, 2019 [Page 12]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
description
"Node over which the service enters or exists.";
}
leaf link-termination-point {
type string;
description
"Client port (Link Termination Point) over which the
service enters or exits.";
}
leaf direction {
type enumeration {
enum "in" {
description "The service enters to the network.";
}
enum "out" {
description "The service exists from the network.";
}
enum "in-out" {
description
"The service enters to and exists from the
network.";
}
}
description
"Whether the service enters to or exits from the
network.";
}
}
leaf switching-type {
type identityref {
base te-types:switching-capabilities;
}
config false;
description
"Tunnel switching type required by the client.";
reference "RFC3945";
}
leaf protection-type {
type identityref {
base te-types:lsp-protection-type;
}
config false;
description
"The protection type required by the client.";
}
leaf encapsulation {
type identityref {
base encapsulation-type;
Bryskin, et al. Expires May 9, 2019 [Page 13]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
}
config false;
description
"The encapsulation type used by the tunnel.";
}
uses te-types:performance-metric-container {
refine performance-metric-one-way {
config false;
}
refine performance-metric-two-way {
config false;
}
}
}
list tunnel {
key "provider-id client-id topology-id source destination "
+ "tunnel-id";
description
"A list of tunnels in the tunnel pool.";
leaf provider-id {
type te-types:te-global-id;
description
"An identifier to uniquely identify a provider.";
}
leaf client-id {
type te-types:te-global-id;
description
"An identifier to uniquely identify a client.";
}
leaf topology-id {
type te-types:te-topology-id;
description
"It is presumed that a datastore will contain many
topologies. To distinguish between topologies it is
vital to have UNIQUE topology identifiers.";
}
leaf source {
type inet:ip-address;
description
"For a p2p or p2mp tunnel, this is the source address;
for a mp2mp tunnel, this is the root address.";
reference "RFC3209, RFC4875, RFC6388, RFC7582.";
}
leaf destination {
type inet:ip-address;
description
"For a p2p tunnel, this is the tunnel endpoint address
Bryskin, et al. Expires May 9, 2019 [Page 14]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
extracted from SESSION object;
for a p2mp tunnel, this identifies the destination
group, or p2mp-id;
for a mp2mp tunnel identified by root and opaque-value,
this value is set to '0'.";
reference "RFC3209, RFC4875, RFC6388, RFC7582.";
}
leaf tunnel-id {
type binary;
description
"For a p2p or p2mp tunnel, this is the tunnel identifier
used in the SESSION that remains constant over the life
of the tunnel;
for a mp2mp tunnel, this is the opaque-value in the
FEC element.";
reference "RFC3209, RFC4875, RFC6388, RFC7582.";
}
leaf tunnel-type {
type identityref {
base te-types:te-tunnel-type;
}
config false;
description
"Tunnel type based on constructing technologies and
multipoint types, including P2P-TE, P2MP-TE, SR-TE,
SR P2P, LDP P2P, LDP MP2MP, GRE, PBB, etc";
}
leaf switching-type {
type identityref {
base te-types:switching-capabilities;
}
config false;
description "Tunnel switching type";
reference "RFC3945";
}
leaf protection-type {
type identityref {
base te-types:lsp-protection-type;
}
config false;
description
"The protection type provided by this tunnel.";
}
leaf encapsulation {
type identityref {
base encapsulation-type;
}
config false;
Bryskin, et al. Expires May 9, 2019 [Page 15]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
description
"The encapsulation type used by the tunnel.";
}
uses te-types:performance-metric-container {
refine performance-metric-one-way {
config false;
}
refine performance-metric-two-way {
config false;
}
}
}
}
}
}
<CODE ENDS>
7. IANA Considerations
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
actual RFC number (and remove this note).
This document registers the following namespace URIs in the IETF XML
registry [RFC3688]:
--------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-tunnel-steering
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-tunnel-steering
namespace: urn:ietf:params:xml:ns:yang:ietf-tunnel-steering
prefix: tnl-steer
reference: RFC XXXX
--------------------------------------------------------------------
8. Security Considerations
The configuration, state, action and notification data defined in
this document are designed to be accessed via the NETCONF protocol
[RFC6241]. The data-model by itself does not create any security
Bryskin, et al. Expires May 9, 2019 [Page 16]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
implications. The security considerations for the NETCONF protocol
are applicable. The NETCONF protocol used for sending the data
supports authentication and encryption.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-18 (work in
progress), June 2018.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and
I. Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels and Interfaces", draft-ietf-teas-yang-te-17 (work
in progress), October 2018.
9.2. Informative References
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
Bryskin, et al. Expires May 9, 2019 [Page 17]
Internet-Draft YANG Model Steering Services to Tunnels November 2018
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
Authors' Addresses
Igor Bryskin
Huawei Technologies
EMail: Igor.Bryskin@huawei.com
Vishnu Pavan Beeram
Juniper Networks
EMail: vbeeram@juniper.net
Tarek Saad
Cisco Systems Inc
EMail: tsaad@cisco.com
Xufeng Liu
Volta Networks
EMail: xufeng.liu.ietf@gmail.com
Young Lee
Huawei Technologies
EMail: leeyoung@huawei.com
Bryskin, et al. Expires May 9, 2019 [Page 18]