draft-ietf-teas-pcecc-use-cases-05.txt   draft-ietf-teas-pcecc-use-cases-06.txt 
TEAS Working Group Q. Zhao TEAS Working Group Z. Li
Internet-Draft Z. Li Internet-Draft B. Khasanov
Intended status: Informational B. Khasanov Intended status: Informational D. Dhody
Expires: September 9, 2020 D. Dhody Expires: March 6, 2021 Huawei Technologies
Huawei Technologies Q. Zhao
Etheric Networks
K. Ke K. Ke
Tencent Holdings Ltd. Tencent Holdings Ltd.
L. Fang L. Fang
Expedia, Inc. Expedia, Inc.
C. Zhou C. Zhou
Cisco Systems HPE
B. Zhang B. Zhang
Telus Communications Telus Communications
A. Rachitskiy A. Rachitskiy
Mobile TeleSystems JLLC Mobile TeleSystems JLLC
A. Gulida A. Gulida
LLC "Lifetech" LLC "Lifetech"
March 8, 2020 September 2, 2020
The Use Cases for Path Computation Element (PCE) as a Central Controller The Use Cases for Path Computation Element (PCE) as a Central Controller
(PCECC). (PCECC).
draft-ietf-teas-pcecc-use-cases-05 draft-ietf-teas-pcecc-use-cases-06
Abstract Abstract
The Path Computation Element (PCE) is a core component of a Software- The Path Computation Element (PCE) is a core component of a Software-
Defined Networking (SDN) system. It can compute optimal paths for Defined Networking (SDN) system. It can compute optimal paths for
traffic across a network and can also update the paths to reflect traffic across a network and can also update the paths to reflect
changes in the network or traffic demands. PCE was developed to changes in the network or traffic demands. PCE was developed to
derive paths for MPLS Label Switched Paths (LSPs), which are supplied derive paths for MPLS Label Switched Paths (LSPs), which are supplied
to the head end of the LSP using the Path Computation Element to the head end of the LSP using the Path Computation Element
Communication Protocol (PCEP). Communication Protocol (PCEP).
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 September 9, 2020. This Internet-Draft will expire on March 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 14, line 6 skipping to change at page 14, line 6
R2----ASBR2====ASBR4---R4---ASBR6 R2----ASBR2====ASBR4---R4---ASBR6
:: :: :: ::
:: :: :: ::
Intra-AS Intra-AS Intra-AS Intra-AS
PCE3 PCE4 PCE3 PCE4
Figure 3: Shorten form of Inter- and Intra-AS PCE Reference Model Figure 3: Shorten form of Inter- and Intra-AS PCE Reference Model
[RFC5376] [RFC5376]
The PCECC belonging to different domain can co-operate to setup The PCECC belonging to different domain can co-operate to setup
inter-AS TE LSP. The stateful H-PCE [I-D.ietf-pce-stateful-hpce] inter-AS TE LSP. The stateful H-PCE [RFC8751] mechanism could also
mechanism could also be used to first establish a per-domain PCECC be used to first establish a per-domain PCECC LSP. These could be
LSP. These could be stitched together to form inter-AS TE LSP as stitched together to form inter-AS TE LSP as described in
described in [I-D.dugeon-pce-stateful-interdomain]. [I-D.dugeon-pce-stateful-interdomain].
For the sake of simplicity, here after the focus is on a simplified For the sake of simplicity, here after the focus is on a simplified
Inter-AS case when both AS1 and AS2 belong to the same service Inter-AS case when both AS1 and AS2 belong to the same service
provider administration. In that case Inter and Intra-AS PCEs could provider administration. In that case Inter and Intra-AS PCEs could
be combined in one single PCE if such combined PCE performance is be combined in one single PCE if such combined PCE performance is
enough for handling all path computation request and setup. There is enough for handling all path computation request and setup. There is
a potential to use a single PCE for both ASes if the scalability and a potential to use a single PCE for both ASes if the scalability and
performance are enough. The PCE would require interfaces (PCEP and performance are enough. The PCE would require interfaces (PCEP and
BGP-LS) to both domains. PCECC redundancy mechanisms are described BGP-LS) to both domains. PCECC redundancy mechanisms are described
in [RFC8283]. Thus routers in AS1 and AS2 (PCCs) can send PCEP in [RFC8283]. Thus routers in AS1 and AS2 (PCCs) can send PCEP
skipping to change at page 22, line 45 skipping to change at page 22, line 45
o What bits of this information to signal to the tail end o What bits of this information to signal to the tail end
These are out of scope of this document. These are out of scope of this document.
3.8. Use Cases of PCECC for SRv6 3.8. Use Cases of PCECC for SRv6
As per [RFC8402], with Segment Routing (SR), a node steers a packet As per [RFC8402], with Segment Routing (SR), a node steers a packet
through an ordered list of instructions, called segments. Segment through an ordered list of instructions, called segments. Segment
Routing can be applied to the IPv6 architecture with the Segment Routing can be applied to the IPv6 architecture with the Segment
Routing Header (SRH) [I-D.ietf-6man-segment-routing-header]. A Routing Header (SRH) [RFC8754]. A segment is encoded as an IPv6
segment is encoded as an IPv6 address. An ordered list of segments address. An ordered list of segments is encoded as an ordered list
is encoded as an ordered list of IPv6 addresses in the routing of IPv6 addresses in the routing header. The active segment is
header. The active segment is indicated by the Destination Address indicated by the Destination Address of the packet. Upon completion
of the packet. Upon completion of a segment, a pointer in the new of a segment, a pointer in the new routing header is incremented and
routing header is incremented and indicates the next segment. indicates the next segment.
As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or
128-bit value. "SRv6 SID" or simply "SID" are often used as a simply "SID" are often used as a shorter reference for "SRv6
shorter reference for "SRv6 Segment". Further details are in An Segment". Further details are in An illustration is provided in
illustration is provided in [I-D.ietf-spring-srv6-network-programming] where SRv6 SID is
[I-D.filsfils-spring-srv6-network-programming] where SRv6 SID is
represented as LOC:FUNCT. represented as LOC:FUNCT.
[I-D.ietf-pce-segment-routing-ipv6] extends [RFC8664] to support SR [I-D.ietf-pce-segment-routing-ipv6] extends [RFC8664] to support SR
for IPv6 data plane. Further a PCECC could be extended to support for IPv6 data plane. Further a PCECC could be extended to support
SRv6 SID allocation and distribution. SRv6 SID allocation and distribution.
2001:db8::1 2001:db8::1
+----------+ +----------+
| R1 | | R1 |
+----------+ +----------+
skipping to change at page 28, line 34 skipping to change at page 28, line 34
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664, Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019, DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>. <https://www.rfc-editor.org/info/rfc8664>.
[I-D.ietf-pce-stateful-hpce] [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
"Hierarchical Stateful Path Computation Element (PCE)", "Hierarchical Stateful Path Computation Element (PCE)",
draft-ietf-pce-stateful-hpce-15 (work in progress), RFC 8751, DOI 10.17487/RFC8751, March 2020,
October 2019. <https://www.rfc-editor.org/info/rfc8751>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[I-D.ietf-pce-pcep-flowspec] [I-D.ietf-pce-pcep-flowspec]
Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow
Specification", draft-ietf-pce-pcep-flowspec-08 (work in Specification", draft-ietf-pce-pcep-flowspec-10 (work in
progress), March 2020. progress), August 2020.
[I-D.ietf-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP
and Protocol Extensions for Using PCE as a Central Procedures and Protocol Extensions for Using PCE as a
Controller (PCECC) of LSPs", draft-ietf-pce-pcep- Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-03 (work in progress), extension-for-pce-controller-07 (work in progress),
November 2019. September 2020.
[I-D.zhao-pce-pcep-extension-pce-controller-sr] [I-D.zhao-pce-pcep-extension-pce-controller-sr]
Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP
and Protocol Extensions for Using PCE as a Central Procedures and Protocol Extensions for Using PCE as a
Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- Central Controller (PCECC) of SR-LSPs", draft-zhao-pce-
extension-pce-controller-sr-05 (work in progress), July pcep-extension-pce-controller-sr-06 (work in progress),
2019. March 2020.
[I-D.li-pce-controlled-id-space] [I-D.li-pce-controlled-id-space]
Li, C., Chen, M., Dong, J., Li, Z., Wang, A., Cheng, W., Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE
and C. Zhou, "PCE Controlled ID Space", draft-li-pce- Controlled ID Space", draft-li-pce-controlled-id-space-06
controlled-id-space-04 (work in progress), January 2020. (work in progress), July 2020.
[I-D.dugeon-pce-stateful-interdomain] [I-D.dugeon-pce-stateful-interdomain]
Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
Extension for Stateful Inter-Domain Tunnels", draft- Extension for Stateful Inter-Domain Tunnels", draft-
dugeon-pce-stateful-interdomain-03 (work in progress), dugeon-pce-stateful-interdomain-04 (work in progress),
November 2019. July 2020.
[I-D.cbrt-pce-stateful-local-protection] [I-D.cbrt-pce-stateful-local-protection]
Barth, C. and R. Torvi, "PCEP Extensions for RSVP-TE Barth, C. and R. Torvi, "PCEP Extensions for RSVP-TE
Local-Protection with PCE-Stateful", draft-cbrt-pce- Local-Protection with PCE-Stateful", draft-cbrt-pce-
stateful-local-protection-01 (work in progress), June stateful-local-protection-01 (work in progress), June
2018. 2018.
[I-D.filsfils-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 Matsushima, S., and Z. Li, "SRv6 Network Programming",
Network Programming", draft-filsfils-spring-srv6-network- draft-ietf-spring-srv6-network-programming-14 (work in
programming-07 (work in progress), February 2019. progress), March 2020.
[I-D.ietf-pce-segment-routing-ipv6] [I-D.ietf-pce-segment-routing-ipv6]
Negi, M., Li, C., Sivabalan, S., Kaladharan, P., and Y. Li, C., Negi, M., Koldychev, M., Kaladharan, P., and Y.
Zhu, "PCEP Extensions for Segment Routing leveraging the Zhu, "PCEP Extensions for Segment Routing leveraging the
IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-03 IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-06
(work in progress), October 2019. (work in progress), July 2020.
[I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-26 (work in
progress), October 2019.
[I-D.ietf-teas-pce-native-ip] [I-D.ietf-teas-pce-native-ip]
Wang, A., Zhao, Q., Khasanov, B., and H. Chen, "PCE in Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE in
Native IP Network", draft-ietf-teas-pce-native-ip-05 (work Native IP Network", draft-ietf-teas-pce-native-ip-11 (work
in progress), January 2020. in progress), August 2020.
[RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi, [RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,
"Scenarios and Simulation Results of PCE in a Native IP "Scenarios and Simulation Results of PCE in a Native IP
Network", RFC 8735, DOI 10.17487/RFC8735, February 2020, Network", RFC 8735, DOI 10.17487/RFC8735, February 2020,
<https://www.rfc-editor.org/info/rfc8735>. <https://www.rfc-editor.org/info/rfc8735>.
[I-D.ietf-bier-te-arch] [I-D.ietf-bier-te-arch]
Eckert, T., Cauchie, G., and M. Menth, "Path Engineering Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering
for Bit Index Explicit Replication (BIER-TE)", draft-ietf- for Bit Index Explicit Replication (BIER-TE)", draft-ietf-
bier-te-arch-06 (work in progress), February 2020. bier-te-arch-07 (work in progress), March 2020.
[I-D.chen-pce-bier] [I-D.chen-pce-bier]
Chen, R., Zhang, Z., Dhanaraj, S., and F. Qin, "PCEP Chen, R., Zhang, Z., Dhanaraj, S., and F. Qin, "PCEP
Extensions for BIER-TE", draft-chen-pce-bier-06 (work in Extensions for BIER-TE", draft-chen-pce-bier-07 (work in
progress), November 2019. progress), May 2020.
[MAP-REDUCE] [MAP-REDUCE]
Lee, K., Choi, T., Ganguly, A., Wolinsky, D., Boykin, P., Lee, K., Choi, T., Ganguly, A., Wolinsky, D., Boykin, P.,
and R. Figueiredo, "Parallel Processing Framework on a P2P and R. Figueiredo, "Parallel Processing Framework on a P2P
System Using Map and Reduce Primitives", , may 2011, System Using Map and Reduce Primitives", , may 2011,
<http://leeky.me/publications/mapreduce_p2p.pdf>. <http://leeky.me/publications/mapreduce_p2p.pdf>.
[MPLS-DC] Afanasiev, D. and D. Ginsburg, "MPLS in DC and inter-DC [MPLS-DC] Afanasiev, D. and D. Ginsburg, "MPLS in DC and inter-DC
networks: the unified forwarding mechanism for network networks: the unified forwarding mechanism for network
programmability at scale", , march 2014, programmability at scale", , march 2014,
skipping to change at page 30, line 41 skipping to change at page 30, line 41
7.3. URIs 7.3. URIs
[1] https://hadoop.apache.org/ [1] https://hadoop.apache.org/
Appendix A. Using reliable P2MP TE based multicast delivery for Appendix A. Using reliable P2MP TE based multicast delivery for
distributed computations (MapReduce-Hadoop) distributed computations (MapReduce-Hadoop)
MapReduce model of distributed computations in computing clusters is MapReduce model of distributed computations in computing clusters is
widely deployed. In Hadoop [1] 1.0 architecture MapReduce operations widely deployed. In Hadoop [1] 1.0 architecture MapReduce operations
on big data performs by means of Master-Slave architecture in the on big data in the Hadoop Distributed File System (HDFS), where
Hadoop Distributed File System (HDFS), where NameNode has the NameNode has the knowledge about resources of the cluster and where
knowledge about resources of the cluster and where actual data actual data (chunks) for particular task are located (which
(chunks) for particular task are located (which DataNode). Each DataNode). Each chunk of data (64MB or more) should have 3 saved
chunk of data (64MB or more) should have 3 saved copies in different copies in different DataNodes based on their proximity.
DataNodes based on their proximity.
Proximity level currently has semi-manual allocation and based on Proximity level currently has semi-manual allocation and based on
Rack IDs (Assumption is that closer data are better because of access Rack IDs (Assumption is that closer data are better because of access
speed/smaller latency). speed/smaller latency).
JobTracker node is responsible for computation tasks, scheduling JobTracker node is responsible for computation tasks, scheduling
across DataNodes and also have Rack-awareness. Currently transport across DataNodes and also have Rack-awareness. Currently transport
protocols between NameNode/JobTracker and DataNodes are based on IP protocols between NameNode/JobTracker and DataNodes are based on IP
unicast. It has simplicity as pros but has numerous drawbacks unicast. It has simplicity as pros but has numerous drawbacks
related with its flat approach. related with its flat approach.
skipping to change at page 31, line 36 skipping to change at page 31, line 33
could improve speed of resource or cluster members discovery inside could improve speed of resource or cluster members discovery inside
the cluster as well as increase redundancy in communications between the cluster as well as increase redundancy in communications between
cluster nodes. cluster nodes.
Is traditional IP based multicast enough for that? We doubt it Is traditional IP based multicast enough for that? We doubt it
because it requires additional control plane (IGMP, PIM) and a lot of because it requires additional control plane (IGMP, PIM) and a lot of
signaling, that is not suitable for high performance computations, signaling, that is not suitable for high performance computations,
that are very sensitive to latency. that are very sensitive to latency.
P2MP TE tunnels looks much more suitable as potential solution for P2MP TE tunnels looks much more suitable as potential solution for
creation of multicast based communications between Master and Slave creation of multicast based communications between NameNode as root
nodes inside cluster. Obviously these P2MP tunnels should be and DataNodes as leaves inside the cluster. Obviously these P2MP
dynamically created and turned down (no manual intervention). Here, tunnels should be dynamically created and turned down (no manual
the PCECC comes to play with main objective to create optimal intervention). Here, the PCECC comes to play with main objective to
topology of each particular request for MapReduce computation and create optimal topology of each particular request for MapReduce
also create P2MP tunnels with needed parameters such as bandwidth and computation and also create P2MP tunnels with needed parameters such
delay. as bandwidth and delay.
This solution would require to use MPLS label based forwarding inside This solution would require to use MPLS label based forwarding inside
the cluster. Usage of label based forwarding inside DC was proposed the cluster. Usage of label based forwarding inside DC was proposed
by Yandex [MPLS-DC]. Technically it is already possible because MPLS by Yandex [MPLS-DC]. Technically it is already possible because MPLS
on switches is already supported by some vendors, MPLS also exists on on switches is already supported by some vendors, MPLS also exists on
Linux and OVS. Linux and OVS.
The following framework can make this task: The following framework can make this task:
+--------+ +--------+
skipping to change at page 32, line 32 skipping to change at page 32, line 32
| | | | | | | | | | | | | | | |
+-------------+ | | | | +----------+ +-------------+ | | | | +----------+
+------------------+ | +-----------+ +------------------+ | +-----------+
| | | | | | | |
|---+-----P2MP TE--+-----|-----------| | |---+-----P2MP TE--+-----|-----------| |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| DataNode1| | DataNode2| | DataNodeN| | DataNode1| | DataNode2| | DataNodeN|
|TaskTraker| |TaskTraker| .... |TaskTraker| |TaskTraker| |TaskTraker| .... |TaskTraker|
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Communication between Master nodes (JobTracker and NameNode) and Communication between JobTracker, NameNode and PCECC can be done via
PCECC via REST API MAY be either done directly or via cluster manager REST API directly or via cluster manager such as Mesos.
such as Mesos.
Phase 1: Distributed cluster resources discovery During this phase Phase 1: Distributed cluster resources discovery During this phase
Master Nodes SHOULD identify and find available Slave nodes according JobTracker and NameNode SHOULD identify and find available DataNodes
to computing request from application (APP). NameNode SHOULD query according to computing request from application (APP). NameNode
PCECC about available DataNodes, NameNode MAY provide additional SHOULD query PCECC about available DataNodes, NameNode MAY provide
constrains to PCECC such as topological proximity, redundancy level. additional constrains to PCECC such as topological proximity,
redundancy level.
PCECC SHOULD analyze the topology of distributed cluster and perform PCECC SHOULD analyze the topology of distributed cluster and perform
constrain based path calculation from client towards most suitable constrain based path calculation from client towards most suitable
NameNodes. PCECC SHOULD reply to NameNode the list of most suitable NameNodes. PCECC SHOULD reply to NameNode the list of most suitable
DataNodes and their resource capabilities. Topology discovery DataNodes and their resource capabilities. Topology discovery
mechanism for PCECC will be added later to that framework. mechanism for PCECC will be added later to that framework.
Phase 2: PCECC SHOULD create P2MP LSP from client towards those Phase 2: PCECC SHOULD create P2MP LSP from client towards those
DataNodes by means of PCEP messages following previously calculated DataNodes by means of PCEP messages following previously calculated
path. path.
skipping to change at page 33, line 16 skipping to change at page 33, line 16
informs client about optimal P2MP path towards DataNodes via PCEP informs client about optimal P2MP path towards DataNodes via PCEP
message. message.
Phase 4. Client sends data blocks to those DataNodes for writing via Phase 4. Client sends data blocks to those DataNodes for writing via
created P2MP tunnel. created P2MP tunnel.
When this task will be finished, P2MP tunnel could be turned down. When this task will be finished, P2MP tunnel could be turned down.
Authors' Addresses Authors' Addresses
Quintin Zhao
Huawei Technologies
125 Nagog Technology Park
Acton, MA 01719
US
Email: quintinzhao@gmail.com
Zhenbin (Robin) Li Zhenbin (Robin) Li
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
Boris Khasanov Boris Khasanov
Huawei Technologies Huawei Technologies
skipping to change at page 34, line 4 skipping to change at page 33, line 39
Email: khasanov.boris@huawei.com Email: khasanov.boris@huawei.com
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Quintin Zhao
Etheric Networks
1009 S CLAREMONT ST
SAN MATEO, CA 94402
USA
Email: qzhao@ethericnetworks.com
King Ke King Ke
Tencent Holdings Ltd. Tencent Holdings Ltd.
Shenzhen Shenzhen
China China
Email: kinghe@tencent.com Email: kinghe@tencent.com
Luyuan Fang Luyuan Fang
Expedia, Inc. Expedia, Inc.
USA USA
Email: luyuanf@gmail.com Email: luyuanf@gmail.com
Chao Zhou Chao Zhou
Cisco Systems HPE
Email: chao.zhou@cisco.com Email: chaozhou_us@yahoo.com
Boris Zhang Boris Zhang
Telus Communications Telus Communications
Email: Boris.zhang@telus.com Email: Boris.zhang@telus.com
Artem Rachitskiy Artem Rachitskiy
Mobile TeleSystems JLLC Mobile TeleSystems JLLC
Nezavisimosti ave., 95 Nezavisimosti ave., 95
Minsk 220043 Minsk 220043
 End of changes. 30 change blocks. 
96 lines changed or deleted 93 lines changed or added

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