< draft-ietf-ospf-two-part-metric-08.txt		draft-ietf-ospf-two-part-metric-09.txt >
	Network Working Group Z. Zhang		Network Working Group 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: February 13, 2017 Cisco Systems		Expires: March 2, 2017 Cisco Systems
	August 12, 2016		August 29, 2016
	OSPF Two-part Metric		OSPF Two-part Metric
	draft-ietf-ospf-two-part-metric-08.txt		draft-ietf-ospf-two-part-metric-09.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. This document updates RFC 2328 and RFC 5340.		two. This document updates RFC 2328.
	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 February 13, 2017.		This Internet-Draft will expire on March 2, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	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. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	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 TE Metric . . . . . . . . . 5
	3.4. Advertising Network-to-Router TE Metric . . . . . . . . . 5		3.4. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5
	3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5		3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5
	3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5		3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . . . . 6
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Normative References . . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . 6
	6.2. Informative References . . . . . . . . . . . . . . . . . 8		6.2. Informative References . . . . . . . . . . . . . . . . . 7
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
	Appendix B. Contributors' Addreses . . . . . . . . . . . . . . . 9		Appendix B. Contributors' Addreses . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	With Open Shortest Path First (OSPF, [RFC2328], [RFC5340]) protocol,		With Open Shortest Path First (OSPF, [RFC2328], [RFC5340]) protocol,
	for a broadcast network, a Network-LSA is advertised to list all		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.
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 12 ¶
	| 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 [RFC4915]. The OSPF Extended Link TLV		one for each topology [RFC4915]. The OSPF Extended Link TLV
	identifies the transit link to the network, and is part of an OSPFv2		identifies the transit link to the network, and is part of an OSPFv2
	Extended-Link Opaque LSA. The Sub-TLV MUST ONLY appear in Extended-		Extended-Link Opaque LSA. The Sub-TLV MUST ONLY appear in Extended-
	Link TLVs for Link Type 2 (link to transit network), and MUST be		Link TLVs for Link Type 2 (link to transit network), and MUST be
	ignored if 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 TE Metric
	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
	[I-D.ietf-ospf-ospfv3-lsa-extend] and the type is TBD3. Currently
	OSPFv3 Multi-Toplogy is not defined so the only valid value for the
	MT field is 0 and only one such Sub-TLV SHOULD be included in the
	Router-Link TLV. Received Sub-TLVs with non-zero MT field MUST be
	ignored.
	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
	received for other link types.
	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 [RFC3630]. The only difference is the TLV type,		Section 2.5.5 of [RFC3630]. The only difference is the TLV type,
	which is TBD4. The Sub-TLV MUST only appear in type 2 Link TLVs		which is TBD3. 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) [RFC5329], 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.4. Advertising Network-to-Router Metric in OSPFv3
			Network-to-Router metric advertisement in OSPFv3 Extended-Router-LSA
			[I-D.ietf-ospf-ospfv3-lsa-extend] will be described in a separate
			document.
	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].
	3.6. SPF Calculation		3.6. SPF Calculation
	The first stage of the shortest-path tree calculation is described in		The first stage of the shortest-path tree calculation is described in
	section 16.1 of [RFC2328] and modified for OSPFv3 as described in		section 16.1 of [RFC2328]. With two-part metric, when a vertex V
	section 4.8.1 of [RFC5340]. With two-part metric, when a vertex V
	corresponding to a Network-LSA has just been added to the Shortest		corresponding to a Network-LSA has just been added to the Shortest
	Path Tree (SPT) and an adjacent vertex W (joined by a link in V's		Path Tree (SPT) and an adjacent vertex W (joined by a link in V's
	corresponding Network-LSA) is being added to the candidate list, the		corresponding Network-LSA) is being added to the candidate list, the
	cost from V to W (W's network-to-router cost) is determined as		cost from V to W (W's network-to-router cost) is determined as
	follows:		follows:
	o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque		o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque
	LSA with an Extended Link TLV for the link from W to V, and the		LSA with an Extended Link TLV for the link from W to V, and the
	Extended Link TLV has a Network-to-Router Metric Sub-TLV for the		Extended Link TLV has a Network-to-Router Metric Sub-TLV for the
	corresponding topology, then the cost from V to W is the metric in		corresponding topology, then the cost from V to W is the metric in
	the Sub-TLV. Otherwise, the cost is 0.		the Sub-TLV. Otherwise, the cost is 0.
	o For OSPFv3, if vertex W has a corresponding E-Router-LSA with a		o OSPFv3 [RFC5340] SPF changes will be described in a separate
	Router-Link TLV for the link from W to V, and the Router-Link TLV		document.
	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.
	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		Information (RI) LSA with a Router Functional Capabilities TLV
	[RFC7770] that includes the following Router Functional Capability		[RFC7770] that includes the following Router Functional Capability
	skipping to change at page 6, line 48 ¶		skipping to change at page 6, line 38 ¶
	This document requests the following IANA assignments:		This document requests the following IANA assignments:
	o A new bit (TBD1) in Registry for OSPF Router Informational		o A new bit (TBD1) in Registry for OSPF Router Informational
	Capability Bits, to indicate the capability of supporting two-part		Capability Bits, to indicate the capability of supporting two-part
	metric.		metric.
	o A new Sub-TLV type (TBD2) in OSPF Extended Link TLV Sub-TLV		o A new Sub-TLV type (TBD2) in OSPF Extended Link TLV Sub-TLV
	registry, for the Network-to-Router Metric Sub-TLV.		registry, for the Network-to-Router Metric Sub-TLV.
	o A new Sub-TLV type (TBD3) in OSPFv3 Extended-LSA Sub-TLV registry,		o A new Sub-TLV type (TBD3) in Types for sub-TLVs of TE Link TLV
	for the Network-to-Router Metric Sub-TLV.
	o A new Sub-TLV type (TBD4) in Types for sub-TLVs of TE Link TLV
	(Value 2) registry, for the Network-to-Router TE Metric Sub-TLV.		(Value 2) registry, for the Network-to-Router TE Metric Sub-TLV.
	5. Security Considerations		5. Security Considerations
	This document does not introduce new security risks. Existing		This document does not introduce new security risks. Existing
	security considerations in OSPFv2 and OSPFv3 apply.		security considerations in OSPFv2 and OSPFv3 apply.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-ospf-ospfv3-lsa-extend]
	Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
	LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-10
	(work in progress), May 2016.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[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,
	<http://www.rfc-editor.org/info/rfc2328>.		<http://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
	skipping to change at page 7, line 46 ¶		skipping to change at page 7, line 29 ¶
	[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.		[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
	Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",		Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
	RFC 4915, DOI 10.17487/RFC4915, June 2007,		RFC 4915, DOI 10.17487/RFC4915, June 2007,
	<http://www.rfc-editor.org/info/rfc4915>.		<http://www.rfc-editor.org/info/rfc4915>.
	[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
	for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
	<http://www.rfc-editor.org/info/rfc5340>.
	[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>.
	[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and		[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
	S. Shaffer, "Extensions to OSPF for Advertising Optional		S. Shaffer, "Extensions to OSPF for Advertising Optional
	Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,		Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
	February 2016, <http://www.rfc-editor.org/info/rfc7770>.		February 2016, <http://www.rfc-editor.org/info/rfc7770>.
	6.2. Informative References		6.2. Informative References
			[I-D.ietf-ospf-ospfv3-lsa-extend]
			Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
			LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-10
			(work in progress), May 2016.
			[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
			for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
			<http://www.rfc-editor.org/info/rfc5340>.
	[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.		[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
	McPherson, "OSPF Stub Router Advertisement", RFC 6987,		McPherson, "OSPF Stub Router Advertisement", RFC 6987,
	DOI 10.17487/RFC6987, September 2013,		DOI 10.17487/RFC6987, September 2013,
	<http://www.rfc-editor.org/info/rfc6987>.		<http://www.rfc-editor.org/info/rfc6987>.
End of changes. 15 change blocks.
	46 lines changed or deleted		32 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/