< draft-ietf-ospf-two-part-metric-02.txt		draft-ietf-ospf-two-part-metric-03.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 1, 2016 Cisco Systems		Expires: June 6, 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
	November 29, 2015		December 4, 2015
	OSPF Two-part Metric		OSPF Two-part Metric
	draft-ietf-ospf-two-part-metric-02.txt		draft-ietf-ospf-two-part-metric-03.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.
	Requirements Language		Requirements Language
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 1, 2016.		This Internet-Draft will expire on June 6, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 26 ¶		skipping to change at page 2, line 26 ¶
	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. 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. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5		3.4. Advertising Network-to-Router TE Metric . . . . . . . . . 5
	3.5. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5		3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5
	3.6. Backward Compatibility . . . . . . . . . . . . . . . . . 6		3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5
			3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . 7		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		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
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 22 ¶
	need to be running any layer-3 protocol. Therefore for generality,		need to be running any layer-3 protocol. Therefore for generality,
	the metric is abstracted as to/from the "network" rather that		the metric is abstracted as to/from the "network" rather that
	specifically to/from the "satellite".		specifically to/from the "satellite".
	3. Speficications		3. Speficications
	The following protocol specifications are added to or modified from		The following protocol specifications are added to or modified from
	the base OSPF protocol. If an area contains one or more two-part		the base OSPF protocol. If an area contains one or more two-part
	metric networks, then all routers in the area must support the		metric networks, then all routers in the area must support the
	extensions specified herein. This is ensured by procedures described		extensions specified herein. This is ensured by procedures described
	in Section 3.6.		in Section 3.7.
	3.1. Router Interface Parameters		3.1. Router Interface Parameters
	The "Router interface parameters" have the following additions:		The "Router interface parameters" have the following additions:
	o Two-part metric: TRUE if the interface connects to a multi-access		o Two-part metric: TRUE if the interface connects to a multi-access
	network that uses two-part metric. All routers connected to the		network that uses two-part metric. All routers connected to the
	same network SHOULD have the same configuration for their		same network SHOULD have the same configuration for their
	corresponding interfaces.		corresponding interfaces.
	o Interface input cost: Link state metric from the two-part-metric		o Interface input cost: Link state metric from the two-part-metric
	network to this router. Defaulted to "Interface output cost" but		network to this router. Defaulted to "Interface output cost" but
	not valid for normal networks using a single metric. May be		not valid for normal networks using a single metric. May be
	configured or dynamically adjusted to a value different from the		configured or dynamically adjusted to a value different from the
	"Interface output cost".		"Interface output cost".
	3.2. Advertising Network-to-Router metric in OSPFv2		3.2. Advertising Network-to-Router Metric in OSPFv2
	For OSPFv2, the Network-to-Router metric is encoded in an OSPF		For OSPFv2, the Network-to-Router metric is encoded in an OSPF
	Extended Link TLV Sub-TLV [ietf-ospf-lsa-extend], defined in this		Extended Link TLV Sub-TLV [RFC7684], defined in this document as the
	document as the Network-to-Router Metric Sub-TLV. The type of the		Network-to-Router Metric Sub-TLV. The type of the Sub-TLV is TBD.
	Sub-TLV is TBD. The length of the Sub-TLV is 4 (for the value part		The length of the Sub-TLV is 4 (for the value part only). The value
	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. The OSPF Extended Link TLV identifies the
	transit link to the network, and is part of an OSPFv2 Extended-Link		transit link to the network, and is part of an OSPFv2 Extended-Link
	Opaque LSA. The Sub-TLV MUST ONLY appear in Extended-Link TLVs for		Opaque LSA. The Sub-TLV MUST ONLY appear in Extended-Link TLVs for
	Link Type 2 (link to transit network), and MUST be ignored if		Link Type 2 (link to transit network), and MUST be ignored if
	received for other link types.		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 [ietf-
	ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is not		ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is not
	defined so the only valid value for the MT field is 0 and only one		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		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. OSPF Stub Router Behavior		3.4. Advertising Network-to-Router TE Metric
			A Traffic Engineering Network-to-Router Metric Sub-TLV is defined,
			similar to the Traffic Engineering Metric Sub-TLV defined in
			Section 2.5.5 of [RFC 3630]. The only difference is the TLV type,
			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
			(OSPFv3) [RFC 5329], and MUST appear at most once in one such Link
			TLV.
			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.5. SPF Calculation		3.6. SPF Calculation
	During the first stage of shortest-path tree calculation for an area,		During the first stage of shortest-path tree calculation for an area,
	when a vertex V corresponding to a Network-LSA is added to the		when a vertex V corresponding to a Network-LSA is added to the
	shortest-path tree and its adjacent vertex W (joined by a link in V's		shortest-path tree and its adjacent vertex W (joined by a link in V's
	corresponding Network LSA), the cost from V to W, which is W's		corresponding Network LSA), the cost from V to W, which is W's
	network-to-router cost, is determined as follows:		network-to-router cost, is determined as 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 For OSPFv3, if vertex W has a corresponding E-Router-LSA with a
	Router-Link TLV for the link from W to V, and the Router-Link TLV		Router-Link TLV for the link from W to V, and the Router-Link TLV
	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.6. 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 [acee-
	ospf-rfc4970bis] that includes the following Router Functional		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.
	4. IANA Considerations		4. IANA Considerations
	This document requests IANA to assigna a new bit in the Router		This document requests the following IANA assignments:
	Functional Capabilities TLV to indicate the capability of supporting
	two-part metric, a new Sub-TLV in the OSPF Extended-Link TLV Sub-TLV		o A new bit in Registry for OSPF Router Informational Capability
	Registry, and a new Sub-TLV in the The OSPFv3 Extend-LSA Sub-TLV		Bits, to indicate the capability of supporting two-part metric.
	registry.
			o A new Sub-TLV type in OSPF Extended Link TLV Sub-TLV registry, for
			the Network-to-Router Metric Sub-TLV.
			o A new Sub-TLV type in OSPFv3 Extended-LSA Sub-TLV registry, for
			the Network-to-Router Metric Sub-TLV.
			o A new Sub-TLV type in Types for sub-TLVs of TE Link 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.		This document does not introduce new security risks.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank Abhay Roy, Hannes Gredler, Peter		The authors would like to thank Abhay Roy, Hannes Gredler, Peter
	Psenak and Eric Wu for their comments and suggestions.		Psenak and Eric Wu for their comments and suggestions.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.acee-ospf-rfc4970bis]		[I-D.acee-ospf-rfc4970bis]
	Lindem, A., Shen, N., Vasseur, J., Aggarwal, R., and S.		Lindem, A., Shen, N., Vasseur, J., Aggarwal, R., and S.
	Shaffer, "Extensions to OSPF for Advertising Optional		Shaffer, "Extensions to OSPF for Advertising Optional
	Router Capabilities", draft-acee-ospf-rfc4970bis-00 (work		Router Capabilities", draft-acee-ospf-rfc4970bis-00 (work
	in progress), July 2014.		in progress), July 2014.
	[I-D.ietf-ospf-lsa-extend]
	Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
	Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem,
	"OSPFv2 LSA Extendibility", draft-ietf-ospf-lsa-extend-00
	(work in progress), August 2014.
	[I-D.ietf-ospf-ospfv3-lsa-extend]		[I-D.ietf-ospf-ospfv3-lsa-extend]
	Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3		Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
	LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09		LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09
	(work in progress), November 2015.		(work in progress), November 2015.
	[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
			(TE) Extensions to OSPF Version 2", RFC 3630,
			DOI 10.17487/RFC3630, September 2003,
			<http://www.rfc-editor.org/info/rfc3630>.
	[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.,
			"Traffic Engineering Extensions to OSPF Version 3",
			RFC 5329, DOI 10.17487/RFC5329, September 2008,
			<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.		[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
	Yeung, "OSPF Link-Local Signaling", RFC 5613,		Yeung, "OSPF Link-Local Signaling", RFC 5613,
	DOI 10.17487/RFC5613, August 2009,		DOI 10.17487/RFC5613, August 2009,
	<http://www.rfc-editor.org/info/rfc5613>.		<http://www.rfc-editor.org/info/rfc5613>.
	[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>.
			[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
			Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
			Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
			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>.
	Authors' Addresses		Authors' Addresses
	Zhaohui Zhang		Zhaohui Zhang
End of changes. 18 change blocks.
	35 lines changed or deleted		63 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/