< draft-dong-pce-discovery-proto-bgp-01.txt		draft-dong-pce-discovery-proto-bgp-02.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: April 28, 2015 Huawei Technologies		Expires: September 6, 2015 Huawei Technologies
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	October 25, 2014		March 5, 2015
	BGP Extensions for Path Computation Element (PCE) Discovery		BGP Extensions for Path Computation Element (PCE) Discovery
	draft-dong-pce-discovery-proto-bgp-01		draft-dong-pce-discovery-proto-bgp-02
	Abstract		Abstract
	In network scenarios 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 Path Computation
	Clients (PCCs) to automatically discover a set of PCEs. As BGP can		Clients (PCCs) to automatically discover a set of PCEs and select the
	be used for north-bound distribution of routing and Label Switched		suitable ones to establish the PCEP session. RFC 5088 and RFC 5089
	Path (LSP) information to PCE, the PCEs may not participate in		define the PCE discovery mechanisms based on Interior Gateway
	Interior Gateway Protocol (IGP) for collecting the routing		Protocols (IGP). This document describes several scenarios in which
	information, thus the IGP based PCE discovery cannot be used directly		the IGP based PCE discovery mechanisms cannot be used directly. This
	in these scenarios. This document specifies the BGP extensions for		document specifies the BGP extensions for PCE discovery in these
	PCE discovery.		scenarios. The BGP 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 47 ¶		skipping to change at page 1, line 48 ¶
	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 28, 2015.		This Internet-Draft will expire on September 6, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . 8		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 a set of PCEs. [RFC5088]		Clients (PCCs) to automatically discover a set of PCEs and select the
	and [RFC5089] define PCE discovery mechanism based on Interior		suitable ones to establish the PCEP session. [RFC5088] and [RFC5089]
	Gateway Protocol (IGP). The IGP based mechanisms may not work well		define PCE discovery mechanism based on Interior Gateway Protocol
	in scenarios where the PCEs do not participate in the IGP, and it is		(IGP). Those IGP based mechanisms may not work in scenarios where
	difficult for PCE to participate in IGP of multiple domains where PCE		the PCEs do not participate in the IGP, and it is difficult for PCEs
	discovery is needed.		to participate in IGP of multiple domains where PCE discovery is
			needed.
	For example, Backward Recursive Path Computation (BRPC) [RFC5441] may		In some other scenarios, Backward Recursive Path Computation (BRPC)
	be used by cooperating PCEs to compute inter-domain path, in which		[RFC5441] can be used by cooperating PCEs to compute inter-domain
	case these cooperating PCEs should be known to other PCEs. In case		path, in which case these cooperating PCEs should be known to each
	of inter-AS network where the PCEs do not participate in a common		other. In case of inter-AS network where the PCEs do not participate
	IGP, the existing IGP discovery mechanism cannot be used to discover		in a common IGP, the existing IGP discovery mechanism cannot be used
	the PCEs in other domains. Also in the Hierarchical PCE scenario,		to discover the PCEs in other domains.
	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		In the Hierarchical PCE scenario [RFC6805], the child PCEs need to
	Label Switched Path (LSP) information to PCE as described in		know the address of the parent PCEs. 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.
			Besides, as BGP could be used for north-bound distribution of routing
			and 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-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, some other PCE
	disovery mechanism is also needed.		discovery mechanism is also needed.
	A detailed set of requirements for a PCE discovery mechanism are		A detailed set of requirements for a PCE discovery mechanism are
	provided in [RFC4674].		provided in [RFC4674].
	This document proposes to extend BGP for PCE discovery for the above		This document proposes to extend BGP for PCE discovery for the above
	scenarios. In networks where BGP-LS is already used for the north-		scenarios. In networks where BGP-LS is already used for the north-
	bound routing information distribution to PCE, BGP based PCE		bound routing information distribution to PCE, BGP based PCE
	discovery can reuse the existing BGP sessions and mechanisms to		discovery can reuse the existing BGP sessions and mechanisms to
	achieve PCE discovery. It should be noted that, in IGP domain, the		achieve PCE discovery. It should be noted that, in IGP domain, the
	IGP based PCE discovery mechanism may be used in conjunction with the		IGP based PCE discovery mechanism may be used in conjunction with the
	skipping to change at page 6, line 42 ¶		skipping to change at page 6, line 42 ¶
	SHOULD be in line with the new sub-TLVs defined for IGP based PCE		SHOULD be in line with the new sub-TLVs defined for IGP based PCE
	discovery.		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 the
	PCE selection on the PCCs would be peformed based on the information		PCE selection on the PCCs would be performed based on the information
	carried in the PCE Discovery TLV.		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 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.
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 37 ¶
	The authors would like to thank Zhenbin Li and Hannes Gredler for		The authors would like to thank Zhenbin Li and Hannes Gredler for
	their discussion and comments.		their 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-06		Information using BGP", draft-ietf-idr-ls-distribution-10
	(work in progress), September 2014.		(work in progress), January 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, March 1997.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		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.
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	[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.
	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-01 (work in progress), July 2014.		distribution-02 (work in progress), January 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-01 (work in progress), July 2014.		idr-te-pm-bgp-02 (work in progress), January 2015.
	[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC		[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
	4272, January 2006.		4272, January 2006.
	[RFC4674] Le Roux, J., "Requirements for Path Computation Element		[RFC4674] Le Roux, J., "Requirements for Path Computation Element
	(PCE) Discovery", RFC 4674, October 2006.		(PCE) Discovery", RFC 4674, October 2006.
	[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A		[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
	Backward-Recursive PCE-Based Computation (BRPC) Procedure		Backward-Recursive PCE-Based Computation (BRPC) Procedure
	to Compute Shortest Constrained Inter-Domain Traffic		to Compute Shortest Constrained Inter-Domain Traffic
End of changes. 15 change blocks.
	37 lines changed or deleted		40 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/