< draft-dong-pce-discovery-proto-bgp-05.txt		draft-dong-pce-discovery-proto-bgp-06.txt >
	Network Working Group J. Dong		Network Working Group J. Dong
	Internet-Draft M. Chen		Internet-Draft M. Chen
	Intended status: Standards Track D. Dhody		Intended status: Standards Track D. Dhody
	Expires: December 26, 2016 Huawei Technologies		Expires: April 30, 2017 Huawei Technologies
	J. Tantsura		J. Tantsura
	Individual		Individual
	K. Kumaki		K. Kumaki
	KDDI Corporation		KDDI Corporation
	T. Murai		T. Murai
	Furukawa Network Solution Corp.		Furukawa Network Solution Corp.
	June 24, 2016		October 27, 2016
	BGP Extensions for Path Computation Element (PCE) Discovery		BGP Extensions for Path Computation Element (PCE) Discovery
	draft-dong-pce-discovery-proto-bgp-05		draft-dong-pce-discovery-proto-bgp-06
	Abstract		Abstract
	In networks where Path Computation Element (PCE) is used for		In networks where a Path Computation Element (PCE) is used for path
	centralized path computation, it is desirable for the Path		computation, it is desirable for the Path Computation Clients (PCCs)
	Computation Clients (PCCs) to automatically discover a set of PCEs		to discover dynamically and automatically a set of PCEs along with
	and select the suitable ones to establish the PCEP session. RFC 5088		certain information relevant for PCE selection. RFC 5088 and RFC
	and RFC 5089 define the PCE discovery mechanisms based on Interior		5089 define the PCE discovery mechanisms based on Interior Gateway
	Gateway Protocols (IGP). This document describes several scenarios		Protocols (IGP). This document defines extensions to BGP for the
	in which the IGP based PCE discovery mechanisms cannot be used		advertisement of PCE Discovery information. The BGP based PCE
	directly. In such scenarios, BGP might be suitable, thus this		discovery mechanism is complementary to the existing IGP based
	document specifies the BGP extensions for PCE discovery. The BGP		mechanisms.
	based PCE discovery mechanism is complementary to the existing IGP
	based mechanisms.
	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 2, line 6 ¶		skipping to change at page 2, line 4 ¶
	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 April 30, 2017.
	This Internet-Draft will expire on December 26, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 PCE Discovery Information in BGP . . . . . . . . . . 4		2. Carrying PCE Discovery Information in BGP . . . . . . . . . . 3
	2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4		2.1. PCE NLRI . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5		2.1.1. PCE Descriptors . . . . . . . . . . . . . . . . . . . 4
	3. Operational Considerations . . . . . . . . . . . . . . . . . 6		2.2. PCE Attribute TLVs . . . . . . . . . . . . . . . . . . . 5
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		2.2.1. PCE Domain TLV . . . . . . . . . . . . . . . . . . . 6
			2.2.2. Neighbor PCE Domain TLV . . . . . . . . . . . . . . . 6
			3. Operational Considerations . . . . . . . . . . . . . . . . . 7
			4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	In network scenarios where Path Computation Element (PCE) is used for		In networks where a Path Computation Element (PCE) is used for path
	centralized path computation, it is desirable for the Path		computation, it is desirable for the Path Computation Clients (PCCs)
	Computation Clients (PCCs) to automatically discover a set of PCEs		to discover dynamically and automatically a set of PCEs along with
	and select the suitable ones to establish the PCEP session.		certain information relevant for PCE selection. [RFC5088] and
	[RFC5088] and [RFC5089] define the PCE discovery mechanisms based on		[RFC5089] define the PCE discovery mechanisms based on Interior
	Interior Gateway Protocols (IGP).		Gateway Protocols (IGP). When PCCs are LSRs participating in the IGP
			(OSPF or IS-IS), and PCEs are either LSRs or servers also
	The IGP based discovery mechanism requires the PCE participate in the		participating in the IGP, an effective mechanism for PCE discovery
	IGP network, which usually requires that the PCE is directly adjacent		within an IGP routing domain consists of utilizing IGP
	to at least one of the IGP routers in the network. In some scenarios		advertisements.
	such requirement cannot be satisfied. For example, a PCE may need to
	provide path computation service to some subsidiary networks of an
	operator, which typically locate in different geographical region
	(and not IGP adjacent). Also when PCE function is implemented in a
	central server running IGP on individual interfaces to each IGP area
	can be cumbersome.
	The requirement on PCE discovery, as described in [RFC4674], also
	include the automatic discovery of the PCEs in other domains, as it
	is a desirable function in the case of inter-domain path computation.
	The IGP based discovery mechanisms cannot meet such requirement.
	For example, Backward Recursive Path Computation (BRPC) [RFC5441] can
	be used by cooperating PCEs to compute an inter-AS path, in which
	case these cooperating PCEs should be known to each other in advance.
	In this case the PCEs belongs to different AS and do not participate
	in a common IGP, the IGP based discovery mechanisms are not
	applicable.
	Another example is the hierarchical PCE scenario [RFC6805], in which
	the child PCEs need to know the information of the parent PCEs. This
	cannot be achieved via IGP based discovery, as the child PCEs and the
	parent PCE are usually in different domains.
	In some BGP IP-VPN networks, an end-to-end TE LSP between the CEs
	(Customer Edges) of a particular VPN is required [RFC5824]. In this
	case, CEs need the information of the PCE which can perform the CE to
	CE path computation for that VPN. Since the PCE may locate in a VPN
	site different from the site of the requesting CE, the IGP based
	discovery mechanism is not directly applicable, and some BGP based
	discovery mechanism is required to distribute the per-VPN PCE
	information to the VPN sites.
	Since BGP has been extended for north-bound distribution of routing
	and Label Switched Path (LSP) information to PCE [RFC7752]
	[I-D.ietf-idr-te-lsp-distribution] and [I-D.ietf-idr-te-pm-bgp], PCEs
	can obtain the routing information without participating in IGP. In
	this scenario, a new BGP based PCE discovery mechanism is needed.
	This document proposes to extend BGP for PCE discovery in the above		[RFC4674] presents a set of requirements for a PCE discovery
	scenarios. In networks where BGP-LS is used for the north-bound		mechanism. This includes the discovery by a PCC of a set of one or
	routing information distribution to PCE, the BGP based PCE discovery		more PCEs which may potentially be in some other domains. This is a
	can make use of the existing BGP sessions and mechanisms to achieve		desirable function in the case of inter-domain path computation. For
	automatic PCE discovery. Further IGP may be used to redistribute		example, Backward Recursive Path Computation (BRPC) [RFC5441] can be
	remote PCE information, the detailed mechanism is out of the scope of		used by cooperating PCEs to compute an inter-AS path, in which case
	this document. Thus the BGP based PCE discovery is complementary to		the discovery of PCE as well as the domain information is useful.
	the existing IGP based mechanisms.
	+-----------+		BGP has been extended for north-bound distribution of routing and TE
	| PCE |		information to PCE [RFC7752] and [I-D.ietf-idr-te-pm-bgp]. Similary
	+-----------+		this document extends BGP to also carry the PCE discovery
	|		information.
	v
	+-----------+
	| BGP | +-----------+
	| Speaker | | PCE |
	+-----------+ +-----------+
	| | | |
	| | | |
	+---------------+ | +-------------------+ |
	v v v v
	+-----------+ +-----------+ +-----------+
	| BGP | | BGP | | BGP |
	| Speaker | | Speaker | . . . | Speaker |
	| & PCC | | & PCC | | & PCC |
	+-----------+ +-----------+ +-----------+
	Figure 1: BGP for PCE discovery		This document defines extensions to BGP to allow a PCE to advertise
			its location, along with some information useful to a PCC for the PCE
			selection, so as to satisfy dynamic PCE discovery requirements set
			forth in [RFC4674].
	As shown in the network architecture in Figure 1, BGP is used both		This specification contains two parts: definition of a new BGP-LS
	for routing information distribution and for PCE information		NLRI [RFC7752] that describes PCE information and definition of PCE
	discovery. The routing information is collected from the network		Attribute TLVs as part of BGP-LS attributes.
	elements and distributed to PCE, while the PCE discovery information
	is advertised from PCE to PCCs, or among different PCEs. The PCCs
	maybe co-located with the BGP speakers as shown in Figure 1.
	2. Carrying PCE Discovery Information in BGP		2. Carrying PCE Discovery Information in BGP
	2.1. PCE Address Information		2.1. PCE NLRI
	The PCE discovery information is advertised in BGP UPDATE messages		The PCE discovery information is advertised in BGP UPDATE messages
	using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760].		using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760].
	The AFI and SAFI defined in [RFC7752] are re-used. For the PCEs in		The "Link- State NLRI" defined in [RFC7752] is extended to carry the
	public network, the AFI / SAFI pair is 16388 / 71, while for the PCEs		PCE information. BGP speakers that wish to exchange PCE discovery
	of a particular VPN, the AFI / SAFI pair is set to 16388 / 72.		information MUST use the BGP Multiprotocol Extensions Capability Code
			(1) to advertise the corresponding (AFI, SAFI) pair, as specified in
			[RFC4760].
	A new NLRI Type is defined for PCE discovery information as below:		The format of "Link-State NLRI" is defined in [RFC7752]. A new "NLRI
			Type" is defined for PCE Information as following:
	o Type = TBD: PCE Discovery NLRI		o Type = TBD1: PCE NLRI
	The format of PCE Discovery NLRI is shown in the following figure:		The format of PCE NLRI 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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ PCE-Address (4 or 16 octets) ~		~ PCE Descriptors (variable) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. PCE Discovery NLRI		Figure 1. PCE NLRI
	The 'Protocol-ID' field SHOULD be set to the appropriate value which		The 'Protocol-ID' field is defined in [RFC7752], to be set to the
	indicates the source of the PCE discovery information. If BGP		appropriate value that indicates the source of the PCE information.
	speaker and PCE are co-located, the Protocol-ID SHOULD be set to		If BGP speaker and PCE are co-located, the Protocol-ID SHOULD be set
	"Direct". In other cases, it is RECOMMENDED that the Protocol-ID		to "Direct". If PCE information to advertise is configured at the
	value be set to "Static configuration".		BGP speaker, the Protocol-ID SHOULD be set to "Static configuration".
	As defined in [RFC7752], the 64-Bit 'Identifier' field is used to		As defined in [RFC7752], the 64-Bit 'Identifier' field is used to
	identify the "routing universe" where the PCE belongs.		identify the "routing universe" where the PCE belongs.
	2.2. PCE Discovery TLVs		2.1.1. PCE Descriptors
	The detailed PCE discovery information is carried in the BGP-LS		The PCE Descriptor field is a set of Type/Length/Value (TLV)
	attribute [RFC7752] with a new "PCE Discovery TLV", which contains a		triplets. The format of each TLV is as per Section 3.1 of [RFC7752].
	set of sub-TLVs for specific PCE discovery information. The PCE		The PCE Descriptor TLVs uniquely identify a PCE. The following PCE
	Discovery TLV and sub-TLVs SHOULD only be used with the PCE Discovery		descriptor are defined -
	NLRI.
	The format of the PCE Discovery TLV is shown as below:		+-----------+-----------------------+----------+
			| Codepoint | Descriptor TLV | Length |
			+-----------+-----------------------+----------+
			| TBD2 | IPv4 PCE Address | 4 |
			| TBD3 | IPv6 PCE Address | 16 |
			+-----------+-----------------------+----------+
			Table 1: PCE Descriptors
	0 1 2 3		The PCE address TLVs specifies an IP address that can be used to
	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		reach the PCE. The PCE-ADDRESS Sub-TLV defined in [RFC5088] and
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		[RFC5089] is used in the OSPF and IS-IS respectively. The format of
	| Type | Length |		the PCE address TLV are -
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		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
	~ PCE Discovery Sub-TLVs (variable) ~		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| Type=TBD2 | Length=4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3. PCE Discovery TLV		| IPv4 PCE Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The PCE Discovery sub-TLVs are listed as below. The format of the		0 1 2 3
	PCE Discovery sub-TLVs are consistent with the IGP PCED sub-TLVs as		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
	defined in [RFC5088] and [RFC5089]. The PATH-SCOPE sub-TLV MUST		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	always be carried in the PCE Discovery TLV. Other PCE Discovery sub-		| Type=TBD3 | Length=16 |
	TLVs are optional and may facilitate the PCE selection process on the		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	PCCs.		| |
			| IPv6 PCE Address |
			| |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 2. PCE Address TLVs
	Type | Length | Name		When the PCE has both an IPv4 and IPv6 address, both the TLVs MAY be
	------+------------+--------------------------------		included.
	1 | 3 | PATH-SCOPE sub-TLV
	2 | variable | PCE-CAP-FLAGS sub-TLV
	3 | variable | OSPF-PCE-DOMAIN sub-TLV
	4 | variable | IS-IS-PCE-DOMAIN sub-TLV
	5 | variable | OSPF-NEIG-PCE-DOMAIN sub-TLV
	6 | variable | IS-IS-NEIG-PCE-DOMAIN sub-TLV
	More PCE Discovery sub-TLVs may be defined in future. The format and		2.2. PCE Attribute TLVs
	semantic of new PCE Discovery sub-TLVs SHOULD be consistent in BGP
	and IGP based PCE discovery.		PCE Attribute TLVs are TLVs that may be encoded in the BGP-LS
			attribute [RFC7752] with a PCE NLRI. The format of each TLV is as
			per Section 3.1 of [RFC7752]. The format and semantics of the Value
			fields in some PCE Attribute TLVs correspond to the format and
			semantics of the Value fields in IS-IS PCED Sub-TLV, defined in
			[RFC5089]. Other PCE Attribute TLVs are defined in this document.
			The following PCE Attribute TLVs are valid in the BGP-LS attribute
			with a PCE NLRI:
			+-----------+---------------------+--------------+------------------+
			| TLV Code | Description | IS-IS TLV | Reference |
			| Point | | /Sub-TLV | (RFC/Section) |
			+-----------+---------------------+--------------+------------------+
			| TBD4 | Path Scope | 5/2 | [RFC5089]/4.2 |
			| TBD5 | PCE Domain | - | - |
			| TBD6 | Neighbor PCE | - | - |
			| | Domain | | |
			| TBD7 | PCE Capability | 5/5 | [RFC5089]/4.5 |
			+-----------+---------------------+--------------+------------------+
			Table 2: PCE Attribute TLVs
			The format and semantics of Path Scope and PCE capability is as per
			[RFC5089]. The Path Scope TLV is mandatory.
			2.2.1. PCE Domain TLV
			The PCE Domain TLV specifies a PCE-Domain (IGP area and/or AS) where
			the PCE has topology visibility and through which the PCE can compute
			paths.
			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=TBD5 | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			// Domain Sub-TLVs (variable) //
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The length of this TLV is variable. The value contains one or more
			domain sub-TLVs as listed below -
			+--------------------+-------------------+----------+
			| Sub-TLV Code Point | Description | Length |
			+--------------------+-------------------+----------+
			| 512 | Autonomous System | 4 |
			| 514 | OSPF Area-ID | 4 |
			| 1027 | IS-IS Area | Variable |
			| | Identifier | |
			+--------------------+-------------------+----------+
			Multiple sub-TLVs MAY be included, when the PCE has visibility into
			multiple PCE-Domains.
			2.2.2. Neighbor PCE Domain TLV
			The Neighbor PCE Domain TLV specifies a neighbor PCE-Domain (IGP area
			and/or AS) toward which a PCE can compute paths.
			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=TBD6 | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			// Domain Sub-TLVs (variable) //
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			The length of this TLV is variable. The value contains one or more
			domain sub-TLVs as listed above. Multiple sub-TLVs MAY be included,
			when the PCE can compute paths towards several neighbor PCE-Domains.
	3. Operational Considerations		3. Operational Considerations
	Existing BGP operational procedures apply to the advertisement of PCE		Existing BGP-LS operational procedures apply to the advertisement of
	discovery information. This information is treated as pure		PCE information as per [RFC7752]. This information is treated as
	application level data which has no immediate impact on forwarding		pure application level data which has no immediate impact on
	states. Normal BGP path selection can be applied to PCE Discovery		forwarding states. The PCE information SHOULD be advertised only to
	NLRI only for the information propagation in the network, while on		the domains where such information is allowed to be used. This can
	PCCs the PCE selection is based on the information carried in the PCE		be achieved by policy control on the ASBRs.
	Discovery TLV. The PCE discovery information SHOULD be advertised
	only to the domains where such information is allowed to be used.
	This can be achieved by policy control on the ASBRs.
	The PCE discovery information is considered relatively stable and		The PCE information is considered relatively stable and does not
	does not change frequently, thus this information will not bring		change frequently, thus this information will not bring significant
	significant impact on the amount of BGP updates in the network.		impact on the amount of BGP updates in the network.
	4. IANA Considerations		4. IANA Considerations
	IANA needs to assign a new NLRI Type for 'PCE Discovery NLRI' from		IANA needs to assign a new NLRI Type for 'PCE NLRI' from the "BGP-LS
	the "BGP-LS NLRI-Types" registry.		NLRI-Types" registry.
	IANA needs to assign a new TLV code point for 'PCE Discovery TLV'		IANA needs to assign new TLV code point as per Table 1 and 2 from the
	from the "node anchor, link descriptor and link attribute TLVs"		"BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
	registry.		Attribute TLVs" registry.
	IANA needs to create a new registry for "PCE Discovery Sub-TLVs".		[Editor's Note - Check if name of the registry should be changes with
	The registry will be initialized as shown in section 2.2 of this		following instructions - Further IANA is requested to rename the
	document.		registry as "BGP-LS Node Descriptor, Link Descriptor, Prefix
			Descriptor, PCE Descriptor, and Attribute TLVs".]
	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 the 'Security Considerations'		affect the BGP security model. See the 'Security Considerations'
	section of [RFC4271] for a discussion of BGP security. Also refer to		section of [RFC4271] for a discussion of BGP security. Also refer to
	[RFC4272] and [RFC6952] for analysis of security issues for BGP.		[RFC4272] and [RFC6952] for analysis of security issues for BGP.
			Existing BGP-LS security considerations as per [RFC7752] continue to
			apply.
	6. Contributors		6. Contributors
	The following individuals gave significant contributions to this		The following individuals gave significant contributions to this
	document:		document:
	Takuya Miyasaka		Takuya Miyasaka
	KDDI Corporation		KDDI Corporation
	ta-miyasaka@kddi.com		ta-miyasaka@kddi.com
	7. Acknowledgements		7. Acknowledgements
	skipping to change at page 8, line 18 ¶		skipping to change at page 9, line 7 ¶
	January 2008, <http://www.rfc-editor.org/info/rfc5089>.		January 2008, <http://www.rfc-editor.org/info/rfc5089>.
	[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>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-idr-te-lsp-distribution]
	Dong, J., Chen, M., Gredler, H., Previdi, S., and J.
	Tantsura, "Distribution of MPLS Traffic Engineering (TE)
	LSP State using BGP", draft-ietf-idr-te-lsp-
	distribution-04 (work in progress), December 2015.
	[I-D.ietf-idr-te-pm-bgp]		[I-D.ietf-idr-te-pm-bgp]
	Previdi, S., Wu, Q., Gredler, H., Ray, S.,		Previdi, S., Wu, Q., Gredler, H., Ray, S.,
	Tantsura, j., Filsfils, C., and L. Ginsberg,		jefftant@gmail.com, j., Filsfils, C., and L. Ginsberg,
	"BGP-LS Advertisement of IGP Traffic Engineering		"BGP-LS Advertisement of IGP Traffic Engineering
	Performance Metric Extensions", draft-ietf-idr-te-pm-		Performance Metric Extensions", draft-ietf-idr-te-pm-
	bgp-03 (work in progress), May 2016.		bgp-03 (work in progress), May 2016.
	[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",		[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
	RFC 4272, DOI 10.17487/RFC4272, January 2006,		RFC 4272, DOI 10.17487/RFC4272, January 2006,
	<http://www.rfc-editor.org/info/rfc4272>.		<http://www.rfc-editor.org/info/rfc4272>.
	[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation		[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation
	Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674,		Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674,
	October 2006, <http://www.rfc-editor.org/info/rfc4674>.		October 2006, <http://www.rfc-editor.org/info/rfc4674>.
	[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,		[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
	"A Backward-Recursive PCE-Based Computation (BRPC)		"A Backward-Recursive PCE-Based Computation (BRPC)
	Procedure to Compute Shortest Constrained Inter-Domain		Procedure to Compute Shortest Constrained Inter-Domain
	Traffic Engineering Label Switched Paths", RFC 5441,		Traffic Engineering Label Switched Paths", RFC 5441,
	DOI 10.17487/RFC5441, April 2009,		DOI 10.17487/RFC5441, April 2009,
	<http://www.rfc-editor.org/info/rfc5441>.		<http://www.rfc-editor.org/info/rfc5441>.
	[RFC5824] Kumaki, K., Ed., Zhang, R., and Y. Kamite, "Requirements
	for Supporting Customer Resource ReSerVation Protocol
	(RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/
	MPLS IP-VPN", RFC 5824, DOI 10.17487/RFC5824, April 2010,
	<http://www.rfc-editor.org/info/rfc5824>.
	[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
	Path Computation Element Architecture to the Determination
	of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
	DOI 10.17487/RFC6805, November 2012,
	<http://www.rfc-editor.org/info/rfc6805>.
	[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
	Jie Dong		Jie Dong
	Huawei Technologies		Huawei Technologies
End of changes. 36 change blocks.
	193 lines changed or deleted		203 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/