< draft-ietf-ospf-two-part-metric-06.txt		draft-ietf-ospf-two-part-metric-07.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 6, 2017 Cisco Systems		Expires: February 9, 2017 Cisco Systems
	August 5, 2016		August 8, 2016
	OSPF Two-part Metric		OSPF Two-part Metric
	draft-ietf-ospf-two-part-metric-06.txt		draft-ietf-ospf-two-part-metric-07.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 and RFC 5340.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	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 February 6, 2017.		This Internet-Draft will expire on February 9, 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 30 ¶		skipping to change at page 2, line 22 ¶
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
			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 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 . . . . . . . . . . . . . . . . . . . . . 6		3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 6
	3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6		3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 37 ¶
	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
	updates of those large Router-LSAs could inhibit network scaling.		updates of those large Router-LSAs could inhibit network scaling.
			1.1. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
	2. Proposed Enhancement		2. Proposed Enhancement
	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.
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	the radio level (layer-2), at layer-3, the satellite does not		the radio level (layer-2), at layer-3, the satellite does not
	participate in packet forwarding. In fact, the satellite does not		participate in packet forwarding. In fact, the satellite does not
	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.7.		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
	skipping to change at page 4, line 52 ¶		skipping to change at page 4, line 52 ¶
	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 [RFC7684], defined in this document as the		Extended Link TLV Sub-TLV [RFC7684], defined in this document as the
	Network-to-Router Metric Sub-TLV. The type of the Sub-TLV is TBD.		Network-to-Router Metric Sub-TLV. The type of the Sub-TLV is TBD2.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 25 ¶
	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 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		used, though it is part of the Router-Link TLV of E-Router-LSA
	[I-D.ietf-ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is		[I-D.ietf-ospf-ospfv3-lsa-extend] and the type is TBD3. Currently
	not defined so the only valid value for the MT field is 0 and only		OSPFv3 Multi-Toplogy is not defined so the only valid value for the
	one such Sub-TLV SHOULD be included in the Router-Link TLV. Received		MT field is 0 and only one such Sub-TLV SHOULD be included in the
	Sub-TLVs with non-zero MT field MUST be ignored.		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		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 [RFC3630]. 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 TBD4. 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.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
	During the first stage of shortest-path tree calculation for an area,		The first stage of the shortest-path tree calculation is described in
	when a vertex V corresponding to a Network-LSA is added to the		section 16.1 of [RFC2328] and modified for OSPFv3 as described in
	shortest-path tree and its adjacent vertex W (joined by a link in V's		section 4.8.1 of [RFC5340]. With two-part metric, when a vertex V
	corresponding Network LSA), the cost from V to W, which is W's		corresponding to a Network-LSA has just been added to the Shortest
	network-to-router cost, is determined as follows:		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
			cost from V to W (W's 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
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 40 ¶
	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
	Bit:		Bit:
	Bit Capabilities		Bit Capabilities
	0 OSPF Two-part Metric [TPM]		TBD1 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 without considering any network-to-router costs.
	4. IANA Considerations		4. IANA Considerations
	This document requests the following IANA assignments:		This document requests the following IANA assignments:
	o A new bit in Registry for OSPF Router Informational Capability		o A new bit (TBD1) in Registry for OSPF Router Informational
	Bits, to indicate the capability of supporting two-part metric.		Capability Bits, to indicate the capability of supporting two-part
			metric.
	o A new Sub-TLV type in OSPF Extended Link TLV Sub-TLV registry, for		o A new Sub-TLV type (TBD2) in OSPF Extended Link TLV Sub-TLV
	the Network-to-Router Metric 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		o A new Sub-TLV type (TBD3) in OSPFv3 Extended-LSA Sub-TLV registry,
	the Network-to-Router Metric Sub-TLV.		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)		o A new Sub-TLV type (TBD4) in Types for sub-TLVs of TE Link TLV
	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.		This document does not introduce new security risks. Existing
			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]		[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-10		LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-10
	(work in progress), May 2016.		(work in progress), May 2016.
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 15 ¶
	Appendix B. Contributors' Addreses		Appendix B. Contributors' Addreses
	David Dubois		David Dubois
	General Dynamics C4S		General Dynamics C4S
	400 John Quincy Adams Road		400 John Quincy Adams Road
	Taunton, MA 02780		Taunton, MA 02780
	EMail: dave.dubois@gd-ms.com		EMail: dave.dubois@gd-ms.com
	Vibhor Julka		Vibhor Julka
	L3 Communications, Linkabit		Individual
	9890 Towne Centre Drive
	San Diego, CA 92121
	EMail: vjulka1@yahoo.com		EMail: vjulka1@yahoo.com
	Tom McMillan		Tom McMillan
	L3 Communications, Linkabit		L3 Communications, Linkabit
	9890 Towne Centre Drive		9890 Towne Centre Drive
	San Diego, CA 92121		San Diego, CA 92121
	EMail: tom.mcmillan@l-3com.com		EMail: tom.mcmillan@l-3com.com
End of changes. 19 change blocks.
	36 lines changed or deleted		41 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/