draft-ietf-teas-pcecc-use-cases-02.txt   draft-ietf-teas-pcecc-use-cases-03.txt 
TEAS Working Group Q. Zhao TEAS Working Group Q. Zhao
Internet-Draft Z. Li Internet-Draft Z. Li
Intended status: Informational B. Khasanov Intended status: Informational B. Khasanov
Expires: April 21, 2019 D. Dhody Expires: September 12, 2019 D. Dhody
Huawei Technologies Huawei Technologies
K. Ke K. Ke
Tencent Holdings Ltd. Tencent Holdings Ltd.
L. Fang L. Fang
Expedia, Inc. Expedia, Inc.
C. Zhou C. Zhou
Cisco Systems Cisco Systems
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"
October 18, 2018 March 11, 2019
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-02 draft-ietf-teas-pcecc-use-cases-03
Abstract Abstract
The Path Computation Element (PCE) is a core component of Software- The Path Computation Element (PCE) is a core component of a Software-
Defined Networking (SDN) systems. 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).
SDN has a broader applicability than signaled MPLS traffic-engineered SDN has a broader applicability than signaled MPLS traffic-engineered
(TE) networks, and the PCE may be used to determine paths in a range (TE) networks, and the PCE may be used to determine paths in a range
of use cases including static LSPs, segment routing, Service Function of use cases including static LSPs, segment routing (SR), Service
Chaining (SFC), and most forms of a routed or switched network. It Function Chaining (SFC), and most forms of a routed or switched
is, therefore, reasonable to consider PCEP as a control protocol for network. It is, therefore, reasonable to consider PCEP as a control
use in these environments to allow the PCE to be fully enabled as a protocol for use in these environments to allow the PCE to be fully
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.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 April 21, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 18 skipping to change at page 3, line 18
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 . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . . . 17
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 . . . 19
3.6. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . 21 3.6. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . 21
3.7. Using PCECC for Traffic Classification Information . . . 22 3.7. Using PCECC for Traffic Classification Information . . . 22
3.8. Use Cases of PCECC for SRv6 . . . . . . . . . . . . . . . 22 3.8. Use Cases of PCECC for SRv6 . . . . . . . . . . . . . . . 22
3.9. Use Cases of PCECC for SFC . . . . . . . . . . . . . . . 23 3.9. Use Cases of PCECC for SFC . . . . . . . . . . . . . . . 24
3.10. Use Cases of PCECC for Native IP . . . . . . . . . . . . 23 3.10. Use Cases of PCECC for Native IP . . . . . . . . . . . . 24
3.11. Use Cases of PCECC for Local Protection (RSVP-TE) . . . . 24 3.11. Use Cases of PCECC for Local Protection (RSVP-TE) . . . . 25
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . 25 7.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Using reliable P2MP TE based multicast delivery for Appendix A. Using reliable P2MP TE based multicast delivery for
distributed computations (MapReduce-Hadoop) . . . . 29 distributed computations (MapReduce-Hadoop) . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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.zhao-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.
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
skipping to change at page 4, line 32 skipping to change at page 4, line 32
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.zhao-pce-pcep-extension-for-pce-controller] describe a mode [I-D.ietf-pce-pcep-extension-for-pce-controller] describe a mode
where LSPs are provisioned as explicit label instructions at each hop where LSPs are provisioned as explicit label instructions at each hop
on the end-to-end path. Each router along the path must be told what on the end-to-end path. Each router along the path must be told what
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.
skipping to change at page 5, line 37 skipping to change at page 5, line 37
| | 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
o PCC would advertise the PCECC capability to the PCE (central o PCC would advertise the PCECC capability to the PCE (central
controller-PCECC) controller-PCECC)
[I-D.zhao-pce-pcep-extension-for-pce-controller]. [I-D.ietf-pce-pcep-extension-for-pce-controller].
o The PCECC could also learn the label range set aside by the PCC o 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 o 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 o 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
skipping to change at page 8, line 30 skipping to change at page 8, line 30
SR-TE paths may not follow an IGP SPT. Such paths may be chosen by a SR-TE paths may not follow an IGP SPT. Such paths may be chosen by a
PCECC and provisioned on the ingress node of the SR-TE path. The SR PCECC and provisioned on the ingress node of the SR-TE path. The SR
header consists of a list of SIDs (or MPLS labels). The header has header consists of a list of SIDs (or MPLS labels). The header has
all necessary information so that, the packets can be guided from the all necessary information so that, the packets can be guided from the
ingress node to the egress node of the path; hence, there is no need ingress node to the egress node of the path; hence, there is no need
for any signaling protocol. For the case where strict traffic for any signaling protocol. For the case where strict traffic
engineering path is needed, all the adjacency SID are stacked, engineering path is needed, all the adjacency SID are stacked,
otherwise a combination of node-SID or adj-SID can be used for the otherwise a combination of node-SID or adj-SID can be used for the
SR-TE paths. SR-TE paths.
Note that the bandwidth reservations is only guaranteed through the Note that the bandwidth reservations is only guaranteed at controller
enforce of the bandwidth admission control. As for the RSVP-TE LSP and through the enforce of the bandwidth admission control. As for
case, the control plane signaling also does the link bandwidth the RSVP-TE LSP case, the control plane signaling also does the link
reservation in each hop of the path. bandwidth reservation in each hop of the path.
The SR traffic engineering path examples are explained as bellow: The SR traffic engineering path examples are explained as bellow:
Note that the node SID for each node is allocated from the SRGB and Note that the node SID for each node is allocated from the SRGB and
adjacency SID for each link are allocated from the SRLB for each adjacency SID for each link are allocated from the SRLB for each
node. node.
Example 1: Example 1:
R1 may send a packet P1 to R8 simply by pushing an SR header with R1 may send a packet P1 to R8 simply by pushing an SR header with
segment list {1008}. Based on the best path, it could be: segment list {1008}. Based on the best path, it could be:
R1-R2-R3-R8. R1-R2-R3-R8.
Example 2: Example 2:
R1 may send a packet P2 to R8 by pushing an SR header with segment R1 may send a packet P2 to R8 by pushing an SR header with segment
list {1002, 9001, 1008}. The path should be: R1-R2-(1)link-R3-R8. list {1002, 9001, 1008}. The path should be: R1-R2-link1-R3-R8.
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 as 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 o 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-(1)link-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 o When node R2 receives the packet from R1 which has the header of
R2-(1)link-R3-R8, and also find out there is a link failure of link1-R3-R8, and also find out there is a link failure of link1,
link1, then the R2 can enforce the traffic over the bypass to send then the R2 can enforce the traffic over the bypass to send out
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 o R1 may send a packet P5 to R8 by pushing an SR header with segment
list {1004, 1008}. The path should 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 o When node R2 receives the packet from R1 which has the header of
{1004, 1008}, and also find out there is a node failure for node4, {1004, 1008}, and also finds out there is a node failure for
then it can enforce the traffic over the bypass and send out the node4, then it can enforce the traffic over the bypass and send
packet with header of {1005, 1008} to node5 instead of node4. out the packet with header of {1005, 1008} to node5 instead of
node4.
3.3. Use Cases of PCECC for TE LSP 3.3. Use Cases of PCECC for TE LSP
In the previous sections, we have discussed the cases where the SR In the Section 3.2 the case of SR path via PCECC is discussed.
path is setup through the PCECC. Although those cases give the Although those cases give the simplicity and scalability, but there
simplicity and scalability, but there are existing functionalities are existing functionalities for the traffic engineering path such as
for the traffic engineering path such as the bandwidth guarantee, the bandwidth guarantee, monitoring where SR based solution are
monitoring where SR based solution are complex. Also there are cases complex. Also there are cases where the depth of the label stack is
where the depth of the label stack is an issue for existing an issue for existing deployment and certain vendors.
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
LSP functionalities. To achieve this, the existing PCEP can be used LSP functionalities. To achieve this, the existing PCEP can be used
to communicate between the PCECC and nodes along the path. This is to communicate between the PCECC and nodes along the path. This is
similar to static LSPs, where LSPs can be provisioned as explicit similar to static LSPs, where LSPs can be provisioned as explicit
label instructions at each hop on the end-to-end path. Each router label instructions at each hop on the end-to-end path. Each router
along the path must be told what label- forwarding instructions to along the path must be told what label- forwarding instructions to
program and what resources to reserve. The PCE-based controller program and what resources to reserve. The PCE-based controller
keeps a view of the network and determines the paths of the end-to- keeps a view of the network and determines the paths of the end-to-
end LSPs, and the controller uses PCEP to communicate with each end LSPs, and the controller uses PCEP to communicate with each
skipping to change at page 10, line 42 skipping to change at page 10, line 42
| 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, o 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 o PCECC would calculate the optimal path according to given
constrains (i.e.bandwidth). constrains (e.g. bandwidth).
o PCECC would provision each node along the path and assign incoming o 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 o 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 o 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). Let's applications is usage of TEs in the mobile backhaul (MBH). Consider
consider the following typical topology. the following topology -
TE1 --------------> TE1 -------------->
+---------+ +--------+ +--------+ +--------+ +------+ +---+ +---------+ +--------+ +--------+ +--------+ +------+ +---+
| Access |----| Access |----| AGG 1 |----| AGG N-1|----|Core 1|--|SR1| | Access |----| Access |----| AGG 1 |----| AGG N-1|----|Core 1|--|SR1|
| SubNode1| | Node 1 | +--------+ +--------+ +------+ +---+ | SubNode1| | Node 1 | +--------+ +--------+ +------+ +---+
+---------+ +--------+ | | | ^ | +---------+ +--------+ | | | ^ |
| Access | Access | AGG Ring 1 | | | | Access | Access | AGG Ring 1 | | |
| SubRing 1 | Ring 1 | | | | | | SubRing 1 | Ring 1 | | | | |
+---------+ +--------+ +--------+ | | | +---------+ +--------+ +--------+ | | |
| Access | | Access | | AGG 2 | | | | | Access | | Access | | AGG 2 | | | |
| SubNode2| | Node 2 | +--------+ | | | | SubNode2| | Node 2 | +--------+ | | |
+---------+ +--------+ | | | | | +---------+ +--------+ | | | | |
| | | | | | | | | | | | | |
| | | +----TE2----|-+ | | | | +----TE2----|-+ |
+---------+ +--------+ +--------+ +--------+ +------+ +---+ +---------+ +--------+ +--------+ +--------+ +------+ +---+
| Access | | Access |----| AGG 3 |----| AGG N |----|Core N|--|SRn| | Access | | Access |----| AGG 3 |----| AGG N |----|Core N|--|SRn|
| SubNodeN|----| Node N | +--------+ +--------+ +------+ +---+ | SubNodeN|----| Node N | +--------+ +--------+ +------+ +---+
+---------+ +--------+ +---------+ +--------+
This MBH architecture uses L2 access rings and subrings. L3 starts This MBH architecture uses L2 access rings and sub-rings. L3 starts
at aggregation. For the sake of simplicity here we have only one at the aggregation layer. For the sake of simplicity, the figure
access subring, access ring and aggregation ring (AGG1...AGGN), shows only one access sub-ring, access ring and aggregation ring
connected by Nx10GE interfaces. Aggregation domain runs its own IGP. (AGG1...AGGN), connected by Nx10GE interfaces. Aggregation domain
There are two Egress routers (AGG N-1,AGG N) that are connected to runs its own IGP. There are two Egress routers (AGG N-1,AGG N) that
the Core domain via L2 interfaces. Core also have connections to are connected to the Core domain via L2 interfaces. Core also have
service routers, RSVP TEs are used for MPLS transport inside the connections to service routers, RSVP-TEs are used for MPLS transport
ring. There could be at least 2 tunnels (one way) from each AGG inside the ring. There could be at least 2 tunnels (one way) from
router to egress AGG routers. There are also many L2 access rings each AGG router to egress AGG routers. There are also many L2 access
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 LB amongst TE tunnels according to current o Perform automatic load-balance amongst TE tunnels according to
traffic load. current traffic load.
o TE bandwidth (BW) management: Provide guaranteed BW for specific o 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 o Simplify development of TE tunnels by automation without any
manual intervention. manual intervention.
o Provide flexibility for Service Router placement (anywhere in the o 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 considered in other PCECC use cases above, Since other tasks are already considered by other PCECC use cases, in
hereafter we will focus only 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 o 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. LSP type: traditional CR-LSP or SR-TE LSP, constrains (i.e. Path Setup Type (PST), bandwidth, inclusion or
bandwidth, inclusion or exclusion specific links or nodes, number exclusion specific links or nodes, number of paths, objective
of paths, shortest path or minimum cost tree, need for disjoint function (OF), need for disjoint LSP paths etc.).
LSP paths etc.).
o PCECC could calculate multiple (Say N) LSPs according to given o 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 o 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 o 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 PCECC would include the SID stack as per
[I-D.ietf-pce-segment-routing]. If the PST is PCECC (basic), then [I-D.ietf-pce-segment-routing]. If the PST is PCECC (basic), then
the PCECC would assigns labels along the calculated path; and set the PCECC would assigns labels along the calculated path; and set
up the path by sending central controller instructions in PCEP up the path by sending central controller instructions in PCEP
message to each node along the path of the LSP as per message to each node along the path of the LSP as per
[I-D.zhao-pce-pcep-extension-for-pce-controller] and then send [I-D.ietf-pce-pcep-extension-for-pce-controller] and then send
PCUpd message to the ingress AGG X router with information about PCUpd message to the ingress AGG X router with information about
new LSP and AGG X(PCC) would respond with PCRpt with LSP status. new LSP and AGG X(PCC) would respond with PCRpt with LSP status.
o AGG X as ingress router now have N LSPs towards AGG N and AGG N-1 o 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 knows as LSDB as TEDB (TE state) he can manage and o Since PCECC is aware of TEDB (TE state) and LSP-DB, it can manage
prevent possible oversubscriptions and limit number of available and prevent possible over-subscriptions and limit number of
LB states. Via PCECC mechanism the control can take quick actions available LB states. Via PCECC mechanism the control can take
into the network by directly provisioning the central control quick actions into the network by directly provisioning the
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].
Requirements for PCE-based Inter-AS setup [RFC5376] describe the Requirements for PCE-based Inter-AS setup [RFC5376] describe the
approach and PCEP functionality that are needed for establishing approach and PCEP functionality that are needed for establishing
Inter-AS TE LSPs. Inter-AS TE LSPs.
skipping to change at page 13, line 47 skipping to change at page 13, line 46
:: :: :: :: :: ::
R1----ASBR1====ASBR3---R3---ASBR5 R1----ASBR1====ASBR3---R3---ASBR5
| AS1 | | PCC | | AS1 | | PCC |
| | | AS2 | | | | AS2 |
R2----ASBR2====ASBR4---R4---ASBR6 R2----ASBR2====ASBR4---R4---ASBR6
:: :: :: ::
:: :: :: ::
Intra-AS Intra-AS Intra-AS Intra-AS
PCE3 PCE4 PCE3 PCE4
Shorten form of Inter- and Intra-AS PCE Reference Model [RFC5376] Figure 3: Shorten form of Inter- and Intra-AS PCE Reference Model
[RFC5376]
The PCECC belonging to different domain can co-operate to setup The PCECC belonging to different domain can co-operate to setup
inter-AS TE LSP. The stateful H-PCE [I-D.ietf-pce-stateful-hpce] inter-AS TE LSP. The stateful H-PCE [I-D.ietf-pce-stateful-hpce]
mechanism could be used to first establish a per-domain PCECC LSP. mechanism could also be used to first establish a per-domain PCECC
LSP. These could be stitched together to form inter-AS TE LSP as
These could be stitched together to form inter-AS TE LSP as described described in [I-D.dugeon-pce-stateful-interdomain].
in [I-D.dugeon-pce-stateful-interdomain].
Hereatfter we will focus on a simplified Inter-AS case when both AS1 For the sake of simplicity, here after the focus is on a simplified
and AS2 belong to the same service provider administration. In that Inter-AS case when both AS1 and AS2 belong to the same service
case Inter and Intra-AS PCEs could be combined in one single PCE if provider administration. In that case Inter and Intra-AS PCEs could
such combined PCE performance is enough for handling all Path be combined in one single PCE if such combined PCE performance is
Computation Requests. Even more in that particular case we enough for handling all path computation request and setup. There is
potentially could use 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, we require interfaces (PCEP and BGP-LS) to performance are enough. The PCE would require interfaces (PCEP and
both domains. PCECC redundancy mechanisms are described in BGP-LS) to both domains. PCECC redundancy mechanisms are described
[RFC8283]. Thus routers in AS1 and AS2 (PCCs) can send Path in [RFC8283]. Thus routers in AS1 and AS2 (PCCs) can send PCEP
Computation messages towards same PCECC. messages towards same PCECC.
+----BGP-LS------+ +------BGP-LS-----+ +----BGP-LS------+ +------BGP-LS-----+
| | | | | | | |
+-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+ +-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+
+-:------|----::-:-+ +--::-:-|-------:---+ +-:------|----::-:-+ +--::-:-|-------:---+
| : | :: : | | :: : | : | | : | :: : | | :: : | : |
| : RR1 :: : | | :: : RR2 : | | : RR1 :: : | | :: : RR2 : |
| v v: : | LSP1 | :: v v | | v v: : | LSP1 | :: v v |
| R1---------ASBR1=======================ASBR3--------R3 | | R1---------ASBR1=======================ASBR3--------R3 |
| | v : | | :v | | | | v : | | :v | |
| +----------ASBR2=======================ASBR4---------+ | | +----------ASBR2=======================ASBR4---------+ |
| | Region 1 : | | : Region 1 | | | | Region 1 : | | : Region 1 | |
|----------------:-| |--:-------------|--| |----------------:-| |--:-------------|--|
| | v | LSP2 | v | | | | v | LSP2 | v | |
| +----------ASBR5=======================ASBR6---------+ | | +----------ASBR5=======================ASBR6---------+ |
| Region 2 | | Region 2 | | Region 2 | | Region 2 |
+------------------+ <--------------> +-------------------+ +------------------+ <--------------> +-------------------+
MPLS Domain 1 Inter-AS MPLS Domain 2 MPLS Domain 1 Inter-AS MPLS Domain 2
<=======AS1=======> <========AS2=======> <=======AS1=======> <========AS2=======>
Particular case of Inter-AS PCE Figure 4: Particular case of Inter-AS PCE
In a case of PCECC Inter-AS TE scenario where service provider In a case of PCECC Inter-AS TE scenario where service provider
controls both domains (AS1 and AS2), each of them have own IGP and controls both domains (AS1 and AS2), each of them have own IGP and
MPLS transport. There is a need is to setup Inter-AS LSPs for MPLS transport. There is a need is to setup Inter-AS LSPs for
transporting different services on top of them (Voice, L3VPN etc.). transporting different services on top of them (Voice, L3VPN etc.).
Inter-AS links with different capacity exist in several regions. The Inter-AS links with different capacity exist in several regions. The
task is not only to provision those Inter-AS LSPs with given task is not only to provision those Inter-AS LSPs with given
constrains but also calculate the path and pre-setup the backup constrains but also calculate the path and pre-setup the backup
Inter-AS LSPs that will be used if primary LSP fails. Inter-AS LSPs that will be used if primary LSP fails.
For the figure above it would be that LSP1 from R1 to R3 may go via As per the Figure 4, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and
ASBR1 and ASBR3, and it is the primary Inter-AS LSP. R1-R3 LSP2 that it is the primary Inter-AS LSP. R1-R3 LSP2 that go via ASBR5 and
go via ASBR5 and ASBR6 is the backup one. In addition there could be ASBR6 is the backup one. In addition there could also be a bypass
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 o 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 o 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 o 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, MAY 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 constrains (i.e. path setup type, bandwidth etc.), including given constraints (i.e. path setup type, bandwidth etc.),
those from [RFC5376]: priority, AS sequence, preferred ASBR, including those from [RFC5376]: priority, AS sequence, preferred
disjoint paths, protection. On this step we would have two paths: ASBR, disjoint paths, protection. On this step we would have two
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 o Depending on given LSP PST (PCECC or PCECC-SR), PCECC would use
download instructions to the PCC. At this stage it is assumed the central control download instructions to the PCC. At this stage
PCECC is aware of the label space it controls and in case of SR it is assumed the PCECC is aware of the label space it controls
the SID allocation and distribution is already done. and in case of SR the SID allocation and distribution is already
done.
o PCECC would send PCInitiate PCEP message [RFC8281] towards ingress o 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 [I-D.ietf-pce-segment-routing]. It may also the SID stack as per [I-D.ietf-pce-segment-routing]. It may also
include binding SID based on AS boundary. The backup SID stack include binding SID based on AS boundary. The backup SID stack
could also be installed at ingress but more importantly each node could also be installed at ingress but more importantly each node
along the SR path could also do local protection just based on the along the SR path could also do local protection just based on the
top segement. If the PST is PCECC (basic), then the PCECC would top segment. If the PST is PCECC (basic), then the PCECC would
assigns labels along the calculated paths (R1-ASBR1-ASBR3-R3, assigns labels along the calculated paths (R1-ASBR1-ASBR3-R3,
R1-ASBR5-ASBR6-R3); and set up the path by sending central R1-ASBR5-ASBR6-R3); and set up the path by sending central
controller instructions in PCEP message to each node along the controller instructions in PCEP message to each node along the
path of the LSPs as per path of the LSPs as per
[I-D.zhao-pce-pcep-extension-for-pce-controller] and then send [I-D.ietf-pce-pcep-extension-for-pce-controller] and then send
PCUpd message to the ingress R1 router with information about new PCUpd message to the ingress R1 router with information about new
LSPs and R1 would respond with PCRpt with LSP(s) status. LSPs and R1 would respond with PCRpt with LSP(s) status.
o 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
of traffic between them. Traffic distribution between those LSPs
depends on particular realization of hash-function on that router.
o After that step R1 now have primary and backup TEs (LSP1 and LSP2) o 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
skipping to change at page 22, line 27 skipping to change at page 22, line 27
classification is closely linked to the computational elements of classification is closely linked to the computational elements of
planning for the network functions just listed because it determines planning for the network functions just listed because it determines
how traffic load is balanced and distributed through the network. how traffic load is balanced and distributed through the network.
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 - Along with traffic classification, there are few more question that
needs to be considered once the path is setup -
o how to use it o how to use it
o Whether it is a virtual link o Whether it is a virtual link
o Whether to advertise it in the IGP o Whether to advertise it in the IGP as a virtual link
o What bits of this information to signal to the tail end o What bits of this information to signal to the tail end
These are out of scope of this document.
3.8. Use Cases of PCECC for SRv6 3.8. Use Cases of PCECC for SRv6
As per [RFC8402], with Segment Routing (SR), a node steers a packet As per [RFC8402], with Segment Routing (SR), a node steers a packet
through an ordered list of instructions, called segments. Segment through an ordered list of instructions, called segments. Segment
Routing can be applied to the IPv6 architecture with the Segment Routing can be applied to the IPv6 architecture with the Segment
Routing Header (SRH) [I-D.ietf-6man-segment-routing-header]. A Routing Header (SRH) [I-D.ietf-6man-segment-routing-header]. A
segment is encoded as an IPv6 address. An ordered list of segments segment is encoded as an IPv6 address. An ordered list of segments
is encoded as an ordered list of IPv6 addresses in the routing is encoded as an ordered list of IPv6 addresses in the routing
header. The active segment is indicated by the Destination Address header. The active segment is indicated by the Destination Address
of the packet. Upon completion of a segment, a pointer in the new of the packet. Upon completion of a segment, a pointer in the new
skipping to change at page 23, line 4 skipping to change at page 23, line 9
segment is encoded as an IPv6 address. An ordered list of segments segment is encoded as an IPv6 address. An ordered list of segments
is encoded as an ordered list of IPv6 addresses in the routing is encoded as an ordered list of IPv6 addresses in the routing
header. The active segment is indicated by the Destination Address header. The active segment is indicated by the Destination Address
of the packet. Upon completion of a segment, a pointer in the new of the packet. Upon completion of a segment, a pointer in the new
routing header is incremented and indicates the next segment. routing header is incremented and indicates the next segment.
As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a
128-bit value. "SRv6 SID" or simply "SID" are often used as a 128-bit value. "SRv6 SID" or simply "SID" are often used as a
shorter reference for "SRv6 Segment". Further details are in An shorter reference for "SRv6 Segment". Further details are in An
illustration is provided in illustration is provided in
[I-D.filsfils-spring-srv6-network-programming] where SRv6 SID is [I-D.filsfils-spring-srv6-network-programming] where SRv6 SID is
represented as LOC:FUNCT. represented as LOC:FUNCT.
[I-D.negi-pce-segment-routing-ipv6] extends [I-D.ietf-pce-segment-routing-ipv6] extends
[I-D.ietf-pce-segment-routing] to support SR for IPv6 data plane. [I-D.ietf-pce-segment-routing] to support SR for IPv6 data plane.
Further a PCECC could be extended to support SRv6 SID allocation and Further a PCECC could be extended to support SRv6 SID allocation and
distribution. distribution.
[Editor's Note - more details to be added] 2001:db8::1
+----------+
| R1 |
+----------+
|
+----------+
| R2 | 2001:db8::2
+----------+
* | * *
* | * *
*link1| * *
2001:db8::4 * | *link2 * 2001:db8::5
+-----------+ | * +-----------+
| R4 | | * | R5 |
+-----------+ | * +-----------+
* | * * +
* | * * +
* | * * +
+-----------+ +-----------+
2001:db8::3 | R3 | |R6 |2001:db8::6
+-----------+ +-----------+
|
+-----------+
| R8 | 2001:db8::8
+-----------+
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
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
o SRv6 SID-List={2001:db8::5, 2001:db8::8} - The path towards R8 via
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
chain is enhanced with the locations at which the service functions chain is enhanced with the locations at which the service functions
skipping to change at page 27, line 8 skipping to change at page 27, line 41
<https://www.rfc-editor.org/info/rfc8355>. <https://www.rfc-editor.org/info/rfc8355>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
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>.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-14 (work in progress), draft-ietf-pce-segment-routing-16 (work in progress),
October 2018. March 2019.
[I-D.ietf-pce-stateful-hpce] [I-D.ietf-pce-stateful-hpce]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D.,
and O. Dios, "Hierarchical Stateful Path Computation and O. Dios, "Hierarchical Stateful Path Computation
Element (PCE).", draft-ietf-pce-stateful-hpce-05 (work in Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in
progress), June 2018. progress), October 2018.
[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-02 (work in Specification", draft-ietf-pce-pcep-flowspec-03 (work in
progress), October 2018. progress), February 2019.
[I-D.zhao-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures
and C. Zhou, "PCEP Procedures and Protocol Extensions for and Protocol Extensions for Using PCE as a Central
Using PCE as a Central Controller (PCECC) of LSPs", draft- Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
zhao-pce-pcep-extension-for-pce-controller-08 (work in extension-for-pce-controller-01 (work in progress),
progress), June 2018. February 2019.
[I-D.zhao-pce-pcep-extension-pce-controller-sr] [I-D.zhao-pce-pcep-extension-pce-controller-sr]
Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures
and C. Zhou, "PCEP Procedures and Protocol Extensions for and Protocol Extensions for Using PCE as a Central
Using PCE as a Central Controller (PCECC) of SR-LSPs", Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep-
draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work extension-pce-controller-sr-04 (work in progress),
in progress), June 2018. February 2019.
[I-D.li-pce-controlled-id-space] [I-D.li-pce-controlled-id-space]
Li, C., Chen, M., Dong, J., Li, Z., and D. Dhody, "PCE Li, C., Chen, M., Dong, J., Li, Z., Wang, A., and C. Zhou,
Controlled ID Space", draft-li-pce-controlled-id-space-00 "PCE Controlled ID Space", draft-li-pce-controlled-id-
(work in progress), June 2018. space-02 (work in progress), March 2019.
[I-D.dugeon-pce-stateful-interdomain] [I-D.dugeon-pce-stateful-interdomain]
Dugeon, O., Meuric, J., Lee, Y., Dhody, D., and D. Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
Ceccarelli, "PCEP Extension for Stateful Inter-Domain Extension for Stateful Inter-Domain Tunnels", draft-
Tunnels", draft-dugeon-pce-stateful-interdomain-01 (work dugeon-pce-stateful-interdomain-02 (work in progress),
in progress), July 2018. March 2019.
[I-D.cbrt-pce-stateful-local-protection] [I-D.cbrt-pce-stateful-local-protection]
Barth, C. and R. Torvi, "PCEP Extensions for RSVP-TE Barth, C. and R. Torvi, "PCEP Extensions for RSVP-TE
Local-Protection with PCE-Stateful", draft-cbrt-pce- Local-Protection with PCE-Stateful", draft-cbrt-pce-
stateful-local-protection-01 (work in progress), June stateful-local-protection-01 (work in progress), June
2018. 2018.
[I-D.filsfils-spring-srv6-network-programming] [I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network- Network Programming", draft-filsfils-spring-srv6-network-
programming-05 (work in progress), July 2018. programming-07 (work in progress), February 2019.
[I-D.negi-pce-segment-routing-ipv6] [I-D.ietf-pce-segment-routing-ipv6]
Negi, M., Kaladharan, P., Dhody, D., and S. Sivabalan, Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP
"PCEP Extensions for Segment Routing leveraging the IPv6 Extensions for Segment Routing leveraging the IPv6 data
data plane", draft-negi-pce-segment-routing-ipv6-02 (work plane", draft-ietf-pce-segment-routing-ipv6-00 (work in
in progress), June 2018. progress), March 2019.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-14 (work in (SRH)", draft-ietf-6man-segment-routing-header-16 (work in
progress), June 2018. progress), February 2019.
[I-D.ietf-teas-pce-native-ip] [I-D.ietf-teas-pce-native-ip]
Wang, A., Zhao, Q., Khasanov, B., Chen, H., Mi, P., Wang, A., Zhao, Q., Khasanov, B., Chen, H., and R. Mallya,
Mallya, R., and S. Peng, "PCE in Native IP Network", "PCE in Native IP Network", draft-ietf-teas-pce-native-
draft-ietf-teas-pce-native-ip-01 (work in progress), June ip-02 (work in progress), October 2018.
2018.
[I-D.ietf-teas-native-ip-scenarios] [I-D.ietf-teas-native-ip-scenarios]
Wang, A., Huang, X., Qou, C., Li, Z., Huang, L., and P. Wang, A., Huang, X., Qou, C., Li, Z., and P. Mi,
Mi, "CCDR Scenario, Simulation and Suggestion", draft- "Scenario, Simulation and Suggestion of PCE in Native IP
ietf-teas-native-ip-scenarios-01 (work in progress), June Network", draft-ietf-teas-native-ip-scenarios-02 (work in
2018. progress), October 2018.
[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,
 End of changes. 59 change blocks. 
155 lines changed or deleted 184 lines changed or added

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