draft-ietf-ospf-xaf-te-04.txt		draft-ietf-ospf-xaf-te-05.txt
	LSR A. Smirnov		LSR A. Smirnov
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Updates: 5786 (if approved) A. Retana		Updates: 5786 (if approved) A. Retana
	Intended status: Standards Track Huawei R&D USA		Intended status: Standards Track Huawei R&D USA
	Expires: April 25, 2019 M. Barnes		Expires: June 13, 2019 M. Barnes
	Cisco Systems, Inc.		Cisco Systems, Inc.
	October 22, 2018		December 10, 2018
	OSPF Routing with Cross-Address Family Traffic Engineering Tunnels		OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
	draft-ietf-ospf-xaf-te-04		draft-ietf-ospf-xaf-te-05
	Abstract		Abstract
	When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6		When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6
	network, the Multiprotocol Label Switching (MPLS) TE Label Switched		network, the Multiprotocol Label Switching (MPLS) TE Label Switched
	Paths (LSP) infrastructure may be duplicated, even if the destination		Paths (LSP) infrastructure may be duplicated, even if the destination
	IPv4 and IPv6 addresses belong to the same remote router. In order		IPv4 and IPv6 addresses belong to the same remote router. In order
	to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must		to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must
	be computed over MPLS TE tunnels created using information propagated		be computed over MPLS TE tunnels created using information propagated
	in another OSPF instance. This issue is solved by advertising cross-		in another OSPF instance. This issue is solved by advertising cross-
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 25, 2019.		This Internet-Draft will expire on June 13, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5		4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6
	4.1. Automatically Switched Optical Networks . . . . . . . . . 6		4.1. Automatically Switched Optical Networks . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	business characteristics and/or applications or class of service, not		business characteristics and/or applications or class of service, not
	constrained by the network protocol used.		constrained by the network protocol used.
	For example, an LSP created based on MPLS TE information propagated		For example, an LSP created based on MPLS TE information propagated
	by an OSPFv2 instance can be used to transport both IPv4 and IPv6		by an OSPFv2 instance can be used to transport both IPv4 and IPv6
	traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a		traffic, as opposed to using both OSPFv2 and OSPFv3 to provision a
	separate LSP for each address family. Even if in some cases the		separate LSP for each address family. Even if in some cases the
	address family-specific traffic is to be separated, calculation from		address family-specific traffic is to be separated, calculation from
	a common database may prove to be operationally beneficial.		a common database may prove to be operationally beneficial.
	A requirement when creating a common MPLS TE infrastructure is the		During the SPF calculation on the TE tunnel head-end router, OSPF
	ability to reliably map the X-AF family addresses to the		computes shortcut routes using TE tunnels. A commonly used algorithm
	corresponding advertising tail-end router. This mapping is a		for computing shortcuts is defined in [RFC3906]. For that, or any
			similar, algorithm to work with a common MPLS TE infrastructure in a
			dual-stack network, a requirement is to reliably map the X-AF
			addresses to the corresponding tail-end router. This mapping is a
	challenge because the LSAs containing the routing information are		challenge because the LSAs containing the routing information are
	carried in one OSPF instance while the TE calculation may be done		carried in one OSPF instance while the TE calculations may be done
	using a TE database from a different instance.		using a TE database from a different OSPF instance.
	A simple solution to this problem is to rely on the Router ID to		A simple solution to this problem is to rely on the Router ID to
	identify a node in the corresponding OSPFv2 and OSPFv3 databases.		identify a node in the corresponding OSPFv2 and OSPFv3 databases.
	This solution would mandate both instances on the same router to be		This solution would mandate both instances on the same router to be
	configured with the same Router ID. However, relying on the		configured with the same Router ID. However, relying on the
	correctness of configuration puts additional burden and cost on the		correctness of configuration puts additional burden and cost on the
	operation of the network. The network becomes even more difficult to		operation of the network. The network becomes even more difficult to
	manage if OSPFv2 and OSPFv3 topologies do not match exactly, for		manage if OSPFv2 and OSPFv3 topologies do not match exactly, for
	example if area borders are chosen differently in the two protocols.		example if area borders are chosen differently in the two protocols.
	Also, if the routing processes do fall out of sync (e.g., having		Also, if the routing processes do fall out of sync (e.g., having
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 27 ¶
	one or more local X-AF addresses using the corresponding Local		one or more local X-AF addresses using the corresponding Local
	Address sub-TLV. In other words, to implement the X-AF routing		Address sub-TLV. In other words, to implement the X-AF routing
	technique described in this document, OSPFv2 will advertise the Node		technique described in this document, OSPFv2 will advertise the Node
	IPv6 Local Address sub-TLV and OSPFv3 will advertise the Node IPv4		IPv6 Local Address sub-TLV and OSPFv3 will advertise the Node IPv4
	Local Address sub-TLV, possibly in addition to advertising other IP		Local Address sub-TLV, possibly in addition to advertising other IP
	addresses as documented by [RFC5786].		addresses as documented by [RFC5786].
	A node that implements X-AF routing SHOULD advertise, in the		A node that implements X-AF routing SHOULD advertise, in the
	corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6		corresponding Node Local Address sub-TLV, all X-AF IPv4 and IPv6
	addresses local to the router that can be used by Constrained SPF		addresses local to the router that can be used by Constrained SPF
	(CSPF) to calculate MPLS TE LSPs. In general, OSPF SHOULD advertise		(CSPF) to calculate MPLS TE LSPs. OSPF MUST advertise the IP address
	the IP address listed in the Router Address TLV [RFC3630] [RFC5329]		listed in the Router Address TLV [RFC3630] [RFC5329] of the X-AF
	of the X-AF instance maintaining the MPLS TE database, plus any		instance maintaining the MPLS TE database, and SHOULD include
	additional local addresses advertised by the X-AF OSPF instance in		additional local addresses advertised by the X-AF OSPF instance in
	its Node Local Address sub-TLVs. An implementation MAY advertise		its Node Local Address sub-TLVs. An implementation MAY advertise
	other local X-AF addresses.		other local X-AF addresses.
	If the Node Attribute TLV carries both the Node IPv4 Local Address		If the Node Attribute TLV carries both the Node IPv4 Local Address
	sub-TLV and the Node IPv6 Local Address sub-TLV, then the X-AF		sub-TLV and the Node IPv6 Local Address sub-TLV, then the X-AF
	component MUST be considered for the consolidated calculation of MPLS		component MUST be considered for the consolidated calculation of MPLS
	TE LSPs. Both instances MAY advertise the required information and		TE LSPs. Both instances MAY advertise the required information and
	it is left to local configuration to determine which database is		it is left to local configuration to determine which database is
	used.		used.
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 8 ¶
	connected to the same set of areas to know with which area to		connected to the same set of areas to know with which area to
	associate computed MPLS TE tunnels.		associate computed MPLS TE tunnels.
	During the X-AF routing calculation, X-AF IP addresses are used to		During the X-AF routing calculation, X-AF IP addresses are used to
	map locally created LSPs to tail-end routers in the Link State		map locally created LSPs to tail-end routers in the Link State
	Database (LSDB). The mapping algorithm can be described as:		Database (LSDB). The mapping algorithm can be described as:
	Walk the list of all MPLS TE tunnels for which the computing		Walk the list of all MPLS TE tunnels for which the computing
	router is a head-end. For each MPLS TE tunnel T:		router is a head-end. For each MPLS TE tunnel T:
	1. If T's destination IP address is from the same address family as		1. If T's destination address is from the same address family as the
	the computing OSPF instance, then the tunnel must have been		OSPF instance associated with the LSDB, then the extensions
	signaled based on MPLS TE information propagated in the same OSPF		defined in this document do not apply.
	instance. Process the tunnel as per [RFC3630] or [RFC5329].
	2. Otherwise it is a X-AF MPLS TE tunnel. Note tunnel's destination		2. Otherwise it is a X-AF MPLS TE tunnel. Note tunnel's destination
	IP address.		IP address.
	3. Walk the X-AF IP addresses in the LSDBs of all connected areas.		3. Walk the X-AF IP addresses in the LSDBs of all connected areas.
	If a matching IP address is found, advertised by router R in area		If a matching IP address is found, advertised by router R in area
	A, then mark the tunnel T as belonging to area A and terminating		A, then mark the tunnel T as belonging to area A and terminating
	on tail-end router R. Assign the intra-area SPF cost to reach		on tail-end router R. Assign the intra-area SPF cost to reach
	router R within area A as the IGP cost of tunnel T.		router R within area A as the IGP cost of tunnel T.
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 37 ¶
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998,		DOI 10.17487/RFC2328, April 1998,
	<https://www.rfc-editor.org/info/rfc2328>.		<https://www.rfc-editor.org/info/rfc2328>.
	[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering		[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
	(TE) Extensions to OSPF Version 2", RFC 3630,		(TE) Extensions to OSPF Version 2", RFC 3630,
	DOI 10.17487/RFC3630, September 2003,		DOI 10.17487/RFC3630, September 2003,
	<https://www.rfc-editor.org/info/rfc3630>.		<https://www.rfc-editor.org/info/rfc3630>.
			[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway
			Protocol (IGP) Routes Over Traffic Engineering Tunnels",
			RFC 3906, DOI 10.17487/RFC3906, October 2004,
			<https://www.rfc-editor.org/info/rfc3906>.
	[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-		[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
	Multipoint Traffic-Engineered MPLS Label Switched Paths		Multipoint Traffic-Engineered MPLS Label Switched Paths
	(LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,		(LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,
	<https://www.rfc-editor.org/info/rfc4461>.		<https://www.rfc-editor.org/info/rfc4461>.
	[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,		[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
	"Traffic Engineering Extensions to OSPF Version 3",		"Traffic Engineering Extensions to OSPF Version 3",
	RFC 5329, DOI 10.17487/RFC5329, September 2008,		RFC 5329, DOI 10.17487/RFC5329, September 2008,
	<https://www.rfc-editor.org/info/rfc5329>.		<https://www.rfc-editor.org/info/rfc5329>.
End of changes. 10 change blocks.
	17 lines changed or deleted		24 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/