< draft-ietf-ospf-two-part-metric-03.txt		draft-ietf-ospf-two-part-metric-04.txt >
	Open Shortest Path First Z. Zhang		Open Shortest Path First Z. Zhang
	Internet-Draft L. Wang		Internet-Draft L. Wang
	Updates: 2328, 5340 (if approved) Juniper Networks, Inc.		Updates: 2328, 5340 (if approved) Juniper Networks, Inc.
	Intended status: Standards Track A. Lindem		Intended status: Standards Track A. Lindem
	Expires: June 6, 2016 Cisco Systems		Expires: November 5, 2016 Cisco Systems
	D. Dubois		D. Dubois
	General Dynamics C4S		General Dynamics C4S
	V. Julka		V. Julka
	T. McMillan		T. McMillan
	L3 Communications, Linkabit		L3 Communications, Linkabit
	December 4, 2015		May 4, 2016
	OSPF Two-part Metric		OSPF Two-part Metric
	draft-ietf-ospf-two-part-metric-03.txt		draft-ietf-ospf-two-part-metric-04.txt
	Abstract		Abstract
	This document specifies an optional extension to the OSPF protocol,		This document specifies an optional extension to the OSPF protocol,
	to represent the metric on a multi-access network as two parts: the		to represent the metric on a multi-access network as two parts: the
	metric from a router to the network, and the metric from the network		metric from a router to the network, and the metric from the network
	to the router. The router to router metric would be the sum of the		to the router. The router to router metric would be the sum of the
	two.		two. This document updates RFC 2328 and RFC 5340.
	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 RFC2119.		document are to be interpreted as described in [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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 June 6, 2016.		This Internet-Draft will expire on November 5, 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
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3		2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3
	3. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4		3. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4		3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4
	3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 4		3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 4
	3.3. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5		3.3. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5
	3.4. Advertising Network-to-Router TE Metric . . . . . . . . . 5		3.4. Advertising Network-to-Router TE Metric . . . . . . . . . 5
	3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5		3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5
	3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5		3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 6
	3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6		3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		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 . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	For a broadcast network, a Network-LSA is advertised to list all		With Open Shortest Path First (OSPF, [RFC2328, RFC5340]) protocol,
			for a broadcast network, a Network-LSA is advertised to list all
	routers on the network, and each router on the network includes a		routers on the network, and each router on the network includes a
	link in its Router-LSA to describe its connection to the network.		link in its Router-LSA to describe its connection to the network.
	The link in the Router-LSA includes a metric but the listed routers		The link in the Router-LSA includes a metric but the listed routers
	in the Network LSA do not include a metric. This is based on the		in the Network LSA do not include a metric. This is based on the
	assumption that from a particular router, all others on the same		assumption that from a particular router, all others on the same
	network can be reached with the same metric.		network can be reached with the same metric.
	With some broadcast networks, different routers can be reached with		With some broadcast networks, different routers can be reached with
	different metrics. RFC 6845 extends the OSPF protocol with a hybrid		different metrics. [RFC6845] extends the OSPF protocol with a hybrid
	interface type for that kind of broadcast network, where no Network		interface type for that kind of broadcast network, where no Network
	LSA is advertised and Router-LSAs simply include p2p links to all		LSA is advertised and Router-LSAs simply include p2p links to all
	routers on the same network with individual metrics. Broadcast		routers on the same network with individual metrics. Broadcast
	capability is still utilized to optimize database synchronization and		capability is still utilized to optimize database synchronization and
	adjacency maintenance.		adjacency maintenance.
	That works well for broadcast networks where the metric between		That works well for broadcast networks where the metric between
	different pair of routers are really independent. For example, VPLS		different pair of routers are really independent. For example, VPLS
	networks.		networks.
	With certain types of broadcast networks, further optimization can be		With certain types of broadcast networks, further optimization can be
	made to reduce the size of the Router-LSAs and number of updates.		made to reduce the size of the Router-LSAs and number of updates.
	Consider a satellite radio network with fixed and mobile ground		Consider a satellite radio network with fixed and mobile ground
	terminals. All communication goes through the satellite. When the		terminals. All communication goes through the satellite. When the
	mobile terminals move about, their communication capability may		mobile terminals move about, their communication capability may
	change. When OSPF runs over the radio network (routers being or in		change. When OSPF runs over the radio network (routers being or in
	tandem with the terminals), RFC 6845 hybrid interface can be used,		tandem with the terminals), [RFC6845] hybrid interface can be used,
	but with the following drawbacks.		but with the following drawbacks.
	Consider that one terminal/router moves into an area where its		Consider that one terminal/router moves into an area where its
	communication capability degrades significantly. Through the radio		communication capability degrades significantly. Through the radio
	control protocol, all other routers determine that the metric to this		control protocol, all other routers determine that the metric to this
	particular router changed and they all need to update their Router-		particular router changed and they all need to update their Router-
	LSAs accordingly. The router in question also determines that its		LSAs accordingly. The router in question also determines that its
	metric to reach all others also changed and it also needs to update		metric to reach all others also changed and it also needs to update
	its Router-LSA. Consider that there could be many terminals and many		its Router-LSA. Consider that there could be many terminals and many
	of them can be moving fast and frequently, the number/frequency of		of them can be moving fast and frequently, the number/frequency of
	skipping to change at page 3, line 44 ¶		skipping to change at page 3, line 45 ¶
	Notice that in the above scenario, when one terminal's communication		Notice that in the above scenario, when one terminal's communication
	capability changes, its metric to all other terminals and the metric		capability changes, its metric to all other terminals and the metric
	from all other terminals to it will all change in a similar fashion.		from all other terminals to it will all change in a similar fashion.
	Given this, the above problem can be easily addressed by breaking the		Given this, the above problem can be easily addressed by breaking the
	metric into two parts: the metric to the satellite and the metric		metric into two parts: the metric to the satellite and the metric
	from the satellite. The metric from terminal R1 to R2 would be the		from the satellite. The metric from terminal R1 to R2 would be the
	sum of the metric from R1 to the satellite and the metric from the		sum of the metric from R1 to the satellite and the metric from the
	satellite to R2.		satellite to R2.
	Now instead of using the RFC 6845 hybrid interface type, the network		Now instead of using the [RFC6845] hybrid interface type, the network
	is just treated as a regular broadcast network. A router on the		is just treated as a regular broadcast network. A router on the
	network no longer lists individual metrics to each neighbor in its		network no longer lists individual metrics to each neighbor in its
	Router-LSA. Instead, each router advertises the metric from the		Router-LSA. Instead, each router advertises the metric from the
	network to itself in addition to the normal metric for the network.		network to itself in addition to the normal metric for the network.
	With the normal Router-to-Network and additional Network-to-Router		With the normal Router-to-Network and additional Network-to-Router
	metrics advertised for each router, individual router-to-router		metrics advertised for each router, individual router-to-router
	metric can be calculated.		metric can be calculated.
	With the proposed enhancement, the size of Router-LSA will be		With the proposed enhancement, the size of Router-LSA will be
	significantly reduced. In addition, when a router's communication		significantly reduced. In addition, when a router's communication
	skipping to change at page 5, line 6 ¶		skipping to change at page 5, line 12 ¶
	The length of the Sub-TLV is 4 (for the value part only). The value		The length of the Sub-TLV is 4 (for the value part only). The value
	part of the Sub-TLV is defined as follows:		part of the Sub-TLV is defined as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MT | 0 | MT metric |		| MT | 0 | MT metric |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Multiple such Sub-TLVs can exist in a single OSPF Extended Link TLV,		Multiple such Sub-TLVs can exist in a single OSPF Extended Link TLV,
	one for each topology. The OSPF Extended Link TLV identifies the		one for each topology [RFC4915]. The OSPF Extended Link TLV
	transit link to the network, and is part of an OSPFv2 Extended-Link		identifies the transit link to the network, and is part of an OSPFv2
	Opaque LSA. The Sub-TLV MUST ONLY appear in Extended-Link TLVs for		Extended-Link Opaque LSA. The Sub-TLV MUST ONLY appear in Extended-
	Link Type 2 (link to transit network), and MUST be ignored if		Link TLVs for Link Type 2 (link to transit network), and MUST be
	received for other link types.		ignored if received for other link types.
	3.3. Advertising Network-to-Router Metric in OSPFv3		3.3. Advertising Network-to-Router Metric in OSPFv3
	For OSPFv3, the same Network-to-Router Metric Sub-TLV definition is		For OSPFv3, the same Network-to-Router Metric Sub-TLV definition is
	used, though it is part of the Router-Link TLV of E-Router-LSA [ietf-		used, though it is part of the Router-Link TLV of E-Router-LSA [I-
	ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is not		D.ietf-ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is
	defined so the only valid value for the MT field is 0 and only one		not defined so the only valid value for the MT field is 0 and only
	such Sub-TLV SHOULD be included in the Router-Link TLV. Received		one such Sub-TLV SHOULD be included in the Router-Link TLV. Received
	Sub-TLVs with non-zero MT field MUST be ignored.		Sub-TLVs with non-zero MT field MUST be ignored.
	Similarly, the Sub-TLV MUST ONLY appear in Router-Link TLVs for Link		Similarly, the Sub-TLV MUST ONLY appear in Router-Link TLVs for Link
	Type 2 (connection to a transit network) and MUST be ignored if		Type 2 (connection to a transit network) and MUST be ignored if
	received for other link types.		received for other link types.
	3.4. Advertising Network-to-Router TE Metric		3.4. Advertising Network-to-Router TE Metric
	A Traffic Engineering Network-to-Router Metric Sub-TLV is defined,		A Traffic Engineering Network-to-Router Metric Sub-TLV is defined,
	similar to the Traffic Engineering Metric Sub-TLV defined in		similar to the Traffic Engineering Metric Sub-TLV defined in
	Section 2.5.5 of [RFC 3630]. The only difference is the TLV type,		Section 2.5.5 of [RFC3630]. The only difference is the TLV type,
	which is TBD. The Sub-TLV MUST only appear in type 2 Link TLVs		which is TBD. The Sub-TLV MUST only appear in type 2 Link TLVs
	(Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs		(Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs
	(OSPFv3) [RFC 5329], and MUST appear at most once in one such Link		(OSPFv3) [RFC5329], and MUST appear at most once in one such Link
	TLV.		TLV.
	3.5. OSPF Stub Router Behavior		3.5. OSPF Stub Router Behavior
	When an OSPF router with interfaces including two-part metric is		When an OSPF router with interfaces including two-part metric is
	advertising itself as a stub router [RFC6987], only the Router-to-		advertising itself as a stub router [RFC6987], only the Router-to-
	Network metric in the stub router's OSPF Router-LSA links is set to		Network metric in the stub router's OSPF Router-LSA links is set to
	the MaxLinkMetric. This is fully backward compatible and will result		the MaxLinkMetric. This is fully backward compatible and will result
	in the same behavior as [RFC6987].		in the same behavior as [RFC6987].
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 31 ¶
	has a Network-to-Router Metric Sub-TLV, then the cost from V to W		has a Network-to-Router Metric Sub-TLV, then the cost from V to W
	is the metric in the Sub-TLV. If not, the cost is 0.		is the metric in the Sub-TLV. If not, the cost is 0.
	3.7. Backward Compatibility		3.7. Backward Compatibility
	Due to the change of procedures in the SPF calculation, all routers		Due to the change of procedures in the SPF calculation, all routers
	in an area that includes one or more two-part metric networks must		in an area that includes one or more two-part metric networks must
	support the changes specified in this document. To ensure that, if		support the changes specified in this document. To ensure that, if
	an area is provisioned to support two-part metric networks, all		an area is provisioned to support two-part metric networks, all
	routers supporting this capability must advertise a Router		routers supporting this capability must advertise a Router
	Information (RI) LSA with a Router Functional Capabilities TLV [acee-		Information (RI) LSA with a Router Functional Capabilities TLV [I-
	ospf-rfc4970bis] that includes the following Router Functional		D.acee-ospf-rfc4970bis] that includes the following Router Functional
	Capability Bit:		Capability Bit:
	Bit Capabilities		Bit Capabilities
	0 OSPF Two-part Metric [TPM]		0 OSPF Two-part Metric [TPM]
	Upon detecting the presence of a reachable Router-LSA without a		Upon detecting the presence of a reachable Router-LSA without a
	companion RI LSA that has the bit set, all routers MUST recalculate		companion RI LSA that has the bit set, all routers MUST recalculate
	routes w/o considering any network-to-router costs.		routes w/o considering any network-to-router costs.
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 14 ¶
	[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,
	<http://www.rfc-editor.org/info/rfc5329>.		<http://www.rfc-editor.org/info/rfc5329>.
	[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF		[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
	for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,		for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
	<http://www.rfc-editor.org/info/rfc5340>.		<http://www.rfc-editor.org/info/rfc5340>.
	[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
	Yeung, "OSPF Link-Local Signaling", RFC 5613,
	DOI 10.17487/RFC5613, August 2009,
	<http://www.rfc-editor.org/info/rfc5613>.
	[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
	McPherson, "OSPF Stub Router Advertisement", RFC 6987,
	DOI 10.17487/RFC6987, September 2013,
	<http://www.rfc-editor.org/info/rfc6987>.
	[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,		[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
	Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute		Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
	Advertisement", RFC 7684, DOI 10.17487/RFC7684, November		Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
	2015, <http://www.rfc-editor.org/info/rfc7684>.		2015, <http://www.rfc-editor.org/info/rfc7684>.
	7.2. Informative References		7.2. Informative References
	[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast		[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast
	and Point-to-Multipoint Interface Type", RFC 6845,		and Point-to-Multipoint Interface Type", RFC 6845,
	DOI 10.17487/RFC6845, January 2013,		DOI 10.17487/RFC6845, January 2013,
	<http://www.rfc-editor.org/info/rfc6845>.		<http://www.rfc-editor.org/info/rfc6845>.
			[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
			McPherson, "OSPF Stub Router Advertisement", RFC 6987,
			DOI 10.17487/RFC6987, September 2013,
			<http://www.rfc-editor.org/info/rfc6987>.
	Authors' Addresses		Authors' Addresses
	Zhaohui Zhang		Zhaohui Zhang
	Juniper Networks, Inc.		Juniper Networks, Inc.
	10 Technology Park Drive		10 Technology Park Drive
	Westford, MA 01886		Westford, MA 01886
	EMail: zzhang@juniper.net		EMail: zzhang@juniper.net
	Lili Wang		Lili Wang
End of changes. 19 change blocks.
	35 lines changed or deleted		31 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/