draft-ietf-teas-pcecc-use-cases-04.txt   draft-ietf-teas-pcecc-use-cases-05.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: January 5, 2020 D. Dhody Expires: September 9, 2020 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"
July 4, 2019 March 8, 2020
The Use Cases for Path Computation Element (PCE) as a Central Controller The Use Cases for Path Computation Element (PCE) as a Central Controller
(PCECC). (PCECC).
draft-ietf-teas-pcecc-use-cases-04 draft-ietf-teas-pcecc-use-cases-05
Abstract Abstract
The Path Computation Element (PCE) is a core component of a Software- The Path Computation Element (PCE) is a core component of a Software-
Defined Networking (SDN) system. It can compute optimal paths for Defined Networking (SDN) system. It can compute optimal paths for
traffic across a network and can also update the paths to reflect traffic across a network and can also update the paths to reflect
changes in the network or traffic demands. PCE was developed to changes in the network or traffic demands. PCE was developed to
derive paths for MPLS Label Switched Paths (LSPs), which are supplied derive paths for MPLS Label Switched Paths (LSPs), which are supplied
to the head end of the LSP using the Path Computation Element to the head end of the LSP using the Path Computation Element
Communication Protocol (PCEP). Communication Protocol (PCEP).
skipping to change at page 2, line 31 skipping to change at page 2, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2020. This Internet-Draft will expire on September 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 5, line 7 skipping to change at page 5, line 7
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.
[I-D.ietf-pce-segment-routing] specifies extensions to PCEP that [RFC8664] specifies extensions to PCEP that allow a stateful PCE to
allow a stateful PCE to compute, update or initiate SR-TE paths. compute, update or initiate SR-TE paths.
[I-D.zhao-pce-pcep-extension-pce-controller-sr] describes the [I-D.zhao-pce-pcep-extension-pce-controller-sr] describes the
mechanism for PCECC to allocate and provision the node/prefix/ mechanism for PCECC to allocate and provision the node/prefix/
adjacency label (SID) via PCEP. To make such allocation PCE needs to adjacency label (SID) via PCEP. To make such allocation PCE needs to
be aware of the label space from Segment Routing Global Block (SRGB) be aware of the label space from Segment Routing Global Block (SRGB)
or Segment Routing Local Block (SRLB) [RFC8402] of the node that it or Segment Routing Local Block (SRLB) [RFC8402] of the node that it
controls. A mechanism for a PCC to inform the PCE of such a label controls. A mechanism for a PCC to inform the PCE of such a label
space to control is needed within PCEP. The full SRGB/SRLB of a node space to control is needed within PCEP. The full SRGB/SRLB of a node
could be learned via existing IGP or BGP-LS mechanism too. could be learned via existing IGP or BGP-LS mechanism too.
[I-D.li-pce-controlled-id-space] defines a PCEP extension to support [I-D.li-pce-controlled-id-space] defines a PCEP extension to support
skipping to change at page 6, line 31 skipping to change at page 6, line 31
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
database of segments can be distributed through the network using a database of segments can be distributed through the network using a
routing protocol (such as IS-IS or OSPF) or by any other means. PCEP routing protocol (such as IS-IS or OSPF) or by any other means. PCEP
(and PCECC) could be one such means. (and PCECC) could be one such means.
[I-D.ietf-pce-segment-routing] specify the SR specific PCEP [RFC8664] specify the SR specific PCEP extensions. PCECC may further
extensions. PCECC may further use PCEP protocol for SR SID (Segment use PCEP protocol for SR SID (Segment Identifier) distribution to the
Identifier) distribution to the SR nodes (PCC) with some benefits. SR nodes (PCC) with some benefits. If the PCECC allocates and
If the PCECC allocates and maintains the SID in the network for the maintains the SID in the network for the nodes and adjacencies; and
nodes and adjacencies; and further distributes them to the SR nodes further distributes them to the SR nodes directly via the PCEP
directly via the PCEP session has some advantage over the session has some advantage over the configurations on each SR node
configurations on each SR node and flooding via IGP, especially in a and flooding via IGP, especially in a SDN environment.
SDN environment.
When the PCECC is used for the distribution of the node segment ID When the PCECC is used for the distribution of the node segment ID
and adjacency segment ID, the node segment ID is allocated from the and adjacency segment ID, the node segment ID is allocated from the
SRGB of the node. For the allocation of adjacency segment ID, the SRGB of the node. For the allocation of adjacency segment ID, the
allocation is from the SRLB of the node as described in allocation is from the SRLB of the node as described in
[I-D.zhao-pce-pcep-extension-pce-controller-sr]. [I-D.zhao-pce-pcep-extension-pce-controller-sr].
[RFC8355] identifies various protection and resiliency usecases for [RFC8355] identifies various protection and resiliency usecases for
SR. Path protection lets the ingress node be in charge of the SR. Path protection lets the ingress node be in charge of the
failure recovery (used for SR-TE). Also protection can be performed failure recovery (used for SR-TE). Also protection can be performed
skipping to change at page 12, line 51 skipping to change at page 12, line 51
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 [RFC8664]. If the PST is
[I-D.ietf-pce-segment-routing]. If the PST is PCECC (basic), then PCECC (basic), then the PCECC would assigns labels along the
the PCECC would assigns labels along the calculated path; and set calculated path; and set up the path by sending central controller
up the path by sending central controller instructions in PCEP instructions in PCEP message to each node along the path of the
message to each node along the path of the LSP as per LSP as per [I-D.ietf-pce-pcep-extension-for-pce-controller] and
[I-D.ietf-pce-pcep-extension-for-pce-controller] and then send then send PCUpd message to the ingress AGG X router with
PCUpd message to the ingress AGG X router with information about information about new LSP and AGG X(PCC) would respond with PCRpt
new LSP and AGG X(PCC) would 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 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 is aware of TEDB (TE state) and LSP-DB, it can manage o 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
skipping to change at page 15, line 41 skipping to change at page 15, line 41
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
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 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 [RFC8664]. It may also include binding SID
include binding SID based on AS boundary. The backup SID stack based on AS boundary. The backup SID stack could also be
could also be installed at ingress but more importantly each node installed at ingress but more importantly each node along the SR
along the SR path could also do local protection just based on the path could also do local protection just based on the top segment.
top segment. If the PST is PCECC (basic), then the PCECC would If the PST is PCECC (basic), then the PCECC would assigns labels
assigns labels along the calculated paths (R1-ASBR1-ASBR3-R3, along the calculated paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3);
R1-ASBR5-ASBR6-R3); and set up the path by sending central and set up the path by sending central controller instructions in
controller instructions in PCEP message to each node along the PCEP message to each node along the path of the LSPs as per
path of the LSPs as per
[I-D.ietf-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 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
skipping to change at page 23, line 12 skipping to change at page 23, line 12
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.ietf-pce-segment-routing-ipv6] extends [I-D.ietf-pce-segment-routing-ipv6] extends [RFC8664] to support SR
[I-D.ietf-pce-segment-routing] to support SR for IPv6 data plane. for IPv6 data plane. Further a PCECC could be extended to support
Further a PCECC could be extended to support SRv6 SID allocation and SRv6 SID allocation and distribution.
distribution.
2001:db8::1 2001:db8::1
+----------+ +----------+
| R1 | | R1 |
+----------+ +----------+
| |
+----------+ +----------+
| R2 | 2001:db8::2 | R2 | 2001:db8::2
+----------+ +----------+
* | * * * | * *
skipping to change at page 24, line 38 skipping to change at page 24, line 38
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 as well as downloading the forwarding instructions
to the SFFs so that they could process the NSH and forward to the SFFs so that they could process the NSH and forward
accordingly. accordingly.
[Editor's Note - more details to be added] [Editor's Note - more details to be added]
3.10. Use Cases of PCECC for Native IP 3.10. Use Cases of PCECC for Native IP
[I-D.ietf-teas-native-ip-scenarios] describes the scenarios, and [RFC8735] describes the scenarios, and suggestions for the "Centrally
suggestions for the "Centrally Control Dynamic Routing (CCDR)" Control Dynamic Routing (CCDR)" architecture, which integrates the
architecture, which integrates the merit of traditional distributed merit of traditional distributed protocols (IGP/BGP), and the power
protocols (IGP/BGP), and the power of centrally control technologies of centrally control technologies (PCE/SDN) to provide one feasible
(PCE/SDN) to provide one feasible traffic engineering solution in traffic engineering solution in various complex scenarios for the
various complex scenarios for the service provider. service provider. [I-D.ietf-teas-pce-native-ip] defines the
[I-D.ietf-teas-pce-native-ip] defines the framework for CCDR traffic framework for CCDR traffic engineering within Native IP network,
engineering within Native IP network, using Dual/Multi-BGP session using Dual/Multi-BGP session strategy and CCDR architecture. PCEP
strategy and CCDR architecture. PCEP protocol can be used to protocol can be used to transfer the key parameters between PCE and
transfer the key parameters between PCE and the underlying network the underlying network devices (PCC) using PCECC technique. The
devices (PCC) using PCECC technique. The central control central control instructions from PCECC to identify which prefix
instructions from PCECC to identify which prefix should be advertised should be advertised on which BGP session.
on which BGP session.
3.11. Use Cases of PCECC for Local Protection (RSVP-TE) 3.11. Use Cases of PCECC for Local Protection (RSVP-TE)
[I-D.cbrt-pce-stateful-local-protection] describes the need for the [I-D.cbrt-pce-stateful-local-protection] describes the need for the
PCE to maintain and associate the local protection paths for the PCE to maintain and associate the local protection paths for the
RSVP-TE LSP. Local protection requires the setup of a bypass at the RSVP-TE LSP. Local protection requires the setup of a bypass at the
PLR. This bypass can be PCC-initiated and delegated, or PCE- PLR. This bypass can be PCC-initiated and delegated, or PCE-
initiated. In either case, the PLR MUST maintain a PCEP session to initiated. In either case, the PLR MUST maintain a PCEP session to
the PCE. The Bypass LSPs need to mapped to the primary LSP. This the PCE. The Bypass LSPs need to mapped to the primary LSP. This
could be done locally at the PLR based on a local policy but there is could be done locally at the PLR based on a local policy but there is
skipping to change at page 28, line 28 skipping to change at page 28, line 28
Shakir, "Resiliency Use Cases in Source Packet Routing in Shakir, "Resiliency Use Cases in Source Packet Routing in
Networking (SPRING) Networks", RFC 8355, Networking (SPRING) Networks", RFC 8355,
DOI 10.17487/RFC8355, March 2018, DOI 10.17487/RFC8355, March 2018,
<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] [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication
and J. Hardwick, "PCEP Extensions for Segment Routing", Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
draft-ietf-pce-segment-routing-16 (work in progress), DOI 10.17487/RFC8664, December 2019,
March 2019. <https://www.rfc-editor.org/info/rfc8664>.
[I-D.ietf-pce-stateful-hpce] [I-D.ietf-pce-stateful-hpce]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
"Hierarchical Stateful Path Computation Element (PCE).", "Hierarchical Stateful Path Computation Element (PCE)",
draft-ietf-pce-stateful-hpce-10 (work in progress), June draft-ietf-pce-stateful-hpce-15 (work in progress),
2019. October 2019.
[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-03 (work in Specification", draft-ietf-pce-pcep-flowspec-08 (work in
progress), February 2019. progress), March 2020.
[I-D.ietf-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures
and Protocol Extensions for Using PCE as a Central and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of LSPs", draft-ietf-pce-pcep- Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-01 (work in progress), extension-for-pce-controller-03 (work in progress),
February 2019. November 2019.
[I-D.zhao-pce-pcep-extension-pce-controller-sr] [I-D.zhao-pce-pcep-extension-pce-controller-sr]
Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures
and Protocol Extensions for Using PCE as a Central and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep-
extension-pce-controller-sr-04 (work in progress), extension-pce-controller-sr-05 (work in progress), July
February 2019. 2019.
[I-D.li-pce-controlled-id-space] [I-D.li-pce-controlled-id-space]
Li, C., Chen, M., Dong, J., Li, Z., Wang, A., Cheng, W., Li, C., Chen, M., Dong, J., Li, Z., Wang, A., Cheng, W.,
and C. Zhou, "PCE Controlled ID Space", draft-li-pce- and C. Zhou, "PCE Controlled ID Space", draft-li-pce-
controlled-id-space-03 (work in progress), June 2019. controlled-id-space-04 (work in progress), January 2020.
[I-D.dugeon-pce-stateful-interdomain] [I-D.dugeon-pce-stateful-interdomain]
Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
Extension for Stateful Inter-Domain Tunnels", draft- Extension for Stateful Inter-Domain Tunnels", draft-
dugeon-pce-stateful-interdomain-02 (work in progress), dugeon-pce-stateful-interdomain-03 (work in progress),
March 2019. November 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-07 (work in progress), February 2019. programming-07 (work in progress), February 2019.
[I-D.ietf-pce-segment-routing-ipv6] [I-D.ietf-pce-segment-routing-ipv6]
Negi, M., Li, C., Sivabalan, S., Kaladharan, P., and Y. Negi, M., Li, C., Sivabalan, S., Kaladharan, P., and Y.
Zhu, "PCEP Extensions for Segment Routing leveraging the Zhu, "PCEP Extensions for Segment Routing leveraging the
IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-02 IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-03
(work in progress), April 2019. (work in progress), October 2019.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
Routing Header (SRH)", draft-ietf-6man-segment-routing- (SRH)", draft-ietf-6man-segment-routing-header-26 (work in
header-21 (work in progress), June 2019. progress), October 2019.
[I-D.ietf-teas-pce-native-ip] [I-D.ietf-teas-pce-native-ip]
Wang, A., Zhao, Q., Khasanov, B., Chen, H., and R. Mallya, Wang, A., Zhao, Q., Khasanov, B., and H. Chen, "PCE in
"PCE in Native IP Network", draft-ietf-teas-pce-native- Native IP Network", draft-ietf-teas-pce-native-ip-05 (work
ip-03 (work in progress), April 2019. in progress), January 2020.
[I-D.ietf-teas-native-ip-scenarios] [RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,
Wang, A., Huang, X., Qou, C., Li, Z., and P. Mi, "Scenarios and Simulation Results of PCE in a Native IP
"Scenarios and Simulation Results of PCE in Native IP Network", RFC 8735, DOI 10.17487/RFC8735, February 2020,
Network", draft-ietf-teas-native-ip-scenarios-06 (work in <https://www.rfc-editor.org/info/rfc8735>.
progress), June 2019.
[I-D.ietf-bier-te-arch] [I-D.ietf-bier-te-arch]
Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic Eckert, T., Cauchie, G., and M. Menth, "Path Engineering
Engineering for Bit Index Explicit Replication (BIER-TE)", for Bit Index Explicit Replication (BIER-TE)", draft-ietf-
draft-ietf-bier-te-arch-02 (work in progress), May 2019. bier-te-arch-06 (work in progress), February 2020.
[I-D.chen-pce-bier] [I-D.chen-pce-bier]
Chen, R. and Z. Zhang, "PCEP Extensions for BIER", draft- Chen, R., Zhang, Z., Dhanaraj, S., and F. Qin, "PCEP
chen-pce-bier-05 (work in progress), March 2019. Extensions for BIER-TE", draft-chen-pce-bier-06 (work in
progress), November 2019.
[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/ <https://www.slideshare.net/DmitryAfanasiev1/yandex-
yandex-nag201320131031>. nag201320131031>.
7.3. URIs 7.3. URIs
[1] https://hadoop.apache.org/ [1] https://hadoop.apache.org/
Appendix A. Using reliable P2MP TE based multicast delivery for Appendix A. Using reliable P2MP TE based multicast delivery for
distributed computations (MapReduce-Hadoop) distributed computations (MapReduce-Hadoop)
MapReduce model of distributed computations in computing clusters is MapReduce model of distributed computations in computing clusters is
widely deployed. In Hadoop [1] 1.0 architecture MapReduce operations widely deployed. In Hadoop [1] 1.0 architecture MapReduce operations
 End of changes. 25 change blocks. 
86 lines changed or deleted 82 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/