draft-ietf-teas-pcecc-use-cases-08.txt		draft-ietf-teas-pcecc-use-cases-09.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: 28 April 2022 Q. Zhao		Expires: 8 September 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		7 March 2022
	Expedia, Inc.
	C. Zhou
	HPE
	B. Zhang
	Telus Communications
	A. Rachitskiy
	Mobile TeleSystems JLLC
	A. Gulida
	LLC "Lifetech"
	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-08		draft-ietf-teas-pcecc-use-cases-09
	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).
	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 (SR), Service		of use cases including static LSPs, segment routing (SR), Service
	Function Chaining (SFC), and most forms of a routed or switched		Function Chaining (SFC), and most forms of a routed or switched
	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		A PCE as a Central Controller (PCECC) can simplify the processing of
	and examines its applicability and benefits, as well as its		a distributed control plane by blending it with elements of SDN and
	challenges and limitations, through a number of use cases. PCEP		without necessarily completely replacing it. This document describes
	extensions required for stateful PCE usage are covered in separate		general considerations for PCECC deployment and examines its
	documents.		applicability and benefits, as well as its challenges and
			limitations, through a number of use cases. PCEP extensions required
			for stateful PCE usage are covered in separate 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",
	"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
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 25 ¶
	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 28 April 2022.		This Internet-Draft will expire on 8 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised 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 . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . 8
	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 . . . 9
	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 . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2.4. SR Policy . . . . . . . . . . . . . . . . . . . . . . 9
	3.3. Use Cases of PCECC for TE LSP . . . . . . . . . . . . . . 9		3.2.4. SR Policy . . . . . . . . . . . . . . . . . . . . . . 10
	3.3.1. PCECC Load Balancing (LB) Use Case . . . . . . . . . 11		3.3. Use Cases of PCECC for TE LSP . . . . . . . . . . . . . . 11
	3.3.2. PCECC and Inter-AS TE . . . . . . . . . . . . . . . . 13		3.3.1. PCECC Load Balancing (LB) Use Case . . . . . . . . . 13
	3.4. Use Cases of PCECC for Multicast LSPs . . . . . . . . . . 16		3.3.2. PCECC and Inter-AS TE . . . . . . . . . . . . . . . . 15
	3.4.1. Using PCECC for P2MP/MP2MP LSPs' Setup . . . . . . . 17		3.4. Use Cases of PCECC for Multicast LSPs . . . . . . . . . . 18
			3.4.1. Using PCECC for P2MP/MP2MP LSPs' Setup . . . . . . . 18
	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 . . . . . . . . . . . . . . . . . . . . . . . . 20
	3.5. Use Cases of PCECC for LSP in the Network Migration . . . 20		3.5. Using PCECC for Traffic Classification Information . . . 22
	3.6. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . 22		3.6. Use Cases of PCECC for SRv6 . . . . . . . . . . . . . . . 23
	3.7. Using PCECC for Traffic Classification Information . . . 23		3.7. Use Cases of PCECC for SFC . . . . . . . . . . . . . . . 24
	3.8. Use Cases of PCECC for SRv6 . . . . . . . . . . . . . . . 23		3.8. Use Cases of PCECC for Native IP . . . . . . . . . . . . 25
	3.9. Use Cases of PCECC for SFC . . . . . . . . . . . . . . . 25		3.9. Use Cases of PCECC for BIER . . . . . . . . . . . . . . . 26
	3.10. Use Cases of PCECC for Native IP . . . . . . . . . . . . 26		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	3.11. Use Cases of PCECC for Local Protection (RSVP-TE) . . . . 26		5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	3.12. Use Cases of PCECC for BIER . . . . . . . . . . . . . . . 26
	4. IANA 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 . . . . . . . . . . . . . . . . . 28		7.2. Informative References . . . . . . . . . . . . . . . . . 28
	Appendix A. Using reliable P2MP TE based multicast delivery for		Appendix A. Other Use Cases of PCECC . . . . . . . . . . . . . . 33
	distributed computations (MapReduce-Hadoop) . . . . . . . 32		A.1. Use Cases of PCECC for LSP in the Network Migration . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35		A.2. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . 34
			A.3. Use Cases of PCECC for Local Protection (RSVP-TE) . . . . 35
			A.4. Using reliable P2MP TE based multicast delivery for
			distributed computations (MapReduce-Hadoop) . . . . . . . 36
			Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 38
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	An Architecture for Use of PCE and PCEP [RFC5440] in a Network with		The Path Computation Element (PCE) [RFC4655] was developed to offload
	Central Control [RFC8283] describes SDN architecture where the Path		the path computation function from routers in an MPLS traffic-
	Computation Element (PCE) determines paths for variety of different		engineered (TE) network. It can compute optimal paths for traffic
	usecases, with PCEP as a general southbound communication protocol		across a network and can also update the paths to reflect changes in
	with all the nodes along the path..		the network or traffic demands. Since then, the role and function of
			the PCE have grown to cover a number of other uses (such as GMPLS
			[RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated
			use of network resources [RFC8281].
			According to [RFC7399], Software-Defined Networking (SDN) refers to a
			separation between the control elements and the forwarding components
			so that software running in a centralized system, called a
			controller, can act to program the devices in the network to behave
			in specific ways. A required element in an SDN architecture is a
			component that plans how the network resources will be used and how
			the devices will be programmed. It is possible to view this
			component as performing specific computations to place traffic flows
			within the network given knowledge of the availability of network
			resources, how other forwarding devices are programmed, and the way
			that other flows are routed. This is the function and purpose of a
			PCE, and the way that a PCE integrates into a wider network control
			system (including an SDN system) is presented in [RFC7491].
			[RFC8283] introduces the architecture for the PCE as a central
			controller as an extension to the architecture described in [RFC4655]
			and assumes the continued use of PCEP as the protocol used between
			the PCE and PCC. [RFC8283] further examines the motivations and
			applicability for PCEP as a Southbound Interface (SBI) and introduces
			the implications for the protocol.
	[RFC9050] introduces the procedures and extensions for PCEP to		[RFC9050] introduces the procedures and extensions for PCEP to
	support the PCECC architecture [RFC8283].		support the PCECC architecture [RFC8283].
	This draft describes the various usecases for the PCECC architecture.		This draft describes the various other usecases for the PCECC
			architecture.
	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.]
	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 to		protocols, Open Shortest Path First (OSPF) or Intermediate System 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
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 22 ¶
	ranges to the router using PCEP.		ranges to the router using PCEP.
	[RFC9050] describe a mode where LSPs are provisioned as explicit		[RFC9050] describe a mode where LSPs are 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 controller uses PCEP to		program and what resources to reserve. The controller uses PCEP to
	communicate with each router along the path of the end-to-end LSP.		communicate with each router along the path of the end-to-end LSP.
	For this to work, the PCE- based controller will take responsibility		For this to work, the PCE- based controller will take responsibility
	for managing some part of the MPLS label space for each of the		for managing some part of the MPLS label space for each of the
	routers that it controls. An extension to PCEP could be done to		routers that it controls. An extension to PCEP could be done to
	allow a PCC to inform the PCE of such a label space to control.		allow a PCC to inform the PCE of such a label space to control. (See
			[I-D.li-pce-controlled-id-space] for a possible PCEP extension to
			support advertisement of the MPLS label space to the PCE 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
	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		Further, there have been various proposals for Global Labels in MPLS,
	advertisement of the MPLS label space to the PCE to control.		the PCECC architecture could be used as means to learn the label
			space of nodes, and could also be used to determine and provision the
	There have been various proposals for Global Labels, the PCECC		global label range.
	architecture could be used as means to learn the label space of
	nodes, and could also be used to determine and provision the global
	label range.
	+------------------------------+ +------------------------------+		+------------------------------+ +------------------------------+
	| PCE DOMAIN 1 | | PCE DOMAIN 2 |		| PCE DOMAIN 1 | | PCE DOMAIN 2 |
	| +--------+ | | +--------+ |		| +--------+ | | +--------+ |
	| | | | | | | |		| | | | | | | |
	| | PCECC1 | ---------PCEP---------- | PCECC2 | |		| | PCECC1 | ---------PCEP---------- | PCECC2 | |
	| | | | | | | |		| | | | | | | |
	| | | | | | | |		| | | | | | | |
	| +--------+ | | +--------+ |		| +--------+ | | +--------+ |
	| ^ ^ | | ^ ^ |		| ^ ^ | | ^ ^ |
	skipping to change at page 6, line 43 ¶		skipping to change at page 7, line 15 ¶
	(and PCECC) could be one such means.		(and PCECC) could be one such means.
	[RFC8664] specify the SR specific PCEP extensions. PCECC may further		[RFC8664] specify the SR specific PCEP extensions. PCECC may further
	use PCEP protocol for SR SID (Segment Identifier) distribution to the		use PCEP protocol for SR SID (Segment Identifier) distribution to the
	SR nodes (PCC) with some benefits. If the PCECC allocates and		SR nodes (PCC) with some benefits. If the PCECC allocates and
	maintains the SID in the network for the nodes and adjacencies; and		maintains the SID in the network for the nodes and adjacencies; and
	further distributes them to the SR nodes directly via the PCEP		further distributes them to the SR nodes directly via the PCEP
	session has some advantage over the configurations on each SR node		session has some advantage over the configurations on each SR node
	and flooding via IGP, especially in a SDN environment.		and flooding via IGP, especially in a SDN environment.
	When the PCECC is used for the distribution of the node segment ID		When the PCECC is used for the distribution of the node SID and
	and adjacency segment ID, the node segment ID is allocated from the		adjacency SID, the node SID is allocated from the SRGB of the node.
	SRGB of the node. For the allocation of adjacency segment ID, the		For the allocation of adjacency SID, the allocation is from the SRLB
	allocation is from the SRLB of the node as described in		of the node as described in
	[I-D.ietf-pce-pcep-extension-pce-controller-sr].		[I-D.ietf-pce-pcep-extension-pce-controller-sr].
	[RFC8355] identifies various protection and resiliency usecases for		[RFC8355] identifies various protection and resiliency usecases for
	SR. Path protection lets the ingress node be in charge of the		SR. Path protection lets the ingress node be in charge of the
	failure recovery (used for SR-TE). Also protection can be performed		failure recovery (used for SR-TE). Also protection can be performed
	by the node adjacent to the failed component, commonly referred to as		by the node adjacent to the failed component, commonly referred to as
	local protection techniques or fast-reroute (FRR) techniques. In		local protection techniques or fast-reroute (FRR) techniques. In
	case of PCECC, the protection paths can be pre-computed and setup by		case of PCECC, the protection paths can be pre-computed and setup by
	the PCE.		the PCE.
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, line 49 ¶
	in the domain, it enforces the ECMP-aware shortest-path forwarding of		in the domain, it enforces the ECMP-aware shortest-path forwarding of
	the packet towards the related node.		the packet towards the related node.
	For each adjacency in the network, PCECC can allocate an Adj-SID.		For each adjacency in the network, PCECC can allocate an Adj-SID.
	The PCECC sends PCInitiate message to update the label map of each		The PCECC sends PCInitiate message to update the label map of each
	Adj to the corresponding nodes in the domain. Each node (PCC)		Adj to the corresponding nodes in the domain. Each node (PCC)
	download the label forwarding instructions accordingly. The		download the label forwarding instructions accordingly. The
	forwarding behavior and the end result is similar to IGP based "Adj-		forwarding behavior and the end result is similar to IGP based "Adj-
	SID" in SR.		SID" in SR.
	The various mechanism are described in		These mechanism are described in
	[I-D.ietf-pce-pcep-extension-pce-controller-sr].		[I-D.ietf-pce-pcep-extension-pce-controller-sr].
	3.2.2. Use Cases of PCECC for SR Best Effort (BE) Path		3.2.2. Use Cases of PCECC for SR Best Effort (BE) Path
	In this mode of the solution, the PCECC just need to allocate the		In this mode of the solution, the PCECC just need to allocate the
	node segment ID and adjacency ID (without calculating the explicit		node SID (without calculating the explicit path for the SR path).
	path for the SR path). The ingress of the forwarding path just need		The ingress of the forwarding path just need to encapsulate the
	to encapsulate the destination node segment ID on top of the packet.		destination node SID on top of the packet. All the intermediate
	All the intermediate nodes will forward the packet based on the		nodes will forward the packet based on the destination node SID. It
	destination node SID. It is similar to the LDP LSP.		is similar to the LDP LSP.
	R1 may send a packet to R8 simply by pushing an SR header with		R1 may send a packet to R8 simply by pushing an SR header with
	segment list {1008} (Node SID for R8). The path would be the based		segment list {1008} (Node SID for R8). The path would be the based
	on the routing/nexthop calculation on the routers.		on the routing/nexthop calculation on the routers.
	3.2.3. Use Cases of PCECC for SR Traffic Engineering (TE) Path		3.2.3. Use Cases of PCECC for SR Traffic Engineering (TE) Path
	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
	skipping to change at page 9, line 40 ¶		skipping to change at page 10, line 33 ¶
	list {1004, 1008}. The path could be : R1-R2-R4-R3-R8.		list {1004, 1008}. The path could be : R1-R2-R4-R3-R8.
	* 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		3.2.4. SR Policy
	[TODO: BORIS - will be added in next version to be published after		[RFC8402] defines Segment Routing architecture, which uses a SR
	the blockade is lifted :) ]		Policy to steer packets from a node through a ordered list of
			segments. The SR Policy could be configured on the headed or
			instantiated by an SR controller. The SR architecture does not
			restrict how the controller programs the network. The options are
			Network Configuration Protocol (NETCONF), PCEP, and BGP. SR Policy
			can be based on either SR-MPLS or SRv6 dataplane.
			A SR Policy architecture is described in
			[I-D.ietf-spring-segment-routing-policy]. An SR Policy is a
			framework that enables the instantiation of an ordered list of
			segments on a node for implementing a source routing policy for the
			steering of traffic for a specific purpose (e.g. for a specific SLA)
			from that node.
			A SR Policy is identified through the tuple <headend, color,
			endpoint>. In the context of a specific headend, one may identify an
			SR policy by the <color, endpoint> tuple.
			The headend is the node where the policy is instantiated/implemented.
			The endpoint indicates the destination of the policy. The color is a
			32-bit numerical value that associates the SR Policy with an intent
			or objective.
			A SR Policy should have one or more Candidate Paths. A candidate
			path is the unit for signaling of an SR Policy to a headend via
			protocol extensions like [I-D.ietf-pce-segment-routing-policy-cp] or
			BGP SR Policy [I-D.ietf-idr-segment-routing-te-policy]. Each
			candidate path must have one or mode Segment-Lists. A Segment- List
			represents a specific source-routed path to send traffic from the
			headend to the endpoint of the corresponding SR Policy.
			A candidate path is either dynamic, explicit, or composite. For
			PCECC use case a candidate path should be either dynamic (i.e. when
			PCE provides its according to specific optimization objective) or
			composite (a composite candidate path construct enables the
			combination of SR Policies, each with explicit candidate paths and/or
			dynamic candidate paths with potentially different optimization
			objectives and constraints).
			[I-D.ietf-pce-segment-routing-policy-cp] defines a new ASSOCIATION
			type that binds previously separated LSPs in the PCEP (Candidate
			Paths) into common SR Policy hierarchy. This is applicable in the
			PCECC scenario as well.
			Further one could also use the PCECC mechanism directly to create an
			SR policy container at the PCC by defining a new CCI for it. The
			advantage of that approach would be to allow SR Policy to be created
			without signaling candidate paths.
	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
	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
	router along the path of the end-to-end LSP.		router along the path of the end-to-end LSP.
	192.0.2.1/32		192.0.2.1/32
	+----------+		+----------+
	| R1 |		| R1 |
	+----------+		+----------+
	| |		| |
	skipping to change at page 12, line 36 ¶		skipping to change at page 14, line 36 ¶
	manual intervention.		manual intervention.
	* 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:
	* 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 load balancing between AGG X and
	N-1 (egress AGG routers which have connections to core) via North		AGG N/AGG N-1 (egress AGG routers which have connections to core).
	Bound Interface (NBI). Each of these would have associated		Each of these would have associated constrains (i.e. bandwidth,
	constrains (i.e. Path Setup Type (PST), bandwidth, inclusion or		inclusion or exclusion specific links or nodes, number of paths,
	exclusion specific links or nodes, number of paths, objective		objective function (OF), need for disjoint LSP paths etc.).
	function (OF), need for disjoint LSP paths etc.).
	* 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.
	* 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.
	* PCECC would send PCInitiate PCEP message [RFC8281] towards ingress		* PCECC would send PCInitiate message [RFC8281] towards ingress AGG
	AGG X router(PCC) for each of N LSPs and receives PCRpt PCEP		X router(PCC) for each of N LSPs and receives PCRpt PCEP message
	message [RFC8231] back from PCCs. If the PST is PCECC-SR, the		[RFC8231] back from PCCs. If the PST is PCECC-SR, the PCECC would
	PCECC would include the SID stack as per [RFC8664]. If the PST is		include the SID stack as per [RFC8664]. If the PST is PCECC
	PCECC (basic), then the PCECC would assigns labels along the		(basic), then the PCECC would assigns labels along the calculated
	calculated path; and set up the path by sending central controller		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 [RFC9050] and then send PCUpd message to the ingress		LSP as per [RFC9050] and then send PCUpd message to the ingress
	AGG X router with information about new LSP and AGG X(PCC) would		AGG X router with information about new LSP and AGG X(PCC) would
	respond with PCRpt with LSP status.		respond with PCRpt with LSP status.
	* 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.
	skipping to change at page 16, line 21 ¶		skipping to change at page 17, line 47 ¶
	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
	* 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.
	* PCECC would send PCInitiate PCEP message [RFC8281] towards ingress		* PCECC would send PCInitiate 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
	[RFC9050] and then send PCUpd message to the ingress R1 router		[RFC9050] and then send PCUpd message to the ingress R1 router
	with information about new LSPs and R1 would respond with PCRpt		with information about new LSPs and R1 would respond with PCRpt
	with LSP(s) status.		with LSP(s) status.
	* 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 multicast LSPs can be setup via the RSVP-TE P2MP or mLDP
	mLDP protocols. The setup of these LSPs may require manual		protocols. The setup of these LSPs may require manual configurations
	configurations and complex signaling when the protection is		and complex signaling when the protection is considered. By using
	considered. By using the PCECC solution, the multicast LSP can be		the PCECC solution, the multicast LSP can be computed and setup
	computed and setup through centralized controller which has the full		through centralized controller which has the full picture of the
	picture of the topology and bandwidth usage for each link. It not		topology and bandwidth usage for each link. It not only reduces the
	only reduces the complex configurations comparing the distributed		complex configurations comparing the distributed RSVP-TE P2MP or mLDP
	RSVP-TE P2MP or mLDP signaling, but also it can compute the disjoint		signaling, but also it can compute the disjoint primary path and
	primary path and secondary P2MP path efficiently.		secondary P2MP path efficiently.
	3.4.1. Using PCECC for P2MP/MP2MP LSPs' Setup		3.4.1. Using PCECC for P2MP/MP2MP LSPs' Setup
	It is assumed the PCECC is aware of the label space it controls for		It is assumed the PCECC is aware of the label space it controls for
	all nodes and make allocations accordingly.		all nodes and make allocations accordingly.
	+----------+		+----------+
	| R1 | Root node of the multicast LSP		| R1 | Root node of the multicast LSP
	+----------+		+----------+
	|6000		|6000
	skipping to change at page 18, line 4 ¶		skipping to change at page 19, line 47 ¶
	constrains (i.e.bandwidth).		constrains (i.e.bandwidth).
	* 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
	6000 to the packet.
	Step2: After R2 receives the packet with label 6000, it will		Step 1: R1 may send a packet P1 to R2 simply by pushing an label
			of 6000 to the packet.
			Step 2: After R2 receives the packet with label 6000, it will
	forwarding to R4 by swapping label to 9001 and by swapping label		forwarding to R4 by swapping label to 9001 and by swapping label
	of 9002 towards R5.		of 9002 towards R5.
	Step3: After R4 receives the packet with label 9001, it will		Step 3: After R4 receives the packet with label 9001, it will
	forwarding to R3 by swapping to 9003. After R5 receives the		forwarding to R3 by swapping to 9003. After R5 receives the
	packet with label 9002, it will forwarding to R6 by swapping to		packet with label 9002, it will forwarding to R6 by swapping to
	9004.		9004.
	Step4: After R3 receives the packet with label 9003, it will		Step 4: After R3 receives the packet with label 9003, it will
	forwarding to R8 by swapping to 9005 and when R5 receives the		forwarding to R8 by swapping to 9005 and when R5 receives the
	packet with label 9004, it will swap to 9004 and send to R6.		packet with label 9004, it will swap to 9004 and send to R6.
	Step5: Packet received at R8 and 9005 is popped; packet receives		Step 5: Packet received at R8 and 9005 is popped; packet receives
	at R6 and 9004 is popped.		at R6 and 9004 is popped.
	3.4.2. Use Cases of PCECC for the Resiliency of P2MP/MP2MP LSPs		3.4.2. Use Cases of PCECC for the Resiliency of P2MP/MP2MP LSPs
	3.4.2.1. PCECC for the End-to-End Protection of the P2MP/MP2MP LSPs		3.4.2.1. PCECC for the End-to-End Protection of the P2MP/MP2MP LSPs
	In this section we describe the end-to-end managed path protection		In this section we describe the end-to-end managed path protection
	service as well as the local protection with the operation management		service as well as the local protection with the operation management
	in the PCECC network for the P2MP/MP2MP LSP.		in the PCECC network for the P2MP/MP2MP LSP.
	skipping to change at page 20, line 45 ¶		skipping to change at page 22, line 45 ¶
	R50}. Both the these two primary forwarding path and secondary		R50}. Both the these two primary forwarding path and secondary
	bypass forwarding path will be downloaded to each routers along the		bypass forwarding path will be downloaded to each routers along the
	primary path and the secondary bypass path. The traffic will be		primary path and the secondary bypass path. The traffic will be
	forwarded through the R10->R20->{R40, R50} path normally, and when		forwarded through the R10->R20->{R40, R50} path normally, and when
	there is a node failure for node R20, then the PLR node R10 will		there is a node failure for node R20, then the PLR node R10 will
	switch the flow to the backup path, which is R10->R30->{R40, R50}.		switch the flow to the backup path, which is R10->R30->{R40, R50}.
	By using the PCECC, the path computation and forwarding path		By using the PCECC, the path computation and forwarding path
	downloading can all be done without the complex signaling used in the		downloading can all be done without the complex signaling used in the
	P2MP RSVP-TE or mLDP.		P2MP RSVP-TE or mLDP.
	3.5. Use Cases of PCECC for LSP in the Network Migration		3.5. Using PCECC for Traffic Classification Information
	One of the main advantages for PCECC solution is that it has backward
	compatibility naturally since the PCE server itself can function as a
	proxy node of MPLS network for all the new nodes which may no longer
	support the signaling protocols.
	As it is illustrated in the following example, the current network
	could migrate to a total PCECC controlled network gradually by
	replacing the legacy nodes. During the migration, the legacy nodes
	still need to signal using the existing MPLS protocol such as LDP and
	RSVP-TE, and the new nodes setup their portion of the forwarding path
	through PCECC directly. With the PCECC function as the proxy of
	these new nodes, MPLS signaling can populate through network as
	normal.
	Example described in this section is based on network configurations
	illustrated using the following figure:
	+------------------------------------------------------------------+
	| PCE DOMAIN |
	| +-----------------------------------------------------+ |
	| | PCECC | |
	| +-----------------------------------------------------+ |
	| ^ ^ ^ ^ |
	| | PCEP | | PCEP | |
	| V V V V |
	| +--------+ +--------+ +--------+ +--------+ +--------+ |
	| | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | |
	| | |...| |...| |...| |...| | |
	| | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | |
	| | Node | | Node | |Enabled | |Enabled | | Enabled| |
	| +--------+ +--------+ +--------+ +--------+ +--------+ |
	| |
	+------------------------------------------------------------------+
	Example: PCECC Initiated LSP Setup In the Network Migration
	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
	centrally controlled and other nodes are legacy nodes.
	* Node1 sends a path request message for the setup of LSP
	destinating to Node5.
	* PCECC sends to node1 a reply message for LSP setup with the path:
	(Node1, if1),(Node2, if2), (Node3, if3), (Node4, if4), Node5.
	* Node1, Node2, Node3 will setup the LSP to Node5 using the local
	labels as usual. Node 3 with help of PCECC could proxy the
	signaling.
	* Then the PCECC will program the out-segment of Node3, the in-
	segment/ out-segment of Node4, and the in-segment for Node5.
	3.6. Use Cases of PCECC for L3VPN and PWE3
	As described in [RFC8283], various network services may be offered
	over a network. These include protection services (including Virtual
	Private Network (VPN) services (such as Layer 3 VPNs [RFC4364] or
	Ethernet VPNs [RFC7432]); or Pseudowires [RFC3985]. Delivering
	services over a network in an optimal way requires coordination in
	the way that network resources are allocated to support the services.
	A PCE-based central controller can consider the whole network and all
	components of a service at once when planning how to deliver the
	service. It can then use PCEP to manage the network resources and to
	install the necessary associations between those resources.
	In the case of L3VPN, VPN labels can be assigned and distributed
	through the PCECC PCEP among the PE router instead of using the BGP
	protocols.
	Example described in this section is based on network configurations
	illustrated using the following figure:
	+-------------------------------------------+
	| PCE DOMAIN |
	| +-----------------------------------+ |
	| | PCECC | |
	| +-----------------------------------+ |
	| ^ ^ ^ |
	|PWE3/L3VPN | PCEP PCEP|LSP PWE3/L3VPN|PCEP |
	| V V V |
	+--------+ | +--------+ +--------+ +--------+ | +--------+
	| CE | | | PE1 | | NODE x | | PE2 | | | CE |
	| |...... | |...| |...| |.....| |
	| Legacy | |if1 | PCECC |if2|PCCEC |if3| PCECC |if4 | Legacy |
	| Node | | | Enabled| |Enabled | |Enabled | | | Node |
	+--------+ | +--------+ +--------+ +--------+ | +--------+
	| |
	+-------------------------------------------+
	Example: Using PCECC for L3VPN and PWE3
	In the case PWE3, instead of using the LDP signaling protocols, the
	label and port pairs assigned to each pseudowire can be assigned
	through PCECC among the PE routers and the corresponding forwarding
	entries will be distributed into each PE routers through the extended
	PCEP protocols and PCECC mechanism.
	3.7. Using PCECC for Traffic Classification Information
	As described in [RFC8283], traffic classification is an important		As described in [RFC8283], traffic classification is an important
	part of traffic engineering. It is the process of looking at a		part of traffic engineering. It is the process of looking at a
	packet to determine how it should be treated as it is forwarded		packet to determine how it should be treated as it is forwarded
	through the network. It applies in many scenarios including MPLS		through the network. It applies in many scenarios including MPLS
	traffic engineering (where it determines what traffic is forwarded		traffic engineering (where it determines what traffic is forwarded
	onto which LSPs); segment routing (where it is used to select which		onto which LSPs); segment routing (where it is used to select which
	set of forwarding instructions to add to a packet); and SFC (where it		set of forwarding instructions to add to a packet); and SFC (where it
	indicates along which service function path a packet should be		indicates along which service function path a packet should be
	forwarded). In conjunction with traffic engineering, traffic		forwarded). In conjunction with traffic engineering, traffic
	classification is an important enabler for load balancing. Traffic		classification is an important enabler for load balancing. Traffic
	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 [RFC9168].
	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 -
	* how to use it		* how to use it
	* Whether it is a virtual link		* Whether it is a virtual link
	* Whether to advertise it in the IGP as a virtual link		* Whether to advertise it in the IGP as a virtual link
	* 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.6. 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
	of IPv6 addresses in the routing header. The active segment is		of IPv6 addresses in the routing header. The active segment is
	indicated by the Destination Address of the packet. Upon completion		indicated by the Destination Address of the packet. Upon completion
	of a segment, a pointer in the new routing header is incremented and		of a segment, a pointer in the new routing header is incremented and
	indicates the next segment.		indicates the next segment.
	skipping to change at page 25, line 5 ¶		skipping to change at page 24, line 40 ¶
	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 -
	* SRv6 SID-List={2001:db8::8} - The best path towards R8		* SRv6 SID-List={2001:db8::8} - The best path towards R8
	* 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.7. 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
	are to be performed to derive a Service Function Path (SFP). Each		are to be performed to derive a Service Function Path (SFP). Each
	packet is marked as belonging to a specific SFP, and that marking		packet is marked as belonging to a specific SFP, and that marking
	skipping to change at page 26, line 5 ¶		skipping to change at page 25, line 38 ¶
	forwarding instructions to each SFFs along the way so that they could		forwarding instructions to each SFFs along the way so that they could
	process the NSH and forward accordingly. Instructions to the service		process the NSH and forward accordingly. Instructions to the service
	classifier handle the context header, meta data etc.		classifier handle the context header, meta data etc.
	It is also possible to support SFC with SR in conjunction with or		It is also possible to support SFC with SR in conjunction with or
	without NSH such as [I-D.ietf-spring-nsh-sr] and		without NSH such as [I-D.ietf-spring-nsh-sr] and
	[I-D.ietf-spring-sr-service-programming]. PCECC technique can also		[I-D.ietf-spring-sr-service-programming]. PCECC technique can also
	be used for service function related segments and SR service		be used for service function related segments and SR service
	policies.		policies.
	3.10. Use Cases of PCECC for Native IP		3.8. 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. [RFC8821] 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)
	[I-D.cbrt-pce-stateful-local-protection] describes the need 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
	PLR. This bypass can be PCC-initiated and delegated, or PCE-
	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
	could be done locally at the PLR based on a local policy but there is
	a need for a PCE to do the mapping as well to exert greater control.
	This mapping can be done via PCECC procedures where the PCE could
	instruct the PLR to the mapping and identify the primary LSP for
	which bypass should be used.
	3.12. Use Cases of PCECC for BIER		3.9. Use Cases of PCECC for BIER
	Bit Index Explicit Replication (BIER) [RFC8279] defines an		Bit Index Explicit Replication (BIER) [RFC8279] defines an
	architecture where all intended multicast receivers are encoded as a		architecture where all intended multicast receivers are encoded as a
	bitmask in the multicast packet header within different		bitmask in the multicast packet header within different
	encapsulations. A router that receives such a packet will forward		encapsulations. A router that receives such a packet will forward
	the packet based on the bit position in the packet header towards the		the packet based on the bit position in the packet header towards the
	receiver(s) following a precomputed tree for each of the bits in the		receiver(s) following a precomputed tree for each of the bits in the
	packet. Each receiver is represented by a unique bit in the bitmask.		packet. Each receiver is represented by a unique bit in the bitmask.
	BIER-TE [I-D.ietf-bier-te-arch] shares architecture and packet		BIER-TE [I-D.ietf-bier-te-arch] shares architecture and packet
	skipping to change at page 27, line 20 ¶		skipping to change at page 26, line 37 ¶
	router with various parameters used in the BIER encapsulation such as		router with various parameters used in the BIER encapsulation such as
	BIER subdomain-ID, BFR-ID, BIER Encapsulation etc etc for both node		BIER subdomain-ID, BFR-ID, BIER Encapsulation etc etc for both node
	and adjacency.		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
	TODO: DHRUV - we plan to add this in the next revision after the		[RFC8283] describes how the security considerations for a PCE-based
	draft submission blockade is lifted.		controller are little different from those for any other PCE system.
			That is, the operation relies heavily on the use and security of
			PCEP, so due consideration should be given to the security features
			discussed in [RFC5440] and the additional mechanisms described in
			[RFC8253]. It further lists the vulnerability of a central
			controller architecture, such as a central point of failure, denial
			of service, and a focus for interception and modification of messages
			sent to individual Network Elements (NEs).
			As per [RFC9050], the use of Transport Layer Security (TLS) in PCEP
			is recommended, as it provides support for peer authentication,
			message encryption, and integrity. It further provides mechanisms
			for associating peer identities with different levels of access and/
			or authoritativeness via an attribute in X.509 certificates or a
			local policy with a specific accept-list of X.509 certificates. This
			can be used to check the authority for the PCECC operations.
			It is expected that each new document that is produced for a specific
			use case will also include considerations of the security impacts of
			the use of a PCE-based central controller on the network type and
			services being managed.
	6. Acknowledgments		6. Acknowledgments
	We would like to thank Adrain Farrel, Aijun Wang, Robert Tao,		We would like to thank Adrian 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
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	skipping to change at page 28, line 5 ¶		skipping to change at page 28, line 5 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An		[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
	Architecture for Use of PCE and the PCE Communication		Architecture for Use of PCE and the PCE Communication
	Protocol (PCEP) in a Network with Central Control",		Protocol (PCEP) in a Network with Central Control",
	RFC 8283, DOI 10.17487/RFC8283, December 2017,		RFC 8283, DOI 10.17487/RFC8283, December 2017,
	<https://www.rfc-editor.org/info/rfc8283>.		<https://www.rfc-editor.org/info/rfc8283>.
			[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
			"PCEPS: Usage of TLS to Provide a Secure Transport for the
			Path Computation Element Communication Protocol (PCEP)",
			RFC 8253, DOI 10.17487/RFC8253, October 2017,
			<https://www.rfc-editor.org/info/rfc8253>.
	7.2. Informative References		7.2. Informative References
	[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation		[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
	Edge-to-Edge (PWE3) Architecture", RFC 3985,		Edge-to-Edge (PWE3) Architecture", RFC 3985,
	DOI 10.17487/RFC3985, March 2005,		DOI 10.17487/RFC3985, March 2005,
	<https://www.rfc-editor.org/info/rfc3985>.		<https://www.rfc-editor.org/info/rfc3985>.
	[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)		[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
	Hierarchy with Generalized Multi-Protocol Label Switching		Hierarchy with Generalized Multi-Protocol Label Switching
	(GMPLS) Traffic Engineering (TE)", RFC 4206,		(GMPLS) Traffic Engineering (TE)", RFC 4206,
	DOI 10.17487/RFC4206, October 2005,		DOI 10.17487/RFC4206, October 2005,
	<https://www.rfc-editor.org/info/rfc4206>.		<https://www.rfc-editor.org/info/rfc4206>.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	2006, <https://www.rfc-editor.org/info/rfc4364>.		2006, <https://www.rfc-editor.org/info/rfc4364>.
			[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
			Computation Element (PCE)-Based Architecture", RFC 4655,
			DOI 10.17487/RFC4655, August 2006,
			<https://www.rfc-editor.org/info/rfc4655>.
	[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,		[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
	"Label Switched Path Stitching with Generalized		"Label Switched Path Stitching with Generalized
	Multiprotocol Label Switching Traffic Engineering (GMPLS		Multiprotocol Label Switching Traffic Engineering (GMPLS
	TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,		TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,
	<https://www.rfc-editor.org/info/rfc5150>.		<https://www.rfc-editor.org/info/rfc5150>.
	[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-		[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
	Domain MPLS and GMPLS Traffic Engineering -- Resource		Domain MPLS and GMPLS Traffic Engineering -- Resource
	Reservation Protocol-Traffic Engineering (RSVP-TE)		Reservation Protocol-Traffic Engineering (RSVP-TE)
	Extensions", RFC 5151, DOI 10.17487/RFC5151, February		Extensions", RFC 5151, DOI 10.17487/RFC5151, February
	skipping to change at page 28, line 46 ¶		skipping to change at page 29, line 11 ¶
	Communication Protocol (PCEP)", RFC 5541,		Communication Protocol (PCEP)", RFC 5541,
	DOI 10.17487/RFC5541, June 2009,		DOI 10.17487/RFC5541, June 2009,
	<https://www.rfc-editor.org/info/rfc5541>.		<https://www.rfc-editor.org/info/rfc5541>.
	[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS		[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
	Requirements for the Path Computation Element		Requirements for the Path Computation Element
	Communication Protocol (PCECP)", RFC 5376,		Communication Protocol (PCECP)", RFC 5376,
	DOI 10.17487/RFC5376, November 2008,		DOI 10.17487/RFC5376, November 2008,
	<https://www.rfc-editor.org/info/rfc5376>.		<https://www.rfc-editor.org/info/rfc5376>.
			[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
			Margaria, "Requirements for GMPLS Applications of PCE",
			RFC 7025, DOI 10.17487/RFC7025, September 2013,
			<https://www.rfc-editor.org/info/rfc7025>.
			[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
			Computation Element Architecture", RFC 7399,
			DOI 10.17487/RFC7399, October 2014,
			<https://www.rfc-editor.org/info/rfc7399>.
	[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,		[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
	Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based		Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
	Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February		Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
	2015, <https://www.rfc-editor.org/info/rfc7432>.		2015, <https://www.rfc-editor.org/info/rfc7432>.
			[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
			Application-Based Network Operations", RFC 7491,
			DOI 10.17487/RFC7491, March 2015,
			<https://www.rfc-editor.org/info/rfc7491>.
	[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function		[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
	Chaining (SFC) Architecture", RFC 7665,		Chaining (SFC) Architecture", RFC 7665,
	DOI 10.17487/RFC7665, October 2015,		DOI 10.17487/RFC7665, October 2015,
	<https://www.rfc-editor.org/info/rfc7665>.		<https://www.rfc-editor.org/info/rfc7665>.
	[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path		[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
	Computation Element Communication Protocol (PCEP)		Computation Element Communication Protocol (PCEP)
	Extensions for Stateful PCE", RFC 8231,		Extensions for Stateful PCE", RFC 8231,
	DOI 10.17487/RFC8231, September 2017,		DOI 10.17487/RFC8231, September 2017,
	<https://www.rfc-editor.org/info/rfc8231>.		<https://www.rfc-editor.org/info/rfc8231>.
	skipping to change at page 30, line 15 ¶		skipping to change at page 30, line 37 ¶
	[RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,		[RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
	"Hierarchical Stateful Path Computation Element (PCE)",		"Hierarchical Stateful Path Computation Element (PCE)",
	RFC 8751, DOI 10.17487/RFC8751, March 2020,		RFC 8751, DOI 10.17487/RFC8751, March 2020,
	<https://www.rfc-editor.org/info/rfc8751>.		<https://www.rfc-editor.org/info/rfc8751>.
	[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,		[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
	Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header		Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
	(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,		(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
	<https://www.rfc-editor.org/info/rfc8754>.		<https://www.rfc-editor.org/info/rfc8754>.
			[RFC8821] Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based
			Traffic Engineering (TE) in Native IP Networks", RFC 8821,
			DOI 10.17487/RFC8821, April 2021,
			<https://www.rfc-editor.org/info/rfc8821>.
	[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		[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
	Computation Element Communication Protocol (PCEP)		Computation Element Communication Protocol (PCEP)
	Procedures and Extensions for Using the PCE as a Central		Procedures and Extensions for Using the PCE as a Central
	Controller (PCECC) of LSPs", RFC 9050,		Controller (PCECC) of LSPs", RFC 9050,
	DOI 10.17487/RFC9050, July 2021,		DOI 10.17487/RFC9050, July 2021,
	<https://www.rfc-editor.org/info/rfc9050>.		<https://www.rfc-editor.org/info/rfc9050>.
	[I-D.ietf-pce-pcep-flowspec]		[RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation
	Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow		Element Communication Protocol (PCEP) Extension for Flow
	Specification", Work in Progress, Internet-Draft, draft-		Specification", RFC 9168, DOI 10.17487/RFC9168, January
	ietf-pce-pcep-flowspec-13, 14 October 2021,		2022, <https://www.rfc-editor.org/info/rfc9168>.
	<https://www.ietf.org/archive/id/draft-ietf-pce-pcep-
	flowspec-13.txt>.
	[I-D.ietf-pce-pcep-extension-pce-controller-sr]		[I-D.ietf-pce-pcep-extension-pce-controller-sr]
	Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou,		Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou,
	"PCEP Procedures and Protocol Extensions for Using PCE as		"Path Computation Element Communication Protocol (PCEP)
	a Central Controller (PCECC) for Segment Routing (SR) MPLS		Procedures and Extensions for Using PCE as a Central
	Segment Identifier (SID) Allocation and Distribution.",		Controller (PCECC) for Segment Routing (SR) MPLS Segment
	Work in Progress, Internet-Draft, draft-ietf-pce-pcep-		Identifier (SID) Allocation and Distribution.", Work in
	extension-pce-controller-sr-03, 30 September 2021,		Progress, Internet-Draft, draft-ietf-pce-pcep-extension-
			pce-controller-sr-04, 6 March 2022,
	<https://www.ietf.org/archive/id/draft-ietf-pce-pcep-		<https://www.ietf.org/archive/id/draft-ietf-pce-pcep-
	extension-pce-controller-sr-03.txt>.		extension-pce-controller-sr-04.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", Work in Progress, Internet-Draft,		Controlled ID Space", Work in Progress, Internet-Draft,
	draft-li-pce-controlled-id-space-09, 22 August 2021,		draft-li-pce-controlled-id-space-10, 24 February 2022,
	<https://www.ietf.org/archive/id/draft-li-pce-controlled-		<https://www.ietf.org/archive/id/draft-li-pce-controlled-
	id-space-09.txt>.		id-space-10.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", Work in		Extension for Stateful Inter-Domain Tunnels", Work in
	Progress, Internet-Draft, draft-ietf-pce-stateful-		Progress, Internet-Draft, draft-ietf-pce-stateful-
	interdomain-02, 12 July 2021,		interdomain-03, 4 March 2022,
	<https://www.ietf.org/archive/id/draft-ietf-pce-stateful-		<https://www.ietf.org/archive/id/draft-ietf-pce-stateful-
	interdomain-02.txt>.		interdomain-03.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", Work in Progress,		Local-Protection with PCE-Stateful", Work in Progress,
	Internet-Draft, draft-cbrt-pce-stateful-local-protection-		Internet-Draft, draft-cbrt-pce-stateful-local-protection-
	01, 29 June 2018, <https://www.ietf.org/archive/id/draft-		01, 29 June 2018, <https://www.ietf.org/archive/id/draft-
	cbrt-pce-stateful-local-protection-01.txt>.		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", Work in Progress,		Routing leveraging the IPv6 data plane", Work in Progress,
	Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, 27		Internet-Draft, draft-ietf-pce-segment-routing-ipv6-11, 10
	May 2021, <https://www.ietf.org/internet-drafts/draft-		January 2022, <https://www.ietf.org/internet-drafts/draft-
	ietf-pce-segment-routing-ipv6-09.txt>.		ietf-pce-segment-routing-ipv6-11.txt>.
	[I-D.ietf-teas-pce-native-ip]
	Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based
	Traffic Engineering (TE) in Native IP Networks", Work in
	Progress, Internet-Draft, draft-ietf-teas-pce-native-ip-
	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)", Work in		for Bit Index Explicit Replication (BIER-TE)", Work in
	Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9		Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9
	July 2021, <https://www.ietf.org/archive/id/draft-ietf-		July 2021, <https://www.ietf.org/archive/id/draft-ietf-
	bier-te-arch-10.txt>.		bier-te-arch-10.txt>.
	[I-D.chen-pce-bier]		[I-D.chen-pce-bier]
	Chen, R., Zhang, Z., Chen, H., Dhanaraj, S., Qin, F., and		Chen, R., Zhang, Z., Chen, H., Dhanaraj, S., Qin, F., and
	skipping to change at page 32, line 13 ¶		skipping to change at page 32, line 36 ¶
	S. Salsano, "Service Programming with Segment Routing",		S. Salsano, "Service Programming with Segment Routing",
	Work in Progress, Internet-Draft, draft-ietf-spring-sr-		Work in Progress, Internet-Draft, draft-ietf-spring-sr-
	service-programming-05, 10 September 2021,		service-programming-05, 10 September 2021,
	<https://www.ietf.org/archive/id/draft-ietf-spring-sr-		<https://www.ietf.org/archive/id/draft-ietf-spring-sr-
	service-programming-05.txt>.		service-programming-05.txt>.
	[I-D.ietf-spring-nsh-sr]		[I-D.ietf-spring-nsh-sr]
	Guichard, J. N. and J. Tantsura, "Integration of Network		Guichard, J. N. and J. Tantsura, "Integration of Network
	Service Header (NSH) and Segment Routing for Service		Service Header (NSH) and Segment Routing for Service
	Function Chaining (SFC)", Work in Progress, Internet-		Function Chaining (SFC)", Work in Progress, Internet-
	Draft, draft-ietf-spring-nsh-sr-09, 26 July 2021,		Draft, draft-ietf-spring-nsh-sr-10, 13 December 2021,
	<https://www.ietf.org/archive/id/draft-ietf-spring-nsh-sr-		<https://www.ietf.org/archive/id/draft-ietf-spring-nsh-sr-
	09.txt>.		10.txt>.
			[I-D.ietf-idr-segment-routing-te-policy]
			Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
			Jain, D., and S. Lin, "Advertising Segment Routing
			Policies in BGP", Work in Progress, Internet-Draft, draft-
			ietf-idr-segment-routing-te-policy-14, 10 November 2021,
			<https://www.ietf.org/archive/id/draft-ietf-idr-segment-
			routing-te-policy-14.txt>.
			[I-D.ietf-spring-segment-routing-policy]
			Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
			P. Mattes, "Segment Routing Policy Architecture", Work in
			Progress, Internet-Draft, draft-ietf-spring-segment-
			routing-policy-18, 17 February 2022,
			<https://www.ietf.org/archive/id/draft-ietf-spring-
			segment-routing-policy-18.txt>.
			[I-D.ietf-pce-segment-routing-policy-cp]
			Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
			Bidgoli, "PCEP extension to support Segment Routing Policy
			Candidate Paths", Work in Progress, Internet-Draft, draft-
			ietf-pce-segment-routing-policy-cp-06, 22 October 2021,
			<https://www.ietf.org/archive/id/draft-ietf-pce-segment-
			routing-policy-cp-06.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>.
	Appendix A. Using reliable P2MP TE based multicast delivery for		Appendix A. Other Use Cases of PCECC
	distributed computations (MapReduce-Hadoop)
			This section list some more advanced use cases of PCECC that were
			discussed and could be worked on in future.
			A.1. Use Cases of PCECC for LSP in the Network Migration
			One of the main advantages for PCECC solution is that it has backward
			compatibility naturally since the PCE server itself can function as a
			proxy node of MPLS network for all the new nodes which may no longer
			support the signaling protocols.
			As it is illustrated in the following example, the current network
			could migrate to a total PCECC controlled network gradually by
			replacing the legacy nodes. During the migration, the legacy nodes
			still need to signal using the existing MPLS protocol such as LDP and
			RSVP-TE, and the new nodes setup their portion of the forwarding path
			through PCECC directly. With the PCECC function as the proxy of
			these new nodes, MPLS signaling can populate through network as
			normal.
			Example described in this section is based on network configurations
			illustrated using the following figure:
			+------------------------------------------------------------------+
			| PCE DOMAIN |
			| +-----------------------------------------------------+ |
			| | PCECC | |
			| +-----------------------------------------------------+ |
			| ^ ^ ^ ^ |
			| | PCEP | | PCEP | |
			| V V V V |
			| +--------+ +--------+ +--------+ +--------+ +--------+ |
			| | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | |
			| | |...| |...| |...| |...| | |
			| | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | |
			| | Node | | Node | |Enabled | |Enabled | | Enabled| |
			| +--------+ +--------+ +--------+ +--------+ +--------+ |
			| |
			+------------------------------------------------------------------+
			Example: PCECC Initiated LSP Setup In the Network Migration
			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
			centrally controlled and other nodes are legacy nodes.
			* Node1 sends a path request message for the setup of LSP
			destinating to Node5.
			* PCECC sends to node1 a reply message for LSP setup with the path:
			(Node1, if1),(Node2, if2), (Node3, if3), (Node4, if4), Node5.
			* Node1, Node2, Node3 will setup the LSP to Node5 using the local
			labels as usual. Node 3 with help of PCECC could proxy the
			signaling.
			* Then the PCECC will program the out-segment of Node3, the in-
			segment/ out-segment of Node4, and the in-segment for Node5.
			A.2. Use Cases of PCECC for L3VPN and PWE3
			As described in [RFC8283], various network services may be offered
			over a network. These include protection services (including Virtual
			Private Network (VPN) services (such as Layer 3 VPNs [RFC4364] or
			Ethernet VPNs [RFC7432]); or Pseudowires [RFC3985]. Delivering
			services over a network in an optimal way requires coordination in
			the way that network resources are allocated to support the services.
			A PCE-based central controller can consider the whole network and all
			components of a service at once when planning how to deliver the
			service. It can then use PCEP to manage the network resources and to
			install the necessary associations between those resources.
			In the case of L3VPN, VPN labels can be assigned and distributed
			through the PCECC PCEP among the PE router instead of using the BGP
			protocols.
			Example described in this section is based on network configurations
			illustrated using the following figure:
			+-------------------------------------------+
			| PCE DOMAIN |
			| +-----------------------------------+ |
			| | PCECC | |
			| +-----------------------------------+ |
			| ^ ^ ^ |
			|PWE3/L3VPN | PCEP PCEP|LSP PWE3/L3VPN|PCEP |
			| V V V |
			+--------+ | +--------+ +--------+ +--------+ | +--------+
			| CE | | | PE1 | | NODE x | | PE2 | | | CE |
			| |...... | |...| |...| |.....| |
			| Legacy | |if1 | PCECC |if2|PCCEC |if3| PCECC |if4 | Legacy |
			| Node | | | Enabled| |Enabled | |Enabled | | | Node |
			+--------+ | +--------+ +--------+ +--------+ | +--------+
			| |
			+-------------------------------------------+
			Example: Using PCECC for L3VPN and PWE3
			In the case PWE3, instead of using the LDP signaling protocols, the
			label and port pairs assigned to each pseudowire can be assigned
			through PCECC among the PE routers and the corresponding forwarding
			entries will be distributed into each PE routers through the extended
			PCEP protocols and PCECC mechanism.
			A.3. Use Cases of PCECC for Local Protection (RSVP-TE)
			[I-D.cbrt-pce-stateful-local-protection] describes the need 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
			PLR. This bypass can be PCC-initiated and delegated, or PCE-
			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
			could be done locally at the PLR based on a local policy but there is
			a need for a PCE to do the mapping as well to exert greater control.
			This mapping can be done via PCECC procedures where the PCE could
			instruct the PLR to the mapping and identify the primary LSP for
			which bypass should be used.
			A.4. Using reliable P2MP TE based multicast delivery for 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 (https://hadoop.apache.org/) 1.0		widely deployed. In Hadoop (https://hadoop.apache.org/) 1.0
	architecture MapReduce operations on big data in the Hadoop		architecture MapReduce operations on big data in the Hadoop
	Distributed File System (HDFS), where NameNode has the knowledge		Distributed File System (HDFS), where NameNode has the knowledge
	about resources of the cluster and where actual data (chunks) for		about resources of the cluster and where actual data (chunks) for
	particular task are located (which DataNode). Each chunk of data		particular task are located (which DataNode). Each chunk of data
	(64MB or more) should have 3 saved copies in different DataNodes		(64MB or more) should have 3 saved copies in different DataNodes
	based on their proximity.		based on their proximity.
	skipping to change at page 35, line 14 ¶		skipping to change at page 38, line 31 ¶
	Phase 3. NameNode SHOULD send this information to client, PCECC		Phase 3. NameNode SHOULD send this information to client, PCECC
	informs client about optimal P2MP path towards DataNodes via PCEP		informs client about optimal P2MP path towards DataNodes via PCEP
	message.		message.
	Phase 4. Client sends data blocks to those DataNodes for writing via		Phase 4. Client sends data blocks to those DataNodes for writing via
	created P2MP tunnel.		created P2MP tunnel.
	When this task will be finished, P2MP tunnel could be turned down.		When this task will be finished, P2MP tunnel could be turned down.
			Appendix B. Contributor Addresses
			Following authors contributed text for this document and should be considered as co-authors:
			Luyuan Fang
			Expedia, Inc.
			United States of America
			Email: luyuanf@gmail.com
			Chao Zhou
			HPE
			Email: chaozhou_us@yahoo.com
			Boris Zhang
			Telus Communications
			Email: Boris.zhang@telus.com
			Artem Rachitskiy
			Mobile TeleSystems JLLC
			Nezavisimosti ave., 95
			220043, Minsk
			Belarus
			Email: arachitskiy@mts.by
			Anton Gulida
			LLC "Lifetech"
			Krasnoarmeyskaya str., 24
			220030, Minsk
			Belarus
			Email: anton.gulida@life.com.by
	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		Beijing
	100095		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		Bangalore
	Karnataka 560066		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
	United States of America		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
	Email: bhassanov@yahoo.com		Email: bhassanov@yahoo.com
	Luyuan Fang
	Expedia, Inc.
	United States of America
	Email: luyuanf@gmail.com
	Chao Zhou
	HPE
	Email: chaozhou_us@yahoo.com
	Boris Zhang
	Telus Communications
	Email: Boris.zhang@telus.com
	Artem Rachitskiy
	Mobile TeleSystems JLLC
	Nezavisimosti ave., 95
	220043, Minsk
	Belarus
	Email: arachitskiy@mts.by
	Anton Gulida
	LLC "Lifetech"
	Krasnoarmeyskaya str., 24
	220030, Minsk
	Belarus
	Email: anton.gulida@life.com.by
End of changes. 65 change blocks.
	274 lines changed or deleted		438 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/