< draft-lopez-pce-hpce-ted-00.txt		draft-lopez-pce-hpce-ted-01.txt >
	Network Working Group V. Lopez		Network Working Group V. Lopez
	Internet-Draft O. Gonzalez de Dios		Internet-Draft O. Gonzalez de Dios
	Intended status: Informational Telefonica I+D		Intended status: Informational Telefonica I+D
	Expires: April 24, 2014 D. King		Expires: August 15, 2014 D. King
	Old Dog Consulting		Old Dog Consulting
	S. Previdi		S. Previdi
	Cisco Systems, Inc.		Cisco Systems, Inc.
	October 21, 2013		February 11, 2014
	Traffic Engineering Database dissemination for Hierarchical PCE		Traffic Engineering Database dissemination for Hierarchical PCE
	scenarios		scenarios
	draft-lopez-pce-hpce-ted-00		draft-lopez-pce-hpce-ted-01
	Abstract		Abstract
	The PCE architecture is well-defined and may be used to compute the		The PCE architecture is well-defined and may be used to compute the
	optimal path for LSPS across domains in MPLS-TE and GMPLS networks.		optimal path for LSPS across domains in MPLS-TE and GMPLS networks.
	The Hierarchical Path Computation Element (H-PCE) [RFC6805] was		The Hierarchical Path Computation Element (H-PCE) [RFC6805] was
	developed to provide an optimal path when the sequence of domains is		developed to provide an optimal path when the sequence of domains is
	not known in advance. The procedure and mechanism for populating the		not known in advance. The procedure and mechanism for populating the
	Traffic Engineering Database (TED) with domain topology and link		Traffic Engineering Database (TED) with domain topology and link
	information used in H-PCE-based path computations is open to		information used in H-PCE-based path computations is open to
	skipping to change at page 1, line 48 ¶		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 24, 2014.		This Internet-Draft will expire on August 15, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	1.1. Parent PCE Domain Topology . . . . . . . . . . . . . . . 3		1.1. Parent PCE Domain Topology . . . . . . . . . . . . . . . 3
	1.2. Parent PCE TED requirements . . . . . . . . . . . . . . . 3		1.2. Parent PCE TED requirements . . . . . . . . . . . . . . . 4
	2. H-PCE Domain Topology Dissemination and Construction Methods 4		2. H-PCE Domain Topology Dissemination and Construction Methods 4
	3. H-PCE architecture using BGP-LS . . . . . . . . . . . . . . . 5		3. H-PCE architecture using BGP-LS . . . . . . . . . . . . . . . 5
	4. Including Inter-domain connectivity in BGP-LS . . . . . . . . 8		4. Including Inter-domain connectivity in BGP-LS . . . . . . . . 8
	4.1. Mapping from OSPF-TE . . . . . . . . . . . . . . . . . . 8		4.1. Mapping from OSPF-TE . . . . . . . . . . . . . . . . . . 8
	4.2. Mapping from ISIS-TE . . . . . . . . . . . . . . . . . . 8		4.2. Mapping from ISIS-TE . . . . . . . . . . . . . . . . . . 8
	5. BGP considerations . . . . . . . . . . . . . . . . . . . . . 8		5. BGP considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. Manageability Considerations . . . . . . . . . . . . . . . . 8		6. Manageability Considerations . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	In scenarios with multiple domains in both MPLS-TE and GMPLS		In scenarios with multiple domains in both MPLS-TE and GMPLS
	networks, the hierarchical Path Computation Element (H-PCE)		networks, the hierarchical Path Computation Element (H-PCE)
	Architecture, defined in [RFC6805], allows to obtain the optimum end-		Architecture, defined in [RFC6805], allows to obtain the optimum end-
	to-end path. The architecture exploits a hierarchical relation among		to-end path. The architecture exploits a hierarchical relation among
	domains.		domains.
	[RFC6805] defines the architecture and requirements for the end-to-		[RFC6805] defines the architecture and requirements for the end-to-
	end path computation across domains. The solution draft for the		end path computation across domains. The solution draft for the
	H-PCE [I-D.draft-ietf-pce-hierarchy-extensions-00] is focused on the		H-PCE [I-D.draft-zhang-pce-hierarchy-extensions-04] is focused on the
	PCEP protocol extensions to support such H-PCE procedures, including		PCEP protocol extensions to support such H-PCE procedures, including
	negotiation of capabilities and errors. However, neither the		negotiation of capabilities and errors. However, neither the
	architecture nor the solution draft specify which mechanism must to		architecture nor the solution draft specify which mechanism must to
	be used to build and populate the parent PCE (pPCE) Traffic		be used to build and populate the parent PCE (pPCE) Traffic
	Engineering Database (TED).		Engineering Database (TED).
	The H-PCE architecture documents define the minimum content needed in		The H-PCE architecture documents define the minimum content needed in
	the traffic engineering database required to compute paths. The		the traffic engineering database required to compute paths. The
	information required by parent TEDB are identified in [RFC6805] and		information required by parent TEDB are identified in [RFC6805] and
	further elaborated in		further elaborated in
	[I-D.draft-ietf-pce-inter-area-as-applicability-03]. For instance,		[I-D.draft-ietf-pce-inter-area-as-applicability-03]. For instance,
	[RFC6805] and [I-D.draft-ietf-pce-inter-area-as-applicability-03]		[RFC6805] and [I-D.draft-ietf-pce-inter-area-as-applicability-03]
	suggest that BGP-LS could be used as a "northbound" TE advertisement.		suggest that BGP-LS could be used as a "northbound" TE advertisement.
	This means that a PCE does not need to listen IGP in its domain, but		This means that a PCE does not need to listen IGP in its domain, but
	its TED is populated by messages received (for example) from a Route		its TED is populated by messages received (for example) from a Route
	Reflector.		Reflector. [I-D.draft-ietf-idr-te-pm-bgp-00] extends BGP-LS to
			disseminate traffic engineering information. The parameters
			considered are: delay, packet loss and bandwidth.
	This document highlights the applicability of BGP-LS to the		This document highlights the applicability of BGP-LS to the
	dissemination of domain topology within the H-PCE architecture. In		dissemination of domain topology within the H-PCE architecture. In
	particular, it describes how can BGP-LS be used to send the inter-		particular, it describes how can BGP-LS be used to send the inter-
	domain connectivity. It also shows how can OSPF-TE and ISIS-TE		domain connectivity. It also shows how can OSPF-TE and ISIS-TE
	updates be mapped into BGP-LS.		updates be mapped into BGP-LS.
	Note that this document is not intended to define new protocol		Note that this document is not intended to define new protocol
	extensions, it is an informational document and where required it		extensions, it is an informational document and where required it
	highlights where existing mechanisms and protocols may be applied.		highlights where existing mechanisms and protocols may be applied.
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 8 ¶
	o Separate IGP instance. [RFC6805] points out that in models such		o Separate IGP instance. [RFC6805] points out that in models such
	as ASON it is possible to consider a separate instance of an IGP		as ASON it is possible to consider a separate instance of an IGP
	running within the parent domain where the participating protocol		running within the parent domain where the participating protocol
	speakers are the nodes directly present in that domain and the		speakers are the nodes directly present in that domain and the
	PCEs (parent and child PCEs).		PCEs (parent and child PCEs).
	o Use north-bound distribution of TE information. The North-Bound		o Use north-bound distribution of TE information. The North-Bound
	Distribution of Link-State and TE Information using BGP has been		Distribution of Link-State and TE Information using BGP has been
	recently propose in the IEFT		recently propose in the IEFT
			[I-D.draft-ietf-idr-ls-distribution-04]. This approach is known
	[I-D.draft-ietf-idr-ls-distribution-03]. This approach is known
	as BGP-LS and defines a mechanism by which links state and traffic		as BGP-LS and defines a mechanism by which links state and traffic
	engineering information can be collected from networks and		engineering information can be collected from networks and
	exported to external elements using the BGP routing protocol. By		exported to external elements using the BGP routing protocol. By
	using BGP-LS as northbound distribution mechanism, there would be		using BGP-LS as northbound distribution mechanism, there would be
	a BGP speaker in each domains that sends the necessary information		a BGP speaker in each domains that sends the necessary information
	to a BGP speaker in the parent domain. This architecture is		to a BGP speaker in the parent domain. This architecture is
	further elaborated in this document.		further elaborated in this document.
	3. H-PCE architecture using BGP-LS		3. H-PCE architecture using BGP-LS
	As mentioned in [I-D.draft-dugeon-pce-ted-reqs-01] PCE has to		As mentioned in [I-D.draft-dugeon-pce-ted-reqs-02] PCE has to
	retrieve Traffic Engineering (TE) information to carry out its path		retrieve Traffic Engineering (TE) information to carry out its path
	computation. This is required not only for intra-domain information,		computation. This is required not only for intra-domain information,
	which can be got using IGP (like OSPF-TE or ISIS-TE), but also for		which can be got using IGP (like OSPF-TE or ISIS-TE), but also for
	inter-domain information in the Hierarchical PCE (H-PCE)		inter-domain information in the Hierarchical PCE (H-PCE)
	architecture.		architecture.
	Figure 1 shows an example of a H-PCE architecture. In this example,		Figure 1 shows an example of a H-PCE architecture. In this example,
	there is a parent PCE and three child PCEs, and they are organized in		there is a parent PCE and three child PCEs, and they are organized in
	multiple domains. The parent PCE does not have information of the		multiple domains. The parent PCE does not have information of the
	whole network, but is only aware of the connectivity among the		whole network, but is only aware of the connectivity among the
	skipping to change at page 6, line 47 ¶		skipping to change at page 7, line 17 ¶
	access to such domain TED and acts as BGP-LS Route Reflector to		access to such domain TED and acts as BGP-LS Route Reflector to
	provide network topology to the pPCE. Next to the pPCE, there is a		provide network topology to the pPCE. Next to the pPCE, there is a
	BGP speaker that maintains a BGP session with each of the BGP		BGP speaker that maintains a BGP session with each of the BGP
	speakers in the domains to receive the topology and build the parent		speakers in the domains to receive the topology and build the parent
	TED. A policy can be applied to the BGP-LS speakers to decide which		TED. A policy can be applied to the BGP-LS speakers to decide which
	information is sent to its peer speaker. The minimum amount of		information is sent to its peer speaker. The minimum amount of
	information that needs to be exchanged is the inter-domain		information that needs to be exchanged is the inter-domain
	connectivity, including the details of the Traffic Engineering Inter-		connectivity, including the details of the Traffic Engineering Inter-
	domain Links [RFC6805]. With this information, the parent PCE is		domain Links [RFC6805]. With this information, the parent PCE is
	able to have access to a domain topology map and its connectivity.		able to have access to a domain topology map and its connectivity.
	Additionally, the BGP-LS speaker can be configured to send the		Additionally, the BGP-LS speaker can be configured to send some
	complete list of TE Links, including its details. In this case, the		intra-domain information for virtual or candidate paths with some TE
	parent PCE has access to an extended database, with visibility of		information. In this case, the parent PCE has access to an extended
	both intra-domain and inter-domain information and can compute the		database, with visibility of both intra-domain and inter-domain
	sequence of domains with better accuracy. Even, the pPCE could have		information and can compute the sequence of domains with better
	enough information to compute the whole end-to-end path by itself.		accuracy.
	BGP-LS [I-D.draft-ietf-idr-ls-distribution-03] extends the BGP Update		BGP-LS [I-D.draft-ietf-idr-ls-distribution-04] extends the BGP Update
	messages to advertise link-state topology thanks to new BGP Network		messages to advertise link-state topology thanks to new BGP Network
	Layer Reachability Information (NLRI). The Link State information is		Layer Reachability Information (NLRI). The Link State information is
	sent in two BGP attributes, the MP_REACH (defined in [RFC4670]) and a		sent in two BGP attributes, the MP_REACH (defined in [RFC4670]) and a
	LINK_STATE attribute (defined in		LINK_STATE attribute (defined in
	[I-D.draft-ietf-idr-ls-distribution-03]). To describe the inter		[I-D.draft-ietf-idr-ls-distribution-04]). To describe the inter
	domain links, in the MP_REACH attribute, a Link NLRI can be used with		domain links, in the MP_REACH attribute, a Link NLRI can be used with
	the local node descriptors the address of the source, and in the		the local node descriptors the address of the source, and in the
	remote descriptors, the address of the destination of the link. The		remote descriptors, the address of the destination of the link. The
	Link Descriptors field has a TLV (Link Local/Remote Identifiers),		Link Descriptors field has a TLV (Link Local/Remote Identifiers),
	which carries the prefix of the Unnumbered or Numbered Interface. In		which carries the prefix of the Unnumbered or Numbered Interface. In
	case of the message informs about an intra-domain link, the standard		case of the message informs about an intra-domain link, the standard
	traffic engineering information is included in the LINK_STATE		traffic engineering information is included in the LINK_STATE
	attribute.		attribute.
	----------------------------------------------------------------------		----------------------------------------------------------------------
	| Parent PCE Domain |		| Parent PCE Domain |
	| ------- ----- ----- |		| ------- ----- ----- |
	| -------+BGP-LS +---+ TED +--+pPCE | |		| -------+BGP-LS +---+ TED +--+pPCE | |
	| / |Speaker| ----- ----- |		| / |Speaker| ----- ----- |
	| / --+---+ |		| / --+---+ |
	| / | \_________________		| / | \_________________
	| / | \		| / | \
	| ------------/-------- ----+------------ ------+------------ |		| ------------/-------- ----+------------ ------+------------ |
	| | Domain 1 / | | | Domain 2 | | | Domain 3 | |		| | Domain 1 / | | | Domain 2 | | | Domain 3 | |
	| | / | | | | | | | |		| | / | | | | | | | |
	| | ------+ | | -+----- | | ---+--- | |		| | ------+ | | -+----- | | ---+--- | |
	| | |BGP-LS | | | |BGP-LS | | | |BGP-LS | | |		| | |BGP-LS | | | |BGP-LS | | | |BGP-LS | | |
	| | |Speaker| | | |Speaker| | | |Speaker| | |		| | |Speaker| | | |Speaker| | | |Speaker| | |
	| | ---+--- | | ---+--- | | ---+--- | |		| | ---+--- | | ---+--- | | ---+--- | |
	| | | | | | | | | | |		| | | | | | | | | | |
	| | ---+--- ------ | | ---+-- ------ | | ---+--- ------ | |		| | ---+--- ------ | | ---+-- ------ | | ---+--- ------ | |
	| | | TED +-+cPCE 1| | | | TED +-+cPCE| | | | TED +-+cPCE 1| | |		| | | TED +-+cPCE 1| | | | TED +-+cPCE| | | | TED +-+cPCE 1| | |
	| | ---+--- ------ | | ---+-- ------ | | ---+--- ------ | |		| | ---+--- ------ | | ---+-- ------ | | ---+--- ------ | |
	| | | | | | | | | | |		| | | | | | | | | | |
	| | ---+--- | | ---+--- | | ---+--- | |		| | ---+--- | | ---+--- | | ---+--- | |
	| | | IGP | | | | IGP | | | | IGP | | |		| | | IGP | | | | IGP | | | | IGP | | |
	| | | Peer | | | | Peer | | | | Peer | | |		| | | Peer | | | | Peer | | | | Peer | | |
	| | ------- | | ------- | | ------- | |		| | ------- | | ------- | | ------- | |
	| | | | | | | | | | |		| | | | | | | | | | |
	| ------+--------------- -----+----------- ------+------------ |		| ------+--------------- -----+----------- ------+------------ |
	| | | | |		| | | | |
	| ------------------- ---------------- ------------------- |		| ------------------- ---------------- ------------------- |
	| | Domain 1 | | Domain 2 | | Domain 3 | |		| | Domain 1 | | Domain 2 | | Domain 3 | |
	| ------------------- ---------------- ------------------- |		| ------------------- ---------------- ------------------- |
	----------------------------------------------------------------------		----------------------------------------------------------------------
	Figure 3: Example of Hierarchical PCE architecture with BGP-LS		Figure 3: Example of Hierarchical PCE architecture with BGP-LS
	4. Including Inter-domain connectivity in BGP-LS		4. Including Inter-domain connectivity in BGP-LS
	TBD		TBD
	4.1. Mapping from OSPF-TE		4.1. Mapping from OSPF-TE
	TBD		TBD
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 27 ¶
	o Multiprotocol extensions		o Multiprotocol extensions
	6. Manageability Considerations		6. Manageability Considerations
	TBD		TBD
	7. Security Considerations		7. Security Considerations
	TBD		TBD
	8. Acknowledgements		8. References
	Authors would like to thank Stefano Previdi for his comments.
	9. References
	9.1. Normative References		8.1. Normative References
	[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.
	[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC		[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC
	4670, August 2006.		4670, August 2006.
	[RFC6805] King, D. and A. Farrel, "The Application of the Path		[RFC6805] King, D. and A. Farrel, "The Application of the Path
	Computation Element Architecture to the Determination of a		Computation Element Architecture to the Determination of a
	Sequence of Domains in MPLS and GMPLS", RFC 6805, November		Sequence of Domains in MPLS and GMPLS", RFC 6805, November
	2012.		2012.
	9.2. Informative References		8.2. Informative References
	[I-D.draft-dugeon-pce-ted-reqs-01]		[I-D.draft-dugeon-pce-ted-reqs-02]
	Dugeon, O., Meuric, J., Douville, R., Casellas, R., and O.		Dugeon, O., Meuric, J., Douville, R., Casellas, R., and O.
	Gonzalez de Dios, "Path Computation Element (PCE) Traffic		Gonzalez de Dios, "Path Computation Element (PCE) Traffic
	Engineering Database (TED) Requirements", March 2012.		Engineering Database (TED) Requirements", July 2013.
	[I-D.draft-ietf-idr-ls-distribution-03]		[I-D.draft-ietf-idr-ls-distribution-04]
	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", May 2013.		Information using BGP", November 2013.
	[I-D.draft-ietf-pce-hierarchy-extensions-00]		[I-D.draft-ietf-idr-te-pm-bgp-00]
	Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,		Wu, Q., Wang, D., Previdi, S., Gredler, H., and S. Ray,
	and D. King, "Extensions to Path Computation Element		"BGP attribute for North-Bound Distribution of Traffic
	Communication Protocol (PCEP) for Hierarchical Path		Engineering (TE) performance Metrics", January 2014.
	Computation Elements (PCE)", August 2013.
	[I-D.draft-ietf-pce-inter-area-as-applicability-03]		[I-D.draft-ietf-pce-inter-area-as-applicability-03]
	King, D., Meuric, J., Dugeon, O., Zhao, Q., and O.		King, D., Meuric, J., Dugeon, O., Zhao, Q., and O.
	Gonzalez de Dios, "Applicability of the Path Computation		Gonzalez de Dios, "Applicability of the Path Computation
	Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic		Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic
	Engineering", March 2012.		Engineering", February 2013.
			[I-D.draft-zhang-pce-hierarchy-extensions-04]
			Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
			and D. King, "Extensions to Path Computation Element
			Communication Protocol (PCEP) for Hierarchical Path
			Computation Elements (PCE)", July 2013.
	Authors' Addresses		Authors' Addresses
	Victor Lopez		Victor Lopez
	Telefonica I+D		Telefonica I+D
	Don Ramon de la Cruz 82-84		Don Ramon de la Cruz 82-84
	Madrid 28045		Madrid 28045
	Spain		Spain
	Phone: +34913128872		Phone: +34913128872
End of changes. 24 change blocks.
	74 lines changed or deleted		75 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/