draft-ietf-ccamp-inter-domain-framework-03.txt		draft-ietf-ccamp-inter-domain-framework-04.txt
	Network Working Group Adrian Farrel		Network Working Group Adrian Farrel
	IETF Internet Draft Olddog Consulting		IETF Internet Draft Olddog Consulting
	Proposed Status: Informational		Proposed Status: Informational
	Expires: December 2005 Jean-Philippe Vasseur		Expires: January 2006 Jean-Philippe Vasseur
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Arthi Ayyangar		Arthi Ayyangar
	Juniper Networks		Juniper Networks
	June 2005		July 2005
	A Framework for Inter-Domain MPLS Traffic Engineering		A Framework for Inter-Domain MPLS Traffic Engineering
	draft-ietf-ccamp-inter-domain-framework-03.txt		draft-ietf-ccamp-inter-domain-framework-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at line 77		skipping to change at line 77
	3. Path Computation Techniques ................................ 6		3. Path Computation Techniques ................................ 6
	3.1. Management Configuration ............................... 7		3.1. Management Configuration ............................... 7
	3.2. Head End Computation ................................... 7		3.2. Head End Computation ................................... 7
	3.2.1. Multi-Domain Visibility Computation ................ 7		3.2.1. Multi-Domain Visibility Computation ................ 7
	3.2.2. Partial Visibility Computation ..................... 7		3.2.2. Partial Visibility Computation ..................... 7
	3.2.3. Local Domain Visibility Computation ................ 8		3.2.3. Local Domain Visibility Computation ................ 8
	3.3. Domain Boundary Computation ............................ 8		3.3. Domain Boundary Computation ............................ 8
	3.4. Path Computation Element ............................... 9		3.4. Path Computation Element ............................... 9
	3.4.1. Multi-Domain Visibility Computation ................ 9		3.4.1. Multi-Domain Visibility Computation ................ 9
	3.4.2. Path Computation Use of PCE When Preserving		3.4.2. Path Computation Use of PCE When Preserving
	Confidentiality .................................... 9		Confidentiality ................................... 10
	3.4.3. Per-Domain Computation Servers .................... 10		3.4.3. Per-Domain Computation Servers .................... 10
	3.5. Optimal Path Computation .............................. 10		3.5. Optimal Path Computation .............................. 10
	4. Distributing Reachability and TE Information .............. 10		4. Distributing Reachability and TE Information .............. 11
	5. Comments on Advanced Functions ............................ 11		5. Comments on Advanced Functions ............................ 12
	5.1. LSP Re-Optimization ................................... 12		5.1. LSP Re-Optimization ................................... 12
	5.2. LSP Setup Failure ..................................... 12		5.2. LSP Setup Failure ..................................... 13
	5.3. LSP Repair ............................................ 13		5.3. LSP Repair ............................................ 13
	5.4. Fast Reroute .......................................... 13		5.4. Fast Reroute .......................................... 14
	5.5. Comments on Path Diversity ............................ 14		5.5. Comments on Path Diversity ............................ 15
	5.6. Domain-Specific Constraints ........................... 15		5.6. Domain-Specific Constraints ........................... 15
	5.7. Policy Control ........................................ 16		5.7. Policy Control ........................................ 16
	5.8. Inter-domain OAM ...................................... 16		5.8. Inter-domain OAM ...................................... 16
	5.9. Point-to-Multipoint ................................... 16		5.9. Point-to-Multipoint ................................... 16
	5.10. Applicability to Non-Packet Technologies ............. 16		5.10. Applicability to Non-Packet Technologies ............. 17
	6. Security Considerations ................................... 17		6. Security Considerations ................................... 17
	7. IANA Considerations ....................................... 17		7. IANA Considerations ....................................... 17
	8. Acknowledgements .......................................... 17		8. Acknowledgements .......................................... 17
	9. Intellectual Property Considerations ...................... 17		9. Intellectual Property Considerations ...................... 17
	10. Normative References ..................................... 18		10. Normative References ..................................... 18
	11. Informational References ................................. 18		11. Informational References ................................. 18
	12. Authors' Addresses ....................................... 19		12. Authors' Addresses ....................................... 20
	13. Full Copyright Statement ................................. 20		13. Full Copyright Statement ................................. 20
	1. Introduction		1. Introduction
	The Traffic Engineering Working Group has developed requirements for		The Traffic Engineering Working Group has developed requirements for
	inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and		inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and
	[INTER-AS].		[INTER-AS].
	Various proposals have subsequently been made to address some or all		Various proposals have subsequently been made to address some or all
	of these requirements through extensions to the RSVP-TE and IGP		of these requirements through extensions to the RSVP-TE and IGP
	skipping to change at line 400		skipping to change at line 400
	If the LSR at the domain boundary has only partial visibility (using		If the LSR at the domain boundary has only partial visibility (using
	the definitions of section 3.2.2) it will fill in the path as far as		the definitions of section 3.2.2) it will fill in the path as far as
	the next domain boundary, and will supply further domain/domain		the next domain boundary, and will supply further domain/domain
	boundary information if not already present in the ERO.		boundary information if not already present in the ERO.
	If the LSR at the domain boundary has only local visibility into the		If the LSR at the domain boundary has only local visibility into the
	immediate domain it will simply add information to the ERO to carry		immediate domain it will simply add information to the ERO to carry
	the Path message as far as the next domain boundary.		the Path message as far as the next domain boundary.
			Domain boundary path computations are performed independently from
			each other. Domain boundary LSRs may have different computation
			capabilities, run different path computation algorithms, apply
			different sets of constraints and optimization criteria, and so
			forth, which might result in path segment quality which is
			unpredictable to and out of the control of the ingress LSR. A
			solution to this issue lies in enhancing the informaiton signaled
			during LSP setup to include a larger set of constraints and to
			include the paths of related LSPs (such as diverse protected LSPs)
			as described in [GMPLS-E2E].
			It is also the case that paths generated on domain boundaries may
			produce loops. Specifically, the paths computed may loop back into a
			domain that has already been crossed by the LSP. This may, or may not
			be a problem, and might even be desirable, but could also give rise
			to real loops. This can be avoided by using the recorded route (RRO)
			to provide exclusions within the path computation algorithm, but in
			the case of lack of trust between domains it may be necessary for the
			RRO to indicate the previously visited domains. Even this solution is
			not available where the RRO is not available on a Path message. Note
			that when an RRO is used to provide exclusions, and a loop-free path
			is found to be not available by the computation at a downstream
			border node, crankback [CRANKBACK] may enable an upstream border node
			to select an alternate path.
	3.4. Path Computation Element		3.4. Path Computation Element
	The computation techniques in sections 3.2 and 3.3 rely on topology		The computation techniques in sections 3.2 and 3.3 rely on topology
	and TE information being distributed to the ingress LSR and those		and TE information being distributed to the ingress LSR and those
	LSRs at domain boundaries. These LSRs are responsible for computing		LSRs at domain boundaries. These LSRs are responsible for computing
	paths. Note that there may be scaling concerns with distributing the		paths. Note that there may be scaling concerns with distributing the
	required information - see section 4.		required information - see section 4.
	An alternative technique places the responsibility for path		An alternative technique places the responsibility for path
	computation with a Path Computation Element (PCE) [PCE]. There may be		computation with a Path Computation Element (PCE) [PCE]. There may be
	skipping to change at line 903		skipping to change at line 928
	progress.		progress.
	[FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE		[FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
	for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute,		for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute,
	work in progress.		work in progress.
	[GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS		[GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS
	Traffic Engineering Requirements",		Traffic Engineering Requirements",
	draft-otani-ccamp-interas-GMPLS-TE, work in progress.		draft-otani-ccamp-interas-GMPLS-TE, work in progress.
			[GMPLS-E2E] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors,
			"RSVP-TE Extensions in support of End-to-End
			GMPLS-based Recovery",
			draft-lang-ccamp-gmpls-recovery-e2e-signaling, work in
			progress.
	[HIER] Kompella K., Rekhter Y., "LSP Hierarchy with		[HIER] Kompella K., Rekhter Y., "LSP Hierarchy with
	Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy,		Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy,
	work in progress.		work in progress.
	[INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of		[INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of
	Inter-Area and Inter-AS MPLS Traffic Engineering",		Inter-Area and Inter-AS MPLS Traffic Engineering",
	draft-ietf-tewg-interarea-mpls-te-req, work in		draft-ietf-tewg-interarea-mpls-te-req, work in
	progress.		progress.
	[INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic		[INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic
End of changes.
This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/