draft-ietf-teas-pcecc-use-cases-06.txt   draft-ietf-teas-pcecc-use-cases-07.txt 
TEAS Working Group Z. Li TEAS Working Group Z. Li
Internet-Draft B. Khasanov Internet-Draft D. Dhody
Intended status: Informational D. Dhody Intended status: Informational Huawei Technologies
Expires: March 6, 2021 Huawei Technologies Expires: September 9, 2021 Q. Zhao
Q. Zhao
Etheric Networks Etheric Networks
K. Ke K. Ke
Tencent Holdings Ltd. Tencent Holdings Ltd.
B. Khasanov
Yandex LLC
L. Fang L. Fang
Expedia, Inc. Expedia, Inc.
C. Zhou C. Zhou
HPE 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"
September 2, 2020 March 8, 2021
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-06 draft-ietf-teas-pcecc-use-cases-07
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 5 skipping to change at page 2, line 7
network. It is, therefore, reasonable to consider PCEP as a control network. It is, therefore, reasonable to consider PCEP as a control
protocol for use in these environments to allow the PCE to be fully protocol for use in these environments to allow the PCE to be fully
enabled as a central controller. enabled as a central controller.
This document describes general considerations for PCECC deployment This document describes general considerations for PCECC deployment
and examines its applicability and benefits, as well as its and examines its applicability and benefits, as well as its
challenges and limitations, through a number of use cases. PCEP challenges and limitations, through a number of use cases. PCEP
extensions required for stateful PCE usage are covered in separate extensions required for stateful PCE usage are covered in separate
documents. documents.
This is a living document to catalogue the use cases for PCECC. This is a living document to catalog the use cases for PCECC. There
There is currently no intention to publish this work as an RFC. is currently no intention to publish this work as an RFC. [Update:
Chairs are evaluating if the document should be published instead.]
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Status of This Memo Status of This Memo
skipping to change at page 2, line 31 skipping to change at page 2, line 34
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 March 6, 2021. This Internet-Draft will expire on September 9, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 20 skipping to change at page 3, line 20
3.1. Use Cases of PCECC for Label Management . . . . . . . . . 4 3.1. Use Cases of PCECC for Label Management . . . . . . . . . 4
3.2. Using PCECC for SR . . . . . . . . . . . . . . . . . . . 6 3.2. Using PCECC for SR . . . . . . . . . . . . . . . . . . . 6
3.2.1. PCECC SID Allocation . . . . . . . . . . . . . . . . 7 3.2.1. PCECC SID Allocation . . . . . . . . . . . . . . . . 7
3.2.2. Use Cases of PCECC for SR Best Effort (BE) Path . . . 8 3.2.2. Use Cases of PCECC for SR Best Effort (BE) Path . . . 8
3.2.3. Use Cases of PCECC for SR Traffic Engineering (TE) 3.2.3. Use Cases of PCECC for SR Traffic Engineering (TE)
Path . . . . . . . . . . . . . . . . . . . . . . . . 8 Path . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Use Cases of PCECC for TE LSP . . . . . . . . . . . . . . 9 3.3. Use Cases of PCECC for TE LSP . . . . . . . . . . . . . . 9
3.3.1. PCECC Load Balancing (LB) Use Case . . . . . . . . . 11 3.3.1. PCECC Load Balancing (LB) Use Case . . . . . . . . . 11
3.3.2. PCECC and Inter-AS TE . . . . . . . . . . . . . . . . 13 3.3.2. PCECC and Inter-AS TE . . . . . . . . . . . . . . . . 13
3.4. Use Cases of PCECC for Multicast LSPs . . . . . . . . . . 16 3.4. Use Cases of PCECC for Multicast LSPs . . . . . . . . . . 16
3.4.1. Using PCECC for P2MP/MP2MP LSPs' Setup . . . . . . . 16 3.4.1. Using PCECC for P2MP/MP2MP LSPs' Setup . . . . . . . 17
3.4.2. Use Cases of PCECC for the Resiliency of P2MP/MP2MP 3.4.2. Use Cases of PCECC for the Resiliency of P2MP/MP2MP
LSPs . . . . . . . . . . . . . . . . . . . . . . . . 17 LSPs . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5. Use Cases of PCECC for LSP in the Network Migration . . . 19 3.5. Use Cases of PCECC for LSP in the Network Migration . . . 20
3.6. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . 21 3.6. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . 22
3.7. Using PCECC for Traffic Classification Information . . . 22 3.7. Using PCECC for Traffic Classification Information . . . 23
3.8. Use Cases of PCECC for SRv6 . . . . . . . . . . . . . . . 22 3.8. Use Cases of PCECC for SRv6 . . . . . . . . . . . . . . . 23
3.9. Use Cases of PCECC for SFC . . . . . . . . . . . . . . . 24 3.9. Use Cases of PCECC for SFC . . . . . . . . . . . . . . . 25
3.10. Use Cases of PCECC for Native IP . . . . . . . . . . . . 24 3.10. Use Cases of PCECC for Native IP . . . . . . . . . . . . 25
3.11. Use Cases of PCECC for Local Protection (RSVP-TE) . . . . 25 3.11. Use Cases of PCECC for Local Protection (RSVP-TE) . . . . 26
3.12. Use Cases of PCECC for BIER . . . . . . . . . . . . . . . 25 3.12. Use Cases of PCECC for BIER . . . . . . . . . . . . . . . 26
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . 26 7.1. Normative References . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Using reliable P2MP TE based multicast delivery for Appendix A. Using reliable P2MP TE based multicast delivery for
distributed computations (MapReduce-Hadoop) . . . . 30 distributed computations (MapReduce-Hadoop) . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
An Architecture for Use of PCE and PCEP [RFC5440] in a Network with An Architecture for Use of PCE and PCEP [RFC5440] in a Network with
Central Control [RFC8283] describes SDN architecture where the Path Central Control [RFC8283] describes SDN architecture where the Path
Computation Element (PCE) determines paths for variety of different Computation Element (PCE) determines paths for variety of different
usecases, with PCEP as a general southbound communication protocol usecases, with PCEP as a general southbound communication protocol
with all the nodes along the path.. with all the nodes along the path..
[I-D.ietf-pce-pcep-extension-for-pce-controller] introduces the [I-D.ietf-pce-pcep-extension-for-pce-controller] introduces the
procedures and extensions for PCEP to support the PCECC architecture procedures and extensions for PCEP to support the PCECC architecture
[RFC8283]. [RFC8283].
This draft describes the various usecases for the PCECC architecture. This draft describes the various usecases for the PCECC architecture.
This is a living document to catalogue the use cases for PCECC. This is a living document to catalog the use cases for PCECC. There
There is currently no intention to publish this work as an RFC. is currently no intention to publish this work as an RFC. [Update:
Chairs are evaluating if the document should be published instead.]
2. Terminology 2. Terminology
The following terminology is used in this document. The following terminology is used in this document.
IGP: Interior Gateway Protocol. Either of the two routing IGP: Interior Gateway Protocol. Either of the two routing
protocols, Open Shortest Path First (OSPF) or Intermediate System protocols, Open Shortest Path First (OSPF) or Intermediate System
to Intermediate System (IS-IS). to Intermediate System (IS-IS).
PCC: Path Computation Client: any client application requesting a PCC: Path Computation Client: any client application requesting a
skipping to change at page 5, line 9 skipping to change at page 5, line 10
label forwarding instructions to program and what resources to label forwarding instructions to program and what resources to
reserve. The controller uses PCEP to communicate with each router reserve. The controller uses PCEP to communicate with each router
along the path of the end-to-end LSP. For this to work, the PCE- along the path of the end-to-end LSP. For this to work, the PCE-
based controller will take responsibility for managing some part of based controller will take responsibility for managing some part of
the MPLS label space for each of the routers that it controls. An the MPLS label space for each of the routers that it controls. An
extension to PCEP could be done to allow a PCC to inform the PCE of extension to PCEP could be done to allow a PCC to inform the PCE of
such a label space to control. such a label space to control.
[RFC8664] specifies extensions to PCEP that allow a stateful PCE to [RFC8664] specifies extensions to PCEP that allow a stateful PCE to
compute, update or initiate SR-TE paths. compute, update or initiate SR-TE paths.
[I-D.zhao-pce-pcep-extension-pce-controller-sr] describes the [I-D.ietf-pce-pcep-extension-pce-controller-sr] describes the
mechanism for PCECC to allocate and provision the node/prefix/ mechanism for PCECC to allocate and provision the node/prefix/
adjacency label (SID) via PCEP. To make such allocation PCE needs to adjacency label (SID) via PCEP. To make such allocation PCE needs to
be aware of the label space from Segment Routing Global Block (SRGB) be aware of the label space from Segment Routing Global Block (SRGB)
or Segment Routing Local Block (SRLB) [RFC8402] of the node that it or Segment Routing Local Block (SRLB) [RFC8402] of the node that it
controls. A mechanism for a PCC to inform the PCE of such a label controls. A mechanism for a PCC to inform the PCE of such a label
space to control is needed within PCEP. The full SRGB/SRLB of a node space to control is needed within PCEP. The full SRGB/SRLB of a node
could be learned via existing IGP or BGP-LS mechanism too. could be learned via existing IGP or BGP-LS mechanism too.
[I-D.li-pce-controlled-id-space] defines a PCEP extension to support [I-D.li-pce-controlled-id-space] defines a PCEP extension to support
advertisement of the MPLS label space to the PCE to control. advertisement of the MPLS label space to the PCE to control.
skipping to change at page 6, line 43 skipping to change at page 6, line 47
SR nodes (PCC) with some benefits. If the PCECC allocates and SR nodes (PCC) with some benefits. If the PCECC allocates and
maintains the SID in the network for the nodes and adjacencies; and maintains the SID in the network for the nodes and adjacencies; and
further distributes them to the SR nodes directly via the PCEP further distributes them to the SR nodes directly via the PCEP
session has some advantage over the configurations on each SR node session has some advantage over the configurations on each SR node
and flooding via IGP, especially in a SDN environment. and flooding via IGP, especially in a SDN environment.
When the PCECC is used for the distribution of the node segment ID When the PCECC is used for the distribution of the node segment ID
and adjacency segment ID, the node segment ID is allocated from the and adjacency segment ID, the node segment ID is allocated from the
SRGB of the node. For the allocation of adjacency segment ID, the SRGB of the node. For the allocation of adjacency segment ID, the
allocation is from the SRLB of the node as described in allocation is from the SRLB of the node as described in
[I-D.zhao-pce-pcep-extension-pce-controller-sr]. [I-D.ietf-pce-pcep-extension-pce-controller-sr].
[RFC8355] identifies various protection and resiliency usecases for [RFC8355] identifies various protection and resiliency usecases for
SR. Path protection lets the ingress node be in charge of the SR. Path protection lets the ingress node be in charge of the
failure recovery (used for SR-TE). Also protection can be performed failure recovery (used for SR-TE). Also protection can be performed
by the node adjacent to the failed component, commonly referred to as by the node adjacent to the failed component, commonly referred to as
local protection techniques or fast-reroute (FRR) techniques. In local protection techniques or fast-reroute (FRR) techniques. In
case of PCECC, the protection paths can be pre-computed and setup by case of PCECC, the protection paths can be pre-computed and setup by
the PCE. the PCE.
The following example illustrate the use case where the node SID and The following example illustrate the use case where the node SID and
skipping to change at page 8, line 6 skipping to change at page 8, line 8
the packet towards the related node. the packet towards the related node.
For each adjacency in the network, PCECC can allocate an Adj-SID. For each adjacency in the network, PCECC can allocate an Adj-SID.
The PCECC sends PCInitiate message to update the label map of each The PCECC sends PCInitiate message to update the label map of each
Adj to the corresponding nodes in the domain. Each node (PCC) Adj to the corresponding nodes in the domain. Each node (PCC)
download the label forwarding instructions accordingly. The download the label forwarding instructions accordingly. The
forwarding behavior and the end result is similar to IGP based "Adj- forwarding behavior and the end result is similar to IGP based "Adj-
SID" in SR. SID" in SR.
The various mechanism are described in The various mechanism are described in
[I-D.zhao-pce-pcep-extension-pce-controller-sr]. [I-D.ietf-pce-pcep-extension-pce-controller-sr].
3.2.2. Use Cases of PCECC for SR Best Effort (BE) Path 3.2.2. Use Cases of PCECC for SR Best Effort (BE) Path
In this mode of the solution, the PCECC just need to allocate the In this mode of the solution, the PCECC just need to allocate the
node segment ID and adjacency ID (without calculating the explicit node segment ID and adjacency ID (without calculating the explicit
path for the SR path). The ingress of the forwarding path just need path for the SR path). The ingress of the forwarding path just need
to encapsulate the destination node segment ID on top of the packet. to encapsulate the destination node segment ID on top of the packet.
All the intermediate nodes will forward the packet based on the All the intermediate nodes will forward the packet based on the
destination node SID. It is similar to the LDP LSP. destination node SID. It is similar to the LDP LSP.
skipping to change at page 14, line 9 skipping to change at page 14, line 25
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 [RFC8751] mechanism could also inter-AS TE LSP. The stateful H-PCE [RFC8751] mechanism could also
be used to first establish a per-domain PCECC LSP. These could be be used to first establish a per-domain PCECC LSP. These could be
stitched together to form inter-AS TE LSP as described in stitched together to form inter-AS TE LSP as described in
[I-D.dugeon-pce-stateful-interdomain]. [I-D.ietf-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 23, line 8 skipping to change at page 24, line 8
Routing Header (SRH) [RFC8754]. A segment is encoded as an IPv6 Routing Header (SRH) [RFC8754]. A segment is encoded as an IPv6
address. An ordered list of segments is encoded as an ordered list address. An ordered list of segments is encoded as an ordered list
of IPv6 addresses in the routing header. The active segment is of IPv6 addresses in the routing header. The active segment is
indicated by the Destination Address of the packet. Upon completion indicated by the Destination Address of the packet. Upon completion
of a segment, a pointer in the new routing header is incremented and of a segment, a pointer in the new routing header is incremented and
indicates the next segment. indicates the next segment.
As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or
simply "SID" are often used as a shorter reference for "SRv6 simply "SID" are often used as a shorter reference for "SRv6
Segment". Further details are in An illustration is provided in Segment". Further details are in An illustration is provided in
[I-D.ietf-spring-srv6-network-programming] where SRv6 SID is [RFC8986] 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 25, line 37 skipping to change at page 26, line 37
receiver(s) following a precomputed tree for each of the bits in the receiver(s) following a precomputed tree for each of the bits in the
packet. Each receiver is represented by a unique bit in the bitmask. packet. Each receiver is represented by a unique bit in the bitmask.
BIER-TE [I-D.ietf-bier-te-arch] shares architecture and packet BIER-TE [I-D.ietf-bier-te-arch] shares architecture and packet
formats with BIER. BIER-TE forwards and replicates packets based on formats with BIER. BIER-TE forwards and replicates packets based on
a BitString in the packet header, but every BitPosition of the a BitString in the packet header, but every BitPosition of the
BitString of a BIER-TE packet indicates one or more adjacencies. BitString of a BIER-TE packet indicates one or more adjacencies.
BIER-TE Path can be derived from a PCE and used at the ingress as BIER-TE Path can be derived from a PCE and used at the ingress as
described in [I-D.chen-pce-bier]. described in [I-D.chen-pce-bier].
Further, PCECC mechanims could be used for the allocation of bits for Further, PCECC mechanism could be used for the allocation of bits for
the BIER router for BIER as well as for the adjacencies for BIER-TE. the BIER router for BIER as well as for the adjacencies for BIER-TE.
PCECC based controller can use PCEP to instruct the BIER capable PCECC based controller can use PCEP to instruct the BIER capable
routers the meaning of the bits as well as other fields needed for routers the meaning of the bits as well as other fields needed for
BIER encapsulation. BIER encapsulation.
[Editor's Note - more details to be added] [Editor's Note - more details to be added]
4. IANA Considerations 4. IANA Considerations
This document does not require any action from IANA. This document does not require any action from IANA.
skipping to change at page 28, line 34 skipping to change at page 29, 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>.
[RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,
"Scenarios and Simulation Results of PCE in a Native IP
Network", RFC 8735, DOI 10.17487/RFC8735, February 2020,
<https://www.rfc-editor.org/info/rfc8735>.
[RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
"Hierarchical Stateful Path Computation Element (PCE)", "Hierarchical Stateful Path Computation Element (PCE)",
RFC 8751, DOI 10.17487/RFC8751, March 2020, RFC 8751, DOI 10.17487/RFC8751, March 2020,
<https://www.rfc-editor.org/info/rfc8751>. <https://www.rfc-editor.org/info/rfc8751>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[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-10 (work in Specification", draft-ietf-pce-pcep-flowspec-12 (work in
progress), August 2020. progress), October 2020.
[I-D.ietf-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP
Procedures and Protocol Extensions for Using PCE as a Procedures and Protocol Extensions for Using PCE as a
Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-07 (work in progress), extension-for-pce-controller-10 (work in progress),
September 2020. January 2021.
[I-D.zhao-pce-pcep-extension-pce-controller-sr] [I-D.ietf-pce-pcep-extension-pce-controller-sr]
Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP
Procedures and Protocol Extensions for Using PCE as a Procedures and Protocol Extensions for Using PCE as a
Central Controller (PCECC) of SR-LSPs", draft-zhao-pce- Central Controller (PCECC) for Segment Routing (SR) MPLS
pcep-extension-pce-controller-sr-06 (work in progress), Segment Identifier (SID) Allocation and Distribution.",
March 2020. draft-ietf-pce-pcep-extension-pce-controller-sr-00 (work
in progress), December 2020.
[I-D.li-pce-controlled-id-space] [I-D.li-pce-controlled-id-space]
Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE
Controlled ID Space", draft-li-pce-controlled-id-space-06 Controlled ID Space", draft-li-pce-controlled-id-space-07
(work in progress), July 2020. (work in progress), October 2020.
[I-D.dugeon-pce-stateful-interdomain] [I-D.ietf-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-ietf-
dugeon-pce-stateful-interdomain-04 (work in progress), pce-stateful-interdomain-00 (work in progress), January
July 2020. 2021.
[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.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-14 (work in
progress), March 2020.
[I-D.ietf-pce-segment-routing-ipv6] [I-D.ietf-pce-segment-routing-ipv6]
Li, C., Negi, M., Koldychev, M., Kaladharan, P., and Y. Li, C., Negi, M., Sivabalan, S., Koldychev, M.,
Zhu, "PCEP Extensions for Segment Routing leveraging the Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment
IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-06 Routing leveraging the IPv6 data plane", draft-ietf-pce-
(work in progress), July 2020. segment-routing-ipv6-08 (work in progress), November 2020.
[I-D.ietf-teas-pce-native-ip] [I-D.ietf-teas-pce-native-ip]
Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE in Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "Path
Native IP Network", draft-ietf-teas-pce-native-ip-11 (work Computation Element (PCE) based Traffic Engineering (TE)
in progress), August 2020. in Native IP Networks", draft-ietf-teas-pce-native-ip-16
(work in progress), January 2021.
[RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,
"Scenarios and Simulation Results of PCE in a Native IP
Network", RFC 8735, DOI 10.17487/RFC8735, February 2020,
<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, "Tree 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-07 (work in progress), March 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-07 (work in Extensions for BIER-TE", draft-chen-pce-bier-07 (work in
progress), May 2020. progress), May 2020.
skipping to change at page 33, line 24 skipping to change at page 34, line 24
Authors' Addresses Authors' Addresses
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
Huawei Technologies
Moskovskiy Prospekt 97A
St.Petersburg 196084
Russia
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 Quintin Zhao
Etheric Networks Etheric Networks
skipping to change at page 34, line 4 skipping to change at page 34, line 39
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Quintin Zhao Quintin Zhao
Etheric Networks Etheric Networks
1009 S CLAREMONT ST 1009 S CLAREMONT ST
SAN MATEO, CA 94402 SAN MATEO, CA 94402
USA USA
Email: qzhao@ethericnetworks.com 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
Boris Khasanov
Yandex LLC
Ulitsa Lva Tolstogo 16
Moscow
Russia
Email: bhassanov@yahoo.com
Luyuan Fang Luyuan Fang
Expedia, Inc. Expedia, Inc.
USA USA
Email: luyuanf@gmail.com Email: luyuanf@gmail.com
Chao Zhou Chao Zhou
HPE HPE
 End of changes. 32 change blocks. 
78 lines changed or deleted 82 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/