draft-ietf-teas-pcecc-use-cases-07.txt   draft-ietf-teas-pcecc-use-cases-08.txt 
TEAS Working Group Z. Li TEAS Working Group Z. Li
Internet-Draft D. Dhody Internet-Draft D. Dhody
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: September 9, 2021 Q. Zhao Expires: 28 April 2022 Q. Zhao
Etheric Networks Etheric Networks
K. Ke K. Ke
Tencent Holdings Ltd. Tencent Holdings Ltd.
B. Khasanov B. Khasanov
Yandex LLC 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"
March 8, 2021 25 October 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-07 draft-ietf-teas-pcecc-use-cases-08
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 7 skipping to change at page 2, line 11
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 catalog the use cases for PCECC. There
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 34 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 September 9, 2021. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4 3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4
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.2.4. SR Policy . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . . 18 LSPs . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5. Use Cases of PCECC for LSP in the Network Migration . . . 20 3.5. Use Cases of PCECC for LSP in the Network Migration . . . 20
3.6. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . 22 3.6. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . 22
3.7. Using PCECC for Traffic Classification Information . . . 23 3.7. Using PCECC for Traffic Classification Information . . . 23
3.8. Use Cases of PCECC for SRv6 . . . . . . . . . . . . . . . 23 3.8. Use Cases of PCECC for SRv6 . . . . . . . . . . . . . . . 23
3.9. Use Cases of PCECC for SFC . . . . . . . . . . . . . . . 25 3.9. Use Cases of PCECC for SFC . . . . . . . . . . . . . . . 25
3.10. Use Cases of PCECC for Native IP . . . . . . . . . . . . 25 3.10. Use Cases of PCECC for Native IP . . . . . . . . . . . . 26
3.11. Use Cases of PCECC for Local Protection (RSVP-TE) . . . . 26 3.11. Use Cases of PCECC for Local Protection (RSVP-TE) . . . . 26
3.12. Use Cases of PCECC for BIER . . . . . . . . . . . . . . . 26 3.12. Use Cases of PCECC for BIER . . . . . . . . . . . . . . . 26
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . 27 7.1. Normative References . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . 27 7.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Using reliable P2MP TE based multicast delivery for Appendix A. Using reliable P2MP TE based multicast delivery for
distributed computations (MapReduce-Hadoop) . . . . 31 distributed computations (MapReduce-Hadoop) . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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 [RFC9050] introduces the procedures and extensions for PCEP to
procedures and extensions for PCEP to support the PCECC architecture 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 catalog the use cases for PCECC. There This is a living document to catalog the use cases for PCECC. There
is currently no intention to publish this work as an RFC. [Update: is currently no intention to publish this work as an RFC. [Update:
Chairs are evaluating if the document should be published instead.] 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
to Intermediate System (IS-IS). Intermediate System (IS-IS).
PCC: Path Computation Client: any client application requesting a PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
PCE: Path Computation Element. An entity (component, application, PCE: Path Computation Element. An entity (component, application,
or network node) that is capable of computing a network path or or network node) that is capable of computing a network path or route
route based on a network graph and applying computational based on a network graph and applying computational constraints.
constraints.
PCECC: PCE as a central controller. Extension of PCE to support SDN PCECC: PCE as a central controller. Extension of PCE to support SDN
functions as per [RFC8283]. functions as per [RFC8283].
TE: Traffic Engineering. TE: Traffic Engineering.
3. Application Scenarios 3. Application Scenarios
In the following sections, several use cases are described, In the following sections, several use cases are described,
showcasing scenarios that benefit from the deployment of PCECC. showcasing scenarios that benefit from the deployment of PCECC.
3.1. Use Cases of PCECC for Label Management 3.1. Use Cases of PCECC for Label Management
As per [RFC8283], in some cases, the PCE-based controller can take As per [RFC8283], in some cases, the PCE-based controller can take
responsibility for managing some part of the MPLS label space for responsibility for managing some part of the MPLS label space for
each of the routers that it controls, and it may taker wider each of the routers that it controls, and it may taker wider
responsibility for partitioning the label space for each router and responsibility for partitioning the label space for each router and
allocating different parts for different uses, communicating the allocating different parts for different uses, communicating the
ranges to the router using PCEP. ranges to the router using PCEP.
[I-D.ietf-pce-pcep-extension-for-pce-controller] describe a mode [RFC9050] describe a mode where LSPs are provisioned as explicit
where LSPs are provisioned as explicit label instructions at each hop label instructions at each hop on the end-to-end path. Each router
on the end-to-end path. Each router along the path must be told what along the path must be told what label forwarding instructions to
label forwarding instructions to program and what resources to program and what resources to reserve. The controller uses PCEP to
reserve. The controller uses PCEP to communicate with each router communicate with each router along the path of the end-to-end LSP.
along the path of the end-to-end LSP. For this to work, the PCE- For this to work, the PCE- based controller will take responsibility
based controller will take responsibility for managing some part of for managing some part of the MPLS label space for each of the
the MPLS label space for each of the routers that it controls. An routers that it controls. An extension to PCEP could be done to
extension to PCEP could be done to allow a PCC to inform the PCE of 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.ietf-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
skipping to change at page 5, line 46 skipping to change at page 6, line 4
| / \ PCEP | | PCEP / \ | | / \ PCEP | | PCEP / \ |
| V V | | V V | | V V | | V V |
| +--------+ +--------+ | | +--------+ +--------+ | | +--------+ +--------+ | | +--------+ +--------+ |
| |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| | | |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| |
| | | ...... | | | | | | ...... | | | | | | ...... | | | | | | ...... | | |
| | PCECC | | PCECC | | | | PCECC | |PCECC | | | | PCECC | | PCECC | | | | PCECC | |PCECC | |
| |Enabled | | Enabled| | |Enabled | |Enabled | | | |Enabled | | Enabled| | |Enabled | |Enabled | |
| +--------+ +--------+ | | +--------+ +--------+ | | +--------+ +--------+ | | +--------+ +--------+ |
| | | | | | | |
+------------------------------+ +------------------------------+ +------------------------------+ +------------------------------+
Figure 1: PCECC for Label Management
Figure 1: PCECC for Label Management * PCC would advertise the PCECC capability to the PCE (central
controller-PCECC) [RFC9050].
o PCC would advertise the PCECC capability to the PCE (central
controller-PCECC)
[I-D.ietf-pce-pcep-extension-for-pce-controller].
o The PCECC could also learn the label range set aside by the PCC * The PCECC could also learn the label range set aside by the PCC
([I-D.li-pce-controlled-id-space]). ([I-D.li-pce-controlled-id-space]).
o Optionally, the PCECC could determine the shared MPLS global label * Optionally, the PCECC could determine the shared MPLS global label
range for the network. range for the network.
o In the case that the shared global label range need to be - In the case that the shared global label range need to be
negotiated across multiple domains, the central controllers of negotiated across multiple domains, the central controllers of
these domains would also need to negotiate a common global these domains would also need to negotiate a common global
label range across domains. label range across domains.
o The PCECC would need to set the shared global label range to - The PCECC would need to set the shared global label range to
all PCC nodes in the network. all PCC nodes in the network.
3.2. Using PCECC for SR 3.2. Using PCECC for SR
Segment Routing (SR) leverages the source routing paradigm. Using Segment Routing (SR) leverages the source routing paradigm. Using
SR, a source node steers a packet through a path without relying on SR, a source node steers a packet through a path without relying on
hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path is hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path is
specified as an ordered list of instructions called "segments". Each specified as an ordered list of instructions called "segments". Each
segment is an instruction to route the packet to a specific place in segment is an instruction to route the packet to a specific place in
the network, or to perform a specific service on the packet. A the network, or to perform a specific service on the packet. A
skipping to change at page 9, line 19 skipping to change at page 9, line 19
Example 3: Example 3:
R1 may send a packet P3 to R8 via R4 by pushing an SR header with R1 may send a packet P3 to R8 via R4 by pushing an SR header with
segment list {1004, 1008}. The path could be : R1-R2-R4-R3-R8 segment list {1004, 1008}. The path could be : R1-R2-R4-R3-R8
The local protection examples for SR TE path are explained below: The local protection examples for SR TE path are explained below:
Example 4: local link protection: Example 4: local link protection:
o R1 may send a packet P4 to R8 by pushing an SR header with segment * R1 may send a packet P4 to R8 by pushing an SR header with segment
list {1002, 9001, 1008}. The path should be: R1-R2-link1-R3-R8. list {1002, 9001, 1008}. The path should be: R1-R2-link1-R3-R8.
o When node R2 receives the packet from R1 which has the header of * When node R2 receives the packet from R1 which has the header of
link1-R3-R8, and also find out there is a link failure of link1, link1-R3-R8, and also find out there is a link failure of link1,
then the R2 can enforce the traffic over the bypass to send out then the R2 can enforce the traffic over the bypass to send out
the packet with header of R3-R8 through link2. the packet with header of R3-R8 through link2.
Example 5: local node protection: Example 5: local node protection:
o R1 may send a packet P5 to R8 by pushing an SR header with segment * R1 may send a packet P5 to R8 by pushing an SR header with segment
list {1004, 1008}. The path could be : R1-R2-R4-R3-R8. list {1004, 1008}. The path could be : R1-R2-R4-R3-R8.
o When node R2 receives the packet from R1 which has the header of * When node R2 receives the packet from R1 which has the header of
{1004, 1008}, and also finds out there is a node failure for {1004, 1008}, and also finds out there is a node failure for
node4, then it can enforce the traffic over the bypass and send node4, then it can enforce the traffic over the bypass and send
out the packet with header of {1005, 1008} to node5 instead of out the packet with header of {1005, 1008} to node5 instead of
node4. node4.
3.2.4. SR Policy
[TODO: BORIS - will be added in next version to be published after
the blockade is lifted :) ]
3.3. Use Cases of PCECC for TE LSP 3.3. Use Cases of PCECC for TE LSP
In the Section 3.2 the case of SR path via PCECC is discussed. In the Section 3.2 the case of SR path via PCECC is discussed.
Although those cases give the simplicity and scalability, but there Although those cases give the simplicity and scalability, but there
are existing functionalities for the traffic engineering path such as are existing functionalities for the traffic engineering path such as
the bandwidth guarantee, monitoring where SR based solution are the bandwidth guarantee, monitoring where SR based solution are
complex. Also there are cases where the depth of the label stack is complex. Also there are cases where the depth of the label stack is
an issue for existing deployment and certain vendors. an issue for existing deployment and certain vendors.
So to address these issues, PCECC architecture also support the TE So to address these issues, PCECC architecture also support the TE
skipping to change at page 10, line 39 skipping to change at page 10, line 46
+-----------+ +-----------+ +-----------+ +-----------+
192.0.2.3/32 | R3 | |R6 |192.0.2.6/32 192.0.2.3/32 | R3 | |R6 |192.0.2.6/32
+-----------+ +-----------+ +-----------+ +-----------+
| | | |
|link8 | |link8 |
| |link9 | |link9
+-----------+ +-----------+
| R8 | 192.0.2.8/32 | R8 | 192.0.2.8/32
+-----------+ +-----------+
Figure 2: PCECC TE LSP Setup Example Figure 2: PCECC TE LSP Setup Example
o Based on path computation request / delegation or PCE initiation, * Based on path computation request / delegation or PCE initiation,
the PCECC receives the PCECC request with constraints and the PCECC receives the PCECC request with constraints and
optimization criteria. optimization criteria.
o PCECC would calculate the optimal path according to given * PCECC would calculate the optimal path according to given
constrains (e.g. bandwidth). constrains (e.g. bandwidth).
o PCECC would provision each node along the path and assign incoming * PCECC would provision each node along the path and assign incoming
and outgoing labels from R1 to R8 with the path: {R1, link1, and outgoing labels from R1 to R8 with the path: {R1, link1,
1001}, {1001, R2, link3, 2003], {2003, R4, link10, 4010}, {4010, 1001}, {1001, R2, link3, 2003], {2003, R4, link10, 4010}, {4010,
R3, link8, 3008}, {3008, R8}. R3, link8, 3008}, {3008, R8}.
o For the end to end protection, PCECC program each node along the * For the end to end protection, PCECC program each node along the
path from R1 to R8 with the secondary path: {R1, link2, 1002}, path from R1 to R8 with the secondary path: {R1, link2, 1002},
{1002, R2, link4, 2004], {2004, R5, link7, 5007}, {5007, R3, {1002, R2, link4, 2004], {2004, R5, link7, 5007}, {5007, R3,
link9, 3009}, {3009, R8}. link9, 3009}, {3009, R8}.
o It is also possible to have a bypass path for the local protection * It is also possible to have a bypass path for the local protection
setup by the PCECC. For example, the primary path as above, then setup by the PCECC. For example, the primary path as above, then
to protect the node R4 locally, PCECC can program the bypass path to protect the node R4 locally, PCECC can program the bypass path
like this: {R2, link5, 2005}, {2005, R3}. By doing this, the node like this: {R2, link5, 2005}, {2005, R3}. By doing this, the node
R4 is locally protected at R2. R4 is locally protected at R2.
3.3.1. PCECC Load Balancing (LB) Use Case 3.3.1. PCECC Load Balancing (LB) Use Case
Very often many service providers use TE tunnels for solving issues Very often many service providers use TE tunnels for solving issues
with non-deterministic paths in their networks. One example of such with non-deterministic paths in their networks. One example of such
applications is usage of TEs in the mobile backhaul (MBH). Consider applications is usage of TEs in the mobile backhaul (MBH). Consider
skipping to change at page 12, line 14 skipping to change at page 12, line 18
each AGG router to egress AGG routers. There are also many L2 access each AGG router to egress AGG routers. There are also many L2 access
rings connected to AGG routers. rings connected to AGG routers.
Service deployment made by means of either L2VPNs (VPLS) or L3VPNs. Service deployment made by means of either L2VPNs (VPLS) or L3VPNs.
Those services use MPLS TE as transport towards egress AGG routers. Those services use MPLS TE as transport towards egress AGG routers.
TE tunnels could be also used as transport towards service routers in TE tunnels could be also used as transport towards service routers in
case of seamless MPLS based architecture in the future. case of seamless MPLS based architecture in the future.
There is a need to solve the following tasks: There is a need to solve the following tasks:
o Perform automatic load-balance amongst TE tunnels according to * Perform automatic load-balance amongst TE tunnels according to
current traffic load. current traffic load.
o TE bandwidth (BW) management: Provide guaranteed BW for specific * TE bandwidth (BW) management: Provide guaranteed BW for specific
service: HSI, IPTV, etc., provide time-based BW reservation (BoD) service: HSI, IPTV, etc., provide time-based BW reservation (BoD)
for other services. for other services.
o Simplify development of TE tunnels by automation without any * Simplify development of TE tunnels by automation without any
manual intervention. manual intervention.
o Provide flexibility for Service Router placement (anywhere in the * Provide flexibility for Service Router placement (anywhere in the
network by creation of transport LSPs to them). network by creation of transport LSPs to them).
Since other tasks are already considered by other PCECC use cases, in Since other tasks are already considered by other PCECC use cases, in
this section, the focus is on load balancing (LB) task. LB task this section, the focus is on load balancing (LB) task. LB task
could be solved by means of PCECC in the following way: could be solved by means of PCECC in the following way:
o After application or network service or operator can ask SDN * After application or network service or operator can ask SDN
controller (PCECC) for LSP based LB between AGG X and AGG N/AGG controller (PCECC) for LSP based LB between AGG X and AGG N/AGG
N-1 (egress AGG routers which have connections to core) via North N-1 (egress AGG routers which have connections to core) via North
Bound Interface (NBI). Each of these would have associated Bound Interface (NBI). Each of these would have associated
constrains (i.e. Path Setup Type (PST), bandwidth, inclusion or constrains (i.e. Path Setup Type (PST), bandwidth, inclusion or
exclusion specific links or nodes, number of paths, objective exclusion specific links or nodes, number of paths, objective
function (OF), need for disjoint LSP paths etc.). function (OF), need for disjoint LSP paths etc.).
o PCECC could calculate multiple (Say N) LSPs according to given * PCECC could calculate multiple (Say N) LSPs according to given
constrains, calculation is based on results of Objective Function constrains, calculation is based on results of Objective Function
(OF) [RFC5541], constraints, endpoints, same or different (OF) [RFC5541], constraints, endpoints, same or different
bandwidth (BW) , different links (in case of disjoint paths) and bandwidth (BW) , different links (in case of disjoint paths) and
other constrains. other constrains.
o Depending on given LSP Path setup type (PST), PCECC would use * Depending on given LSP Path setup type (PST), PCECC would use
download instructions to the PCC. At this stage it is assumed the download instructions to the PCC. At this stage it is assumed the
PCECC is aware of the label space it controls and in case of SR PCECC is aware of the label space it controls and in case of SR
the SID allocation and distribution is already done. the SID allocation and distribution is already done.
o PCECC would send PCInitiate PCEP message [RFC8281] towards ingress * PCECC would send PCInitiate PCEP message [RFC8281] towards ingress
AGG X router(PCC) for each of N LSPs and receives PCRpt PCEP AGG X router(PCC) for each of N LSPs and receives PCRpt PCEP
message [RFC8231] back from PCCs. If the PST is PCECC-SR, the message [RFC8231] back from PCCs. If the PST is PCECC-SR, the
PCECC would include the SID stack as per [RFC8664]. If the PST is PCECC would include the SID stack as per [RFC8664]. If the PST is
PCECC (basic), then the PCECC would assigns labels along the PCECC (basic), then the PCECC would assigns labels along the
calculated path; and set up the path by sending central controller calculated path; and set up the path by sending central controller
instructions in PCEP message to each node along the path of the instructions in PCEP message to each node along the path of the
LSP as per [I-D.ietf-pce-pcep-extension-for-pce-controller] and LSP as per [RFC9050] and then send PCUpd message to the ingress
then send PCUpd message to the ingress AGG X router with AGG X router with information about new LSP and AGG X(PCC) would
information about new LSP and AGG X(PCC) would respond with PCRpt respond with PCRpt with LSP status.
with LSP status.
o AGG X as ingress router now have N LSPs towards AGG N and AGG N-1 * AGG X as ingress router now have N LSPs towards AGG N and AGG N-1
which are available for installing to router's forwarding and LB which are available for installing to router's forwarding and LB
of traffic between them. Traffic distribution between those LSPs of traffic between them. Traffic distribution between those LSPs
depends on particular realization of hash-function on that router. depends on particular realization of hash-function on that router.
o Since PCECC is aware of TEDB (TE state) and LSP-DB, it can manage * Since PCECC is aware of TEDB (TE state) and LSP-DB, it can manage
and prevent possible over-subscriptions and limit number of and prevent possible over-subscriptions and limit number of
available LB states. Via PCECC mechanism the control can take available LB states. Via PCECC mechanism the control can take
quick actions into the network by directly provisioning the quick actions into the network by directly provisioning the
central control instructions. central control instructions.
3.3.2. PCECC and Inter-AS TE 3.3.2. PCECC and Inter-AS TE
There are various signaling options for establishing Inter-AS TE LSP: There are various signaling options for establishing Inter-AS TE LSP:
contiguous TE LSP [RFC5151], stitched TE LSP [RFC5150], nested TE LSP contiguous TE LSP [RFC5151], stitched TE LSP [RFC5150], nested TE LSP
[RFC4206]. [RFC4206].
skipping to change at page 15, line 44 skipping to change at page 15, line 44
As per the Figure 4, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and As per the Figure 4, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and
it is the primary Inter-AS LSP. R1-R3 LSP2 that go via ASBR5 and it is the primary Inter-AS LSP. R1-R3 LSP2 that go via ASBR5 and
ASBR6 is the backup one. In addition there could also be a bypass ASBR6 is the backup one. In addition there could also be a bypass
LSP setup to protect against ASBR or inter-AS link failure. LSP setup to protect against ASBR or inter-AS link failure.
After the addition of PCECC functionality to PCE (SDN controller), After the addition of PCECC functionality to PCE (SDN controller),
PCECC based Inter-AS TE model SHOULD follow as PCECC usecase for TE PCECC based Inter-AS TE model SHOULD follow as PCECC usecase for TE
LSP as requirements of [RFC5376] with the following details: LSP as requirements of [RFC5376] with the following details:
o Since PCECC needs to know the topology of both domains AS1 and * Since PCECC needs to know the topology of both domains AS1 and
AS2, PCECC could use BGP-LS peering with routers (or RRs) in both AS2, PCECC could use BGP-LS peering with routers (or RRs) in both
domains. domains.
o PCECC needs to PCEP connectivity towards all routers in both * PCECC needs to PCEP connectivity towards all routers in both
domains (see also section 4 in [RFC5376]) in a similar manner as a domains (see also section 4 in [RFC5376]) in a similar manner as a
SDN controller. SDN controller.
o After operator's application or service orchestrator will create * After operator's application or service orchestrator will create
request for tunnel creation of specific service, PCECC should request for tunnel creation of specific service, PCECC should
receive that request via NBI (NBI type is implementation receive that request via NBI (NBI type is implementation
dependent, could be NETCONF/Yang, REST etc.). Then PCECC would dependent, could be NETCONF/Yang, REST etc.). Then PCECC would
calculate the optimal path based on Objective Function (OF) and calculate the optimal path based on Objective Function (OF) and
given constraints (i.e. path setup type, bandwidth etc.), given constraints (i.e. path setup type, bandwidth etc.),
including those from [RFC5376]: priority, AS sequence, preferred including those from [RFC5376]: priority, AS sequence, preferred
ASBR, disjoint paths, protection. On this step we would have two ASBR, disjoint paths, protection. On this step we would have two
paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3 paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3
o Depending on given LSP PST (PCECC or PCECC-SR), PCECC would use * Depending on given LSP PST (PCECC or PCECC-SR), PCECC would use
central control download instructions to the PCC. At this stage central control download instructions to the PCC. At this stage
it is assumed the PCECC is aware of the label space it controls it is assumed the PCECC is aware of the label space it controls
and in case of SR the SID allocation and distribution is already and in case of SR the SID allocation and distribution is already
done. done.
o PCECC would send PCInitiate PCEP message [RFC8281] towards ingress * PCECC would send PCInitiate PCEP message [RFC8281] towards ingress
router R1 (PCC) in AS1 and receives PCRpt PCEP message [RFC8231] router R1 (PCC) in AS1 and receives PCRpt PCEP message [RFC8231]
back from PCC. If the PST is PCECC-SR, the PCECC would include back from PCC. If the PST is PCECC-SR, the PCECC would include
the SID stack as per [RFC8664]. It may also include binding SID the SID stack as per [RFC8664]. It may also include binding SID
based on AS boundary. The backup SID stack could also be based on AS boundary. The backup SID stack could also be
installed at ingress but more importantly each node along the SR installed at ingress but more importantly each node along the SR
path could also do local protection just based on the top segment. path could also do local protection just based on the top segment.
If the PST is PCECC (basic), then the PCECC would assigns labels If the PST is PCECC (basic), then the PCECC would assigns labels
along the calculated paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3); along the calculated paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3);
and set up the path by sending central controller instructions in and set up the path by sending central controller instructions in
PCEP message to each node along the path of the LSPs as per PCEP message to each node along the path of the LSPs as per
[I-D.ietf-pce-pcep-extension-for-pce-controller] and then send [RFC9050] and then send PCUpd message to the ingress R1 router
PCUpd message to the ingress R1 router with information about new with information about new LSPs and R1 would respond with PCRpt
LSPs and R1 would respond with PCRpt with LSP(s) status. with LSP(s) status.
o After that step R1 now have primary and backup TEs (LSP1 and LSP2) * After that step R1 now have primary and backup TEs (LSP1 and LSP2)
towards R3. It is up to router implementation how to make towards R3. It is up to router implementation how to make
switchover to backup LSP2 if LSP1 fails. switchover to backup LSP2 if LSP1 fails.
3.4. Use Cases of PCECC for Multicast LSPs 3.4. Use Cases of PCECC for Multicast LSPs
The current multicast LSPs are setup either using the RSVP-TE P2MP or The current multicast LSPs are setup either using the RSVP-TE P2MP or
mLDP protocols. The setup of these LSPs may require manual mLDP protocols. The setup of these LSPs may require manual
configurations and complex signaling when the protection is configurations and complex signaling when the protection is
considered. By using the PCECC solution, the multicast LSP can be considered. By using the PCECC solution, the multicast LSP can be
computed and setup through centralized controller which has the full computed and setup through centralized controller which has the full
skipping to change at page 17, line 37 skipping to change at page 17, line 37
| R3 | | R6 | Leaf Node | R3 | | R6 | Leaf Node
+-----------+ +-----------+ +-----------+ +-----------+
9005| 9005|
+-----------+ +-----------+
| R8 | Leaf Node | R8 | Leaf Node
+-----------+ +-----------+
The P2MP examples are explained here, where R1 is root and R8 and R6 The P2MP examples are explained here, where R1 is root and R8 and R6
are the leaves. are the leaves.
o Based on the P2MP path computation request / delegation or PCE * Based on the P2MP path computation request / delegation or PCE
initiation, the PCECC receives the PCECC request with constraints initiation, the PCECC receives the PCECC request with constraints
and optimization criteria. and optimization criteria.
o PCECC would calculate the optimal P2MP path according to given * PCECC would calculate the optimal P2MP path according to given
constrains (i.e.bandwidth). constrains (i.e.bandwidth).
o PCECC would provision each node along the path and assign incoming * PCECC would provision each node along the path and assign incoming
and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000}, and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000},
{6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003,
R3, 9005}, {9004, R6}, {9005, R8}. The main difference is in the R3, 9005}, {9004, R6}, {9005, R8}. The main difference is in the
branch node instruction at R2 where two copies of packet are sent branch node instruction at R2 where two copies of packet are sent
towards R4 and R5 with 9001 and 9002 labels respectively. towards R4 and R5 with 9001 and 9002 labels respectively.
The packet forwarding involves - The packet forwarding involves -
Step1: R1 may send a packet P1 to R2 simply by pushing an label of Step1: R1 may send a packet P1 to R2 simply by pushing an label of
6000 to the packet. 6000 to the packet.
skipping to change at page 21, line 40 skipping to change at page 21, line 40
| +--------+ +--------+ +--------+ +--------+ +--------+ | | +--------+ +--------+ +--------+ +--------+ +--------+ |
| | | |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
Example: PCECC Initiated LSP Setup In the Network Migration Example: PCECC Initiated LSP Setup In the Network Migration
In this example, there are five nodes for the TE LSP from head end In this example, there are five nodes for the TE LSP from head end
(Node1) to the tail end (Node5). Where the Node4 and Node5 are (Node1) to the tail end (Node5). Where the Node4 and Node5 are
centrally controlled and other nodes are legacy nodes. centrally controlled and other nodes are legacy nodes.
o Node1 sends a path request message for the setup of LSP * Node1 sends a path request message for the setup of LSP
destinating to Node5. destinating to Node5.
o PCECC sends to node1 a reply message for LSP setup with the path: * PCECC sends to node1 a reply message for LSP setup with the path:
(Node1, if1),(Node2, if2), (Node3, if3), (Node4, if4), Node5. (Node1, if1),(Node2, if2), (Node3, if3), (Node4, if4), Node5.
o Node1, Node2, Node3 will setup the LSP to Node5 using the local * Node1, Node2, Node3 will setup the LSP to Node5 using the local
labels as usual. Node 3 with help of PCECC could proxy the labels as usual. Node 3 with help of PCECC could proxy the
signaling. signaling.
o Then the PCECC will program the out-segment of Node3, the in- * Then the PCECC will program the out-segment of Node3, the in-
segment/ out-segment of Node4, and the in-segment for Node5. segment/ out-segment of Node4, and the in-segment for Node5.
3.6. Use Cases of PCECC for L3VPN and PWE3 3.6. Use Cases of PCECC for L3VPN and PWE3
As described in [RFC8283], various network services may be offered As described in [RFC8283], various network services may be offered
over a network. These include protection services (including Virtual over a network. These include protection services (including Virtual
Private Network (VPN) services (such as Layer 3 VPNs [RFC4364] or Private Network (VPN) services (such as Layer 3 VPNs [RFC4364] or
Ethernet VPNs [RFC7432]); or Pseudowires [RFC3985]. Delivering Ethernet VPNs [RFC7432]); or Pseudowires [RFC3985]. Delivering
services over a network in an optimal way requires coordination in services over a network in an optimal way requires coordination in
the way that network resources are allocated to support the services. the way that network resources are allocated to support the services.
skipping to change at page 23, line 30 skipping to change at page 23, line 30
Therefore, selecting what traffic classification should be performed Therefore, selecting what traffic classification should be performed
by a router is an important part of the work done by a PCECC. by a router is an important part of the work done by a PCECC.
Instructions can be passed from the controller to the routers using Instructions can be passed from the controller to the routers using
PCEP. These instructions tell the routers how to map traffic to PCEP. These instructions tell the routers how to map traffic to
paths or connections. Refer [I-D.ietf-pce-pcep-flowspec]. paths or connections. Refer [I-D.ietf-pce-pcep-flowspec].
Along with traffic classification, there are few more question that Along with traffic classification, there are few more question that
needs to be considered once the path is setup - needs to be considered once the path is setup -
o how to use it * how to use it
o Whether it is a virtual link * Whether it is a virtual link
o Whether to advertise it in the IGP as a virtual link * Whether to advertise it in the IGP as a virtual link
o What bits of this information to signal to the tail end * 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) [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
skipping to change at page 24, line 44 skipping to change at page 24, line 44
+-----------+ +-----------+ +-----------+ +-----------+
| |
+-----------+ +-----------+
| R8 | 2001:db8::8 | R8 | 2001:db8::8
+-----------+ +-----------+
In this case, PCECC could assign the SRv6 SID (in form of a IPv6 In this case, PCECC could assign the SRv6 SID (in form of a IPv6
address) to be used for node and adjacency. Later SRv6 path in form address) to be used for node and adjacency. Later SRv6 path in form
of list of SRv6 SID could be used at the ingress. Some examples - of list of SRv6 SID could be used at the ingress. Some examples -
o SRv6 SID-List={2001:db8::8} - The best path towards R8 * SRv6 SID-List={2001:db8::8} - The best path towards R8
o SRv6 SID-List={2001:db8::5, 2001:db8::8} - The path towards R8 via * SRv6 SID-List={2001:db8::5, 2001:db8::8} - The path towards R8 via
R5 R5
3.9. Use Cases of PCECC for SFC 3.9. Use Cases of PCECC for SFC
Service Function Chaining (SFC) is described in [RFC7665]. It is the Service Function Chaining (SFC) is described in [RFC7665]. It is the
process of directing traffic in a network such that it passes through process of directing traffic in a network such that it passes through
specific hardware devices or virtual machines (known as service specific hardware devices or virtual machines (known as service
function nodes) that can perform particular desired functions on the function nodes) that can perform particular desired functions on the
traffic. The set of functions to be performed and the order in which traffic. The set of functions to be performed and the order in which
they are to be performed is known as a service function chain. The they are to be performed is known as a service function chain. The
skipping to change at page 25, line 29 skipping to change at page 25, line 29
configured to understand the packet markings, and the edge nodes must configured to understand the packet markings, and the edge nodes must
be told how to mark packets entering the network. Additionally, it be told how to mark packets entering the network. Additionally, it
may be necessary to establish tunnels between service function nodes may be necessary to establish tunnels between service function nodes
to carry the traffic. Planning an SFC network requires load to carry the traffic. Planning an SFC network requires load
balancing between service function nodes and traffic engineering balancing between service function nodes and traffic engineering
across the network that connects them. As per [RFC8283], these are across the network that connects them. As per [RFC8283], these are
operations that can be performed by a PCE-based controller, and that operations that can be performed by a PCE-based controller, and that
controller can use PCEP to program the network and install the controller can use PCEP to program the network and install the
service function chains and any required tunnels. service function chains and any required tunnels.
A possible mechanism would be to add support for SFC based central
control instruction that would be able to instruct the following to
the each SFF along the SFP -
* Service Path Identifier (SPI): Uniquely identifies a SFP.
* Service Index (SI): Provides location within the SFP.
* SFC Proxy handling
PCECC can play the role for setting the traffic classification rules PCECC can play the role for setting the traffic classification rules
at the classifier as well as downloading the forwarding instructions at the classifier to impose the NSH as well as downloading the
to the SFFs so that they could process the NSH and forward forwarding instructions to each SFFs along the way so that they could
accordingly. process the NSH and forward accordingly. Instructions to the service
classifier handle the context header, meta data etc.
[Editor's Note - more details to be added] It is also possible to support SFC with SR in conjunction with or
without NSH such as [I-D.ietf-spring-nsh-sr] and
[I-D.ietf-spring-sr-service-programming]. PCECC technique can also
be used for service function related segments and SR service
policies.
3.10. Use Cases of PCECC for Native IP 3.10. Use Cases of PCECC for Native IP
[RFC8735] describes the scenarios, and suggestions for the "Centrally [RFC8735] describes the scenarios, and suggestions for the "Centrally
Control Dynamic Routing (CCDR)" architecture, which integrates the Control Dynamic Routing (CCDR)" architecture, which integrates the
merit of traditional distributed protocols (IGP/BGP), and the power merit of traditional distributed protocols (IGP/BGP), and the power
of centrally control technologies (PCE/SDN) to provide one feasible of centrally control technologies (PCE/SDN) to provide one feasible
traffic engineering solution in various complex scenarios for the traffic engineering solution in various complex scenarios for the
service provider. [I-D.ietf-teas-pce-native-ip] defines the service provider. [I-D.ietf-teas-pce-native-ip] defines the
framework for CCDR traffic engineering within Native IP network, framework for CCDR traffic engineering within Native IP network,
skipping to change at page 26, line 41 skipping to change at page 27, line 9
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 mechanism 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. The PCECC could be used to program the BIER
router with various parameters used in the BIER encapsulation such as
[Editor's Note - more details to be added] BIER subdomain-ID, BFR-ID, BIER Encapsulation etc etc for both node
and adjacency.
4. IANA Considerations 4. IANA Considerations
This document does not require any action from IANA. This document does not require any action from IANA.
5. Security Considerations 5. Security Considerations
TBD. TODO: DHRUV - we plan to add this in the next revision after the
draft submission blockade is lifted.
6. Acknowledgments 6. Acknowledgments
We would like to thank Adrain Farrel, Aijun Wang, Robert Tao, We would like to thank Adrain Farrel, Aijun Wang, Robert Tao,
Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey
Elperin and Evgeniy Brodskiy for their useful comments and Elperin and Evgeniy Brodskiy for their useful comments and
suggestions. suggestions.
7. References 7. References
skipping to change at page 30, line 11 skipping to change at page 30, line 21
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, [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>.
[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-12 (work in Specification", Work in Progress, Internet-Draft, draft-
progress), October 2020. ietf-pce-pcep-flowspec-13, 14 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-pce-pcep-
[I-D.ietf-pce-pcep-extension-for-pce-controller] flowspec-13.txt>.
Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP
Procedures and Protocol Extensions for Using PCE as a
Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-10 (work in progress),
January 2021.
[I-D.ietf-pce-pcep-extension-pce-controller-sr] [I-D.ietf-pce-pcep-extension-pce-controller-sr]
Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou,
Procedures and Protocol Extensions for Using PCE as a "PCEP Procedures and Protocol Extensions for Using PCE as
Central Controller (PCECC) for Segment Routing (SR) MPLS a Central Controller (PCECC) for Segment Routing (SR) MPLS
Segment Identifier (SID) Allocation and Distribution.", Segment Identifier (SID) Allocation and Distribution.",
draft-ietf-pce-pcep-extension-pce-controller-sr-00 (work Work in Progress, Internet-Draft, draft-ietf-pce-pcep-
in progress), December 2020. extension-pce-controller-sr-03, 30 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-pce-pcep-
extension-pce-controller-sr-03.txt>.
[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-07 Controlled ID Space", Work in Progress, Internet-Draft,
(work in progress), October 2020. draft-li-pce-controlled-id-space-09, 22 August 2021,
<https://www.ietf.org/archive/id/draft-li-pce-controlled-
id-space-09.txt>.
[I-D.ietf-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-ietf- Extension for Stateful Inter-Domain Tunnels", Work in
pce-stateful-interdomain-00 (work in progress), January Progress, Internet-Draft, draft-ietf-pce-stateful-
2021. interdomain-02, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-pce-stateful-
interdomain-02.txt>.
[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", Work in Progress,
stateful-local-protection-01 (work in progress), June Internet-Draft, draft-cbrt-pce-stateful-local-protection-
2018. 01, 29 June 2018, <https://www.ietf.org/archive/id/draft-
cbrt-pce-stateful-local-protection-01.txt>.
[I-D.ietf-pce-segment-routing-ipv6] [I-D.ietf-pce-segment-routing-ipv6]
Li, C., Negi, M., Sivabalan, S., Koldychev, M., Li, C., Negi, M., Sivabalan, S., Koldychev, M.,
Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment
Routing leveraging the IPv6 data plane", draft-ietf-pce- Routing leveraging the IPv6 data plane", Work in Progress,
segment-routing-ipv6-08 (work in progress), November 2020. Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, 27
May 2021, <https://www.ietf.org/internet-drafts/draft-
ietf-pce-segment-routing-ipv6-09.txt>.
[I-D.ietf-teas-pce-native-ip] [I-D.ietf-teas-pce-native-ip]
Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "Path Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based
Computation Element (PCE) based Traffic Engineering (TE) Traffic Engineering (TE) in Native IP Networks", Work in
in Native IP Networks", draft-ietf-teas-pce-native-ip-16 Progress, Internet-Draft, draft-ietf-teas-pce-native-ip-
(work in progress), January 2021. 17, 1 February 2021, <https://www.ietf.org/archive/id/
draft-ietf-teas-pce-native-ip-17.txt>.
[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)", Work in
bier-te-arch-07 (work in progress), March 2020. Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9
July 2021, <https://www.ietf.org/archive/id/draft-ietf-
bier-te-arch-10.txt>.
[I-D.chen-pce-bier] [I-D.chen-pce-bier]
Chen, R., Zhang, Z., Dhanaraj, S., and F. Qin, "PCEP Chen, R., Zhang, Z., Chen, H., Dhanaraj, S., Qin, F., and
Extensions for BIER-TE", draft-chen-pce-bier-07 (work in A. Wang, "PCEP Extensions for BIER-TE", Work in Progress,
progress), May 2020. Internet-Draft, draft-chen-pce-bier-09, 12 July 2021,
<https://www.ietf.org/archive/id/draft-chen-pce-bier-
09.txt>.
[I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
S. Salsano, "Service Programming with Segment Routing",
Work in Progress, Internet-Draft, draft-ietf-spring-sr-
service-programming-05, 10 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-spring-sr-
service-programming-05.txt>.
[I-D.ietf-spring-nsh-sr]
Guichard, J. N. and J. Tantsura, "Integration of Network
Service Header (NSH) and Segment Routing for Service
Function Chaining (SFC)", Work in Progress, Internet-
Draft, draft-ietf-spring-nsh-sr-09, 26 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-spring-nsh-sr-
09.txt>.
[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,
<https://www.slideshare.net/DmitryAfanasiev1/yandex- <https://www.slideshare.net/DmitryAfanasiev1/yandex-
nag201320131031>. nag201320131031>.
7.3. URIs
[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 (https://hadoop.apache.org/) 1.0
on big data in the Hadoop Distributed File System (HDFS), where architecture MapReduce operations on big data in the Hadoop
NameNode has the knowledge about resources of the cluster and where Distributed File System (HDFS), where NameNode has the knowledge
actual data (chunks) for particular task are located (which about resources of the cluster and where actual data (chunks) for
DataNode). Each chunk of data (64MB or more) should have 3 saved particular task are located (which DataNode). Each chunk of data
copies in different DataNodes based on their proximity. (64MB or more) should have 3 saved copies in different 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 34, line 19 skipping to change at page 35, line 19
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
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
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
1009 S CLAREMONT ST 1009 S CLAREMONT ST
SAN MATEO, CA 94402 SAN MATEO, CA 94402
USA United States of America
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 Boris Khasanov
Yandex LLC Yandex LLC
Ulitsa Lva Tolstogo 16 Ulitsa Lva Tolstogo 16
Moscow Moscow
Russia
Email: bhassanov@yahoo.com Email: bhassanov@yahoo.com
Luyuan Fang Luyuan Fang
Expedia, Inc. Expedia, Inc.
USA United States of America
Email: luyuanf@gmail.com Email: luyuanf@gmail.com
Chao Zhou Chao Zhou
HPE HPE
Email: chaozhou_us@yahoo.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 220043, Minsk
Belarus Belarus
Email: arachitskiy@mts.by Email: arachitskiy@mts.by
Anton Gulida Anton Gulida
LLC "Lifetech" LLC "Lifetech"
Krasnoarmeyskaya str., 24 Krasnoarmeyskaya str., 24
Minsk 220030 220030, Minsk
Belarus Belarus
Email: anton.gulida@life.com.by Email: anton.gulida@life.com.by
 End of changes. 92 change blocks. 
157 lines changed or deleted 200 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/