< draft-ietf-ospf-graceful-impl-report-04.txt		draft-ietf-ospf-graceful-impl-report-05.txt >
	Network Working Group Acee Lindem (Redback Networks)		Network Working Group Acee Lindem (Redback Networks)
	Internet Draft		Internet Draft
	Expiration Date: September 2004 Proposed Status: Informational		Expiration Date: October 2004 Proposed Status: Informational
	File name: draft-ietf-ospf-graceful-impl-report-04.txt Apr 2004		File name: draft-ietf-ospf-graceful-impl-report-05.txt May 2004
	Graceful OSPF Restart Implementation Report		Graceful OSPF Restart Implementation Report
	draft-ietf-ospf-graceful-impl-report-04.txt		draft-ietf-ospf-graceful-impl-report-05.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	implementation survey. It also documents implementation differences		implementation survey. It also documents implementation differences
	between the vendors responding to the survey. Section 3 contains a		between the vendors responding to the survey. Section 3 contains a
	MIB reference. Sections 4 provide an authentication reference.		MIB reference. Sections 4 provide an authentication reference.
	Section 5 simply refers to the implementations listed in section 2.		Section 5 simply refers to the implementations listed in section 2.
	Section 6 includes a minimal set of test scenarios. Finally,		Section 6 includes a minimal set of test scenarios. Finally,
	section 7 includes a disclaimer with respect to operational		section 7 includes a disclaimer with respect to operational
	experience.		experience.
	2. Implementation Experience		2. Implementation Experience
	Ten vendors have implemented graceful OSPF and have completed the		Eleven vendors have implemented graceful OSPF and have completed
	implementation survey. These include Redback, Juniper, Motorola		the implementation survey. These include Redback, Juniper, Motorola
	Computer Group (formerly Netplane Systems), Mahi Networks,		Computer Group (formerly Netplane Systems), Mahi Networks,
	Nexthop technologies, Force10 Networks, Procket, Alcatel, Laurel		Nexthop technologies, Force10 Networks, Procket, Alcatel, Laurel
	Networks, and DCL (Data Connection Limited). All have implemented		Networks, DCL (Data Connection Limited), and Ericsson. All have
	restart from the perspective of both a restarting and helper router.		implemented restart from the perspective of both a restarting
	All but one vendor implemented both planned and unplanned restart.		and helper router. All but one vendor implemented both planned
	All implementations are original. Six successfully tested		and unplanned restart. All implementations are original. Seven
	interoperability with Juniper. Juniper successfully tested		successfully tested interoperability with Juniper. Juniper
	interoperability with Force10 Networks. One vendor tested with John		successfully tested interoperability with Force10 Networks. One
	Moy's GNU Public License implementation [OSPFD]. Two vendors		vendor tested with John Moy's GNU Public License implementation
	hadn't tested interoperability at the time of the survey.		[OSPFD]. Two vendors hadn't tested interoperability at the time of
			the survey.
	2.1 Implementation Differences		2.1 Implementation Differences
	The first difference was whether or not strict LSA checking was		The first difference was whether or not strict LSA checking was
	implemented and, if so, whether it was configurable. In the context		implemented and, if so, whether it was configurable. In the context
	of graceful OSPF restart, strict LSA checking indicates whether or		of graceful OSPF restart, strict LSA checking indicates whether or
	not a changed LSA will result in termination of graceful restart		not a changed LSA will result in termination of graceful restart
	by a helping router. Four vendors made it configurable (three		by a helping router. Four vendors made it configurable (three
	defaulted it to enabled and one disabled), another made it		defaulted it to enabled and one disabled), another made it
	a compile option (shipping with strict LSA checking disabled),		a compile option (shipping with strict LSA checking disabled),
	another didn't implement it at all, and four implemented strict		another didn't implement it at all, and five implemented strict
	LSA checking with no configuration option to disable it.		LSA checking with no configuration option to disable it.
	The second was whether a received grace LSA would be taken to apply		The second was whether a received grace LSA would be taken to apply
	only to the adjacency on which it was received or all adjacencies		only to the adjacency on which it was received or all adjacencies
	with the restarting router. This is a rather subtle difference		with the restarting router. This is a rather subtle difference
	since it only applies to helping and restarting routers with more		since it only applies to helping and restarting routers with more
	than one full adjacency at the time or restart. Seven vendors		than one full adjacency at the time or restart. Eight vendors
	implemented the option of received grace LSA only applying to the		implemented the option of received grace LSA only applying to the
	adjacency on which it was received. Three vendors applied the grace		adjacency on which it was received. Three vendors applied the grace
	LSA to all adjacencies with the grace LSA originator (i.e., the		LSA to all adjacencies with the grace LSA originator (i.e., the
	restarting router).		restarting router).
	The final difference was in whether or not additional extensions		The final difference was in whether or not additional extensions
	were implemented to accommodate other features such as protocol		were implemented to accommodate other features such as protocol
	redistribution or interaction with MPLS VPNs [VPN]. Five vendors		redistribution or interaction with MPLS VPNs [VPN]. Five vendors
	implemented extensions and five did not. It should be noted that		implemented extensions and six did not. It should be noted that
	such extensions are beyond the scope of Graceful OSPF		such extensions are beyond the scope of Graceful OSPF
	Restart [GRACE].		Restart [GRACE].
	3. MIB Reference		3. MIB Reference
	MIB objects for the Graceful OSPF Restart have been added to the		MIB objects for the Graceful OSPF Restart have been added to the
	OSPF Version 2 Management Information Base [OSPFMIB]. Additions		OSPF Version 2 Management Information Base [OSPFMIB]. Additions
	include:		include:
	- Objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge,		- Objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge,
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 29 ¶
	- Padma Pillay-Esnault (Juniper Networks)		- Padma Pillay-Esnault (Juniper Networks)
	- Vishwas Manral (Motorola Computer Group, formerly Netplane		- Vishwas Manral (Motorola Computer Group, formerly Netplane
	System).		System).
	- Sriganesh Kini (Mahi Networks)		- Sriganesh Kini (Mahi Networks)
	- Jason Chen (Force10 Networks)		- Jason Chen (Force10 Networks)
	- Daniel Gryniewicz (NextHop Technologies)		- Daniel Gryniewicz (NextHop Technologies)
	- Hasmit Grover (Procket Networks)		- Hasmit Grover (Procket Networks)
	- Pramoda Nallur (Alcatel)		- Pramoda Nallur (Alcatel)
	- Ardas Cilingiroglu (Laurel Networks)		- Ardas Cilingiroglu (Laurel Networks)
	- Philip Crocker (Data Connection Limited)		- Philip Crocker (Data Connection Limited)
			- Le-Vinh Hoang (Ericsson)
	13. Author's Address		13. Author's Address
	Acee Lindem		Acee Lindem
	Redback Networks		Redback Networks
	102 Carric Bend Court		102 Carric Bend Court
	Cary, NC 27519		Cary, NC 27519
	Email: acee@redback.com		Email: acee@redback.com
End of changes. 8 change blocks.
	16 lines changed or deleted		18 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/