< draft-ietf-idr-te-lsp-distribution-03.txt		draft-ietf-idr-te-lsp-distribution-04.txt >
	Network Working Group J. Dong		Network Working Group J. Dong
	Internet-Draft M. Chen		Internet-Draft M. Chen
	Intended status: Standards Track Huawei Technologies		Intended status: Standards Track Huawei Technologies
	Expires: November 8, 2015 H. Gredler		Expires: June 5, 2016 H. Gredler
	Juniper Networks, Inc.		Individual Contributor
	S. Previdi		S. Previdi
	Cisco Systems, Inc.		Cisco Systems, Inc.
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	May 7, 2015		December 3, 2015
	Distribution of MPLS Traffic Engineering (TE) LSP State using BGP		Distribution of MPLS Traffic Engineering (TE) LSP State using BGP
	draft-ietf-idr-te-lsp-distribution-03		draft-ietf-idr-te-lsp-distribution-04
	Abstract		Abstract
	This document describes a mechanism to collect the Traffic		This document describes a mechanism to collect the Traffic
	Engineering (TE) LSP information using BGP. Such information can be		Engineering (TE) LSP information using BGP. Such information can be
	used by external components for path reoptimization, service		used by external components for path reoptimization, service
	placement and network visualization.		placement, and network visualization.
	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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	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
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 November 8, 2015.		This Internet-Draft will expire on June 5, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	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 LSP State Information in BGP . . . . . . . . . . . . 4		2. Carrying LSP State Information in BGP . . . . . . . . . . . . 4
	2.1. LSP Identifier Information . . . . . . . . . . . . . . . 4		2.1. MPLS TE LSP Information . . . . . . . . . . . . . . . . . 4
	2.2. LSP State Information . . . . . . . . . . . . . . . . . . 6		2.2. IPv4/IPv6 MPLS TE LSP NLRI . . . . . . . . . . . . . . . 5
	3. Operational Considerations . . . . . . . . . . . . . . . . . 7		2.2.1. MPLS TE LSP Descriptors . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		2.3. LSP State Information . . . . . . . . . . . . . . . . . . 8
	4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 8		2.3.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . 10
	4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 8		2.3.2. PCE Objects . . . . . . . . . . . . . . . . . . . . . 11
	4.3. BGP-LS Instance-IDs . . . . . . . . . . . . . . . . . . . 9		2.3.3. SR Encap TLVs . . . . . . . . . . . . . . . . . . . . 11
	4.4. BGP-LS Attribute TLVs . . . . . . . . . . . . . . . . . . 9		3. Operational Considerations . . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . 9		4.3. BGP-LS Descriptors TLVs . . . . . . . . . . . . . . . . . 13
	7.2. Informative References . . . . . . . . . . . . . . . . . 11		4.4. BGP-LS LSP-State TLV Protocol Origin . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
			6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
			7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
			7.1. Normative References . . . . . . . . . . . . . . . . . . 14
			7.2. Informative References . . . . . . . . . . . . . . . . . 15
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	In some network environments, the states of established Multi-		In some network environments, the state of established Multi-Protocol
	Protocol Label Switching (MPLS) Traffic Engineering (TE) Label		Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
	Switched Paths (LSPs) in the network are required by some components		(LSPs) and Tunnels in the network are required by components external
	external to the network domain. Usually this information is directly		to the network domain. Usually this information is directly
	maintained by the ingress Label Edge Routers (LERs) of the MPLS TE		maintained by the ingress Label Edge Routers (LERs) of the MPLS TE
	LSPs.		LSPs.
	One example of using the LSP information is stateful Path Computation		One example of using the LSP information is stateful Path Computation
	Element (PCE) [I-D.ietf-pce-stateful-pce], which could provide		Element (PCE) [I-D.ietf-pce-stateful-pce], which could provide
	benefits in path reoptimization . While some extensions are proposed		benefits in path reoptimization. While some extensions are proposed
	in Path Computation Element Communication Protocol (PCEP) for the		in Path Computation Element Communication Protocol (PCEP) for the
	Path Computation Clients (PCCs) to report the LSP states to the PCE,		Path Computation Clients (PCCs) to report the LSP states to the PCE,
	this mechanism may not be applicable in a management-based PCE		this mechanism may not be applicable in a management-based PCE
	architecture as specified in section 5.5 of [RFC4655]. As		architecture as specified in section 5.5 of [RFC4655]. As
	illustrated in the figure below, the PCC is not an LSR in the routing		illustrated in the figure below, the PCC is not an LSR in the routing
	domain, thus the head-end nodes of the TE-LSP may not implement the		domain, thus the head-end nodes of the TE-LSPs may not implement the
	PCEP protocol. In this case some general mechanism to collect the		PCEP protocol. In this case a general mechanism to collect the TE-
	TE-LSP states from the ingress LERs is needed. This document		LSP states from the ingress LERs is needed. This document proposes
	proposes an LSP state collection mechanism complementary to the		an LSP state collection mechanism complementary to the mechanism
	mechanism defined in [I-D.ietf-pce-stateful-pce].		defined in [I-D.ietf-pce-stateful-pce].
	-----------		-----------
	| ----- |		| ----- |
	Service | | TED |<-+----------->		Service | | TED |<-+----------->
	Request | ----- | TED synchronization		Request | ----- | TED synchronization
	| | | | mechanism (for example,		| | | | mechanism (for example,
	v | | | routing protocol)		v | | | routing protocol)
	------------- Request/ | v |		------------- Request/ | v |
	| | Response| ----- |		| | Response| ----- |
	| NMS |<--------+> | PCE | |		| NMS |<--------+> | PCE | |
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 41 ¶
	Request |		Request |
	v		v
	---------- Signaling ----------		---------- Signaling ----------
	| Head-End | Protocol | Adjacent |		| Head-End | Protocol | Adjacent |
	| Node |<---------->| Node |		| Node |<---------->| Node |
	---------- ----------		---------- ----------
	Figure 1. Management-Based PCE Usage		Figure 1. Management-Based PCE Usage
	In networks with composite PCE nodes as specified in section 5.1 of		In networks with composite PCE nodes as specified in section 5.1 of
	[RFC4655], the PCE is implemented on several routers in the network,		[RFC4655], PCE is implemented on several routers in the network, and
	and the PCCs in the network can use the mechanism described in		the PCCs in the network can use the mechanism described in
	[I-D.ietf-pce-stateful-pce] to report the LSP information to the PCE		[I-D.ietf-pce-stateful-pce] to report the LSP information to the PCE
	nodes. An external component may further need to collect the LSP		nodes. An external component may also need to collect the LSP
	information from all the PCEs in the network to get a global view of		information from all the PCEs in the network to obtain a global view
	the LSP states in the network.		of the LSP state in the network.
	In multi-area or multi-AS scenarios, each area or AS can have a child		In multi-area or multi-AS scenarios, each area or AS can have a child
	PCE to collect the LSP states of its own domain, in addition a parent		PCE to collect the LSP state in its own domain, in addition, a parent
	PCE needs to collect the LSP information from multiple child PCEs to		PCE needs to collect LSP information from multiple child PCEs to
	obtain a global view of LSPs inside and across the domains involved.		obtain a global view of LSPs inside and across the domains involved.
	In another network scenario, a centralized controller is used for		In another network scenario, a centralized controller is used for
	service placement. Obtaining the TE LSP state information is quite		service placement. Obtaining the TE LSP state information is quite
	important for making appropriate service placement decisions with the		important for making appropriate service placement decisions with the
	purpose of both meeting the application's requirements and utilizing		purpose to both meet the application's requirements and utilize
	the network resource efficiently.		network resources efficiently.
	The Network Management System (NMS) may need to provide global		The Network Management System (NMS) may need to provide global
	visibility of the TE LSPs in the network as part of the network		visibility of the TE LSPs in the network as part of the network
	visualization function.		visualization function.
	BGP has been extended to distribute link-state and traffic		BGP has been extended to distribute link-state and traffic
	engineering information to some external components		engineering information to external components
	[I-D.ietf-idr-ls-distribution]. Using the same protocol to collect		[I-D.ietf-idr-ls-distribution]. Using the same protocol to collect
	other network layer information would be desirable for the external		TE LSP information is desirable for these external components since
	components, which avoids introducing multiple protocols for network		this avoids introducing multiple protocols for network information
	information collection. This document describes a mechanism to		collection. This document describes a mechanism to distribute TE LSP
	distribute the TE LSP information to external components using BGP.		information to external components using BGP.
	2. Carrying LSP State Information in BGP		2. Carrying LSP State Information in BGP
	2.1. LSP Identifier Information		2.1. MPLS TE LSP Information
	The TE LSP Identifier information is advertised in BGP UPDATE		The MPLS TE LSP information is advertised in BGP UPDATE messages
	messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes		using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760].
	[RFC4760]. The "Link-State NLRI" defined in		The "Link-State NLRI" defined in [I-D.ietf-idr-ls-distribution] is
	[I-D.ietf-idr-ls-distribution] is extended to carry the TE LSP		extended to carry the MPLS TE LSP information. BGP speakers that
	Identifier information. BGP speakers that wish to exchange TE LSP		wish to exchange MPLS TE LSP information MUST use the BGP
	information MUST use the BGP Multiprotocol Extensions Capability Code		Multiprotocol Extensions Capability Code (1) to advertise the
	(1) to advertise the corresponding (AFI, SAFI) pair, as specified in		corresponding (AFI, SAFI) pair, as specified in [RFC4760].
	[RFC4760].
	The format of "Link-State NLRI" is defined in		The format of "Link-State NLRI" is defined in
	[I-D.ietf-idr-ls-distribution]. Two new "NLRI Type" are defined for		[I-D.ietf-idr-ls-distribution]. A new "NLRI Type" is defined for
	TE LSP Identifier Information as following:		MPLS TE LSP Information as following:
	o NLRI Type = 5: IPv4 TE LSP NLRI		o NLRI Type: IPv4/IPv6 MPLS TE LSP NLRI (suggested codepoint value
			5, to be assigned by IANA).
	o NLRI Type = 6: IPv6 TE LSP NLRI		[I-D.ietf-idr-ls-distribution] defines the BGP-LS NLRI as follows:
	The IPv4 TE LSP NLRI (NLRI Type = 5) is shown in the following		0 1 2 3
	figure:		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| NLRI Type | Total NLRI Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			// Link-State NLRI (variable) //
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			This document defines a new NLRI-Type and its format: the IPv4/IPv6
			MPLS TE LSP NLRI defined in the following section.
			2.2. IPv4/IPv6 MPLS TE LSP NLRI
			The IPv4/IPv6 MPLS TE LSP NLRI (NLRI Type 5. Suggested value, to be
			assigned by 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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Tunnel Sender Address |		// MPLS TE LSP Descriptors (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Tunnel ID | LSP ID |
			where:
			o Protocol-ID field specifies the type of signaling of the MPLS TE
			LSP. The following Protocol-IDs are defined (suggested values, to
			be assigned by IANA) and apply to the IPv4/IPv6 MPLS TE LSP NLRI:
			+-------------+----------------------------------+
			| Protocol-ID | NLRI information source protocol |
			+-------------+----------------------------------+
			| 7 | RSVP-TE |
			| 8 | Segment Routing |
			+-------------+----------------------------------+
			o "Identifier" is an 8 octet value as defined in
			[I-D.ietf-idr-ls-distribution].
			o Following MPLS TE LSP Descriptors are defined:
			+-----------+----------------------------------+
			| Codepoint | Descriptor TLV |
			+-----------+----------------------------------+
			| 267 | Tunnel ID |
			| 268 | LSP ID |
			| 269 | IPv4/6 Tunnel Head-end address |
			| 270 | IPv4/6 Tunnel Tail-end address |
			| 271 | SR-ENCAP Identifier |
			+-----------+----------------------------------+
			2.2.1. MPLS TE LSP Descriptors
			This sections defines the MPLS TE Descriptors TLVs.
			2.2.1.1. Tunnel Identifier (Tunnel ID)
			The Tunnel Identifier TLV contains the Tunnel ID defined in [RFC3209]
			and has the following format:
			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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Tunnel End-point Address |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. IPv4 TE LSP NLRI		| Tunnel ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The IPv6 TE LSP NLRI (NLRI Type = 6) is shown in the following		where:
	figure:
			o Type: To be assigned by IANA (suggested value: 267)
			o Length: 2 octets.
			o Tunnel ID: 2 octets as defined in [RFC3209].
			2.2.1.2. LSP Identifier (LSP ID)
			The LSP Identifier TLV contains the LSP ID defined in [RFC3209] and
			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
	+-+-+-+-+-+-+-+-+
	| Protocol-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier |		| Type | Length |
	| (64 bits) |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| LSP ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			where:
			o Type: To be assigned by IANA (suggested value: 268)
			o Length: 2 octets.
			o LSP ID: 2 octets as defined in [RFC3209].
			2.2.1.3. IPv4/IPv6 Tunnel Head-End Address
			The IPv4/IPv6 Tunnel Head-End Address TLV contains the Tunnel Head-
			End Address defined in [RFC3209] and has following format:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			// IPv4/IPv6 Tunnel Head-End Address (variable) //
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			where:
			o Type: To be assigned by IANA (suggested value: 269)
			o Length: 4 or 16 octets.
			When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv4
			address, its length is 4 (octets).
			When the IPv4/IPv6 Tunnel Head-end Address TLV contains an IPv6
			address, its length is 16 (octets).
			2.2.1.4. IPv4/IPv6 Tunnel Tail-End Address
			The IPv4/IPv6 Tunnel Tail-End Address TLV contains the Tunnel Tail-
			End Address defined in [RFC3209] and has following format:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			// IPv4/IPv6 Tunnel Tail-End Address (variable) //
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			where:
			o Type: To be assigned by IANA (suggested value: 270)
			o Length: 4 or 16 octets.
			When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv4
			address, its length is 4 (octets).
			When the IPv4/IPv6 Tunnel Tail-end Address TLV contains an IPv6
			address, its length is 16 (octets).
			2.2.1.5. SR-Encap TLV
			The SR-ENCAP TLV contains the Identifier defined in
			[I-D.sreekantiah-idr-segment-routing-te] and has the following
			format:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| SR-ENCAP Identifier |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			where:
			o Type: To be assigned by IANA (suggested value: 271)
			o Length: 4 octets.
			o SR-ENCAP Identifier: 4 octets as defined in
			[I-D.sreekantiah-idr-segment-routing-te].
			2.3. LSP State Information
			A new TLV called "LSP State TLV" (codepoint to be assigned by IANA),
			is used to describe the characteristics of the MPLS TE LSPs, which is
			carried in the optional non-transitive BGP Attribute "LINK_STATE
			Attribute" defined in [I-D.ietf-idr-ls-distribution]. These MPLS TE
			LSP characteristics include the switching technology of the LSP,
			Quality of Service (QoS) parameters, route information, the
			protection mechanisms, etc.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		// LSP State Information (variable) //
	| IPv6 Tunnel Sender Address |
	+ (16 octets) +
	| |
	+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Tunnel ID | LSP ID |
			LSP State TLV
			Type: Suggested value 1158 (to be assigned by IANA)
			LSP State Information: Consists of a set of TE-LSP objects as defined
			in [RFC3209],[RFC3473] and [RFC5440]. Rather than replicating all
			MPLS TE LSP related objects in this document, the semantics and
			encodings of the MPLS TE LSP objects are reused. These MPLS TE LSP
			objects are carried in the "LSP State Information" with the following
			format.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|Protocol-Origin| Reserved | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		// Protocol specific TE-LSP object //
	| IPv6 Tunnel End-point Address |
	+ (16 octets) +
	| |
	+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3. IPv6 TE LSP NLRI
	For IPv4 and IPv6 TE LSP NLRI, the Protocol-ID field specifies the		LSP State Information
	type of signaling of the TE LSP. The following Protocol-IDs applies
	to IPv4/IPv6 TE LSP NLRI:
	+-------------+----------------------------------+		The Protocol-Origin field identifies the protocol from which the
	| Protocol-ID | NLRI information source protocol |		contained MPLS TE LSP object originated. This allows for MPLS TE LSP
	+-------------+----------------------------------+		objects defined in different protocols to be collected while avoiding
	| TBD | RSVP-TE |		the possible code collisions among these protocols. Three Protocol-
	| TBD | Segment Routing |		Origins are defined in this document (suggested values, to be
	+-------------+----------------------------------+		assigned by IANA)
	The 64-Bit 'Identifier' field is used to discriminate between		+----------+--------------+
	instances with different LSP technologies. The default identifier		| Protocol | LSP Object |
	"0" identifies the instance for packet switched LSPs. A new		| Origin | Origin |
	identifier TBD is used to identify the instance of optical layer		+----------+--------------+
	LSPs.		| 1 | RSVP-TE |
			| 2 | PCE |
			| 3 | SR ENCAP |
			+----------+--------------+
	The other fields in the IPv4 TE LSP NLRI and IPv6 TE LSP NLRI are the		The 8-bit Reserved field SHOULD be set to 0 on transmission and
	same as defined in [RFC3209]. When the Protocol-ID is set to Segment		ignored on receipt.
	Routing, the Tunnel ID and LSP ID field SHOULD be filled with the
	source node's locally generated identifiers which can uniquely
	identify a specific SR LSP.
	2.2. LSP State Information		The Length field is set to the Length of the value field, which is
			the total length of the contained MPLS TE LSP object.
	The LSP State TLV is used to describe the characteristics of the TE		The Valued field is a MPLS-TE LSP object which is defined in the
	LSPs, which is carried in the optional non-transitive BGP Attribute		protocol identified by the Protocol-Origin field.
	"LINK_STATE Attribute" defined in [I-D.ietf-idr-ls-distribution].
	The "Value" field of the LSP State TLV corresponds to the format and		2.3.1. RSVP Objects
	semantics of a set of objects defined in [RFC3209], [RFC3473] and
	other extensions for TE LSPs. Rather than replicating all RSVP-TE
	related objects in this document, the semantics and encodings of the
	existing TE LSP objects are re-used. Hence all TE LSP objects are
	regarded as sub-TLVs. The LSP State TLV SHOULD only be used with
	IPv4/IPv6 TE LSP NLRI.
	0 1 2 3		RSVP-TE objects are encoded in the "Value" field of the LSP State TLV
	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		and consists of MPLS TE LSP objects defined in RSVP-TE [RFC3209]
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		[RFC3473]. Rather than replicating all MPLS TE LSP related objects
	| Type | Length |		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
	| |		LSP State TLV.
	~ TE LSP Objects (variable) ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4. LSP State TLV
	Currently the TE LSP Objects that can be carried in the LSP State TLV		When carrying RSVP-TE objects, the "Protocol-Origin" field is set to
	include:		"RSVP-TE" (suggested value 1, to be assigned by IANA).
			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 Record Route 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]
	skipping to change at page 7, line 38 ¶		skipping to change at page 10, line 49 ¶
	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 BANDWIDTH Object [RFC5440]		o LABEL_REQUEST Object [RFC3209][RFC3473]
			For the MPLS TE LSP Objects listed above, the corresponding sub-
			objects are also applicable to this mechanism. Note that this list
			is not exhaustive, other MPLS TE LSP objects which reflect specific
			characteristics of the MPLS TE LSP can also be carried in the LSP
			state TLV.
			2.3.2. PCE Objects
			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
			replicating all MPLS TE LSP related objects 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 LSP State TLV.
			When carrying PCE objects, the "Protocol-Origin" field is set to
			"PCE" (suggested value 2, to be assigned by IANA).
			The following PCE Objects are defined:
	o METRIC Object [RFC5440]		o METRIC Object [RFC5440]
	For the TE LSP Objects listed above, the corresponding subobjects are		o BANDWIDTH Object [RFC5440]
	also applicable to this mechanism. Other TE LSP objects which
	reflect specific states or attributes of the LSP may also be carried		For the MPLS TE LSP Objects listed above, the corresponding sub-
	in the LSP state TLV, which is for further study.		objects are also applicable to this mechanism. Note that this list
			is not exhaustive, other MPLS TE LSP objects which reflect specific
			characteristics of the MPLS TE LSP can also be carried in the LSP
			state TLV.
			2.3.3. SR Encap TLVs
			SR-ENCAP objects are encoded in the "Value" field of the LSP State
			TLV and consists of SR-ENCAP objects defined in
			[I-D.sreekantiah-idr-segment-routing-te]. Rather than replicating
			all MPLS TE LSP related objects 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 LSP State TLV.
			When carrying SR-ENCAP objects, the "Protocol-Origin" field is set to
			"SR-ENCAP" (suggested value 3, to be assigned by IANA).
			The following SR-ENCAP Objects are defined:
			o ERO TLV [I-D.sreekantiah-idr-segment-routing-te]
			o Weight TLV [I-D.sreekantiah-idr-segment-routing-te]
			o Binding SID TLV [I-D.sreekantiah-idr-segment-routing-te]
			For the MPLS TE LSP Objects listed above, the corresponding sub-
			objects are also applicable to this mechanism. Note that this list
			is not exhaustive, other MPLS TE LSP objects which reflect specific
			characteristics of the MPLS TE LSP can also be carried in the LSP
			state TLV.
	3. Operational Considerations		3. Operational Considerations
	The Existing BGP operational procedures apply to this document. No		The Existing BGP operational procedures apply to this document. No
	new operation procedures are defined in this document. The		new operation procedures are defined in this document. The
	operational considerations as specified in		operational considerations as specified in
	[I-D.ietf-idr-ls-distribution] apply to this document.		[I-D.ietf-idr-ls-distribution] apply to this document.
	In general the ingress nodes of the LSPs are responsible for the		In general the ingress nodes of the MPLS TE LSPs are responsible for
	distribution of LSP state information, while other nodes on the LSP		the distribution of LSP state information, while other nodes on the
	path may report the LSP information if needed, e.g. the border		LSP path MAY report the LSP information when needed. For example,
	routers in the inter-domain case, where the ingress node may not have		the border routers in the inter-domain case will also distribute LSP
	the complete information of the end-to-end path.		state information since the ingress node may not have the complete
			information for the end-to-end path.
	4. IANA Considerations		4. IANA Considerations
	IANA is requested to administer the assignment of new values defined		This document requires new IANA assigned codepoints.
	in this document and summarized in this section.
	IANA needs to assign one new TLV type for "LSP State TLV" from the
	registry of BGP-LS Attribute TLVs.
	4.1. BGP-LS NLRI-Types		4.1. BGP-LS NLRI-Types
	IANA maintains a registry called "Border Gateway Protocol - Link		IANA maintains a registry called "Border Gateway Protocol - Link
	State (BGP-LS) Parameters" with a sub-registry called "BGP-LS NLRI-		State (BGP-LS) Parameters" with a sub-registry called "BGP-LS NLRI-
	Types".		Types".
	IANA is requested to assign two new NLRI-Types:		The following codepoints is suggested (to be assigned by IANA):
	+------+---------------------------+---------------+		+------+----------------------------+---------------+
	| Type | NLRI Type | Reference |		| Type | NLRI Type | Reference |
	+------+---------------------------+---------------+		+------+----------------------------+---------------+
	| 5 | IPv4 TE LSP NLRI | this document |		| 5 | IPv4/IPv6 MPLS TE LSP NLRI | this document |
	| 6 | IPv6 TE LSP NLRI | this document |		+------+----------------------------+---------------+
	+------+---------------------------+---------------+
	4.2. BGP-LS Protocol-IDs		4.2. BGP-LS Protocol-IDs
	IANA maintains a registry called "Border Gateway Protocol - Link		IANA maintains a registry called "Border Gateway Protocol - Link
	State (BGP-LS) Parameters" with a sub-registry called "BGP-LS		State (BGP-LS) Parameters" with a sub-registry called "BGP-LS
	Protocol-IDs".		Protocol-IDs".
	IANA is requested to assign two new Protocol-IDs:		The following Protocol-ID codepoints are suggested (to be assigned by
			IANA):
	+-------------+----------------------------------+---------------+		+-------------+----------------------------------+---------------+
	| Protocol-ID | NLRI information source protocol | Reference |		| Protocol-ID | NLRI information source protocol | Reference |
	+-------------+----------------------------------+---------------+		+-------------+----------------------------------+---------------+
	| TBD | RSVP-TE | this document |		| 7 | RSVP-TE | this document |
	| TBD | Segment Routing | this document |		| 8 | Segment Routing | this document |
	+-------------+----------------------------------+---------------+		+-------------+----------------------------------+---------------+
	4.3. BGP-LS Instance-IDs		4.3. BGP-LS Descriptors TLVs
	IANA maintains a registry called "Border Gateway Protocol - Link		IANA maintains a registry called "Border Gateway Protocol - Link
	State (BGP-LS) Parameters" with a sub-registry called "BGP-LS Well-		State (BGP-LS) Parameters" with a sub-registry called "Node Anchor,
	known Instance-IDs".		Link Descriptor and Link Attribute TLVs".
	IANA is requested to assign one new Instance-ID:
	+------------+----------------------------------+---------------+		The following TLV codepoints are suggested (to be assigned by IANA):
	| Identifier | Routing Universe | Reference: |
	+------------+----------------------------------+---------------+
	| TBD | Default Optical Network Topology | this document |
	+------------+----------------------------------+---------------+
	4.4. BGP-LS Attribute TLVs		+----------+--------------------------------------+---------------+
			| TLV Code | Description | Value defined |
			| Point | | in |
			+----------+--------------------------------------+---------------+
			| 1158 | LSP State TLV | this document |
			| 267 | Tunnel ID TLV | this document |
			| 268 | LSP ID TLV | this document |
			| 269 | IPv4/6 Tunnel Head-end address TLV | this document |
			| 270 | IPv4/6 Tunnel Tail-end address TLV | this document |
			| 271 | SR-ENCAP Identifier TLV | this document |
			+----------+--------------------------------------+---------------+
	IANA maintains a registry called "Border Gateway Protocol - Link		4.4. BGP-LS LSP-State TLV Protocol Origin
	State (BGP-LS) Parameters" with a sub-registry called "Node Anchor,
	Link Descriptor and Link Attribute TLVs".
	IANA is requested to assign one new TLV code point:		This document requests IANA to maintain a new sub-registry under
			"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new
			registry is called "Protocol Origin" and contains the codepoints
			allocated to the "Protocol Origin" field defined in Section 2.3. The
			registry contains the following codepoints (suggested values, to be
			assigned by IANA):
	+-----------+---------------------+---------------+-----------------+		+----------+--------------+
	| TLV Code | Description | IS-IS TLV/ | Value defined |		| Protocol | Description |
	| Point | | Sub-TLV | in: |		| Origin | |
	+-----------+---------------------+---------------+-----------------+		+----------+--------------+
	| TBD | LSP State TLV | --- | this document |		| 1 | RSVP-TE |
	+-----------+---------------------+---------------+-----------------+		| 2 | PCE |
			| 3 | SR-ENCAP |
			+----------+--------------+
	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 and Mohammed Abdul Aziz		The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz
	Khalid for their review and valuable comments.		Khalid, Lou Berger, Acee Lindem, Siva Sivabalan and Arjun Sreekantiah
			for their review and valuable comments.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-idr-ls-distribution]		[I-D.ietf-idr-ls-distribution]
	Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.		Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
	Ray, "North-Bound Distribution of Link-State and TE		Ray, "North-Bound Distribution of Link-State and TE
	Information using BGP", draft-ietf-idr-ls-distribution-10		Information using BGP", draft-ietf-idr-ls-distribution-13
	(work in progress), January 2015.		(work in progress), October 2015.
			[I-D.sreekantiah-idr-segment-routing-te]
			Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S.,
			Mattes, P., and J. Marcon, "Segment Routing Traffic
			Engineering Policy using BGP", draft-sreekantiah-idr-
			segment-routing-te-00 (work in progress), October 2015.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2205] Braden, B., 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, September 1997.		Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
			September 1997, <http://www.rfc-editor.org/info/rfc2205>.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
			<http://www.rfc-editor.org/info/rfc3209>.
	[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic		Switching (GMPLS) Signaling Resource ReserVation Protocol-
	Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.		Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
			DOI 10.17487/RFC3473, January 2003,
			<http://www.rfc-editor.org/info/rfc3473>.
	[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute		[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
	Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May		Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
	2005.		DOI 10.17487/RFC4090, May 2005,
			<http://www.rfc-editor.org/info/rfc4090>.
	[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760, January		"Multiprotocol Extensions for BGP-4", RFC 4760,
	2007.		DOI 10.17487/RFC4760, January 2007,
			<http://www.rfc-editor.org/info/rfc4760>.
	[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE		[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
	Extensions in Support of End-to-End Generalized Multi-		Ed., "RSVP-TE Extensions in Support of End-to-End
	Protocol Label Switching (GMPLS) Recovery", RFC 4872, May		Generalized Multi-Protocol Label Switching (GMPLS)
	2007.		Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
			<http://www.rfc-editor.org/info/rfc4872>.
	[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,		[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
	"GMPLS Segment Recovery", RFC 4873, May 2007.		"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
			May 2007, <http://www.rfc-editor.org/info/rfc4873>.
	[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -		[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
	Extension to Resource ReserVation Protocol-Traffic		Extension to Resource ReserVation Protocol-Traffic
	Engineering (RSVP-TE)", RFC 4874, April 2007.		Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874,
			April 2007, <http://www.rfc-editor.org/info/rfc4874>.
	[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.		[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
	Ayyangarps, "Encoding of Attributes for MPLS LSP		Ayyangarps, "Encoding of Attributes for MPLS LSP
	Establishment Using Resource Reservation Protocol Traffic		Establishment Using Resource Reservation Protocol Traffic
	Engineering (RSVP-TE)", RFC 5420, February 2009.		Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
			February 2009, <http://www.rfc-editor.org/info/rfc5420>.
	[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element		[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
	(PCE) Communication Protocol (PCEP)", RFC 5440, March		Element (PCE) Communication Protocol (PCEP)", RFC 5440,
	2009.		DOI 10.17487/RFC5440, March 2009,
			<http://www.rfc-editor.org/info/rfc5440>.
	7.2. Informative References		7.2. Informative References
	[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-11 (work in progress), April 2015.		pce-13 (work in progress), December 2015.
	[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, August 2006.		Element (PCE)-Based Architecture", RFC 4655,
			DOI 10.17487/RFC4655, August 2006,
			<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, May 2013.		Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
			<http://www.rfc-editor.org/info/rfc6952>.
	Authors' Addresses		Authors' Addresses
	Jie Dong		Jie Dong
	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
	Huawei Technologies		Huawei Technologies
	Huawei Campus, No. 156 Beiqing Rd.		Huawei Campus, No. 156 Beiqing Rd.
	Beijing 100095		Beijing 100095
	China		China
	Email: mach.chen@huawei.com		Email: mach.chen@huawei.com
	Hannes Gredler		Hannes Gredler
	Juniper Networks, Inc.		Individual Contributor
	1194 N. Mathilda Ave.		Austria
	Sunnyvale, CA 94089
	US		Email: hannes@gredler.at
	Email: hannes@juniper.net
	Stefano Previdi		Stefano Previdi
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Via Del Serafico, 200		Via Del Serafico, 200
	Rome 00142		Rome 00142
	Italy		Italy
	Email: sprevidi@cisco.com		Email: sprevidi@cisco.com
	Jeff Tantsura		Jeff Tantsura
	Ericsson		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	Email: jeff.tantsura@ericsson.com		Email: jeff.tantsura@ericsson.com
End of changes. 80 change blocks.
	209 lines changed or deleted		445 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/