< draft-ietf-ospf-stdreport-02.txt		draft-ietf-ospf-stdreport-03.txt >
	Network Working Group J. Moy		Network Working Group J. Moy
	Internet Draft Cascade Communications Corp.		Internet Draft Ascend Communications, Inc.
	Expiration Date: November 1997 May 1997		Expiration Date: August 1998 February 1998
	File name: draft-ietf-ospf-stdreport-02.txt		File name: draft-ietf-ospf-stdreport-03.txt
	OSPF Standardization Report		OSPF Standardization Report
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	This memo documents how the requirements for advancing a routing		This memo documents how the requirements for advancing a routing
	protocol to Full Standard, set out in [Ref2], have been met for		protocol to Full Standard, set out in [Ref2], have been met for
	OSPFv2.		OSPFv2.
	Please send comments to ospf@gated.cornell.edu.		Please send comments to ospf@gated.cornell.edu.
	Table of Contents		Table of Contents
	1 Introduction ........................................... 2		1 Introduction ........................................... 2
	2 Modifications since Draft Standard status .............. 2		2 Modifications since Draft Standard status .............. 2
	2.1 Point-to-MultiPoint interface .......................... 3		2.1 Point-to-MultiPoint interface .......................... 4
	2.2 Cryptographic Authentication ........................... 4		2.2 Cryptographic Authentication ........................... 4
	3 Updated implementation and deployment experience ....... 4		3 Updated implementation and deployment experience ....... 4
	4 Protocol Security ...................................... 6		4 Protocol Security ...................................... 6
	References ............................................. 7		References ............................................. 7
	Security Considerations ................................ 8		Security Considerations ................................ 8
	Author's Address ....................................... 8		Author's Address ....................................... 8
	1. Introduction		1. Introduction
	OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing		OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing
	protocol documented in [Ref1]. OSPF is a link-state routing		protocol documented in [Ref8]. OSPF is a link-state routing
	protocol. It is designed to be run internal to a single Autonomous		protocol. It is designed to be run internal to a single Autonomous
	System. Each OSPF router maintains an identical database describing		System. Each OSPF router maintains an identical database describing
	the Autonomous System's topology. From this database, a routing		the Autonomous System's topology. From this database, a routing
	table is calculated by constructing a shortest-path tree. OSPF		table is calculated by constructing a shortest-path tree. OSPF
	features include the following:		features include the following:
	o OSPF responds quickly to topology changes, expending a minimum		o OSPF responds quickly to topology changes, expending a minimum
	of network bandwidth in the process.		of network bandwidth in the process.
	o Support for CIDR addressing.		o Support for CIDR addressing.
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	security.		security.
	o Equal-cost multipath.		o Equal-cost multipath.
	o An area routing capability is provided, enabling an Autonomous		o An area routing capability is provided, enabling an Autonomous
	system to be split into a two level hierarchy to further reduce		system to be split into a two level hierarchy to further reduce
	the amount of routing protocol traffic.		the amount of routing protocol traffic.
	o OSPF allows import of external routing information into the		o OSPF allows import of external routing information into the
	Autonomous System, including a tagging feature that can be		Autonomous System, including a tagging feature that can be
	exploited to exchange extra information at the AS boundaries		exploited to exchange extra information at the AS boundary (see
	(see [Ref7]).		[Ref7]).
	An analysis of OSPF together with a more detailed description of		An analysis of OSPF together with a more detailed description of
	OSPF features was originally provided in [Ref6], as a part of		OSPF features was originally provided in [Ref6], as a part of
	promoting OSPF to Draft Standard status. The analysis of OSPF		promoting OSPF to Draft Standard status. The analysis of OSPF
	remains unchanged. Two additional major features have been developed		remains unchanged. Two additional major features have been developed
	for OSPF since the protocol achieved Draft Standard status: the		for OSPF since the protocol achieved Draft Standard status: the
	Point-to-MultiPoint interface and Cryptographic Authentication.		Point-to-MultiPoint interface and Cryptographic Authentication.
	These features are described in Sections 2.1 and 2.2 respectively of		These features are described in Sections 2.1 and 2.2 respectively of
	this memo.		this memo.
	The OSPF MIB is documented in [Ref4]. It is currently at Draft		The OSPF MIB is documented in [Ref4]. It is currently at Draft
	Standard status.		Standard status.
	2. Modifications since Draft Standard status		2. Modifications since Draft Standard status
	OSPF was last released as RFC 1583 [Ref3], which is labeled with		OSPF became a Draft Standard with the release of RFC 1583 [Ref3].
	Draft Standard status. Implementations of the new specification in		Implementations of the new specification in [Ref8] are backward-
	[Ref1] are backward-compatible with RFC 1583. The differences		compatible with RFC 1583. The differences between the two documents
	between the two documents are described in Appendix G of [Ref1].		are described in the Appendix Gs of [Ref1] and [Ref8]. These
	These differences are listed briefly below. Two major features were		differences are listed briefly below. Two major features were also
	also added, the Point-to-MultiPoint interface and Cryptographic		added, the Point-to-MultiPoint interface and Cryptographic
	Authentication, which are described in separate sections.		Authentication, which are described in separate sections.
	o Configuration requirements for OSPF area address ranges have		o Configuration requirements for OSPF area address ranges have
	been relaxed to allow greater flexibility in area assignment.		been relaxed to allow greater flexibility in area assignment.
	See Section G.3 of [Ref1] for details.		See Section G.3 of [Ref1] for details.
	o The OSPF flooding algorithm was modified to a) improve database		o The OSPF flooding algorithm was modified to a) improve database
	convergence in networks with low speed links and b) resolve a		convergence in networks with low speed links b) resolve a
	problem where unnecessary LSA retransmissions could occur as a		problem where unnecessary LSA retransmissions could occur as a
	result of differing clock granularities. See Sections G.4 and		result of differing clock granularities, c) remove race
	G.5 of [Ref1] for details.		conditions between the flooding of MaxAge LSAs and the Database
			Exchange process, d) clarify the use of the MinLSArrival
			constant, and e) rate-limit the response to less recent LSAs
			received via flooding. See Sections G.4 and G.5 of [Ref1] and
			Section G.1 of [Ref8] for details.
	o To resolve the long-standing confusion regarding representation		o To resolve the long-standing confusion regarding representation
	of point-to-point links in OSPF, the specification now		of point-to-point links in OSPF, the specification now
	optionally allows advertisement of a stub link to a point-to-		optionally allows advertisement of a stub link to a point-to-
	point link's subnet, ala RIP. See Section G.6 of [Ref1].		point link's subnet, ala RIP. See Section G.6 of [Ref1].
	o Several problems involving advertising the same external route		o Several problems involving advertising the same external route
	from multiple areas were found and fixed, as described in		from multiple areas were found and fixed, as described in
	Section G.7 of [Ref1]. Without the fixes, persistent routing		Section G.7 of [Ref1] and Section G.2 of [Ref8]. Without the
	loops could form in certain such configurations. Note that one		fixes, persistent routing loops could form in certain such
	of the fixes was not backward-compatible, in that mixing routers		configurations. Note that one of the fixes was not backward-
	implementing the fixes with those implementing just RFC 1583		compatible, in that mixing routers implementing the fixes with
	could cause loops not present in an RFC 1583-only configuration.		those implementing just RFC 1583 could cause loops not present
	This caused an RFC1583Compatibility global configuration		in an RFC 1583-only configuration. This caused an
	parameter to be added, as described in Section C.1 of [Ref1].		RFC1583Compatibility global configuration parameter to be added,
			as described in Section C.1 of [Ref1].
	o In order to deal with high delay links, retransmissions of		o In order to deal with high delay links, retransmissions of
	initial Database Description packets no longer reset an OSPF		initial Database Description packets no longer reset an OSPF
	adjacency.		adjacency.
	o In order to detect link MTU mismatches, which can cause problems		o In order to detect link MTU mismatches, which can cause problems
	both in IP forwarding and in the OSPF routing protocol itself,		both in IP forwarding and in the OSPF routing protocol itself,
	MTU was added to OSPF's Database Description packets.		MTU was added to OSPF's Database Description packets.
	Neighboring routers refuse to bring up an OSPF adjacency unless		Neighboring routers refuse to bring up an OSPF adjacency unless
	they agree on their common link's MTU.		they agree on their common link's MTU.
	o The TOS routing option was deleted from OSPF. However, for		o The TOS routing option was deleted from OSPF. However, for
	backward compatibility the formats of OSPF's various LSAs remain		backward compatibility the formats of OSPF's various LSAs remain
	unchanged, maintaining the ability to specify TOS metrics in		unchanged, maintaining the ability to specify TOS metrics in
	router-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external-		router-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external-
	LSAs.		LSAs.
			o OSPF's routing table lookup algorithm was changed to reflect
			current practice. The "best match" routing table entry is now
			always selected to be the one providing the most specific
			(longest) match. See Section G.4 of [Ref8] for details.
	2.1. Point-to-MultiPoint interface		2.1. Point-to-MultiPoint interface
	The Point-to-MultiPoint interface was added as an alternative to		The Point-to-MultiPoint interface was added as an alternative to
	OSPF's NBMA interface when running OSPF over non-broadcast		OSPF's NBMA interface when running OSPF over non-broadcast
	subnets. Unlike the NBMA interface, Point-to-MultiPoint does not		subnets. Unlike the NBMA interface, Point-to-MultiPoint does not
	require full mesh connectivity over the non-broadcast subnet.		require full mesh connectivity over the non-broadcast subnet.
	Point-to-MultiPoint is less efficient than NBMA, but is easier		Point-to-MultiPoint is less efficient than NBMA, but is easier
	to configure (in fact, it can be self-configuring) and is more		to configure (in fact, it can be self-configuring) and is more
	robust than NBMA, tolerating all failures within the non-		robust than NBMA, tolerating all failures within the non-
	broadcast subnet. For more information on the Point-to-		broadcast subnet. For more information on the Point-to-
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	Parameter Responses Min Mode Mean Max		Parameter Responses Min Mode Mean Max
	_________________________________________________________________		_________________________________________________________________
	Max routers in domain 8 20 350 510 1000		Max routers in domain 8 20 350 510 1000
	Max routers in single area 8 20 100 160 350		Max routers in single area 8 20 100 160 350
	Max areas in domain 7 1 15 23 60		Max areas in domain 7 1 15 23 60
	Max AS-external-LSAs 6 50 1K 2K 5K		Max AS-external-LSAs 6 50 1K 2K 5K
	Table 3: OSPF domain sizes deployed		Table 3: OSPF domain sizes deployed
			In an attempt to ascertain the extent to which OSPF is currently
			deployed, vendors were also asked in January 1998 to provide
			deployment estimates. Four vendors of OSPF routers responded, with a
			total estimate of 182,000 OSPF routers in service, organized into
			4300 separate OSPF routing domains.
	4. Protocol Security		4. Protocol Security
	All OSPF protocol exchanges are authenticated. OSPF supports		All OSPF protocol exchanges are authenticated. OSPF supports
	multiple types of authentication; the type of authentication in use		multiple types of authentication; the type of authentication in use
	can be configured on a per network segment basis. One of OSPF's		can be configured on a per network segment basis. One of OSPF's
	authentication types, namely the Cryptographic authentication		authentication types, namely the Cryptographic authentication
	option, is believed to be secure against passive attacks and provide		option, is believed to be secure against passive attacks and provide
	significant protection against active attacks. When using the		significant protection against active attacks. When using the
	Cryptographic authentication option, each router appends a "message		Cryptographic authentication option, each router appends a "message
	digest" to its transmitted OSPF packets. Receivers then use the		digest" to its transmitted OSPF packets. Receivers then use the
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	None of the OSPF authentication types provide confidentiality. Nor		None of the OSPF authentication types provide confidentiality. Nor
	do they protect against traffic analysis. Key management is also not		do they protect against traffic analysis. Key management is also not
	addressed by the OSPF specification.		addressed by the OSPF specification.
	For more information, see Sections 8.1, 8.2, and Appendix D of		For more information, see Sections 8.1, 8.2, and Appendix D of
	[Ref1].		[Ref1].
	References		References
	[Ref1] Moy, J., "OSPF Version 2", Internet Draft, <draft-ietf-		[Ref1] Moy, J., "OSPF Version 2", RFC 2178, July 1997.
	ospf-version2-11.txt>, Cascade, April 1997.
	[Ref2] Hinden, B., "Internet Routing Protocol Standardization		[Ref2] Hinden, B., "Internet Routing Protocol Standardization
	Criteria", RFC 1264, October 1991.		Criteria", RFC 1264, October 1991.
	[Ref3] Moy, J., "OSPF Version 2", RFC 1583, March 1994.		[Ref3] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
	[Ref4] Baker, F,, and R. Coltun, "OSPF Version 2 Management		[Ref4] Baker, F,, and R. Coltun, "OSPF Version 2 Management
	Information Base", RFC 1850, November 1995.		Information Base", RFC 1850, November 1995.
	[Ref5] Moy, J., "OSPF Protocol Analysis", RFC 1245, August 1991.		[Ref5] Moy, J., "OSPF Protocol Analysis", RFC 1245, August 1991.
	[Ref6] Moy, J., "Experience with the OSPF Protocol", RFC 1246,		[Ref6] Moy, J., "Experience with the OSPF Protocol", RFC 1246,
	August 1991.		August 1991.
	[Ref7] Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for IP---		[Ref7] Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for IP---
	OSPF Interaction", RFC 1745, December 1994.		OSPF Interaction", RFC 1745, December 1994.
			[Ref8] Moy, J., "OSPF Version 2", Internet Draft, <draft-ietf-
			ospf-vers2-02.txt>, January 1998.
	Security Considerations		Security Considerations
	Security considerations are addressed in Section 4 of this memo.		Security considerations are addressed in Section 4 of this memo.
	Author's Address		Author's Address
	John Moy		John Moy
	Cascade Communications Corp.		Ascend Communications, Inc.
	5 Carlisle Road		1 Robbins Road
	Westford, MA 01886		Westford, MA 01886
	Phone: 508-952-1367		Phone: 978-952-1367
	Fax: 508-692-9214		Fax: 978-392-2075
	Email: jmoy@casc.com		Email: jmoy@casc.com
	This document expires in November 1997.		This document expires in August 1998.
End of changes. 15 change blocks.
	29 lines changed or deleted		47 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/