< draft-ietf-idr-te-lsp-distribution-06.txt		draft-ietf-idr-te-lsp-distribution-07.txt >
	Network Working Group S. Previdi, Ed.		Network Working Group S. Previdi, Ed.
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track J. Dong, Ed.		Intended status: Standards Track J. Dong, Ed.
	Expires: July 10, 2017 M. Chen		Expires: January 2, 2018 M. Chen
	Huawei Technologies		Huawei Technologies
	H. Gredler		H. Gredler
	RtBrick Inc.		RtBrick Inc.
	J. Tantsura		J. Tantsura
	Individual		Individual
	January 6, 2017		July 1, 2017
	Distribution of Traffic Engineering (TE) Policies and State using BGP-LS		Distribution of Traffic Engineering (TE) Policies and State using BGP-LS
	draft-ietf-idr-te-lsp-distribution-06		draft-ietf-idr-te-lsp-distribution-07
	Abstract		Abstract
	This document describes a mechanism to collect the Traffic		This document describes a mechanism to collect the Traffic
	Engineering and Policy information that is locally available in a		Engineering and Policy information that is locally available in a
	router and advertise it into BGP-LS updates. Such information can be		router and advertise it into BGP-LS updates. Such information can be
	used by external components for path computation, re-optimization,		used by external components for path computation, re-optimization,
	service placement, network visualization, etc.		service placement, network visualization, etc.
	Requirements Language		Requirements Language
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 July 10, 2017.		This Internet-Draft will expire on January 2, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Carrying TE Policy Information in BGP . . . . . . . . . . . . 5		2. Carrying TE Policy Information in BGP . . . . . . . . . . . . 5
	2.1. TE Policy Information . . . . . . . . . . . . . . . . . . 5		2.1. TE Policy Information . . . . . . . . . . . . . . . . . . 5
	2.2. TE Policy NLRI . . . . . . . . . . . . . . . . . . . . . 5		2.2. TE Policy NLRI . . . . . . . . . . . . . . . . . . . . . 5
	2.2.1. TE Policy Descriptors . . . . . . . . . . . . . . . . 6		2.2.1. TE Policy Descriptors . . . . . . . . . . . . . . . . 7
	2.3. TE Policy State . . . . . . . . . . . . . . . . . . . . . 12		2.3. TE Policy State . . . . . . . . . . . . . . . . . . . . . 12
	2.3.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . 14		2.3.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . 14
	2.3.2. PCE Objects . . . . . . . . . . . . . . . . . . . . . 15		2.3.2. PCE Objects . . . . . . . . . . . . . . . . . . . . . 15
	2.3.3. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . 15		2.3.3. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . 16
	3. Operational Considerations . . . . . . . . . . . . . . . . . 21		3. Operational Considerations . . . . . . . . . . . . . . . . . 22
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 22		4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 22
	4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 22		4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 23
	4.3. BGP-LS Descriptors TLVs . . . . . . . . . . . . . . . . . 22		4.3. BGP-LS Descriptors TLVs . . . . . . . . . . . . . . . . . 23
	4.4. BGP-LS LSP-State TLV Protocol Origin . . . . . . . . . . 23		4.4. BGP-LS LSP-State TLV Path Origin . . . . . . . . . . . . 23
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 23		4.5. BGP-LS LSP-State TLV Dataplane . . . . . . . . . . . . . 24
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	7.1. Normative References . . . . . . . . . . . . . . . . . . 24		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
	7.2. Informative References . . . . . . . . . . . . . . . . . 25		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		8.1. Normative References . . . . . . . . . . . . . . . . . . 25
			8.2. Informative References . . . . . . . . . . . . . . . . . 26
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	In many network environments, traffic engineering policies are		In many network environments, traffic engineering policies are
	instantiated into various forms:		instantiated into various forms:
	o MPLS Traffic Engineering Label Switched Paths (TE-LSPs).		o MPLS Traffic Engineering Label Switched Paths (TE-LSPs).
	o IP based tunnels (IP in IP, GRE, etc).		o IP based tunnels (IP in IP, GRE, etc).
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 20 ¶
	2. Carrying TE Policy Information in BGP		2. Carrying TE Policy Information in BGP
	2.1. TE Policy Information		2.1. TE Policy Information
	TE Policy information is advertised in BGP UPDATE messages using the		TE Policy information is advertised in BGP UPDATE messages using the
	MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The "Link-		MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The "Link-
	State NLRI" defined in [RFC7752] is extended to carry the TE Policy		State NLRI" defined in [RFC7752] is extended to carry the TE Policy
	information. BGP speakers that wish to exchange TE Policy		information. BGP speakers that wish to exchange TE Policy
	information MUST use the BGP Multiprotocol Extensions Capability Code		information MUST use the BGP Multiprotocol Extensions Capability Code
	(1) to advertise the corresponding (AFI, SAFI) pair, as specified in		(1) to advertise the corresponding (AFI, SAFI) pair, as specified in
	[RFC4760].		[RFC4760]. A new TLV carried in the Link_State Attribute defined in
			[RFC7752] is also defined in order to carry the attributes of a TE
			Policy (Section 2.3).
	The format of "Link-State NLRI" is defined in [RFC7752]. A new "NLRI		The format of "Link-State NLRI" is defined in [RFC7752]. A new "NLRI
	Type" is defined for TE Policy Information as following:		Type" is defined for TE Policy Information as following:
	o NLRI Type: TE Policy NLRI (suggested codepoint value 5, to be		o NLRI Type: TE Policy NLRI (suggested codepoint value 5, to be
	assigned by IANA).		assigned by IANA).
	[RFC7752] defines the BGP-LS NLRI as follows:		[RFC7752] defines the BGP-LS NLRI as follows:
	0 1 2 3		0 1 2 3
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	IANA) is shown in the following figure:		IANA) 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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Protocol-ID |		| Protocol-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier |		| Identifier |
	| (64 bits) |		| (64 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			// Headend (Node Descriptors) //
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// TE Policy Descriptors (variable) //		// TE Policy Descriptors (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Protocol-ID field specifies the signaling protocol of the TE		o Protocol-ID field specifies the component that owns the TE Policy
	Policy. The following Protocol-IDs are defined (suggested values,		state in the advertising node. The following Protocol-IDs are
	to be assigned by IANA) and apply to the TE Policy NLRI:		defined (suggested values, to be assigned by IANA) and apply to
			the TE Policy NLRI:
	+-------------+----------------------------------+		+-------------+----------------------------------+
	| Protocol-ID | NLRI information source protocol |		| Protocol-ID | NLRI information source protocol |
	+-------------+----------------------------------+		+-------------+----------------------------------+
	| 8 | RSVP-TE |		| 8 | RSVP-TE |
	| 9 | Segment Routing |		| 9 | Segment Routing |
	+-------------+----------------------------------+		+-------------+----------------------------------+
	o "Identifier" is an 8 octet value as defined in [RFC7752].		o "Identifier" is an 8 octet value as defined in [RFC7752].
	o Following TE Policy Descriptors are defined:		o "Headend" consists of a Node Descriptor defined in [RFC7752].
			o "TE Policy Descriptors" consists of:
	+-----------+----------------------------------+		+-----------+----------------------------------+
	| Codepoint | Descriptor TLV |		| Codepoint | Descriptor TLV |
	+-----------+----------------------------------+		+-----------+----------------------------------+
	| 267 | Tunnel ID |		| 267 | Tunnel ID |
	| 268 | LSP ID |		| 268 | LSP ID |
	| 269 | IPv4/6 Tunnel Head-end address |		| 269 | IPv4/6 Tunnel Head-end address |
	| 270 | IPv4/6 Tunnel Tail-end address |		| 270 | IPv4/6 Tunnel Tail-end address |
	| 271 | SR TE Policy |		| 271 | SR TE Policy |
	| 272 | Local Cross Connect |		| 272 | Local Cross Connect |
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	interface (incoming or outgoing) in the form of an IPv4 address or an		interface (incoming or outgoing) in the form of an IPv4 address or an
	IPv6 address.		IPv6 address.
	The Interface sub-TLV has the following format:		The Interface sub-TLV has the following format:
	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 | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Interface Address (4 or 16 octets) //
			+-+-+-+-+-+-+-+-+
			| Flags |
			+-+-+-+-+-+-+-+-+
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Local Interface Identifier (4 octets) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			// Interface Address (4 or 16 octets) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	o Type: To be assigned by IANA (suggested value: 1)		o Type: To be assigned by IANA (suggested value: 1)
	o Length: 5 or 17.		o Length: 9 or 21.
	o Flags: 1 octet of flags defined as follows:		o Flags: 1 octet of flags defined as follows:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|I| |		|I| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	where:		where:
	* I-Flag is the Interface flag. When set, the Interface Sub-TLV		* I-Flag is the Interface flag. When set, the Interface Sub-TLV
	describes an incoming interface. If the I-flag is not set,		describes an incoming interface. If the I-flag is not set,
	then the Interface Sub-TLV describes an outgoing interface.		then the Interface Sub-TLV describes an outgoing interface.
			o Local Interface Identifier: a 4 octet identifier.
	o Interface address: a 4 octet IPv4 address or a 16 octet IPv6		o Interface address: a 4 octet IPv4 address or a 16 octet IPv6
	address.		address.
	2.2.1.6.1.2. Forwarding Equivalent Class (FEC) Sub-TLV		2.2.1.6.1.2. Forwarding Equivalent Class (FEC) Sub-TLV
	The FEC sub-TLV is optional and contains the FEC associated to the		The FEC sub-TLV is optional and contains the FEC associated to the
	incoming label.		incoming label.
	The FEC sub-TLV has the following format:		The FEC sub-TLV has the following format:
	skipping to change at page 12, line 45 ¶		skipping to change at page 12, line 52 ¶
	o Prefix: an IPv4 or IPv6 prefix whose mask length is given by the "		o Prefix: an IPv4 or IPv6 prefix whose mask length is given by the "
	Mask Length" field.		Mask Length" field.
	2.3. TE Policy State		2.3. TE Policy State
	A new TLV called "TE Policy State TLV" (codepoint to be assigned by		A new TLV called "TE Policy State TLV" (codepoint to be assigned by
	IANA), is used to describe the characteristics of the TE Policy,		IANA), is used to describe the characteristics of the TE Policy,
	which is carried in the optional non-transitive BGP Attribute		which is carried in the optional non-transitive BGP Attribute
	"LINK_STATE Attribute" defined in [RFC7752]. These TE Policy		"LINK_STATE Attribute" defined in [RFC7752]. These TE Policy
	characteristics include the characteristics and attributs of the		characteristics include the characteristics and attributes of the
	policy, it's dataplane, explicit path, Quality of Service (QoS)		policy, it's dataplane, explicit path, Quality of Service (QoS)
	parameters, route information, the protection mechanisms, etc.		parameters, route information, the protection mechanisms, etc.
	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 | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| Path-origin | Dataplane | RESERVED |
	// TE Policy State Information (variable) //
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TE Policy State TLV		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			// TE Policy State Sub-TLVs (variable) //
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: Suggested value 1158 (to be assigned by IANA)		where:
	TE Policy State Information: Consists of a set of objects as defined		TE Policy State TLV
	in [RFC3209],[RFC3473], [RFC5440] and
	[I-D.previdi-idr-segment-routing-te-policy]. Rather than replicating
	all these objects in this document, the semantics and encodings of
	the objects are reused. These objects are carried in the "TE Policy
	State Information" with the following format.
	0 1 2 3		o Type: Suggested value 1158 (to be assigned by IANA)
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Protocol-Origin| Reserved | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	// Protocol specific TE Policy objects //
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TE Policy State Information		o Length: the total length of the TE Policy State TLV not including
			Type and Length fields.
	The Protocol-Origin field identifies the protocol from which the		o Path-origin: identifies the component (or protocol) from which the
	contained object originated. This allows for objects defined in		contained object originated. This allows for objects defined in
	different protocols to be collected while avoiding the possible code		different components to be collected while avoiding the possible
	collisions among these protocols. Three Protocol-Origins are defined		code collisions among these components. Following path-origin
	in this document (suggested values, to be assigned by IANA)		codepoints are defined in this document (suggested values, to be
			assigned by IANA).
	+----------+------------------+		+----------+------------------+
	| Protocol | LSP Object |		| Code | Path |
	| Origin | Origin |		| Point | Origin |
	+----------+------------------+		+----------+------------------+
	| 1 | RSVP-TE |		| 1 | RSVP-TE |
	| 2 | PCE |		| 2 | PCE |
	| 3 | BGP SR TE Policy |		| 3 | BGP SR TE Policy |
			| 4 | NETCONF |
			| 5 | Static |
	+----------+------------------+		+----------+------------------+
	The 8-bit Reserved field SHOULD be set to 0 on transmission and MUST		o Dataplane: describes to which dataplane the policy is applied to.
	be ignored on receipt.		The following dataplane values are defined:
	The Length field is set to the Length of the value field, which is		+----------+------------------+
	the total length of the contained object.		| Code | Dataplane |
			| Point | |
			+----------+------------------+
			| 1 | MPLS-IPv4 |
			| 2 | MPLS-IPv6 |
			| 3 | IPv6 |
			+----------+------------------+
	The Valued field is a TE Policy object which is defined in the		o RESERVED: 16-bit field field. SHOULD be set to 0 on transmission
	protocol identified by the Protocol-Origin field.		and MUST be ignored on receipt.
			TE Policy State sub-TLVs: objects as defined in [RFC3209],[RFC3473],
			[RFC5440] and [I-D.previdi-idr-segment-routing-te-policy]. Rather
			than replicating all these objects in this document, the semantics
			and encodings of the objects are reused. These objects are carried
			in the "TE Policy State Information" with the following format.
	2.3.1. RSVP Objects		2.3.1. RSVP Objects
	RSVP-TE objects are encoded in the "Value" field of the LSP State TLV		RSVP-TE objects are encoded in the "Value" field of the LSP State TLV
	and consists of MPLS TE LSP objects defined in RSVP-TE [RFC3209]		and consists of MPLS TE LSP objects defined in RSVP-TE [RFC3209]
	[RFC3473]. Rather than replicating all MPLS TE LSP related objects		[RFC3473]. Rather than replicating all MPLS TE LSP related objects
	in this document, the semantics and encodings of the MPLS TE LSP		in this document, the semantics and encodings of the MPLS TE LSP
	objects are re-used. These MPLS TE LSP objects are carried in the		objects are re-used. These MPLS TE LSP objects are carried in the
	LSP State TLV.		LSP State TLV.
	When carrying RSVP-TE objects, the "Protocol-Origin" field is set to		When carrying RSVP-TE objects, the "Path-Origin" field is set to
	"RSVP-TE" (suggested value 1, to be assigned by IANA).		"RSVP-TE".
	The following RSVP-TE Objects are defined:		The following RSVP-TE Objects are defined:
	o SENDER_TSPEC and FLOW_SPEC [RFC2205]		o SENDER_TSPEC and FLOW_SPEC [RFC2205]
	o SESSION_ATTRIBUTE [RFC3209]		o SESSION_ATTRIBUTE [RFC3209]
	o EXPLICIT_ROUTE Object (ERO) [RFC3209]		o EXPLICIT_ROUTE Object (ERO) [RFC3209]
	o ROUTE_RECORD Object (RRO) [RFC3209]		o ROUTE_RECORD Object (RRO) [RFC3209]
	skipping to change at page 14, line 43 ¶		skipping to change at page 15, line 4 ¶
	o ROUTE_RECORD Object (RRO) [RFC3209]		o ROUTE_RECORD Object (RRO) [RFC3209]
	o FAST_REROUTE Object [RFC4090]		o FAST_REROUTE Object [RFC4090]
	o DETOUR Object [RFC4090]		o DETOUR Object [RFC4090]
	o EXCLUDE_ROUTE Object (XRO) [RFC4874]		o EXCLUDE_ROUTE Object (XRO) [RFC4874]
	o SECONDARY_EXPLICIT_ROUTE Object (SERO) [RFC4873]		o SECONDARY_EXPLICIT_ROUTE Object (SERO) [RFC4873]
	o SECONDARY_RECORD_ROUTE (SRRO) [RFC4873]		o SECONDARY_RECORD_ROUTE (SRRO) [RFC4873]
	o LSP_ATTRIBUTES Object [RFC5420]		o LSP_ATTRIBUTES Object [RFC5420]
	o LSP_REQUIRED_ATTRIBUTES Object [RFC5420]		o LSP_REQUIRED_ATTRIBUTES Object [RFC5420]
	o PROTECTION Object [RFC3473][RFC4872][RFC4873]		o PROTECTION Object [RFC3473][RFC4872][RFC4873]
	o ASSOCIATION Object [RFC4872]		o ASSOCIATION Object [RFC4872]
	o PRIMARY_PATH_ROUTE Object [RFC4872]		o PRIMARY_PATH_ROUTE Object [RFC4872]
	o ADMIN_STATUS Object [RFC3473]		o ADMIN_STATUS Object [RFC3473]
	o LABEL_REQUEST Object [RFC3209][RFC3473]		o LABEL_REQUEST Object [RFC3209][RFC3473]
	For the MPLS TE LSP Objects listed above, the corresponding sub-		For the MPLS TE LSP Objects listed above, the corresponding sub-
	objects are also applicable to this mechanism. Note that this list		objects are also applicable to this mechanism. Note that this list
	is not exhaustive, other MPLS TE LSP objects which reflect specific		is not exhaustive, other MPLS TE LSP objects which reflect specific
	characteristics of the MPLS TE LSP can also be carried in the LSP		characteristics of the MPLS TE LSP can also be carried in the LSP
	state TLV.		state TLV.
	2.3.2. PCE Objects		2.3.2. PCE Objects
	PCE objects are encoded in the "Value" field of the MPLS TE LSP State		PCE objects are encoded in the "Value" field of the MPLS TE LSP State
	TLV and consists of PCE objects defined in [RFC5440]. Rather than		TLV and consists of PCE objects defined in [RFC5440]. Rather than
	replicating all MPLS TE LSP related objects in this document, the		replicating all MPLS TE LSP related objects in this document, the
	semantics and encodings of the MPLS TE LSP objects are re-used.		semantics and encodings of the MPLS TE LSP objects are re-used.
	These MPLS TE LSP objects are carried in the LSP State TLV.		These MPLS TE LSP objects are carried in the LSP State TLV.
	When carrying PCE objects, the "Protocol-Origin" field is set to		When carrying PCE objects, the "Path-Origin" field is set to "PCE".
	"PCE" (suggested value 2, to be assigned by IANA).
	The following PCE Objects are defined:		The following PCE Objects are defined:
	o METRIC Object [RFC5440]		o METRIC Object [RFC5440]
	o BANDWIDTH Object [RFC5440]		o BANDWIDTH Object [RFC5440]
	For the MPLS TE LSP Objects listed above, the corresponding sub-		For the MPLS TE LSP Objects listed above, the corresponding sub-
	objects are also applicable to this mechanism. Note that this list		objects are also applicable to this mechanism. Note that this list
	is not exhaustive, other MPLS TE LSP objects which reflect specific		is not exhaustive, other MPLS TE LSP objects which reflect specific
	skipping to change at page 16, line 4 ¶		skipping to change at page 16, line 17 ¶
	Segment Routing Traffic Engineering Policy (SR TE Policy) as		Segment Routing Traffic Engineering Policy (SR TE Policy) as
	described in [I-D.previdi-idr-segment-routing-te-policy]makes use of		described in [I-D.previdi-idr-segment-routing-te-policy]makes use of
	the Tunnel Encapsulation Attribute defined in		the Tunnel Encapsulation Attribute defined in
	[I-D.ietf-idr-tunnel-encaps] and defines following sub-TLVs:		[I-D.ietf-idr-tunnel-encaps] and defines following sub-TLVs:
	o Preference		o Preference
	o Binding SID		o Binding SID
	o Weight		o Weight
	o Segment List		o Segment List
	o Segment		o Segment
	The equivalent sub-TLVs are defined hereafter and carried in the TE		The equivalent sub-TLVs are defined hereafter and carried in the TE
	Policy State TLV. When carrying SR TE Policy objects, the "Protocol-		Policy State TLV. When carrying SR TE Policy objects, the "Path-
	Origin" field is set to "BGP SR TE Policy" (suggested value 3, to be		Origin" field is set to "BGP SR TE Policy".
	assigned by IANA).
	2.3.3.1. Preference Object		2.3.3.1. Preference Object
	The Preference sub-TLV has the following format:		The Preference sub-TLV has the following format:
	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 | Length | Flags | RESERVED |		| Type | Length | Flags | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 23, line 17 ¶		skipping to change at page 23, line 41 ¶
	| Point | | in |		| Point | | in |
	+----------+--------------------------------------+---------------+		+----------+--------------------------------------+---------------+
	| 1158 | TE Policy State TLV | this document |		| 1158 | TE Policy State TLV | this document |
	| 267 | Tunnel ID TLV | this document |		| 267 | Tunnel ID TLV | this document |
	| 268 | LSP ID TLV | this document |		| 268 | LSP ID TLV | this document |
	| 269 | IPv4/6 Tunnel Head-end address TLV | this document |		| 269 | IPv4/6 Tunnel Head-end address TLV | this document |
	| 270 | IPv4/6 Tunnel Tail-end address TLV | this document |		| 270 | IPv4/6 Tunnel Tail-end address TLV | this document |
	| 271 | SR TE Policy Identifier TLV | this document |		| 271 | SR TE Policy Identifier TLV | this document |
	+----------+--------------------------------------+---------------+		+----------+--------------------------------------+---------------+
	4.4. BGP-LS LSP-State TLV Protocol Origin		4.4. BGP-LS LSP-State TLV Path Origin
	This document requests IANA to maintain a new sub-registry under		This document requests IANA to maintain a new sub-registry under
	"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new		"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new
	registry is called "Protocol Origin" and contains the codepoints		registry is called "Path Origin" and contains the codepoints
	allocated to the "Protocol Origin" field defined in Section 2.3. The		allocated to the "Path Origin" field defined in Section 2.3. The
	registry contains the following codepoints (suggested values, to be		registry contains the following codepoints (suggested values, to be
	assigned by IANA):		assigned by IANA):
	+----------+------------------+		+----------+------------------+
	| Protocol | Description |		| Code | Path |
	| Origin | |		| Point | Origin |
	+----------+------------------+		+----------+------------------+
	| 1 | RSVP-TE |		| 1 | RSVP-TE |
	| 2 | PCE |		| 2 | PCE |
	| 3 | BGP SR TE Policy |		| 3 | BGP SR TE Policy |
	+----------+------------------+		| 4 | NETCONF |
			| 5 | Static |
			+----------+------------------+
			4.5. BGP-LS LSP-State TLV Dataplane
			This document requests IANA to maintain a new sub-registry under
			"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new
			registry is called "Dataplane" and contains the codepoints allocated
			to the "dataplane" field defined in Section 2.3. The registry
			contains the following codepoints (suggested values, to be assigned
			by IANA):
			+----------+------------------+
			| Code | Dataplane |
			| Point | |
			+----------+------------------+
			| 1 | MPLS-IPv4 |
			| 2 | MPLS-IPv6 |
			| 3 | IPv6 |
			+----------+------------------+
	5. Security Considerations		5. Security Considerations
	Procedures and protocol extensions defined in this document do not		Procedures and protocol extensions defined in this document do not
	affect the BGP security model. See [RFC6952] for details.		affect the BGP security model. See [RFC6952] for details.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz		The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz
	Khalid, Lou Berger, Acee Lindem, Siva Sivabalan, Arjun Sreekantiah,		Khalid, Lou Berger, Acee Lindem, Siva Sivabalan, Arjun Sreekantiah,
	Dhanendra Jain and Clarence Filsfils for their review and valuable		and Dhanendra Jain for their review and valuable comments.
	comments.
	7. References		7. Contributors
	7.1. Normative References
			The following people have substantially contributed to the editing of
			this document:
			Ketan Talaulikar
			Cisco Systems
			Email: ketant@cisco.com
			Clarence Filsfils
			Cisco Systems
			Email: cfilsfil@cisco.com
			8. References
			8.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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, DOI 10.17487/RFC2205,		Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
	September 1997, <http://www.rfc-editor.org/info/rfc2205>.		September 1997, <http://www.rfc-editor.org/info/rfc2205>.
	skipping to change at page 25, line 22 ¶		skipping to change at page 26, line 27 ¶
	Element (PCE) Communication Protocol (PCEP)", RFC 5440,		Element (PCE) Communication Protocol (PCEP)", RFC 5440,
	DOI 10.17487/RFC5440, March 2009,		DOI 10.17487/RFC5440, March 2009,
	<http://www.rfc-editor.org/info/rfc5440>.		<http://www.rfc-editor.org/info/rfc5440>.
	[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and		[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
	S. Ray, "North-Bound Distribution of Link-State and		S. Ray, "North-Bound Distribution of Link-State and
	Traffic Engineering (TE) Information Using BGP", RFC 7752,		Traffic Engineering (TE) Information Using BGP", RFC 7752,
	DOI 10.17487/RFC7752, March 2016,		DOI 10.17487/RFC7752, March 2016,
	<http://www.rfc-editor.org/info/rfc7752>.		<http://www.rfc-editor.org/info/rfc7752>.
	7.2. Informative References		8.2. Informative References
	[I-D.ietf-idr-tunnel-encaps]		[I-D.ietf-idr-tunnel-encaps]
	Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel		Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
	Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-03		Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-06
	(work in progress), November 2016.		(work in progress), June 2017.
	[I-D.ietf-pce-stateful-pce]		[I-D.ietf-pce-stateful-pce]
	Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP		Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
	Extensions for Stateful PCE", draft-ietf-pce-stateful-		Extensions for Stateful PCE", draft-ietf-pce-stateful-
	pce-18 (work in progress), December 2016.		pce-21 (work in progress), June 2017.
	[I-D.previdi-idr-segment-routing-te-policy]		[I-D.previdi-idr-segment-routing-te-policy]
	Previdi, S., Filsfils, C., Sreekantiah, A., Sivabalan, S.,		Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S.
	Mattes, P., Rosen, E., and S. Lin, "Advertising Segment		Lin, "Advertising Segment Routing Policies in BGP", draft-
	Routing Traffic Engineering Policies in BGP", draft-		previdi-idr-segment-routing-te-policy-07 (work in
	previdi-idr-segment-routing-te-policy-03 (work in		progress), June 2017.
	progress), December 2016.
	[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation		[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
	Element (PCE)-Based Architecture", RFC 4655,		Element (PCE)-Based Architecture", RFC 4655,
	DOI 10.17487/RFC4655, August 2006,		DOI 10.17487/RFC4655, August 2006,
	<http://www.rfc-editor.org/info/rfc4655>.		<http://www.rfc-editor.org/info/rfc4655>.
	[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of		[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
	BGP, LDP, PCEP, and MSDP Issues According to the Keying		BGP, LDP, PCEP, and MSDP Issues According to the Keying
	and Authentication for Routing Protocols (KARP) Design		and Authentication for Routing Protocols (KARP) Design
	Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,		Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
	<http://www.rfc-editor.org/info/rfc6952>.		<http://www.rfc-editor.org/info/rfc6952>.
	Authors' Addresses		Authors' Addresses
	Stefano Previdi (editor)		Stefano Previdi (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Via Del Serafico, 200
	Rome 00142
	Italy
	Email: sprevidi@cisco.com		Email: stefano@previdi.net
	Jie Dong (editor)		Jie Dong (editor)
	Huawei Technologies		Huawei Technologies
	Huawei Campus, No. 156 Beiqing Rd.		Huawei Campus, No. 156 Beiqing Rd.
	Beijing 100095		Beijing 100095
	China		China
	Email: jie.dong@huawei.com		Email: jie.dong@huawei.com
	Mach(Guoyi) Chen		Mach(Guoyi) Chen
End of changes. 44 change blocks.
	94 lines changed or deleted		143 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/