< draft-dong-pce-discovery-proto-bgp-00.txt		draft-dong-pce-discovery-proto-bgp-01.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 D. Dhody
	Expires: January 1, 2015 June 30, 2014		Expires: April 28, 2015 Huawei Technologies
			J. Tantsura
			Ericsson
			October 25, 2014
	BGP Extensions for Path Computation Element (PCE) Discovery		BGP Extensions for Path Computation Element (PCE) Discovery
	draft-dong-pce-discovery-proto-bgp-00		draft-dong-pce-discovery-proto-bgp-01
	Abstract		Abstract
	In network scenarios where Path Computation Element (PCE) is used for		In network scenarios where Path Computation Element (PCE) is used for
	centralized path computation, it is desirable for Path Computation		centralized path computation, it is desirable for Path Computation
	Clients (PCCs) to automatically discover the set of PCEs. As BGP has		Clients (PCCs) to automatically discover a set of PCEs. As BGP can
	been extended for north-bound distribution of routing and LSP path		be used for north-bound distribution of routing and Label Switched
	information to PCE, the PCEs may not participate in Interior Gateway		Path (LSP) information to PCE, the PCEs may not participate in
	Protocol (IGP) for collecting the routing information, thus the IGP		Interior Gateway Protocol (IGP) for collecting the routing
	based PCE discovery cannot be used directly in these scenarios. This		information, thus the IGP based PCE discovery cannot be used directly
	document specifies the BGP extensions for PCE discovery.		in these scenarios. This document specifies the BGP extensions for
			PCE discovery.
	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 43 ¶		skipping to change at page 1, line 47 ¶
	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 January 1, 2015.		This Internet-Draft will expire on April 28, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 . . . . . . . . . . 3		2. Carrying PCE Discovery Information in BGP . . . . . . . . . . 4
	2.1. PCE Address Information . . . . . . . . . . . . . . . . . 3		2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4
	2.2. PCE Discovery Attribute . . . . . . . . . . . . . . . . . 4		2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5
	3. Operational Considerations . . . . . . . . . . . . . . . . . 5		3. Operational Considerations . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . 5		7.1. Normative References . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . 6		7.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	In network scenarios where Path Computation Element (PCE) is used for		In network scenarios where Path Computation Element (PCE) is used for
	centralized path computation, it is desirable for Path Computation		centralized path computation, it is desirable for Path Computation
	Clients (PCCs) to automatically discover the set of PCEs. As BGP		Clients (PCCs) to automatically discover a set of PCEs. [RFC5088]
	will be used for north-bound distribution of routing and Label		and [RFC5089] define PCE discovery mechanism based on Interior
	Switched Path (LSP) information to PCE[I-D.ietf-idr-ls-distribution]		Gateway Protocol (IGP). The IGP based mechanisms may not work well
	[I-D.ietf-idr-te-lsp-distribution] [I-D.ietf-idr-te-pm-bgp], the PCEs		in scenarios where the PCEs do not participate in the IGP, and it is
	may not participate in Interior Gateway Protocol (IGP) for collecting		difficult for PCE to participate in IGP of multiple domains where PCE
	the routing information, thus the IGP based PCE discovery mechanisms		discovery is needed.
	defined in [RFC5088] [RFC5089] cannot be used directly.
	This document proposes to extend BGP for PCE discovery in such		For example, Backward Recursive Path Computation (BRPC) [RFC5441] may
	scenarios. While in each IGP domain, the IGP based PCE discovery		be used by cooperating PCEs to compute inter-domain path, in which
	mechanism may be used in conjunction with the BGP based PCE		case these cooperating PCEs should be known to other PCEs. In case
	discovery. Thus the BGP based PCE discovery is complemental to the		of inter-AS network where the PCEs do not participate in a common
	existing IGP based mechanisms.		IGP, the existing IGP discovery mechanism cannot be used to discover
			the PCEs in other domains. Also in the Hierarchical PCE scenario,
			the child PCEs need to know the address of the parent PCE. This
			cannot be achieved through IGP based discovery, as normally the child
			PCEs and the parent PCE are under different administration and reside
			in different domains.
	+---------+		As BGP could be used for north-bound distribution of routing and
	| PCE |		Label Switched Path (LSP) information to PCE as described in
	+---------+		[I-D.ietf-idr-ls-distribution] [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, some other PCE
	| V		disovery mechanism is also needed.
	+---------+
	+--------->| BGP |<---------+
	| +----| Speaker |----+ |
	| | +---------+ | |
	| | ^ | | |
	| | | | | |
	| V | V V |
	+---------+ +---------+ +---------+
	| BGP | | BGP | | BGP |
	| Speaker | | Speaker | | Speaker |
	+---------+ +---------+ +---------+
	^ ^ ^
	IGP(optional) | | |
	V V V
	+---------+ +---------+ +---------+
	| PCC | | PCC | | PCC |
	+---------+ +---------+ +---------+
	Figure 1. BGP for routing collection and PCE discovery		A detailed set of requirements for a PCE discovery mechanism are
			provided in [RFC4674].
			This document proposes to extend BGP for PCE discovery for the above
			scenarios. In networks where BGP-LS is already used for the north-
			bound routing information distribution to PCE, BGP based PCE
			discovery can reuse the existing BGP sessions and mechanisms to
			achieve PCE discovery. It should be noted that, in IGP domain, the
			IGP based PCE discovery mechanism may be used in conjunction with the
			BGP based PCE discovery. Thus the BGP based PCE discovery is
			complementary to the existing IGP based mechanisms.
			+-----------+
			| PCE |
			+-----------+
			|
			v
			+-----------+
			| BGP | +-----------+
			| Speaker | | PCE |
			+-----------+ +-----------+
			| | | |
			| | | |
			+---------------+ | +-------------------+ |
			v v v v
			+-----------+ +-----------+ +-----------+
			| BGP | | BGP | | BGP |
			| Speaker | | Speaker | . . . | Speaker |
			| & PCC | | & PCC | | |
			+-----------+ +-----------+ +-----------+
			|
			| via
			| IGP
			v
			+-----------+
			| PCC |
			+-----------+
			Figure 1: BGP for PCE discovery
	As shown in the network architecture in Figure 1, BGP is used for		As shown in the network architecture in Figure 1, BGP is used for
	both routing information distribution and PCE information discovery.		both routing information distribution and PCE information discovery.
	The routing information is distributed from the network elements up		The routing information is collected from the network elements and
	to PCE, while the PCE discovery information is advertised from PCE		distributed to PCE, while the PCE discovery information is advertised
	down to PCCs. IGP based PCE discovery mechanism may be used for the		from PCE to PCCs, or between different PCEs. The PCCs maybe co-
	distribution of PCE discovery information in each IGP domain.		located with the BGP speakers as shown in Figure 1. The IGP based
			PCE discovery mechanism may be used for the distribution of PCE
			discovery information in IGP domain.
	2. Carrying PCE Discovery Information in BGP		2. Carrying PCE Discovery Information in BGP
	2.1. PCE Address Information		2.1. PCE Address Information
	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]. A		using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760].
	new NLRI called PCE_ADDR NLRI is defined for carrying the PCE address		The AFI and SAFI defined in [I-D.ietf-idr-ls-distribution] are re-
	information which can be used to reach the PCE. The AFI/SAFI value		used, and a new NLRI Type is defined for PCE discovery information as
	for the PCE_ADDR NLRI is TBD. In order for two BGP speakers to		below:
	exchange PCE_ADDR NLRI, they MUST use BGP Capabilities Advertisement
	[RFC4760] to ensure that both are capable of properly processing such
	NLRI. This is done by using Capability Code 1 (which indicates
	Multiprotocol Extensions capabilities), with the AFI/SAFI pair for
	the PCE_ADDR NLRI.
	The format of PCE_ADDR NLRI is shown as below:		o Type = TBD: PCE Discovery NLRI
	0 1 2 3		The format of PCE Discovery NLRI is shown in the following 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ PCE-Address (4 or 16 octets) ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. PCE_ADDR NLRI
	For PCEs identified by IPv4 address, the Type field SHOULD be set to		0 1 2 3
	1, and the Length field SHOULD be set to 4.		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 |
			| (64 bits) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ PCE-Address (4 or 16 octets) ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 2. PCE Discovery NLRI
	For PCEs identified by IPv6 address, the Type field SHOULD be set to		The 'Protocol-ID' field do not apply to the PCE Discovery NLRI and
	2, and the Length field SHOULD be set to 16.		SHOULD be set to 0 on transmission and be ignored upon receipt.
	2.2. PCE Discovery Attribute		The 'Identifier' field is used to identify the "routing universe"
			where the PCE belongs, and the identifier values as below defined in
			[I-D.ietf-idr-ls-distribution] apply.
	The detailed PCE discovery information is carried in a new optional		+------------+---------------------+
	non-transitive BGP attribute called PCE_DISC Attribute, which		| Identifier | Routing Universe |
	consists of a series of PCE Discovery TLVs for specific PCE		+------------+---------------------+
	information. The PCE_DISC attribute SHOULD only be used with		| 0 | L3 packet topology |
	PCE_ADDR NLRI.		| 1 | L1 optical topology |
			+------------+---------------------+
			2.2. PCE Discovery TLVs
			The detailed PCE discovery information is carried in BGP-LS attribute
			[I-D.ietf-idr-ls-distribution] with a new "PCE Discovery TLV", which
			contains a set of sub-TLVs for specific PCE discovery information.
			The PCE Discovery TLV and sub-TLVs SHOULD only be used with the PCE
			Discovery NLRI.
	The format of the PCE Discovery TLV is shown as below:		The format of the PCE Discovery TLV is shown as below:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ PCE Discovery TLVs (variable) ~		~ PCE Discovery Sub-TLVs (variable) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3. PCE Discovery TLVs		Figure 3. PCE Discovery TLV
	The Type code and format of the PCE Discovery TLVs are consistent
	with the IGP PCED Sub-TLVs defined in [RFC5088] [RFC5089]. Type 1 is
	reserved, which is used in IGP based PCE discovery mechanisms to
	carry PCE Address .
	TLV-Type Length Name		The PCE Discovery Sub-TLVs are listed as below. The format of the
	2 3 PATH-SCOPE TLV		PCE Discovery sub-TLVs are consistent with the IGP PCED sub-TLVs
	3 variable PCE-DOMAIN TLV		defined in [RFC5088] and [RFC5089]. The PATH-SCOPE TLV MUST always
	4 variable NEIG-PCE-DOMAIN TLV		be carried in the BGP-LS Attribute if the NLRI is PCE Discovery NLRI.
	5 variable PCE-CAP-FLAGS TLV		Other PCE Discovery TLVs are optional and may facilitate the PCE
			selection process.
	The PATH-SCOPE TLV MUST always be carried in the PCE_DISC Attribute.		Type Length Name
	Other TLVs are optional and may facilitate the PCE selection.		TBD 3 PATH-SCOPE sub-TLV
			TBD variable PCE-CAP-FLAGS sub-TLV
			TBD variable OSPF-PCE-DOMAIN sub-TLV
			TBD variable IS-IS-PCE-DOMAIN sub-TLV
			TBD variable OSPF-NEIG-PCE-DOMAIN sub-TLV
			TBD variable IS-IS-NEIG-PCE-DOMAIN sub-TLV
	More PCE Discovery TLVs may be defined in future.		More PCE Discovery sub-TLVs may be defined in future and the format
			SHOULD be in line with the new sub-TLVs defined for IGP based PCE
			discovery.
	3. Operational Considerations		3. Operational Considerations
	Existing BGP operational procedures apply to the advertisement of PCE		Existing BGP operational procedures apply to the advertisement of PCE
	discovery information. Such information is treated as pure		discovery information. This information is treated as pure
	application level data which has no immediate impact on forwarding		application level data which has no immediate impact on forwarding
	states.		states. Normal BGP path selection can be applied to PCE Discovery
			NLRI only for the information propagation in the network, while the
			PCE selection on the PCCs would be peformed based on the information
			carried in the PCE Discovery TLV.
	PCE discovery information is considered relatively stable and does		PCE discovery information is considered relatively stable and does
	not change frequently, thus this information will not bring		not change frequently, thus this information will not bring
	significant impact on the amount of BGP updates in the network.		significant impact on the amount of BGP updates in the network.
	4. IANA Considerations		4. IANA Considerations
	IANA needs to assign new AFI and SAFI codes for PCE_ADDR NLRI from		IANA needs to assign a new NLRI Type for 'PCE Discovery NLRI' from
	"Address Family Numbers" and "Subsequent Address Family Identifiers"		the "BGP-LS NLRI- Types" registry.
			IANA needs to assign a new TLV code point for 'PCE Discovery TLV'
			from the "node anchor, link descriptor and link attribute TLVs"
	registry.		registry.
	IANA needs to assign a new type code for "PCE_DISC" attribute from		IANA needs to create a new registry for "PCE Discovery Sub-TLVs".
	"BGP Path Attributes" registry.		The registry will be initialized as shown in section 2.2 of this
			document.
	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 the 'Security Considerations'
			section of [RFC4271] for a discussion of BGP security. Also refer to
			[RFC4272] and [RFC6952] for analysis of security issues for BGP.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank Zhenbin Li for the discussion and		The authors would like to thank Zhenbin Li and Hannes Gredler for
	comments.		their discussion and comments.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
			[I-D.ietf-idr-ls-distribution]
			Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
			Ray, "North-Bound Distribution of Link-State and TE
			Information using BGP", draft-ietf-idr-ls-distribution-06
			(work in progress), September 2014.
	[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, March 1997.
			[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
			Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[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, January
	2007.		2007.
	[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,		[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
	"OSPF Protocol Extensions for Path Computation Element		"OSPF Protocol Extensions for Path Computation Element
	(PCE) Discovery", RFC 5088, January 2008.		(PCE) Discovery", RFC 5088, January 2008.
	[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,		[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
	"IS-IS Protocol Extensions for Path Computation Element		"IS-IS Protocol Extensions for Path Computation Element
	(PCE) Discovery", RFC 5089, January 2008.		(PCE) Discovery", RFC 5089, January 2008.
	[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
	BGP, LDP, PCEP, and MSDP Issues According to the Keying
	and Authentication for Routing Protocols (KARP) Design
	Guide", RFC 6952, May 2013.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-idr-ls-distribution]
	Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
	Ray, "North-Bound Distribution of Link-State and TE
	Information using BGP", draft-ietf-idr-ls-distribution-05
	(work in progress), May 2014.
	[I-D.ietf-idr-te-lsp-distribution]		[I-D.ietf-idr-te-lsp-distribution]
	Dong, J., Chen, M., Gredler, H., and S. Previdi,		Dong, J., Chen, M., Gredler, H., Previdi, S., and J.
	"Distribution of MPLS Traffic Engineering (TE) LSP State		Tantsura, "Distribution of MPLS Traffic Engineering (TE)
	using BGP", draft-ietf-idr-te-lsp-distribution-00 (work in		LSP State using BGP", draft-ietf-idr-te-lsp-
	progress), January 2014.		distribution-01 (work in progress), July 2014.
	[I-D.ietf-idr-te-pm-bgp]		[I-D.ietf-idr-te-pm-bgp]
	Wu, Q., Danhua, W., Previdi, S., Gredler, H., and S. Ray,		Wu, Q., Previdi, S., Gredler, H., Ray, S., and J.
	"BGP attribute for North-Bound Distribution of Traffic		Tantsura, "BGP attribute for North-Bound Distribution of
	Engineering (TE) performance Metrics", draft-ietf-idr-te-		Traffic Engineering (TE) performance Metrics", draft-ietf-
	pm-bgp-00 (work in progress), January 2014.		idr-te-pm-bgp-01 (work in progress), July 2014.
			[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
			4272, January 2006.
			[RFC4674] Le Roux, J., "Requirements for Path Computation Element
			(PCE) Discovery", RFC 4674, October 2006.
			[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
			Backward-Recursive PCE-Based Computation (BRPC) Procedure
			to Compute Shortest Constrained Inter-Domain Traffic
			Engineering Label Switched Paths", RFC 5441, April 2009.
			[RFC6805] King, D. and A. Farrel, "The Application of the Path
			Computation Element Architecture to the Determination of a
			Sequence of Domains in MPLS and GMPLS", RFC 6805, November
			2012.
			[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
			BGP, LDP, PCEP, and MSDP Issues According to the Keying
			and Authentication for Routing Protocols (KARP) Design
			Guide", RFC 6952, May 2013.
	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
			Dhruv Dhody
			Huawei Technologies
			Leela Palace
			Bangalore, Karnataka 560008
			India
			Email: dhruv.ietf@gmail.com
			Jeff Tantsura
			Ericsson
			300 Holger Way
			San Jose, CA 95134
			US
			Email: jeff.tantsura@ericsson.com
End of changes. 35 change blocks.
	134 lines changed or deleted		204 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/