< draft-ietf-pce-binding-label-sid-09.txt		draft-ietf-pce-binding-label-sid-10.txt >
	PCE Working Group S. Sivabalan		PCE Working Group S. Sivabalan
	Internet-Draft Ciena Corporation		Internet-Draft Ciena Corporation
	Intended status: Standards Track C. Filsfils		Intended status: Standards Track C. Filsfils
	Expires: December 5, 2021 Cisco Systems, Inc.		Expires: January 9, 2022 Cisco Systems, Inc.
	J. Tantsura		J. Tantsura
	Juniper Networks		Microsoft Corporation
	S. Previdi		S. Previdi
	C. Li, Ed.		C. Li, Ed.
	Huawei Technologies		Huawei Technologies
	June 3, 2021		July 8, 2021
	Carrying Binding Label/Segment Identifier in PCE-based Networks.		Carrying Binding Label/Segment Identifier in PCE-based Networks.
	draft-ietf-pce-binding-label-sid-09		draft-ietf-pce-binding-label-sid-10
	Abstract		Abstract
	In order to provide greater scalability, network confidentiality, and		In order to provide greater scalability, network confidentiality, and
	service independence, Segment Routing (SR) utilizes a Binding Segment		service independence, Segment Routing (SR) utilizes a Binding Segment
	Identifier (BSID). It is possible to associate a BSID to an RSVP-TE-		Identifier (BSID). It is possible to associate a BSID to an RSVP-TE-
	signaled Traffic Engineering Label Switched Path or an SR Traffic		signaled Traffic Engineering Label Switched Path or an SR Traffic
	Engineering path. The BSID can be used by an upstream node for		Engineering path. The BSID can be used by an upstream node for
	steering traffic into the appropriate TE path to enforce SR policies.		steering traffic into the appropriate TE path to enforce SR policies.
	This document specifies the binding value as an MPLS label or Segment		This document specifies the binding value as an MPLS label or Segment
	Identifier. It further specify an approach for reporting binding		Identifier. It further specifies an approach for reporting binding
	label/SID by a Path Computation Client (PCC) to the Path Computation		label/SID by a Path Computation Client (PCC) to the Path Computation
	Element (PCE) to support PCE-based Traffic Engineering policies.		Element (PCE) to support PCE-based Traffic Engineering policies.
	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.
	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 December 5, 2021.		This Internet-Draft will expire on January 9, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/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
	skipping to change at page 3, line 9 ¶		skipping to change at page 3, line 9 ¶
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	14.1. Normative References . . . . . . . . . . . . . . . . . . 17		14.1. Normative References . . . . . . . . . . . . . . . . . . 17
	14.2. Informative References . . . . . . . . . . . . . . . . . 19		14.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 20		Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	A Path Computation Element (PCE) can compute Traffic Engineering		A Path Computation Element (PCE) can compute Traffic Engineering
	paths (TE paths) through a network where those paths are subject to		paths (TE paths) through a network where those paths are subject to
	various constraints. Currently, TE paths are set up either using the		various constraints. Currently, TE paths are set up using either the
	RSVP-TE signaling protocol or Segment Routing (SR). We refer to such		RSVP-TE signaling protocol or Segment Routing (SR). We refer to such
	paths as RSVP-TE paths and SR-TE paths respectively in this document.		paths as RSVP-TE paths and SR-TE paths respectively in this document.
	As per [RFC8402] SR allows a head-end node to steer a packet flow		As per [RFC8402] SR allows a head-end node to steer a packet flow
	along any path. The head-end node is said to steer a flow into a		along any path. The head-end node is said to steer a flow into a
	Segment Routing Policy (SR Policy). Further, as per		Segment Routing Policy (SR Policy). Further, as per
	[I-D.ietf-spring-segment-routing-policy], an SR Policy is a framework		[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		that enables the instantiation of an ordered list of segments on a
	node for implementing a source routing policy with a specific intent		node for implementing a source routing policy with a specific intent
	for traffic steering from that node.		for traffic steering from that node.
	As described in [RFC8402], a Binding Segment Identifier (BSID) is		As described in [RFC8402], a Binding Segment Identifier (BSID) is
	bound to a Segment Routed (SR) Policy, instantiation of which may		bound to a Segment Routing (SR) Policy, instantiation of which may
	involve a list of SIDs. Any packets received with an active segment		involve a list of SIDs. Any packets received with an active segment
	equal to a BSID are steered onto the bound SR Policy. A BSID may be		equal to a BSID are steered onto the bound SR Policy. A BSID may be
	either a local (SR Local Block (SRLB)) or a global (SR Global Block		either a local (SR Local Block (SRLB)) or a global (SR Global Block
	(SRGB)) SID. As per Section 6.4 of		(SRGB)) SID. As per Section 6.4 of
	[I-D.ietf-spring-segment-routing-policy] a BSID can also be		[I-D.ietf-spring-segment-routing-policy] a BSID can also be
	associated with any type of interface or tunnel to enable the use of		associated with any type of interface or tunnel to enable the use of
	a non-SR interface or tunnel as a segment in a SID list. In this		a non-SR interface or tunnel as a segment in a SID list. In this
	document, binding label/SID is used to generalize the allocation of		document, binding label/SID is used to generalize the allocation of
	binding value for both SR and non-SR paths.		binding value for both SR and non-SR paths.
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 41 ¶
	( ) SID of ( )		( ) SID of ( )
	'-----' Node-1 '-----'		'-----' Node-1 '-----'
	is Y SIDs for SR-TE LSP:		is Y SIDs for SR-TE LSP:
	{A, B, C, D}		{A, B, C, D}
	Figure 1: A sample Use-case of Binding SID		Figure 1: A sample Use-case of Binding SID
	A PCC could report to the stateful PCE the binding label/SID it		A PCC could report to the stateful PCE the binding label/SID it
	allocated via a Path Computation LSP State Report (PCRpt) message.		allocated via a Path Computation LSP State Report (PCRpt) message.
	It is also possible for a stateful PCE to request a PCC to allocate a		It is also possible for a stateful PCE to request a PCC to allocate a
	specific binding label/SID by sending aPath Computation LSP Update		specific binding label/SID by sending a Path Computation LSP Update
	Request (PCUpd) message. If the PCC can successfully allocate the		Request (PCUpd) message. If the PCC can successfully allocate the
	specified binding value, it reports the binding value to the PCE.		specified binding value, it reports the binding value to the PCE.
	Otherwise, the PCC sends an error message to the PCE indicating the		Otherwise, the PCC sends an error message to the PCE indicating the
	cause of the failure. A local policy or configuration at the PCC		cause of the failure. A local policy or configuration at the PCC
	SHOULD dictate if the binding label/SID needs to be assigned.		SHOULD dictate if the binding label/SID needs to be assigned.
	In this document, we introduce a new OPTIONAL TLV that a PCC can use		In this document, we introduce a new OPTIONAL TLV that a PCC can use
	in order to report the binding label/SID associated with a TE LSP, or		in order to report the binding label/SID associated with a TE LSP, or
	a PCE to request a PCC to allocate a specific binding label/SID		a PCE to request a PCC to allocate a specific binding label/SID
	value. This TLV is intended for TE LSPs established using RSVP-TE,		value. This TLV is intended for TE LSPs established using RSVP-TE,
	skipping to change at page 9, line 25 ¶		skipping to change at page 9, line 25 ¶
	SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV		SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV
	by setting the BT (Binding Type) to 3. This enables the sender to		by setting the BT (Binding Type) to 3. This enables the sender to
	have control of the SRv6 Endpoint Behavior and SID Structure. A		have control of the SRv6 Endpoint Behavior and SID Structure. A
	sender MAY choose to set the BT to 2, in which case the receiving		sender MAY choose to set the BT to 2, in which case the receiving
	implementation chooses how to interpret the SRv6 Endpoint Behavior		implementation chooses how to interpret the SRv6 Endpoint Behavior
	and SID Structure according to local policy.		and SID Structure according to local policy.
	If a PCC wishes to withdraw a previously reported binding value, it		If a PCC wishes to withdraw a previously reported binding value, it
	MUST send a PCRpt message with the specific TE-PATH-BINDING TLV with		MUST send a PCRpt message with the specific TE-PATH-BINDING TLV with
	R flag set to 1. If a PCC wishes to modify a previously reported		R flag set to 1. If a PCC wishes to modify a previously reported
	binding, it MUST withdraw the former old binding value (with R flag		binding, it MUST withdraw the former binding value (with R flag set
	set in the former TE-PATH-BINDING TLV) and include a new TE-PATH-		in the former TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING
	BINDING TLV containing the new binding value. Note that other		TLV containing the new binding value. Note that other instances of
	instances of TE-PATH-BINDING TLVs that are unchanged MAY also be		TE-PATH-BINDING TLVs that are unchanged MAY also be included.
	included.
	If a PCE requires a PCC to allocate a (or several) specific binding		If a PCE requires a PCC to allocate a (or several) specific binding
	value(s), it may do so by sending a PCUpd or PCInitiate message		value(s), it may do so by sending a PCUpd or PCInitiate message
	containing a TE-PATH-BINDING TLV(s). If the value(s) can be		containing a TE-PATH-BINDING TLV(s). If the value(s) can be
	successfully allocated, the PCC reports the binding value(s) to the		successfully allocated, the PCC reports the binding value(s) to the
	PCE. If the PCC considers the binding value specified by the PCE		PCE. If the PCC considers the binding value specified by the PCE
	invalid, it MUST send a PCErr message with Error-Type = TBD2		invalid, it MUST send a PCErr message with Error-Type = TBD2
	("Binding label/SID failure") and Error Value = TBD3 ("Invalid SID").		("Binding label/SID failure") and Error Value = TBD3 ("Invalid SID").
	If the binding value is valid, but the PCC is unable to allocate the		If the binding value is valid, but the PCC is unable to allocate the
	binding value, it MUST send a PCErr message with Error-Type = TBD2		binding value, it MUST send a PCErr message with Error-Type = TBD2
	skipping to change at page 12, line 33 ¶		skipping to change at page 12, line 28 ¶
	TE-PATH-BINDING TLV in the LSP object.		TE-PATH-BINDING TLV in the LSP object.
	o To let the PCC allocates the binding label/SID, a PCE MUST set P=0		o To let the PCC allocates the binding label/SID, a PCE MUST set P=0
	and include an empty TE-PATH-BINDING TLV ( i.e., no binding value		and include an empty TE-PATH-BINDING TLV ( i.e., no binding value
	is specified) in the LSP object in PCInitiate/PCUpd message.		is specified) in the LSP object in PCInitiate/PCUpd message.
	o To request that the PCE allocate the binding label/SID, a PCC MUST		o To request that the PCE allocate the binding label/SID, a PCC MUST
	set P=1, D=1, and include an empty TE-PATH-BINDING TLV in PCRpt		set P=1, D=1, and include an empty TE-PATH-BINDING TLV in PCRpt
	message. The PCE SHOULD allocate it and respond to the PCC with		message. The PCE SHOULD allocate it and respond to the PCC with
	PCUpd message including the allocated binding label/SID in the TE-		PCUpd message including the allocated binding label/SID in the TE-
	PATH-BINDING TLV and P=1, D=1 in the LSP object.		PATH-BINDING TLV and P=1, D=1 in the LSP object. If the PCE is
			unable to allocate, it MUST send a PCErr message with Error-Type =
			TBD2 ("Binding label/SID failure") and Error-Value = TBD5 ("Unable
			to allocate a new binding label/SID").
	o If both peers have not exchanged the PCECC capabilities as per		o If both peers have not exchanged the PCECC capabilities as per
	[I-D.ietf-pce-pcep-extension-for-pce-controller] and a PCEP peer		[I-D.ietf-pce-pcep-extension-for-pce-controller] and a PCEP peer
	receives P=1 in the LSP object, it needs to act as per		receives P=1 in the LSP object, it needs to act as per
	[I-D.ietf-pce-pcep-extension-for-pce-controller]:		[I-D.ietf-pce-pcep-extension-for-pce-controller]:
	* Send a PCErr message with Error-Type=19 (Invalid Operation) and		* Send a PCErr message with Error-Type=19 (Invalid Operation) and
	Error-Value=16 (Attempted PCECC operations when PCECC		Error-Value=16 (Attempted PCECC operations when PCECC
	capability was not advertised)		capability was not advertised)
	skipping to change at page 21, line 13 ¶		skipping to change at page 21, line 13 ¶
	EMail: msiva282@gmail.com		EMail: msiva282@gmail.com
	Clarence Filsfils		Clarence Filsfils
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Pegasus Parc		Pegasus Parc
	De kleetlaan 6a, DIEGEM BRABANT 1831		De kleetlaan 6a, DIEGEM BRABANT 1831
	BELGIUM		BELGIUM
	EMail: cfilsfil@cisco.com		EMail: cfilsfil@cisco.com
	Jeff Tantsura		Jeff Tantsura
	Juniper Networks		Microsoft Corporation
	EMail: jefftant.ietf@gmail.com		EMail: jefftant.ietf@gmail.com
	Stefano Previdi		Stefano Previdi
	Huawei Technologies		Huawei Technologies
	EMail: stefano@previdi.net		EMail: stefano@previdi.net
	Cheng Li (editor)		Cheng Li (editor)
	Huawei Technologies		Huawei Technologies
End of changes. 12 change blocks.
	16 lines changed or deleted		18 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/