draft-ietf-pce-association-diversity-11.txt		draft-ietf-pce-association-diversity-12.txt
	PCE Working Group S. Litkowski		PCE Working Group S. Litkowski
	Internet-Draft Orange		Internet-Draft S. Sivabalan
	Intended status: Standards Track S. Sivabalan		Intended status: Standards Track Cisco Systems, Inc.
	Expires: April 30, 2020 Cisco Systems, Inc.		Expires: April 30, 2020 C. Barth
	C. Barth
	Juniper Networks		Juniper Networks
	M. Negi		M. Negi
	Huawei Technologies		Huawei Technologies
	October 28, 2019		October 28, 2019
	Path Computation Element Communication Protocol (PCEP) Extension for LSP		Path Computation Element Communication Protocol (PCEP) Extension for LSP
	Diversity Constraint Signaling		Diversity Constraint Signaling
	draft-ietf-pce-association-diversity-11		draft-ietf-pce-association-diversity-12
	Abstract		Abstract
	This document introduces a simple mechanism to associate a group of		This document introduces a simple mechanism to associate a group of
	Label Switched Paths (LSPs) via an extension to the Path Computation		Label Switched Paths (LSPs) via an extension to the Path Computation
	Element (PCE) communication Protocol (PCEP) with the purpose of		Element (PCE) communication Protocol (PCEP) with the purpose of
	computing diverse paths for those LSPs. The proposed extension		computing diverse paths for those LSPs. The proposed extension
	allows a Path Computation Client (PCC) to advertise to a PCE that a		allows a Path Computation Client (PCC) to advertise to a PCE that a
	particular LSP belongs to a particular disjoint-group, thus the PCE		particular LSP belongs to a particular disjoint-group, thus the PCE
	knows that the LSPs in the same group need to be disjoint from each		knows that the LSPs in the same group need to be disjoint from each
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 7		5. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Association Group . . . . . . . . . . . . . . . . . . . . 7		5.1. Association Group . . . . . . . . . . . . . . . . . . . . 7
	5.2. Disjoint TLVs . . . . . . . . . . . . . . . . . . . . . . 8		5.2. Disjoint TLVs . . . . . . . . . . . . . . . . . . . . . . 8
	5.3. Disjointness Objective Functions . . . . . . . . . . . . 10		5.3. Disjointness Objective Functions . . . . . . . . . . . . 10
	5.4. Relationship to SVEC . . . . . . . . . . . . . . . . . . 11		5.4. Relationship to SVEC . . . . . . . . . . . . . . . . . . 12
	5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 12		5.4.1. SVEC and OF . . . . . . . . . . . . . . . . . . . . . 12
	5.6. Disjointness Computation Issues . . . . . . . . . . . . . 15		5.5. P Flag Considerations . . . . . . . . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		5.6. Disjointness Computation Issues . . . . . . . . . . . . . 16
			6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7.1. Association Type . . . . . . . . . . . . . . . . . . . . 17		7.1. Association Type . . . . . . . . . . . . . . . . . . . . 17
	7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 17		7.2. PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . 18
	7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 18		7.3. Objective Functions . . . . . . . . . . . . . . . . . . . 19
	7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 18		7.4. NO-PATH-VECTOR Bit Flags . . . . . . . . . . . . . . . . 19
	7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 19		7.5. PCEP-ERROR Codes . . . . . . . . . . . . . . . . . . . . 19
	8. Manageability Considerations . . . . . . . . . . . . . . . . 19		8. Manageability Considerations . . . . . . . . . . . . . . . . 20
	8.1. Control of Function and Policy . . . . . . . . . . . . . 19		8.1. Control of Function and Policy . . . . . . . . . . . . . 20
	8.2. Information and Data Models . . . . . . . . . . . . . . . 20		8.2. Information and Data Models . . . . . . . . . . . . . . . 20
	8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20		8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20
	8.4. Verification of Correct Operations . . . . . . . . . . . 20		8.4. Verification of Correct Operations . . . . . . . . . . . 20
	8.5. Requirements on Other Protocols . . . . . . . . . . . . . 20		8.5. Requirements on Other Protocols . . . . . . . . . . . . . 21
	8.6. Impact on Network Operations . . . . . . . . . . . . . . 20		8.6. Impact on Network Operations . . . . . . . . . . . . . . 21
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	10.1. Normative References . . . . . . . . . . . . . . . . . . 20		10.1. Normative References . . . . . . . . . . . . . . . . . . 21
	10.2. Informative References . . . . . . . . . . . . . . . . . 21		10.2. Informative References . . . . . . . . . . . . . . . . . 22
	Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 23		Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	[RFC5440] describes the Path Computation Element communication		[RFC5440] describes the Path Computation Element communication
	Protocol (PCEP) which enables the communication between a Path		Protocol (PCEP) which enables the communication between a Path
	Computation Client (PCC) and a Path Control Element (PCE), or between		Computation Client (PCC) and a Path Control Element (PCE), or between
	two PCEs based on the PCE architecture [RFC4655].		two PCEs based on the PCE architecture [RFC4655].
	PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of		PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of
	extensions to PCEP to enable active control of MPLS-TE and GMPLS		extensions to PCEP to enable active control of MPLS-TE and GMPLS
	skipping to change at page 7, line 18 ¶		skipping to change at page 7, line 18 ¶
	o Status: Used to communicate the status of the computed		o Status: Used to communicate the status of the computed
	disjointness.		disjointness.
	5. Protocol Extension		5. Protocol Extension
	5.1. Association Group		5.1. Association Group
	As per [I-D.ietf-pce-association-group], LSPs are associated with		As per [I-D.ietf-pce-association-group], LSPs are associated with
	other LSPs with which they interact by adding them to a common		other LSPs with which they interact by adding them to a common
	association group. As described in [I-D.ietf-pce-association-group]		association group. As described in [I-D.ietf-pce-association-group]
	the association A A group is uniquely identified by the combination		the association group is uniquely identified by the combination of
	of these fields in the ASSOCIATION object:A Association Type,		these fields in the ASSOCIATION object: Association Type, Association
	Association ID, Association Source, and (if present) Global		ID, Association Source, and (if present) Global Association Source or
	Association Source or Extended Association ID.		Extended Association ID.
	This document defines a new Association type, based on the generic		This document defines a new Association type, based on the generic
	Association object:		Association object:
	o Association type = TBD1 Disjoint Association Type (DAT).		o Association type = TBD1 Disjoint Association Type (DAT).
	[I-D.ietf-pce-association-group] specifies the mechanism for the		[I-D.ietf-pce-association-group] specifies the mechanism for the
	capability advertisement of the association types supported by a PCEP		capability advertisement of the association types supported by a PCEP
	speaker by defining a ASSOC-Type-List TLV to be carried within an		speaker by defining a ASSOC-Type-List TLV to be carried within an
	OPEN object. This capability exchange for the Disjointness		OPEN object. This capability exchange for the Disjointness
	Association Type (TBD1) MUST be done before using the disjointness		Association Type (TBD1) MUST be done before using the disjointness
	association. Thus the PCEP speaker MUST include the Disjointness		association. Thus the PCEP speaker MUST include the Disjointness
	Association Type in the ASSOC-Type-List TLV before using the Disjoint		Association Type in the ASSOC-Type-List TLV before using the Disjoint
	Association Group (DAG) in PCEP messages.		Association Group (DAG) in PCEP messages.
	This association type is considered to be both dynamic and operator-		This association type is considered to be both dynamic and operator-
	configured in nature. The association group could be created by the		configured in nature. As per [I-D.ietf-pce-association-group], the
	operator manually on the PCEP peers and the LSPs belonging to this		association group could be created by the operator manually on the
	associations is conveyed via PCEP messages to the PCEP peer; or the		PCEP peers and the LSPs belonging to this associations is conveyed
	association group could be created dynamically by the PCEP speaker		via PCEP messages to the PCEP peer; or the association group could be
	and both the association group information and the LSPs belonging to		created dynamically by the PCEP speaker and both the association
	the association group is conveyed to the PCEP peer. The Operator-		group information and the LSPs belonging to the association group is
	configured Association Range MUST be set for this association-type to		conveyed to the PCEP peer. The Operator-configured Association Range
	mark a range of association identifiers that are used for operator-		MUST be set for this association-type to mark a range of association
	configured associations to avoid any association identifier clash		identifiers that are used for operator-configured associations to
	within the scope of the association source. (Refer to		avoid any association identifier clash within the scope of the
	[I-D.ietf-pce-association-group].)		association source. (Refer to [I-D.ietf-pce-association-group].)
	A disjoint group can have two or more LSPs, but a PCE may be limited		A disjoint group can have two or more LSPs, but a PCE may be limited
	in the number of LSPs it can take into account when computing		in the number of LSPs it can take into account when computing
	disjointness. If a PCE receives more LSPs in the group than it can		disjointness. If a PCE receives more LSPs in the group than it can
	handle in its computation algorithm, it SHOULD apply disjointness		handle in its computation algorithm, it SHOULD apply disjointness
	computation to only a subset of LSPs in the group. The subset of		computation to only a subset of LSPs in the group. The subset of
	disjoint LSPs will be decided by PCE as a local policy. Local		disjoint LSPs will be decided by PCE as a local policy. Local
	polices MAY define the computational behavior for the other LSPs in		polices MAY define the computational behavior for the other LSPs in
	the group. For example, the PCE may provide no path, a shortest		the group. For example, the PCE may provide no path, a shortest
	path, or a constrained path based on relaxing disjointness, etc. The		path, or a constrained path based on relaxing disjointness, etc. The
	disjoint status is informed to the PCC.		disjoint status of the computed path is informed to the PCC via
			DISJOINTNESS-STATUS-TLV (see Section 5.2).
			There are differet types of disjointness identified by the flags (T,
			S, N, L) in the DISJOINTNESS-CONFIGURATION-TLV (see Section 5.2).
	All LSPs in a particular disjoint group MUST use the same combination		All LSPs in a particular disjoint group MUST use the same combination
	of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLVSection 5.2.		of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV. If a PCEP
	If a PCEP peer receives a PCEP messages for LSPs belonging to the		peer receives a PCEP messages for LSPs belonging to the same disjoint
	same disjoint group but having an inconsistent combination of T, S,		group but having an inconsistent combination of T, S, N, L flags, the
	N, L flags, the PCEP peer SHOULD NOT try to add the LSPs in disjoint		PCEP peer MUST NOT try to add the LSPs in disjoint group and MUST
	group and SHOULD reply with a PCErr with Error-type 26 (Association		reply with a PCErr with Error-type 26 (Association Error) and Error-
	Error) and Error- Value 6 (Association information mismatch).		Value 6 (Association information mismatch).
	Associating a particular LSP to multiple disjoint groups is		A particular LSP MAY be associated to multiple disjoint groups, but
	authorized from a protocol perspective, however there is no assurance		in that case, the PCE SHOULD try to consider all the disjoint groups
	that the PCE will be able to compute properly the multi-disjointness		during path computation if possible. Otherwise a local policy MAY
	constraint.		define the computational behavior. If a PCE does not support such a
			path computation it MUST NOT add the LSP into association group and
			return a PCErr with Error-type 26 (Association Error) and Error-Value
			7 (Cannot join the association group).
	5.2. Disjoint TLVs		5.2. Disjoint TLVs
	The disjoint group MUST carry the following TLV:		The disjoint group MUST carry the following TLV:
	o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some		o DISJOINTNESS-CONFIGURATION-TLV: Used to communicate some
	disjointness configuration parameters.		disjointness configuration parameters.
	In addition, the disjoint group MAY carry the following TLV:		In addition, the disjoint group MAY carry the following TLV:
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	to PCC (PCUpd, PCInitiate or PCRep message).		to PCC (PCUpd, PCInitiate or PCRep message).
	o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor-		o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor-
	specific behavioral information, described in [RFC7470].		specific behavioral information, described in [RFC7470].
	o OF-List TLV: Used to communicate the disjointness objective		o OF-List TLV: Used to communicate the disjointness objective
	function. See Section 5.3.		function. See Section 5.3.
	The DISJOINTNESS-CONFIGURATION-TLV is shown in the following figure:		The DISJOINTNESS-CONFIGURATION-TLV is shown in the following figure:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = TBD2 | Length |		| Type = TBD2 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags |T|P|S|N|L|		| Flags |T|P|S|N|L|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: TBD2.		Type: TBD2.
	Length: Fixed value of 4 bytes.		Length: Fixed value of 4 bytes.
	skipping to change at page 9, line 35 ¶		skipping to change at page 9, line 35 ¶
	in common.		in common.
	* S (SRLG diverse) bit: when set, this indicates that the		* S (SRLG diverse) bit: when set, this indicates that the
	computed paths within the disjoint group MUST NOT share any		computed paths within the disjoint group MUST NOT share any
	SRLG (Shared Risk Link Group).		SRLG (Shared Risk Link Group).
	* P (Shortest path) bit: when set, this indicates that the		* P (Shortest path) bit: when set, this indicates that the
	computed path of the LSP SHOULD satisfy all the constraints and		computed path of the LSP SHOULD satisfy all the constraints and
	objective functions first without considering the diversity		objective functions first without considering the diversity
	constraint, this means that all of the LSPs with P flag set in		constraint, this means that all of the LSPs with P flag set in
	the association group are computed first, and then with those		the association group are computed first as if the disjointness
	LSPs fixed, the other LSPs with P flag unset in the association		constraint has not been configured, and then with those LSPs
	group are computed. The role of P flag is further described		fixed, the other LSPs with P flag unset in the association
	with example inA Section 5.5		group are computed by taking into account the disjointness
			constraint. The role of P flag is further described with
			examples in Section 5.5.
	* T (Strict disjointness) bit: when set, if disjoint paths cannot		* T (Strict disjointness) bit: when set, if disjoint paths cannot
	be found, PCE SHOULD return no path for LSPs that could not be		be found, PCE SHOULD return no path for LSPs that could not be
	be disjoint. When unset, the PCE is allowed to relax		be disjoint. When unset, the PCE is allowed to relax
	disjointness by Section 5.5either applying a requested		disjointness by Section 5.5 either applying a requested
	objective function (cf. Section 5.3 below) or using the local		objective function (cf. Section 5.3 below) or using the local
	policy if no objective function is requested (e.g. using a		policy if no objective function is requested (e.g. using a
	lower disjoint type (link instead of node) or fully relaxing		lower disjoint type (link instead of node) or fully relaxing
	disjointness constraint). Further see Section 5.6 for details.		disjointness constraint). Further see Section 5.6 for details.
	* Unassigned bits are considered reserved. They MUST be set to 0		* Unassigned bits are considered reserved. They MUST be set to 0
	on transmission and MUST be ignored on receipt.		on transmission and MUST be ignored on receipt.
	If a PCEP speaker receives a disjoint-group without DISJOINTNESS-		If a PCEP speaker receives a disjoint-group without DISJOINTNESS-
	CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6		CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6
	(Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS-		(Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS-
	CONFIGURATION-TLV missing).		CONFIGURATION-TLV missing).
	The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS-		The DISJOINTNESS-STATUS-TLV uses the same format as the DISJOINTNESS-
	CONFIGURATION-TLV with a different type TBD3 (in the TLV). The L, N,		CONFIGURATION-TLV with a different type TBD3 (in the TLV). The L, N,
	and S flags are set if the respective disjointness criterion was		and S flags are set if the respective disjointness criterion was
	requested and the computed paths meet it. The P flag is set to		requested and the computed paths meet it. The P flag indicates that
	indicate that the computed path is the shortest.		the computed path is the shortest path (computed first without taking
			disjointness constraints into consideration, but considering other
			constraints).
	The T flag has no meaning in the DISJOINTNESS-STATUS-TLV and MUST NOT		The T flag has no meaning in the DISJOINTNESS-STATUS-TLV and MUST NOT
	be set while sending and MUST be ignored on receipt.		be set while sending and MUST be ignored on receipt.
	Any document defining a new flag for the DISJOINTNESS-CONFIGURATION-		Any document defining a new flag for the DISJOINTNESS-CONFIGURATION-
	TLV automatically defines a new flag A A with the same name and in		TLV automatically defines a new flag with the same name and in the
	the same location in DISJOINTNESS-STATUS-TLV; the semantics of the		same location in DISJOINTNESS-STATUS-TLV; the semantics of the flag
	flag in A A DISJOINTNESS-STATUS-TLV MUST be specified in the		in DISJOINTNESS-STATUS-TLV MUST be specified in the document that
	document that specifies the flag in DISJOINTNESS-CONFIGURATION-TLV.		specifies the flag in DISJOINTNESS-CONFIGURATION-TLV.
	5.3. Disjointness Objective Functions		5.3. Disjointness Objective Functions
	An objective function (OF) MAY be applied to the disjointness		An objective function (OF) MAY be applied to the disjointness
	computation to drive the PCE computation behavior. In this case, the		computation to drive the PCE computation behavior. In this case, the
	OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the		OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the
	Association Group Object. Whereas the PCEP OF-List TLV allows		Association Group Object. Whereas the PCEP OF-List TLV allows
	multiple OF-codes inside the TLV, a sender SHOULD include a single		multiple OF-codes inside the TLV, a sender SHOULD include a single
	OF-code in the OF-List TLV when included in the Association Group,		OF-code in the OF-List TLV when included in the Association Group,
	and the receiver MUST consider the first OF-code only and ignore		and the receiver MUST consider the first OF-code only and ignore
	skipping to change at page 10, line 49 ¶		skipping to change at page 10, line 51 ¶
	MSL		MSL
	* Name: Minimize the number of shared (common) Links.		* Name: Minimize the number of shared (common) Links.
	* Objective Function Code: TBD4		* Objective Function Code: TBD4
	* Description: Find a set of paths such that it passes through the		* Description: Find a set of paths such that it passes through the
	least number of shared (common) links.		least number of shared (common) links.
			* A network comprises a set of N links {Li, (i=1...N)}.
			* A path P passes through K links {Lpi,(i=1...K)}.
			* A set of paths {P1...Pm} have L links that are common to more
			than one path {Lpi,(i=1...L)}.
			* Find a set of paths such that the value of L is minimized.
	MSS		MSS
	* Name: Minimize the number of shared (common) SRLGs.		* Name: Minimize the number of shared (common) SRLGs.
	* Objective Function Code: TBD5		* Objective Function Code: TBD5
	* Description: Find a set of paths such that it passes through the		* Description: Find a set of paths such that it passes through the
	least number of shared (common) SRLGs.		least number of shared (common) SRLGs.
			* A network comprises a set of N links {Li, (i=1...N)}.
			* A path P passes through K links {Lpi,(i=1...K)} belonging to
			unique M SRLGs {Spi,(i=1..M)}.
			* A set of paths {P1...Pm} have L SRLGs that are common to more
			than one path {Spi,(i=1...L)}.
			* Find a set of paths such that the value of L is minimized.
	MSN		MSN
	* Name: Minimize the number of shared (common) Nodes.		* Name: Minimize the number of shared (common) Nodes.
	* Objective Function Code: TBD6		* Objective Function Code: TBD6
	* Description: Find a set of paths such that they pass through the		* Description: Find a set of paths such that they pass through the
	least number of shared (common) nodes.		least number of shared (common) nodes.
			* A network comprises a set of N nodes {Ni, (i=1...N)}.
			* A path P passes through K nodes {Npi,(i=1...K)}.
			* A set of paths {P1...Pm} have L nodes that are common to more
			than one path {Npi,(i=1...L)}.
			* Find a set of paths such that the value of L is minimized.
	If the OF-list TLV is included in the Association Object, the OF-code		If the OF-list TLV is included in the Association Object, the OF-code
	inside the OF Object MUST include one of the disjoint OFs defined in		inside the OF Object MUST include one of the disjoint OFs defined in
	this document. If this condition is not met, the PCEP speaker MUST		this document. If this condition is not met, the PCEP speaker MUST
	respond with a PCErr message with Error-Type=10 (Reception of an		respond with a PCErr message with Error-Type=10 (Reception of an
	invalid object) and Error-Value=TBD9 (Incompatible OF code).		invalid object) and Error-Value=TBD9 (Incompatible OF code).
	5.4. Relationship to SVEC		5.4. Relationship to SVEC
	[RFC5440] defines a mechanism for the synchronization of a set of		[RFC5440] defines a mechanism for the synchronization of a set of
	path computation requests by using the SVEC object, that specifies		path computation requests by using the SVEC object, that specifies
	the list of synchronized requests that can either be dependent or		the list of synchronized requests that can either be dependent or
	independent. The SVEC object identify the relationship between the		independent. The SVEC object identifies the relationship between the
	set of path computation requests, identified by 'Request-ID-number'		set of path computation requests, identified by 'Request-ID-number'
	in RP (Request Parameters) object. [RFC6007] further clarified the		in RP (Request Parameters) object. [RFC6007] further clarified the
	use of the SVEC list for synchronized path computations when		use of the SVEC list for synchronized path computations when
	computing dependent requests as well as described a number of usage		computing dependent requests as well as described a number of usage
	scenarios for SVEC lists within single-domain and multi-domain		scenarios for SVEC lists within single-domain and multi-domain
	environments.		environments.
	The SVEC object includes a Flags field that indicates the potential		The SVEC object includes a Flags field that indicates the potential
	dependency between the set of path computation request in a similar		dependency between the set of path computation requests in a similar
	way as the Flags field in the TLVs defined in this document. The		way as the Flags field in the TLVs defined in this document. The
	path computation request in the PCReq message MAY use both the SVEC		path computation request in the PCReq message MAY use both the SVEC
	and ASSOCIATION objects to identify the related path computation		and ASSOCIATION objects to identify the related path computation
	request as well as the diversity association group. The PCE MUST try		request as well as the DAG. The PCE MUST try to find a path that
	to find a path that meets both the constraints. It is possible that		meets both the constraints. It is possible that the diversity
	the diversity requirement in the association group is different from		requirement in the association group is different from the one in the
	the one in the SVEC object. The PCE MUST consider both the objects		SVEC object. The PCE MUST consider both the objects as per the
	as per the processing rules and aim to find a path that meets both of		processing rules and aim to find a path that meets both of these
	these constraints. In case no such path is possible, the PCE MUST		constraints. In case no such path is possible, the PCE MUST send a
	send a path computation reply (PCRep) with a NO-PATH object		path computation reply (PCRep) with a NO-PATH object indicating path
	indicating path computation failure as per [RFC5440].		computation failure as per [RFC5440]. It should be noted that the
			LSPs in the association group can be fully same or partially
			overlapping with the LSPs grouped by the SVEC object in PCReq
			message.
	[RFC5440] uses SVEC diversity flag for node, link or SRLG to describe		Some examples of usage are listed below:
	the potential disjointness between the set of path computation
	requests used in PCEP protocol.		o PCReq with SVEC object with node-diverse bit=1 (LSP1,LSP2) and DAG
			with S=1 (LSP1,LSP2) - both node and SRLG diverse path between
			LSP1, LSP2.
			o PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG
			with L=1 (LSP1,LSP3) - link diverse paths between LSP1, LSP2,
			LSP3. But any future change in LSP2 will have no impact.
			5.4.1. SVEC and OF
	This document defines three new OF-codes Section 5.3 to maximize		This document defines three new OF-codes Section 5.3 to maximize
	diversity as much as possible, in other words, new OF-codes allow		diversity as much as possible, in other words, new OF-codes allow
	specification of minimization of common A A shared resources (Node,		specification of minimization of common shared resources (Node, Link
	Link or SRLG) among a set of paths during path computation.		or SRLG) among a set of paths during path computation.
	It may be interesting to note that the diversity flags in the SVEC		It may be interesting to note that the diversity flags in the SVEC
	object and OF for diversity can be used together. Some examples of		object and OF for diversity can be used together. Some examples of
	usage are listed below:		usage are listed below:
	o SVEC object with node-diverse bit=1 - ensure full node-diversity.		o SVEC object with node-diverse bit=1 - ensure full node-diversity.
	o SVEC object with node-diverse bit=1 and OF=MSS - full node diverse		o SVEC object with node-diverse bit=1 and OF=MSS - full node diverse
	with as much as SRLG-diversity as possible.		with as much as SRLG-diversity as possible.
	skipping to change at page 12, line 42 ¶		skipping to change at page 13, line 35 ¶
	however this specification does not prohibit redundant constraints		however this specification does not prohibit redundant constraints
	while using "SVEC object" and "OF" together for diversity.		while using "SVEC object" and "OF" together for diversity.
	5.5. P Flag Considerations		5.5. P Flag Considerations
	As mentioned in Section 5.2, the P flag (when set) indicates that the		As mentioned in Section 5.2, the P flag (when set) indicates that the
	computed path of the LSP SHOULD satisfies all constraints and		computed path of the LSP SHOULD satisfies all constraints and
	objective functions first without considering the diversity		objective functions first without considering the diversity
	constraint.		constraint.
	This means that an LSP with P flag set should be placed as if the		This means that an LSP with P flag set should be placed first as if
	disjointness constraint has not been configured, while the other LSPs		the disjointness constraint has not been configured, while the other
	in the association with P flag unset should be placed by taking into		LSPs in the association with P flag unset should be placed by taking
	account the disjointness constraint. Setting P flag changes the		into account the disjointness constraint. Setting P flag changes the
	relationship between LSPs to a one-sided relationship (LSP 1 with P=0		relationship between LSPs to a one-sided relationship (LSP 1 with P=0
	depends of LSP 2 with P=1, but LSP 2 with P=1 does not depend of LSP		depends of LSP 2 with P=1, but LSP 2 with P=1 does not depend of LSP
	1 with P=0). Multiple LSPs in the same disjoint group may have the P		1 with P=0). Multiple LSPs in the same disjoint group may have the P
	flag set. In such a case, those LSPs may not be disjoint from each		flag set. In such a case, those LSPs may not be disjoint from each
	other but will be disjoint from others LSPs in the group that have		other but will be disjoint from other LSPs in the group that have the
	the P flag unset.		P flag unset.
	This could be required in some primary/backup scenarios where the		This could be required in some primary/backup scenarios where the
	primary path should use the more optimal path available (taking into		primary path should use the more optimal path available (taking into
	account the other constraints). When disjointness is computed, it is		account the other constraints). When disjointness is computed, it is
	important for the algorithm to know that it should try to optimize		important for the algorithm to know that it should try to optimize
	the path of one or more LSPs in the disjoint group (for instance the		the path of one or more LSPs in the disjoint group (for instance the
	primary path) while other paths are allowed to be costlier (compared		primary path) while other paths are allowed to be costlier (compared
	to a similar path without the disjointness constraint). Without such		to a similar path without the disjointness constraint). Without such
	a hint, the disjointness algorithm may set a path for all LSPs that		a hint, the disjointness algorithm may set a path for all LSPs that
	may not completely fulfill the customer's requirement.		may not completely fulfill the customer's requirement.
	skipping to change at page 17, line 15 ¶		skipping to change at page 17, line 37 ¶
	Also, as stated in [I-D.ietf-pce-association-group], much of the		Also, as stated in [I-D.ietf-pce-association-group], much of the
	information carried in the Disjointness Association object, as per		information carried in the Disjointness Association object, as per
	this document is not extra sensitive. It often reflects information		this document is not extra sensitive. It often reflects information
	that can also be derived from the LSP Database, but association		that can also be derived from the LSP Database, but association
	provides a much easier grouping of related LSPs and messages. The		provides a much easier grouping of related LSPs and messages. The
	disjointness association could provide an adversary with the		disjointness association could provide an adversary with the
	opportunity to eavesdrop on the relationship between the LSPs.		opportunity to eavesdrop on the relationship between the LSPs.
	Thus securing the PCEP session using Transport Layer Security (TLS)		Thus securing the PCEP session using Transport Layer Security (TLS)
	[RFC8253], as per the recommendations and best current practices in		[RFC8253], as per the recommendations and best current practices in
	[RFC7525], is RECOMMENDED.		BCP 195 [RFC7525], is RECOMMENDED.
	7. IANA Considerations		7. IANA Considerations
	7.1. Association Type		7.1. Association Type
	This document defines a new Association type, originally described in		This document defines a new Association type, originally described in
	[I-D.ietf-pce-association-group]. IANA is requested to make the		[I-D.ietf-pce-association-group]. IANA is requested to make the
	assignment of a new value for the sub-registry "ASSOCIATION Type		assignment of a new value for the sub-registry "ASSOCIATION Type
	Field" (request to be created in [I-D.ietf-pce-association-group]),		Field" (request to be created in [I-D.ietf-pce-association-group]),
	as follows:		as follows:
	skipping to change at page 20, line 46 ¶		skipping to change at page 21, line 25 ¶
	LSPs that can belong to a DAG.		LSPs that can belong to a DAG.
	9. Acknowledgments		9. Acknowledgments
	A special thanks to authors of [I-D.ietf-pce-association-group], this		A special thanks to authors of [I-D.ietf-pce-association-group], this
	document borrow some of the text from it. Authors would also like to		document borrow some of the text from it. Authors would also like to
	thank Adrian Farrel and Julien Meuric for the valuable comments.		thank Adrian Farrel and Julien Meuric for the valuable comments.
	Thanks to Emmanuel Baccelli for RTGDIR reviews.		Thanks to Emmanuel Baccelli for RTGDIR reviews.
			Thanks to Dale Worley for a detailed GENART review.
	10. References		10. References
	10.1. Normative References		10.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,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	skipping to change at page 23, line 18 ¶		skipping to change at page 24, line 18 ¶
	Huawei Technologies		Huawei Technologies
	Divyashree Techno Park, Whitefield		Divyashree Techno Park, Whitefield
	Bangalore, Karnataka 560066		Bangalore, Karnataka 560066
	India		India
	EMail: dhruv.ietf@gmail.com		EMail: dhruv.ietf@gmail.com
	Authors' Addresses		Authors' Addresses
	Stephane Litkowski		Stephane Litkowski
	Orange		Cisco Systems, Inc.
	EMail: stephane.litkowski@orange.com		EMail: slitkows.ietf@gmail.com
	Siva Sivabalan		Siva Sivabalan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	2000 Innovation Drive		2000 Innovation Drive
	Kanata, Ontario K2K 3E8		Kanata, Ontario K2K 3E8
	Canada		Canada
	EMail: msiva@cisco.com		EMail: msiva@cisco.com
	Colby Barth		Colby Barth
End of changes. 31 change blocks.
	84 lines changed or deleted		135 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/