< draft-madhukar-ospf-agr-asymmetric-00.txt		draft-madhukar-ospf-agr-asymmetric-01.txt >
	INTERNET-DRAFT Madhukar Anand		INTERNET-DRAFT Madhukar Anand
	Hasmit Grover		Hasmit Grover
	Abhay Roy		Abhay Roy
	Intended Status: Proposed Standard Cisco Systems		Intended Status: Proposed Standard Cisco Systems
	Expires: Jul 25, 2013 Jan 25, 2013		Expires: Nov 16, 2013 Jun 16, 2013
	Asymmetric OSPF Hold Timer		Asymmetric OSPF Hold Timer
	draft-madhukar-ospf-agr-asymmetric-00		draft-madhukar-ospf-agr-asymmetric-01
	Abstract		Abstract
	Current OSPF standard requires that the HELLO/Dead interval be		Current OSPF standard requires that the HELLO/Dead interval be
	symmetric on either side of the link in order to maintain adjacency.		symmetric on either side of the link in order to maintain adjacency.
	There are many scenarios in which this may not be desirable. This		There are many scenarios in which this may not be desirable. This
	memo describes a technique to allow OSPF adjacency to be maintained		memo describes a technique to allow OSPF adjacency to be maintained
	with asymmetric values of the OSPF Dead interval.		with asymmetric values of the OSPF Dead interval.
	Status of this Memo		Status of this Memo
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
	2 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 3		2 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1 Sending HELLOs with Asymmetric Hold Timers. . . . . . . . . 4		2.1 Sending HELLOs with Asymmetric Hold Timers. . . . . . . . . 4
	2.2 Receiving HELLOs with Asymmetric Hold Timer Values. . . . . 5		2.2 Receiving HELLOs with Asymmetric Hold Timer Values. . . . . 5
	4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
	6 Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8		6 Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
	7 Security Considerations . . . . . . . . . . . . . . . . . . . . 9		7 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
	8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9		8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
	9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1 Normative References . . . . . . . . . . . . . . . . . . . 9		9.1 Normative References . . . . . . . . . . . . . . . . . . . 9
	9.2 Informative References . . . . . . . . . . . . . . . . . . 9		9.2 Informative References . . . . . . . . . . . . . . . . . . 9
	skipping to change at page 3, line 48 ¶		skipping to change at page 3, line 48 ¶
	adjacencies in a stub area router, and an adjacent ABR can		adjacencies in a stub area router, and an adjacent ABR can
	potentially differ by an order of magnitude. Another example is in		potentially differ by an order of magnitude. Another example is in
	the case of a hub and spoke topology. The hub router is definitely		the case of a hub and spoke topology. The hub router is definitely
	more loaded than the spoke router. Further, in such topologies it may		more loaded than the spoke router. Further, in such topologies it may
	be desirable that the failure of a non-central (leaf node) router is		be desirable that the failure of a non-central (leaf node) router is
	to be detected faster, so that the routers in the center of the		to be detected faster, so that the routers in the center of the
	topology can possibly reroute traffic. This could be supported, for		topology can possibly reroute traffic. This could be supported, for
	instance, by having the non-central routers send HELLOs at a much		instance, by having the non-central routers send HELLOs at a much
	faster rate than the central routers.		faster rate than the central routers.
			Finally, OSPFv3 Auto-configuration [OSPFV3-AUTOCONFIG] calls for
			flexibility in OSPFv3 HELLO and Dead intervals (See Sec 3 of [OSPFV3-
			AUTOCONFIG]). These requirements can be easily met by implementing
			the proposal here.
	1.1 Terminology		1.1 Terminology
			INTERNET DRAFT Asymmetric OSPF Hold Timer <Issue Date>
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2 Proposed Solution		2 Proposed Solution
	INTERNET DRAFT Asymmetric OSPF Hold Timer <Issue Date>
	We expect that OSPF interface on which an asymmetric hold timer is to		We expect that OSPF interface on which an asymmetric hold timer is to
	be supported have appropriate CLI configuration to accept the normal		be supported have appropriate CLI configuration to accept the normal
	(symmetric), and alternate (potentially asymmetric) values of Dead		(symmetric), and alternate (potentially asymmetric) values of Dead
	interval. Alternatively, the asymmetric value of Dead interval could		interval. Alternatively, the asymmetric value of Dead interval could
	also be derived through other means. Henceforth, we refer to the		also be derived through other means. Henceforth, we refer to the
	(potentially) asymmetric dead interval advertised by a router as the		(potentially) asymmetric dead interval advertised by a router as the
	OSPF hold interval for that router on the receiving link.		OSPF hold interval for that router on the receiving link.
	Another requirement is that, all routers in the network that form an		Another requirement is that, all routers in the network that form an
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 39 ¶
	Routers that wish to set asymmetric hold timer in OSPF would make		Routers that wish to set asymmetric hold timer in OSPF would make
	use of the LLS block (RFC 4813) attached to the HELLO packet, with		use of the LLS block (RFC 4813) attached to the HELLO packet, with
	the following changes.		the following changes.
	1. The router will set the L-bit indicating the presence of the LLS		1. The router will set the L-bit indicating the presence of the LLS
	block. The router will also set the LLS type to 0 (reserved), and use		block. The router will also set the LLS type to 0 (reserved), and use
	the following extended options bit (0x00000003) in the EO-TLV,		the following extended options bit (0x00000003) in the EO-TLV,
	introduced for this purpose.		introduced for this purpose.
	Extended Options Bit Name Reference		Extended Options Bit Name Reference
	0x00000003 Asymmetric Hello capability draft-ietf-agr-		0x00000003 Asymmetric Hello capability draft-madhukar-
	asymmetric-13		ospf-asymmetric-01
	2. The value of the hold timer would be specified in a LLS TLV. Note		2. The value of the hold timer would be specified in a LLS TLV. Note
	that the LLS TLV types are maintained by the IANA, and this document		that the LLS TLV types are maintained by the IANA, and this document
	proposes the introduction of a new TLV. The type field of the new TLV		proposes the introduction of a new TLV. The type field of the new TLV
	is proposed to be 18, the length of the value is 4 bytes.		is proposed to be 18, the length of the value is 4 bytes.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 18 | 4 |		| 18 | 4 |
			INTERNET DRAFT Asymmetric OSPF Hold Timer <Issue Date>
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| OSPF Hold Timer Value |		| OSPF Hold Timer Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	INTERNET DRAFT Asymmetric OSPF Hold Timer <Issue Date>
	3. Routers must set the HELLO and Dead interval values carried in the		3. Routers must set the HELLO and Dead interval values carried in the
	OSPF Hello packet to zero.		OSPF HELLO packet to zero.
	4. To stop advertising the asymmetric hold timer value, routers will		4. To stop advertising the asymmetric hold timer value, routers will
	simply revert back to advertising configured (non-zero) values of		simply revert back to advertising configured (non-zero) values of
	HELLO and dead interval in the OSPF Hello packet.		HELLO and dead interval in the OSPF Hello packet.
	The mechanism of sending HELLOs would remain as specified in Sec 9.5		The mechanism of sending HELLOs would remain as specified in Sec 9.5
	of RFC 2328.		of RFC 2328.
	2.2 Receiving HELLOs with Asymmetric Hold Timer Values.		2.2 Receiving HELLOs with Asymmetric Hold Timer Values.
	The processing of an incoming HELLO packet with the L-bit set, and		The processing of an incoming HELLO packet with the L-bit set, and
	containing the extended options set for alternate HELLOs would follow		containing the extended options set for alternate HELLOs would follow
	the specification in Sec 10.5 of RFC 2328 with one modification.		the specification in Sec 10.5 of RFC 2328 with one modification.
	1. Routers that recognize this new extended options will set the		1. Routers that recognize this new extended options will set the
	value of the neighbor dead interval to the value specified in the LLS		value of the neighbor dead interval to the value specified in the LLS
	block TLV.		block TLV, but only if BOTH the HELLO and dead interval are set to
			zero in the OSPF HELLO packet.
	2. Routers that do not recognize the extended options would drop		2. Routers that do not recognize the extended options would drop
	adjacency as it will not match with the configured (or default) HELLO		adjacency as it will not match with the configured (or default) HELLO
	or dead interval as specified in Sec 10.5 of RFC 2328.		or dead interval as specified in Sec 10.5 of RFC 2328.
	Note that, routers can stop appending the LLS block in their HELLO,		Note that, routers can stop appending the LLS block in their HELLO,
	and the neighbors will simply (re)start using the value specified in		and the neighbors will simply (re)start using the value specified in
	the HELLO packet.		the HELLO packet.
	INTERNET DRAFT Asymmetric OSPF Hold Timer <Issue Date>		INTERNET DRAFT Asymmetric OSPF Hold Timer <Issue Date>
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	4 Discussion		4 Discussion
	It is possible to use Bidirectional Forwarding Detection (BFD) [RFC		It is possible to use Bidirectional Forwarding Detection (BFD) [RFC
	5880] to alleviate some of the concerns in the use-cases identified		5880] to alleviate some of the concerns in the use-cases identified
	above. Relying entirely on BFD without OSPF HELLOs is not a		above. Relying entirely on BFD without OSPF HELLOs is not a
	possibility given that OSPF HELLOs are still used for discovery of		possibility given that OSPF HELLOs are still used for discovery of
	neighbors. The BFD approach has its own shortcomings such as limited		neighbors. The BFD approach has its own shortcomings such as limited
	cross-vendor and cross-platform support and also performance		cross-vendor and cross-platform support and also performance
	implications, especially with increasing scale requirements. In any		implications, especially with increasing scale requirements. In any
	case, BFD can be made to work in conjunction with the proposal in		case, BFD can be made to work in conjunction with the proposal in
	this document to achieve the best possible network performance.		this document to achieve the best possible network performance. It is
			intended that the proposal for asymmetric hold timer would work
			independent of BFD deployment considerations, and could also help in
			new applications where it may be desirable to support asymmetric and
			possibly dynamic dead interval values (e.g., OSPFv3 Auto-
			Configuration, [OSPFV3-AUTOCONFIG]).
	INTERNET DRAFT Asymmetric OSPF Hold Timer <Issue Date>		INTERNET DRAFT Asymmetric OSPF Hold Timer <Issue Date>
	5 Acknowledgements		5 Acknowledgements
	The authors would like to thank Paul Wells for careful review of		The authors would like to thank Paul Wells for careful review of
	this document. We would also like to thank Anton Smirnov for		this document. We would also like to thank Anton Smirnov for
	reviewing this document and bringing the BFD alternative to our		reviewing this document and bringing the BFD alternative to our
	attention.		attention.
	skipping to change at page 9, line 32 ¶		skipping to change at page 9, line 32 ¶
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 2434, October		IANA Considerations Section in RFCs", RFC 2434, October
	1998.		1998.
	9.2 Informative References		9.2 Informative References
			[OSPFV3-AUTOCONFIG] Lindem, A., and Arkko, J., "OSPFv3 Auto-
			Configuration", draft-ietf-ospf-ospfv3-autoconfig-02.txt,
			Apr 15, 2013 (work in progress).
	[RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A.		[RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A.
	Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.		Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.
	Authors' Addresses		[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding
			Detection", RFC 5880, June 2010.
	Madhukar Anand		Authors' Addresses
	Cisco Systems
	170 W Tasman Drive
	San Jose, CA 95138
	US
	Email: anandmkr@cisco.com		Madhukar Anand
			Cisco Systems
			170 W Tasman Drive
			San Jose, CA 95138
			US
	INTERNET DRAFT Asymmetric OSPF Hold Timer <Issue Date>		INTERNET DRAFT Asymmetric OSPF Hold Timer <Issue Date>
	Hasmit Grover		Email: anandmkr@cisco.com
	Cisco Systems
	170 W Tasman Drive
	San Jose, CA 95138
	US
	Email: hasmit@cisco.com		Hasmit Grover
			Cisco Systems
			170 W Tasman Drive
			San Jose, CA 95138
			US
	Abhay Roy		Email: hasmit@cisco.com
	Cisco Systems
	170 W Tasman Drive
	San Jose, CA 95138
	US
	Email: akr@cisco.com		Abhay Roy
			Cisco Systems
			170 W Tasman Drive
			San Jose, CA 95138
			US
			Email: akr@cisco.com
End of changes. 20 change blocks.
	29 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/