< draft-dong-pce-discovery-proto-bgp-03.txt		draft-dong-pce-discovery-proto-bgp-04.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: March 4, 2016 Huawei Technologies		Expires: September 10, 2016 Huawei Technologies
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	September 1, 2015		March 9, 2016
	BGP Extensions for Path Computation Element (PCE) Discovery		BGP Extensions for Path Computation Element (PCE) Discovery
	draft-dong-pce-discovery-proto-bgp-03		draft-dong-pce-discovery-proto-bgp-04
	Abstract		Abstract
	In networks where Path Computation Element (PCE) is used for		In networks where Path Computation Element (PCE) is used for
	centralized path computation, it is desirable for Path Computation		centralized path computation, it is desirable for the Path
	Clients (PCCs) to automatically discover a set of PCEs and select the		Computation Clients (PCCs) to automatically discover a set of PCEs
	suitable ones to establish the PCEP session. RFC 5088 and RFC 5089		and select the suitable ones to establish the PCEP session. RFC 5088
	define the PCE discovery mechanisms based on Interior Gateway		and RFC 5089 define the PCE discovery mechanisms based on Interior
	Protocols (IGP). This document describes several scenarios in which		Gateway Protocols (IGP). This document describes several scenarios
	the IGP based PCE discovery mechanisms cannot be used directly. This		in which the IGP based PCE discovery mechanisms cannot be used
	document specifies the BGP extensions for PCE discovery in these		directly. In such scenarios, BGP might be suitable, thus this
	scenarios. The BGP based PCE discovery mechanism is complementary to		document specifies the BGP extensions for PCE discovery. The BGP
	the existing IGP based 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 1, line 48 ¶		skipping to change at page 1, line 49 ¶
	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 March 4, 2016.		This Internet-Draft will expire on September 10, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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 . . . . . . . . . . 4
	2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4		2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4
	2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5		2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5
	3. Operational Considerations . . . . . . . . . . . . . . . . . 6		3. Operational Considerations . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . 7		7.1. Normative References . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		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 the Path
	Clients (PCCs) to automatically discover a set of PCEs and select the		Computation Clients (PCCs) to automatically discover a set of PCEs
	suitable ones to establish the PCEP session. [RFC5088] and [RFC5089]		and select the suitable ones to establish the PCEP session.
	define the PCE discovery mechanisms based on Interior Gateway		[RFC5088] and [RFC5089] define the PCE discovery mechanisms based on
	Protocols (IGP). Those IGP based mechanisms may not work in several		Interior Gateway Protocols (IGP).
	scenarios where the PCEs do not participate in the IGP, and it is
	difficult for PCEs to participate in multiple IGP domains where PCE
	discovery is needed.
	In some scenarios, Backward Recursive Path Computation (BRPC)		The IGP based discovery mechanism requires the PCE participate in the
	[RFC5441] can be used by cooperating PCEs to compute inter-domain		IGP network, which usually requires that the PCE is directly adjacent
	path, in which case these cooperating PCEs should be known to each		to at least one of the IGP routers in the network. In some scenarios
	other in advance. In case of inter-AS networks where the PCEs do not		such requirement cannot be satisfied. For example, a PCE may need to
	participate in a common IGP, the existing IGP discovery mechanism		provide path computation service to some subsidiary networks of an
	cannot be used to discover the PCEs in other domains.		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.
	In the Hierarchical PCE scenario [RFC6805], the child PCEs need to		The requirement on PCE discovery, as described in [RFC4674], also
	know the address of the parent PCEs. This cannot be achieved through		include the automatic discovery of the PCEs in other domains, as it
	IGP based discovery, as normally the child PCEs and the parent PCE		is a desirable function in the case of inter-domain path computation.
	are under different administration and reside in different domains.		The IGP based discovery mechanisms cannot meet such requirement.
	Besides, as BGP could be used for north-bound distribution of routing		For example, Backward Recursive Path Computation (BRPC) [RFC5441] can
	and Label Switched Path (LSP) information to PCE as described in		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.
			Since BGP has been extended for north-bound distribution of routing
			and Label Switched Path (LSP) information to PCE
	[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-te-lsp-distribution] and		[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		[I-D.ietf-idr-te-pm-bgp], PCEs can obtain the routing information
	without participating in IGP. In this scenario, some other PCE		without participating in IGP. In this scenario, a new BGP based PCE
	discovery mechanism is needed.		discovery mechanism is needed.
	A detailed set of requirements for a PCE discovery mechanism are
	provided in [RFC4674].
	This document proposes to extend BGP for PCE discovery in the above		This document proposes to extend BGP for PCE discovery in the above
	scenarios. In networks where BGP-LS is used for the north-bound		scenarios. In networks where BGP-LS is used for the north-bound
	routing information distribution to PCE, the BGP based PCE discovery		routing information distribution to PCE, the BGP based PCE discovery
	can reuse the existing BGP sessions and mechanisms to achieve PCE		can make use of the existing BGP sessions and mechanisms to achieve
	discovery. It should be noted that in each IGP domain, the IGP based		automatic PCE discovery. Further IGP may be used to redistribute
	PCE discovery mechanism may be used in conjunction with the BGP based		remote PCE information, the detailed mechanism is out of the scope of
	PCE discovery. Thus the BGP based PCE discovery is complementary to		this document. Thus the BGP based PCE discovery is complementary to
	the existing IGP based mechanisms.		the existing IGP based mechanisms.
	+-----------+		+-----------+
	| PCE |		| PCE |
	+-----------+		+-----------+
	|		|
	v		v
	+-----------+		+-----------+
	| BGP | +-----------+		| BGP | +-----------+
	| Speaker | | PCE |		| Speaker | | PCE |
	+-----------+ +-----------+		+-----------+ +-----------+
	| | | |		| | | |
	| | | |		| | | |
	+---------------+ | +-------------------+ |		+---------------+ | +-------------------+ |
	v v v v		v v v v
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	| BGP | | BGP | | BGP |		| BGP | | BGP | | BGP |
	| Speaker | | Speaker | . . . | Speaker |		| Speaker | | Speaker | . . . | Speaker |
	| & PCC | | & PCC | | |		| & PCC | | & PCC | | & PCC |
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	|
	| via
	| IGP
	v
	+-----------+
	| PCC |
	+-----------+
	Figure 1: BGP for PCE discovery		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 both
	both routing information distribution and PCE information discovery.		for routing information distribution and for PCE information
	The routing information is collected from the network elements and		discovery. The routing information is collected from the network
	distributed to PCE, while the PCE discovery information is advertised		elements and distributed to PCE, while the PCE discovery information
	from PCE to PCCs, or between different PCEs. The PCCs maybe co-		is advertised from PCE to PCCs, or among different PCEs. The PCCs
	located with the BGP speakers as shown in Figure 1. The IGP based		maybe co-located with the BGP speakers as shown in Figure 1.
	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].		using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760].
	The AFI and SAFI defined in [I-D.ietf-idr-ls-distribution] are re-		The AFI and SAFI defined in [I-D.ietf-idr-ls-distribution] are re-
	used, and a new NLRI Type is defined for PCE discovery information as		used, and a new NLRI Type is defined for PCE discovery information as
	below:		below:
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 19 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier |		| Identifier |
	| (64 bits) |		| (64 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ PCE-Address (4 or 16 octets) ~		~ PCE-Address (4 or 16 octets) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. PCE Discovery NLRI		Figure 2. PCE Discovery NLRI
	The 'Protocol-ID' field SHOULD be set to a new value which indicates		The 'Protocol-ID' field SHOULD be set to the appropriate value which
	the information source protocol is PCE.		indicates the source of the PCE discovery information. If BGP
			speaker and PCE are co-located, the Protocol-ID SHOULD be set to
	+-------------+----------------------------------+		"Direct". In other cases, it is RECOMMENDED that the Protocol-ID
	| Protocol-ID | NLRI information source protocol |		value be set to "Static configuration".
	+-------------+----------------------------------+
	| TBD | PCE |
	+-------------+----------------------------------+
	As defined in [I-D.ietf-idr-ls-distribution], the 64-Bit 'Identifier'		As defined in [I-D.ietf-idr-ls-distribution], the 64-Bit 'Identifier'
	field is used to identify the "routing universe" where the PCE		field is used to identify the "routing universe" where the PCE
	belongs.		belongs.
	2.2. PCE Discovery TLVs		2.2. PCE Discovery TLVs
	The detailed PCE discovery information is carried in the BGP-LS		The detailed PCE discovery information is carried in the BGP-LS
	attribute [I-D.ietf-idr-ls-distribution] with a new "PCE Discovery		attribute [I-D.ietf-idr-ls-distribution] with a new "PCE Discovery
	TLV", which contains a set of sub-TLVs for specific PCE discovery		TLV", which contains a set of sub-TLVs for specific PCE discovery
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 10 ¶
	The PCE Discovery sub-TLVs are listed as below. The format of the		The PCE Discovery sub-TLVs are listed as below. The format of the
	PCE Discovery sub-TLVs are consistent with the IGP PCED sub-TLVs as		PCE Discovery sub-TLVs are consistent with the IGP PCED sub-TLVs as
	defined in [RFC5088] and [RFC5089]. The PATH-SCOPE sub-TLV MUST		defined in [RFC5088] and [RFC5089]. The PATH-SCOPE sub-TLV MUST
	always be carried in the PCE Discovery TLV. Other PCE Discovery sub-		always be carried in the PCE Discovery TLV. Other PCE Discovery sub-
	TLVs are optional and may facilitate the PCE selection process on the		TLVs are optional and may facilitate the PCE selection process on the
	PCCs.		PCCs.
	Type | Length | Name		Type | Length | Name
	------+------------+--------------------------------		------+------------+--------------------------------
	TBD | 3 | PATH-SCOPE sub-TLV		1 | 3 | PATH-SCOPE sub-TLV
	TBD | variable | PCE-CAP-FLAGS sub-TLV		2 | variable | PCE-CAP-FLAGS sub-TLV
	TBD | variable | OSPF-PCE-DOMAIN sub-TLV		3 | variable | OSPF-PCE-DOMAIN sub-TLV
	TBD | variable | IS-IS-PCE-DOMAIN sub-TLV		4 | variable | IS-IS-PCE-DOMAIN sub-TLV
	TBD | variable | OSPF-NEIG-PCE-DOMAIN sub-TLV		5 | variable | OSPF-NEIG-PCE-DOMAIN sub-TLV
	TBD | variable | IS-IS-NEIG-PCE-DOMAIN sub-TLV		6 | variable | IS-IS-NEIG-PCE-DOMAIN sub-TLV
	More PCE Discovery sub-TLVs may be defined in future and the format		More PCE Discovery sub-TLVs may be defined in future. The format and
	SHOULD be in line with the new sub-TLVs defined for IGP based PCE		semantic of new PCE Discovery sub-TLVs SHOULD be consistent in BGP
	discovery.		and 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. This 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. Normal BGP path selection can be applied to PCE Discovery		states. Normal BGP path selection can be applied to PCE Discovery
	NLRI only for the information propagation in the network, while the		NLRI only for the information propagation in the network, while on
	PCE selection on the PCCs would be based on the information carried		PCCs the PCE selection is based on the information carried in the PCE
	in the PCE Discovery TLV.		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 discovery information is considered relatively stable and
	does not change frequently, thus this information will not bring		does 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 a new NLRI Type for 'PCE Discovery NLRI' from		IANA needs to assign a new NLRI Type for 'PCE Discovery NLRI' from
	the "BGP-LS NLRI-Types" registry.		the "BGP-LS NLRI-Types" registry.
	IANA needs to assign a new Protocol-ID for "PCE" from the "BGP-LS
	Protocol-IDs" registry.
	IANA needs to assign a new TLV code point for 'PCE Discovery TLV'		IANA needs to assign a new TLV code point for 'PCE Discovery TLV'
	from the "node anchor, link descriptor and link attribute TLVs"		from the "node anchor, link descriptor and link attribute TLVs"
	registry.		registry.
	IANA needs to create a new registry for "PCE Discovery Sub-TLVs".		IANA needs to create a new registry for "PCE Discovery Sub-TLVs".
	The registry will be initialized as shown in section 2.2 of this		The registry will be initialized as shown in section 2.2 of this
	document.		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 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.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank Zhenbin Li and Hannes Gredler for		The authors would like to thank Zhenbin Li, Hannes Gredler, Jan
	their discussion and comments.		Medved, Adrian Farrel and Julien Meuric for the valuable discussion
			and 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-11		Information using BGP", draft-ietf-idr-ls-distribution-13
	(work in progress), June 2015.		(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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	DOI 10.17487/RFC4271, January 2006,		DOI 10.17487/RFC4271, January 2006,
	<http://www.rfc-editor.org/info/rfc4271>.		<http://www.rfc-editor.org/info/rfc4271>.
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 11 ¶
	Zhang, "IS-IS Protocol Extensions for Path Computation		Zhang, "IS-IS Protocol Extensions for Path Computation
	Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,		Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
	January 2008, <http://www.rfc-editor.org/info/rfc5089>.		January 2008, <http://www.rfc-editor.org/info/rfc5089>.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-idr-te-lsp-distribution]		[I-D.ietf-idr-te-lsp-distribution]
	Dong, J., Chen, M., Gredler, H., Previdi, S., and J.		Dong, J., Chen, M., Gredler, H., Previdi, S., and J.
	Tantsura, "Distribution of MPLS Traffic Engineering (TE)		Tantsura, "Distribution of MPLS Traffic Engineering (TE)
	LSP State using BGP", draft-ietf-idr-te-lsp-		LSP State using BGP", draft-ietf-idr-te-lsp-
	distribution-03 (work in progress), May 2015.		distribution-04 (work in progress), December 2015.
	[I-D.ietf-idr-te-pm-bgp]		[I-D.ietf-idr-te-pm-bgp]
	Wu, Q., Previdi, S., Gredler, H., Ray, S., and J.		Wu, Q., Previdi, S., Gredler, H., Ray, S., and J.
	Tantsura, "BGP attribute for North-Bound Distribution of		Tantsura, "BGP attribute for North-Bound Distribution of
	Traffic Engineering (TE) performance Metrics", draft-ietf-		Traffic Engineering (TE) performance Metrics", draft-ietf-
	idr-te-pm-bgp-02 (work in progress), January 2015.		idr-te-pm-bgp-02 (work in progress), January 2015.
	[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>.
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 4 ¶
	DOI 10.17487/RFC6805, November 2012,		DOI 10.17487/RFC6805, November 2012,
	<http://www.rfc-editor.org/info/rfc6805>.		<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
	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		Dhruv Dhody
	Huawei Technologies		Huawei Technologies
	Leela Palace		Divyashree Techno Park, Whitefield
	Bangalore, Karnataka 560008		Bangalore, Karnataka 560066
	India		India
	Email: dhruv.ietf@gmail.com		Email: dhruv.ietf@gmail.com
	Jeff Tantsura		Jeff Tantsura
	Ericsson		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, CA 95134		San Jose, CA 95134
	US		US
End of changes. 28 change blocks.
	91 lines changed or deleted		88 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/