< draft-bryskin-teas-service-tunnel-steering-model-02.txt   draft-bryskin-teas-service-tunnel-steering-model-03.txt >
Network Working Group I. Bryskin Network Working Group I. Bryskin
Internet-Draft Huawei Technologies Internet-Draft Futurewei
Intended status: Informational V. Beeram Intended status: Informational V. Beeram
Expires: August 30, 2019 Juniper Networks Expires: January 6, 2020 T. Saad
T. Saad Juniper Networks
Cisco Systems Inc
X. Liu X. Liu
Volta Networks Volta Networks
Y. Lee Y. Lee
Huawei Technologies Huawei Technologies
February 26, 2019 A. Guo
Futurewei
July 5, 2019
Basic YANG Model for Steering Client Services To Server Tunnels Basic YANG Model for Steering Client Services To Server Tunnels
draft-bryskin-teas-service-tunnel-steering-model-02 draft-bryskin-teas-service-tunnel-steering-model-03
Abstract Abstract
This document describes a YANG data model for managing pools of This document describes a YANG data model for managing pools of
transport tunnels and steering client services on them. transport tunnels and steering client services on them.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 38 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2019. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4
2. Explicit vs. Implicit Service2tunnel Mapping. Steering 2. Explicit vs. Implicit Service2tunnel Mapping. Steering
Services to Transport Tunnel Pools . . . . . . . . . . . . . 4 Services to Transport Tunnel Pools . . . . . . . . . . . . . 5
3. The purpose of the model . . . . . . . . . . . . . . . . . . 5 3. The purpose of the model . . . . . . . . . . . . . . . . . . 5
4. Model Design . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Model Design . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 7 5. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 7
6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 7 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Client layer services/signals are normally mapped onto carrying them Client layer services/signals are normally mapped onto carrying them
across the network transport tunnels via client/server layer across the network transport tunnels via client/server layer
adaptation relationships. Such relationships are usually modeled as adaptation relationships. Such relationships are usually modeled as
multi-layer topologies, whereas tunnels set up in underlay (server) multi-layer topologies, whereas tunnels set up in underlay (server)
topologies support links in respective overlay (client) topologies. topologies support links in respective overlay (client) topologies.
In this respect having a link in a client topology means that the In this respect having a link in a client topology means that the
client layer traffic could be forwarded between link termination client layer traffic could be forwarded between link termination
skipping to change at page 6, line 11 skipping to change at page 6, line 18
network (domain) controller, such as ACTN PNC, to act as a proxy network (domain) controller, such as ACTN PNC, to act as a proxy
server on behalf of any network element/node (physical or abstract) server on behalf of any network element/node (physical or abstract)
under its control. under its control.
4. Model Design 4. Model Design
The data store described/governed by the model is comprised of a The data store described/governed by the model is comprised of a
single top level list - TunnelPools. A TunnelPool, list element, is single top level list - TunnelPools. A TunnelPool, list element, is
a container describing a set of transport tunnels (presumably with a container describing a set of transport tunnels (presumably with
similar characteristics) identified by a network unique ID (color). similar characteristics) identified by a network unique ID (color).
A given TunnelPool could be generic to the entire network or specific
to a particular netwrok slice or network abstract topology.
Furthermore, a TunnelPool may have no tunnels (i.e. may have empty
Tunnels list). Service steered onto such a TunnelPool will be
carried by best effort forwarding technique and flexibility available
in the slice/topology the TunnelPool is assigned to or generally in
the network
The TunnelPool container has the following fields: The TunnelPool container has the following fields:
o Color [uint32 list key]; o Color [uint32 list key];
o Slice/Abstract topology ID (if zero, the TunnelPool is generic to
the network).
o Tunnels list; o Tunnels list;
o Services list. o Services list.
The Tunnels list describes the pool constituents - active transport The Tunnels list describes the pool constituents - active transport
tunnels. The list members - Tunnel containers - include the tunnels. The list members - Tunnel containers - include the
following information: following information:
o tunnel type [e.g. P2P-TE, P2MP-TE, SR-TE, SR P2P, LDP P2P, LDP o tunnel type [e.g. P2P-TE, P2MP-TE, SR-TE, SR P2P, LDP P2P, LDP
MP2MP, GRE, PBB, etc] MP2MP, GRE, PBB, etc]
o tunnel type specific tunnel ID [provided that a data store of the o tunnel type specific tunnel ID [provided that a data store of the
tunnel type, e.g. TE tunnels, is supported, the tunnelID allows tunnel type, e.g. TE tunnels, is supported, the tunnelID allows
for the management application to look up the tunnel in question for the management application to look up the tunnel in question
to obtain detailed information about the tunnel]; to obtain detailed information about the tunnel];
o topology ID [ identifies the topology over which the tunnel's
connection paths are defined];
o tunnel encapsulation [e.g. MPLS label stack, Ethernet STAGs, GRE o tunnel encapsulation [e.g. MPLS label stack, Ethernet STAGs, GRE
header, PBB header, etc]. header, PBB header, etc].
The Services list describes services currently steered on the tunnel The Services list describes services currently steered on the tunnel
pool. The list members - Service containers - have the following pool. The list members - Service containers - have the following
attributes: attributes:
o service type [e.g. fixed/transparent, L3VPN, L2VPN, EVPN, ELINE, o service type [e.g. fixed/transparent, L3VPN, L2VPN, EVPN, ELINE,
EPL, EVPL, L1VPN, ACTN VN, etc.]; EPL, EVPL, L1VPN, ACTN VN, etc.];
skipping to change at page 7, line 10 skipping to change at page 8, line 4
o client ports (source/destination node LTPs over which the service o client ports (source/destination node LTPs over which the service
enters/exits the node/network, relevant only for fixed/transparent enters/exits the node/network, relevant only for fixed/transparent
services); services);
o service encapsulation [e.g. MPLS label stack, Ethernet CTAGs, o service encapsulation [e.g. MPLS label stack, Ethernet CTAGs,
etc.] - for service multiplexing/de-multiplexing on/from a etc.] - for service multiplexing/de-multiplexing on/from a
statistically shared tunnel]. statistically shared tunnel].
5. Tree Structure 5. Tree Structure
module: ietf-tunnel-steering module: ietf-tunnel-steering
+--rw tunnel-pools +--rw tunnel-pools
+--rw tunnel-pool* [color] +--rw tunnel-pool* [color]
+--rw color uint32 +--rw color uint32
+--rw description? string +--rw description? string
+--rw te-topology-identifier
| +--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 service* [service-type id] +--rw service* [service-type id]
| +--rw service-type identityref | +--rw service-type identityref
| +--rw id string | +--rw id string
| +--rw encapsulation | +--rw encapsulation
| | +--rw type? identityref | | +--rw type? identityref
| | +--rw value? binary | | +--rw value? binary
| +--rw access-point* [node-address link-termination-point] | +--rw access-point* [node-address link-termination-point]
| +--rw node-address inet:ip-address | +--rw node-address inet:ip-address
| +--rw link-termination-point string | +--rw link-termination-point string
| +--rw direction? enumeration | +--rw direction? enumeration
+--rw tunnel* +--rw tunnel* [tunnel-type source destination tunnel-id]
[provider-id client-id topology-id tunnel-type 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 tunnel-type identityref +--rw tunnel-type identityref
+--rw source inet:ip-address +--rw source inet:ip-address
+--rw destination inet:ip-address +--rw destination inet:ip-address
+--rw tunnel-id binary +--rw tunnel-id binary
+--rw encapsulation +--rw encapsulation
+--rw type? identityref +--rw type? identityref
+--rw value? binary +--rw value? binary
6. YANG Modules 6. YANG Modules
<CODE BEGINS> file "ietf-tunnel-steering@2019-02-15.yang" <CODE BEGINS> file "ietf-tunnel-steering@2019-07-05.yang"
module ietf-tunnel-steering { module ietf-tunnel-steering {
yang-version 1; yang-version 1;
namespace "urn:ietf:params:xml:ns:yang:ietf-tunnel-steering"; namespace "urn:ietf:params:xml:ns:yang:ietf-tunnel-steering";
prefix "tnl-steer"; prefix "tnl-steer";
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-te-types { import ietf-te-types {
prefix "te-types"; prefix "te-types";
} }
organization organization
"IETF Traffic Engineering Architecture and Signaling (TEAS) "IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/teas/> "WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org> WG List: <mailto:teas@ietf.org>
Editors: Igor Bryskin Editors: Igor Bryskin
<mailto:Igor.Bryskin@huawei.com> <mailto:Igor.Bryskin@huawei.com>
skipping to change at page 8, line 49 skipping to change at page 9, line 41
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info)."; (http://trustee.ietf.org/license-info).";
revision 2019-02-15 { revision 2019-07-05 {
description "Initial revision"; description "Initial revision";
reference "TBD"; reference "TBD";
} }
/* /*
* Typedefs * Typedefs
*/ */
/* /*
* Identities * Identities
*/ */
identity service-type { identity service-type {
skipping to change at page 12, line 33 skipping to change at page 13, line 25
leaf color { leaf color {
type uint32; type uint32;
description description
"Unique ID of a tunnel pool."; "Unique ID of a tunnel pool.";
} }
leaf description { leaf description {
type string; type string;
description description
"Client provided description of the tunnel pool."; "Client provided description of the tunnel pool.";
} }
uses te-types:te-topology-identifier;
list service { list service {
key "service-type id"; key "service-type id";
description description
"A list of client services that are steered on this tunnel "A list of client services that are steered on this tunnel
pool."; pool.";
leaf service-type { leaf service-type {
type identityref { type identityref {
base service-type; base service-type;
} }
description description
skipping to change at page 14, line 4 skipping to change at page 14, line 47
enum "in" { enum "in" {
description "The service enters to the network."; description "The service enters to the network.";
} }
enum "out" { enum "out" {
description "The service exists from the network."; description "The service exists from the network.";
} }
enum "in-out" { enum "in-out" {
description description
"The service enters to and exists from the "The service enters to and exists from the
network."; network.";
} }
} }
description description
"Whether the service enters to or exits from the "Whether the service enters to or exits from the
network."; network.";
} }
} }
} }
list tunnel { list tunnel {
key "provider-id client-id topology-id tunnel-type source " key "tunnel-type source destination tunnel-id";
+ "destination tunnel-id";
description description
"A list of tunnels in the tunnel pool."; "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 tunnel-type { leaf tunnel-type {
type identityref { type identityref {
base tunnel-type; base tunnel-type;
} }
description description
"Tunnel type based on constructing technologies and "Tunnel type based on constructing technologies and
multipoint types, including P2P-TE, P2MP-TE, SR-TE, multipoint types, including P2P-TE, P2MP-TE, SR-TE,
SR P2P, LDP P2P, LDP MP2MP, GRE, PBB, etc"; SR P2P, LDP P2P, LDP MP2MP, GRE, PBB, etc";
} }
leaf source { leaf source {
skipping to change at page 16, line 37 skipping to change at page 17, line 13
-------------------------------------------------------------------- --------------------------------------------------------------------
8. Security Considerations 8. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246]. [RFC8446].
The NETCONF access control model [RFC6536] provides the means to The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. operations and content.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
skipping to change at page 17, line 26 skipping to change at page 18, line 5
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC3688, January 2004,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc3688>.
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6241] 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 and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012,
<https://www.rfc-editor.org/info/rfc6536>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE) O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-19 (work in Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), February 2019. progress), June 2019.
[I-D.ietf-teas-yang-te] [I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"A YANG Data Model for Traffic Engineering Tunnels and "A YANG Data Model for Traffic Engineering Tunnels and
Interfaces", draft-ietf-teas-yang-te-19 (work in Interfaces", draft-ietf-teas-yang-te-21 (work in
progress), February 2019. progress), April 2019.
9.2. Informative References 9.2. Informative References
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
Authors' Addresses Authors' Addresses
Igor Bryskin Igor Bryskin
Huawei Technologies Futurewei
EMail: Igor.Bryskin@huawei.com EMail: igor.bryskin@futurewei.com
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
EMail: vbeeram@juniper.net EMail: vbeeram@juniper.net
Tarek Saad Tarek Saad
Cisco Systems Inc Juniper Networks
EMail: tsaad@juniper.net
EMail: tsaad@cisco.com
Xufeng Liu Xufeng Liu
Volta Networks Volta Networks
EMail: xufeng.liu.ietf@gmail.com EMail: xufeng.liu.ietf@gmail.com
Young Lee Young Lee
Huawei Technologies Huawei Technologies
EMail: leeyoung@huawei.com EMail: leeyoung@huawei.com
Aihua Guo
Futurewei
EMail: aihuaguo@futurewei.com
 End of changes. 37 change blocks. 
67 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/