< draft-karthik-bmwg-ldp-convergence-meth-01.txt		draft-karthik-bmwg-ldp-convergence-meth-02.txt >
	Network Working Group J. Karthik		Network Working Group J. Karthik, Ed.
	Internet Draft Cisco Systems		Internet-Draft Cisco Systems
	Expires: January 2008 R. Papneja		Intended status: Informational R. Papneja, Ed.
	Isocore		Expires: August 22, 2008 Isocore
	Charles Rexrode		M. Nanduri
	Verizon		Tata Communications
	July, 2007		February 19, 2008
	Methodology for Benchmarking LDP Data Plane Convergence		Methodology for Benchmarking LDP Convergence
			draft-karthik-bmwg-ldp-convergence-meth-02
	<draft-karthik-bmwg-ldp-convergence-meth-01.txt>		Status of this Memo
	Status of this Memo		By submitting this Internet-Draft, each author represents that any
			applicable patent or other IPR claims of which he or she is aware
			have been or will be disclosed, and any of which he or she becomes
			aware will be disclosed, in accordance with Section 6 of BCP 79.
	By submitting this Internet-Draft, each author represents that		Internet-Drafts are working documents of the Internet Engineering
	any applicable patent or other IPR claims of which he or she is		Task Force (IETF), its areas, and its working groups. Note that
	aware have been or will be disclosed, and any of which he or she		other groups may also distribute working documents as Internet-
	becomes aware will be disclosed, in accordance with Section 6 of		Drafts.
	BCP 79.
	This document may only be posted in an Internet-Draft.		Internet-Drafts are draft documents valid for a maximum of six months
			and may be updated, replaced, or obsoleted by other documents at any
			time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
	Internet-Drafts are working documents of the Internet Engineering		The list of current Internet-Drafts can be accessed at
	Task Force (IETF), its areas, and its working groups. Note that		http://www.ietf.org/ietf/1id-abstracts.txt.
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		The list of Internet-Draft Shadow Directories can be accessed at
	and may be updated, replaced, or obsoleted by other documents at any		http://www.ietf.org/shadow.html.
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on August 22, 2008.
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		Copyright Notice
	http://www.ietf.org/shadow.html
	Abstract		Copyright (C) The IETF Trust (2008).
	This document describes methodology which includes procedure and network		Abstract
	setup, for benchmarking Label Distribution Protocol (LDP) [MPLS-LDP]
	Convergence. The proposed methodology is to be used for benchmarking LDP
	convergence independent of the underlying IGP used (OSPF or ISIS) and
	the LDP operating modes. The terms used in this document are defined in
	a companion draft [LDP-TERM].
	Benchmarking Methodology		This document describes methodology which includes procedure and
			network setup, for benchmarking Label Distribution Protocol (LDP)
			[RFC5036]Convergence. The proposed methodology is to be used for
			benchmarking LDP convergence independent of the underlying IGP used
			(OSPF or ISIS) and the LDP operating modes. The terms used in this
			document are defined in a companion draft [LDP-Term].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		Requirements Language
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	Table of Contents		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 RFC 2119 [RFC2119].
	1. Introduction...................................................2		Table of Contents
	2. Existing definitions...........................................3
	3. Test Considerations............................................4
	3.1. Convergence Events........................................4
	3.2. Failure Detection [LDP-TERM]..............................4
	3.3. Use of Data Traffic for LDP Convergence...................4
	3.4. Selection of IGP..........................................5
	3.5. LDP FEC Scaling...........................................5
	3.6. Timers....................................................5
	3.7. BGP Configuration.........................................5
	3.8. Traffic generation........................................6
	4. Test Setup.....................................................6
	4.1. Topology for Single NextHop FECs (Link Failure)...........6
	4.2. Topology for Multi NextHop FECs (Link and Node Failure)...7
	5. Test Methodology...............................................7
	6. Reporting Format...............................................8
	7. Security Considerations........................................9
	8. Acknowledgements...............................................9
	9. References.....................................................9
	10. Author's Address..............................................9
	1. Introduction		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
			2. Existing definitions . . . . . . . . . . . . . . . . . . . . . 3
			3. Benchmarking Considerations . . . . . . . . . . . . . . . . . 4
			3.1. Convergence Events . . . . . . . . . . . . . . . . . . . . 4
			3.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 5
			3.3. Use of Data Traffic for LDP Convergence . . . . . . . . . 5
			3.4. Selection of IGP . . . . . . . . . . . . . . . . . . . . . 5
			3.5. LDP FEC Scaling . . . . . . . . . . . . . . . . . . . . . 5
			3.6. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 5
			3.7. BGP Configuration . . . . . . . . . . . . . . . . . . . . 6
			3.8. Traffic generation . . . . . . . . . . . . . . . . . . . . 6
			3.9. Test Payload . . . . . . . . . . . . . . . . . . . . . . . 7
			4. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 7
			5. Test Methodology . . . . . . . . . . . . . . . . . . . . . . . 7
			5.1. Objective . . . . . . . . . . . . . . . . . . . . . . . . 8
			5.2. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . 8
			5.3. Test Configuration . . . . . . . . . . . . . . . . . . . . 8
			5.4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 8
			6. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 8
			7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
			8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
			10.2. Informative References . . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
			Intellectual Property and Copyright Statements . . . . . . . . . . 11
	Results of several recent surveys indicate that LDP is becoming one of		1. Introduction
	the key enabler of large number of MPLS based services such as Layer 2
	and Layer 3 VPNs. Given the revenue that these services generate for the
	service providers, it becomes imperative that reliability and recovery
	of these services from failures is very quick or may be un-noticeable to
	the end user. This is ensured when implementations can guarantee very
	short convergence times from any planned or unplanned failures. Given
	the criticality of network convergence, service providers are
	considering convergence as a key metric to evaluate router architectures
	and LDP implementations. End customers monitor the service level
	Benchmarking Methodology
	agreements based on total packets lost in a given time frame, hence		Results of several recent surveys indicate that LDP is becoming one
	convergence becomes a direct measure of reliability and quality.		of the key enabler of large number of MPLS based services such as
			Layer 2 and Layer 3 VPNs [RFC5037] and [RFC5038]. Given the revenue
			that these services generate for the service providers, it becomes
			imperative that reliability and recovery of these services from
			failures is very quick or may be un-noticeable to the end user. This
			is ensured when implementations can guarantee very short convergence
			times from any planned or unplanned failures. Given the criticality
			of network convergence, service providers are considering convergence
			as a key metric to evaluate router architectures and LDP
			implementations. End customers monitor the service level agreements
			based on total packets lost in a given time frame, hence convergence
			becomes a direct measure of reliability and quality.
	This document describes the methodology for benchmarking LDP Data		This document describes the methodology for benchmarking LDP Data
	Convergence. An accompanying document describes the Terminology related		Convergence. An accompanying document describes the Terminology
	to LDP data convergence benchmarking [LDP-TERM]. The primary motivation		related to LDP data convergence benchmarking [LDP-Term]. The primary
	for this work is the increased focus on minimizing convergence time for		motivation for this work is the increased focus on minimizing
	LDP as an alternative to other solutions such as MPLS Fast Reroute (i.e.		convergence time for LDP as an alternative to other solutions such as
	protection techniques using RSVP-TE extensions). The procedures outlined		MPLS Fast Reroute (i.e. protection techniques using RSVP-TE
	here are transparent to the Advertisement type (Downstream on Demand Vs		extensions). The procedures outlined here are transparent to the
	Downstream Unsolicited), Label Retention mode in use as well as the		Advertisement type (Downstream on Demand Vs Downstream Unsolicited),
	Label Distribution Control and hence can be used in all of these types.		Label Retention mode in use as well as the Label Distribution Control
			and hence can be used in all of these types.
	The test cases defined in this document considers black-box type tests		The test cases defined in this document considers black-box type
	that emulate the network events causing route convergence events. This		tests that emulate the network events causing route convergence
	is similar to that defined in [IGP APP]. The LDP methodology (and		events. This is similar to that defined in
	terminology) for benchmarking LDP FEC convergence is independent to any		[I-D.ietf-bmwg-igp-dataplane-conv-app][IGP APP]. The LDP methodology
	link-state IGP such as ISIS [IGP-ISIS] and OSPF [IGP-OSPF]. These		(and terminology) for benchmarking LDP FEC convergence is independent
	methodologies apply to IPv4 and IPv6 traffic as well as IPv4 and IPv6		to any link-state IGP such as ISIS and OSPF. These methodologies
	IGPs.		apply to IPv4 and IPv6 traffic as well as IPv4 and IPv6 IGPs.
	Future versions of this document will include ECMP benchmarks, LDP		Future versions of this document will include ECMP benchmarks, LDP
	targeted peers and correlated failure scenarios.		targeted peers and correlated failure scenarios.
	2. Existing definitions		2. Existing definitions
	For the sake of clarity and continuity this RFC adopts the template		For the sake of clarity and continuity this RFC adopts the template
	for definitions set out in Section 2 of RFC 1242. Definitions are		for definitions set out in Section 2 of RFC 1242. Definitions are
	indexed and grouped together in sections for ease of reference.		indexed and grouped together in sections for ease of reference.
	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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	this document are to be interpreted as described in RFC 2119.		document are to be interpreted as described in RFC 2119
			The reader is assumed to be familiar with the commonly used MPLS
			terminology, some of which is defined in[LDP-Term]. as much as
			possible, but will extend the terminology when necessary. It is
			assumed that the reader is familiar with the concepts introduced in ,
			as they will not be repeated here.
	The reader is assumed to be familiar with the commonly used MPLS		3. Benchmarking Considerations
	terminology, some of which is defined in [LDP-TERM].
	Benchmarking Methodology		This section discusses the fundamentals of LDP data plane convergence
			benchmarking:
	3. Test Considerations		o Network events that cause rerouting
	This section discusses the fundamentals of LDP data plane convergence		o Failure detections
	benchmarking:
	-Network events that cause rerouting		o Data traffic
	-Failure detections
	-Data traffic
	-Traffic generation
	-IGP Selection
	3.1. Convergence Events		o Traffic generation
	FEC reinstallation by LDP is triggered by link or node failures		o IGP Selection
	downstream of the DUT (Device Under Test) that impact the network
	stability:
	- Interface Shutdown on DUT side with POS Alarm		3.1. Convergence Events
	- Interface Shutdown on remote side with POS Alarm
	- Interface Shutdown on DUT side with BFD
	- Interface Shutdown on remote side with BFD
	- Fiber Pull on DUT side
	- Fiber Pull on remote side
	- Online Insertion and Removal (OIR) of line cards on DUT side
	- Online Insertion and Removal (OIR) on remote side
	- Downstream node failure
	- New peer coming up
	- New link coming up
	3.2. Failure Detection [LDP-TERM]		FEC reinstallation by LDP is triggered by link or node failures
			downstream of the DUT (Device Under Test) that impact the network
			stability:
	Local failures can be detected via SONET failure with directly		o Interface Shutdown on DUT side with POS Alarm
	connected LSR. Failure detection may vary with the type of alarm -
	LOS, AIS, or RDI. Failures on Ethernet links such as Gigabit Ethernet
	sometimes rely upon Layer 3 signaling indication for failure. L3
	failures could also be detected using BFD
	3.3. Use of Data Traffic for LDP Convergence		o Interface Shutdown on remote side with POS Alarm
	Customers of service providers use packet loss as the metric for		o Interface Shutdown on DUT side with BFD
	failover time. Packet loss is an externally observable event having
	direct impact on customers' application performance. LDP convergence
	Benchmarking Methodology
	benchmarking aim at measuring traffic loss to determine the down time		o Interface Shutdown on remote side with BFD
	when a convergence event occurs.
	3.4. Selection of IGP		o Fiber Pull on DUT side
	The LDP convergence methodology presented here is independent of the		o Fiber Pull on remote side
	type of underlying IGP used.
	3.5. LDP FEC Scaling		o Online Insertion and Removal (OIR) of line cards on DUT side
	The number of installed LDP FECs will impact the measured LDP		o Online Insertion and Removal (OIR) on remote side
	convergence time for the entire LDP FEC table. To obtain results
	similar to those that would be observed in an operation network, it
	is recommended that number of installed routes closely approximate
	that for the routers in the real network. The number of IGP areas, or
	levels may not impact the LDP convergence time, however it does
	impact the performance of the IGP route convergence.
	3.6. Timers		o Downstream node failure
	There are some timers that will impact the measured LDP Convergence		o New peer coming up
	time. While the default timers may be suitable in most cases, it is		o New link coming up
	recommended that the following timers be configured to the minimum
	value prior to beginning execution of the test cases:		o Soft Failures (LDP Hello Timers expiring)
			o BFD detecting failures in the forwarding plane
			3.2. Failure Detection
			Local failures can be detected via SONET failure detection with
			directly connected LSR. Failure detection may vary with the type of
			alarm - LOS, AIS, or RDI. Failures on Ethernet links such as Gigabit
			Ethernet sometimes rely upon Layer 3 signaling indication for
			failure. L3 failures could also be detected using BFD
			3.3. Use of Data Traffic for LDP Convergence
			Customers of service providers use packet loss as one metric for
			failover time. Packet loss is an externally observable event having
			direct impact on customers' application performance. LDP convergence
			benchmarking aim at measuring traffic loss to determine the down time
			when a convergence event occurs.
			3.4. Selection of IGP
			The LDP convergence methodology presented here is independent of the
			type of underlying IGP used.
			3.5. LDP FEC Scaling
			The number of installed LDP FECs will impact the measured LDP
			convergence time for the entire LDP FEC table. To obtain results
			similar to those that would be observed in an operation network, it
			is recommended that number of installed routes be similar to that of
			the routers in the operational network. The number of IGP areas, or
			levels may not impact the LDP convergence time, however it does
			impact the performance of the IGP route convergence.
			3.6. Timers
	Timer Recommended Value		Timer Recommended Value
	----- -----------------		----- -----------------
	Link Failure Indication Delay <10milliseconds		Link Failure Indication Delay <10milliseconds
	IGP Hello Timer 1 second		IGP Hello Timer 1 second
	LDP Hello Timer 1 second		LDP Hello Timer 1 second
	LDP Hold Timer 3 seconds		LDP Hold Timer 3 seconds
	IGP Dead-Interval 3 seconds		IGP Dead-Interval 3 seconds
	LSA Generation Delay 0		LSA Generation Delay 0
	LSA Flood Packet Pacing 0		LSA Flood Packet Pacing 0
	LSA Retransmission Packet Pacing 0		LSA Retransmission Packet Pacing 0
	SPF Delay 0		SPF Delay 0
	3.7. BGP Configuration		Figure 1: Timers Recommendation
	The observed LDP convergence numbers could be different if BGP routes		3.7. BGP Configuration
	are installed, and will further worsen, if any failure event imposed
	Benchmarking Methodology
	to measure the LDP convergence causes BGP routes to flap. BGP routes		The observed LDP convergence numbers could be different if BGP routes
	installed will not only consume memory but also CPU cycles when		are installed, and will further worsen, if any failure event imposed
	routes need to reconverge.		to measure the LDP convergence causes BGP routes to flap. BGP routes
			installed will not only consume memory but also CPU cycles when
			routes need to reconverge. Hence the tester could do one of the
			following. 1. Have the BGP routes and LDP FECs on different paths,
			and hence ensuring that flaps in LDP path would not affect the BGP
			routes 2. If the observations shows significant difference due to
			BGP convergence, then one needs to rerun the test with no BGP routes.
	3.8. Traffic generation		3.8. Traffic generation
	It is suggested that at least 3 traffic streams be configured using a		It is suggested that at least 3 traffic streams be configured using a
	traffic generator. In order to monitor the DUT performance for		traffic generator. In order to monitor the DUT performance for
	recovery times a set of route prefixes should be advertised before		recovery times a set of route prefixes should be advertised before
	traffic is sent. The traffic should be configured to be sent to these		traffic is sent. The traffic should be configured to be sent to
	routes.		these routes.
	A typical example would be configuring the traffic generator to send		A typical example would be configuring the traffic generator to send
	the traffic to the first and last of the advertised routes. Also In		the traffic to the first and last of the advertised routes. Also In
	order to have a good understanding of the performance behavior one		order to have a good understanding of the performance behavior one
	may choose to send the traffic to the route, lying at the middle of		may choose to send the traffic to the route, lying at the middle of
	the advertised routes. For example, if 100 routes are advertised, the		the advertised routes. For example, if 100 routes are advertised,
	user should send traffic to route prefix number 1, route prefix		the user should send traffic to route prefix number 1, route prefix
	number 50 and to last route prefix advertised, which is 100 in this		number 50 and to last route prefix advertised, which is 100 in this
	example.		example.
	If the traffic generator is capable of sending traffic to multiple		If the traffic generator is capable of sending traffic to multiple
	prefixes without losing granularity, traffic could be generated to		prefixes without losing granularity, traffic could be generated to
	more number of prefixes than the recommended 3.		more number of prefixes than the recommended 3.
	4. Test Setup		3.9. Test Payload
	Topologies to be used for benchmarking the LDP Convergence:		This memo does not explicitly discuss LDP applications such as Layer
			3 VPN, mVPN, Layer-2 VPN (VPLS, AToM) etc could be used as the
			payload of LDP. The authors of this memo do not believe that the
			convergence of LDP is dependent on the application and verification
			of this statement is beyond the scope of this document.
	4.1. Topology for Single NextHop FECs (Link Failure with parallel		4. Test Setup
	links)
	-------- A --------		Topologies to be used for benchmarking the LDP Convergence:
	TG-|Ingress |----| Egress |-TA
	| DUT |----| Node |
	-------- B --------
	A - Preferred egress interface		-------- A --------
	B - Next-best egress interface		TG-|Ingress |----| Egress |-TA
	Benchmarking Methodology		| DUT |----| Node |
			-------- B --------
	TA – Traffic Analyzer		A - Preferred egress interface
	TG – Traffic Generator		B - Next-best egress interface
			TA - Traffic Analyzer
			TG - Traffic Generator
	Figure 1: Topology for Single NextHop FECs (Link Failure)		Figure 2: Topology for Single NextHop FECs (Link Failure)
	4.2. Topology for Multi NextHop FECs (Link and Node Failure)		--------
			--------| Midpt |---------
			| | Node 2 | |
			| B -------- |
			| |
			-------- -------- ---------
			TG-|Ingress |----| Midpt |----| Egress |-TA
			| DUT | A | Node 1 | | Node |
			-------- -------- ---------
	--------		A - Preferred egress interface
	--------| Midpt |---------		B - Next-best egress interface
	| | Node 2 | |		TA - Traffic Analyzer
	| B -------- |		TG - Traffic Generator
	| |
	-------- -------- ---------
	TG-|Ingress |----| Midpt |----| Egress |-TA
	| DUT | A | Node 1 | | Node |
	-------- -------- ---------
	A - Preferred egress interface		Figure 3: Topology for Multi NextHop FECs (Node Failure)
	B - Next-best egress interface
	TA – Traffic Analyzer
	TG – Traffic Generator
	Figure 2: Topology for Multi NextHop FECs (Node Failure)		5. Test Methodology
	5. Test Methodology		The procedure described here can apply to all the convergence
			benchmarking cases.
	The procedure described here can apply to all the convergence		5.1. Objective
	benchmarking cases.
	Objective		To benchmark the LDP Data Plane Convergence time as seen on the DUT
			when a Convergence event occurs resulting in the current best FEC is
			not reachable anymore.
	To benchmark the LDP Data Plane Convergence time as seen on the		5.2. Test Setup
	DUT when a Convergence event occurs resulting in the current best FEC
	is not reachable anymore.
	Test Setup		- Based on whether 1 hop or multi hop case is benchmarked use the
	Benchmarking Methodology		appropriate setup from the ones described in section 4.
	- Based on whether 1 hop or multi hop case is benchmarked use		5.3. Test Configuration
	the appropriate setup from the ones described in section 4.		1. Configure LDP and other necessary Routing Protocol configuration on the DUT and
			on the supporting devices
			2. Advertise FECs over parallel interfaces upstream to the DUT.
	Test Configuration		5.4. Procedure
			1.Verify that the DUT installs the FECs in the MPLS forwarding table
			2.Generate traffic destined to the FECs advertised by the egress.
			3.Verify and ensure there is 0 traffic loss
			4.Trigger any choice of failure/convergence event as described in section 3.1
			5.Verify that forwarding resumes over the next best egress i/f.
			6.Stop traffic stream and measure the traffic loss.
			7.Convergence time is calculated as defined in section 6, Reporting format.
	1. Configure LDP and other necessary Routing Protocol		6. Reporting Format
	configuration on the DUT and on the supporting devices
	2. Advertise FECs over parallel interfaces upstream to the DUT.
	Procedure		For each test, it is recommended that the results be reported in the
			following format.
			Parameter Units
	1. Verify that the DUT installs the FECs in the MPLS		IGP used for the test ISIS-TE/ OSPF-TE
	forwarding table		Interface types Gige, POS, ATM, etc.
	2. Generate traffic destined to the FECs advertised by the		Packet Sizes offered to the DUT Bytes
	egress.		IGP routes advertised number of IGP routes
	3. Verify and ensure there is 0 traffic loss
	4. Trigger any choice of failure/convergence event as
	described in section 3.1
	5. Verify that forwarding resumes over the next best egress
	i/f.
	6. Stop traffic stream and measure the traffic loss.
	7. Convergence time is calculated as defined in section 6,
	Reporting format.
	6. Reporting Format		Benchmarks
	For each test, it is recommended that the results be reported in the		1st Prefix's convergence time milliseconds
	following format.		Mid Prefix's convergence time milliseconds
			Last Prefix's convergence time milliseconds
	Parameter Units		Convergence time suggested above is calculated using the following formula: (Numbers of packet drop/rate per second * 1000) milliseconds
			7. IANA Considerations
	IGP used for the test ISIS-TE/ OSPF-TE		This document makes no request of IANA.
	Interface types Gige, POS, ATM, etc.
	Packet Sizes offered to the DUT Bytes
	IGP routes advertised number of IGP routes
	Benchmarks		Note to RFC Editor: this section may be removed on publication as an
	Benchmarking Methodology		RFC.
	1st Prefix's convergence time milliseconds		8. Security Considerations
	Mid Prefix's convergence time milliseconds
	Last Prefix's convergence time milliseconds
	Convergence time suggested above is calculated using the following		The security considerations that apply to any active measurement of
	formula: (Numbers of packet drop/rate per second * 1000) milliseconds		live networks are relevant here as well. See [RFC4656].
	7. Security Considerations		9. Acknowledgements
	Documents of this type do not directly affect the security of		We thank Bob Thomas for providing valuable comments to this document.
	the Internet or of corporate networks as long as benchmarking		We also thank Andrey Kiselev for his review and suggestions.
	is not performed on devices or systems connected to operating
	networks.
	8. Acknowledgements		10. References
	We thank Bob Thomas for providing valuable comments to this document.		10.1. Normative References
	We also thank Andrey Kiselev for his review and suggestions.
	9. References		[I-D.ietf-bmwg-igp-dataplane-conv-app]
			Poretsky, S., "Considerations for Benchmarking Link-State
			IGP Data Plane Route Convergence",
			draft-ietf-bmwg-igp-dataplane-conv-app-14 (work in
			progress), November 2007.
	[LDP-TERM] Eriksson, et al, “Terminology for Benchmarking LDP Data		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Plane Convergence”, draft-eriksson-ldp-convergence-term-		Requirement Levels", BCP 14, RFC 2119, March 1997.
	04 (Work in progress), February 2007.
	[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and		[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
	B. Thomas, "LDP Specification", RFC 3036, January 2001.		Zekauskas, "A One-way Active Measurement Protocol
			(OWAMP)", RFC 4656, September 2006.
	[IGP-METH] S. Poretsky, B. Imhoff, "Benchmarking Methodology for		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	IGP Data Plane Route Convergence," draft-ietf-bmwg-igp-		Specification", RFC 5036, October 2007.
	dataplane-conv-meth-11.txt,” work in progress.
	[IGP OSPF] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998.		[RFC5037] Andersson, L., Minei, I., and B. Thomas, "Experience with
			the Label Distribution Protocol (LDP)", RFC 5037,
			October 2007.
	10. Author's Address		[RFC5038] Thomas, B. and L. Andersson, "The Label Distribution
			Protocol (LDP) Implementation Survey Results", RFC 5038,
			October 2007.
	Jay Karthik		10.2. Informative References
	Benchmarking Methodology
	Cisco System		[LDP-Term]
	300 Beaver Brook Road		T. Eriksson, et al., "Terminology for Benchmarking LDP
	Boxborough, MA 01719		Data Plane Convergence", February 2007.
	USA
	Phone: +1 978 936 0533
	Email: jkarthik@cisco.com
	Rajiv Papneja		Authors' Addresses
	Isocore
	12359 Sunrise Valley Drive, STE 100
	Reston, VA 20190
	USA
	Phone: +1 703 860 9273
	Email: rpapneja@isocore.com
	Charles Rexrode		Jay Karthik (editor)
	Verizon		Cisco Systems
	320 St Paul Place, 14th Fl		300 Beaver Brook Road
	Baltimore, MD 21202		Boxborough, MA 01719
	USA		USA
	Email: charles.a.rexrode@verizon.com
	Full Copyright Statement		Phone: +1 978 936 0533
			Fax: +1 978 936 0000
			Email: jkarthik@cisco.com
			URI: http://www.cisco.com
	Copyright (C) The IETF Trust (2007).		Rajiv Papneja (editor)
			Isocore
			12359 Sunrise Valley Drive, STE 100
			Reston 20190
			USA
	This document is subject to the rights, licenses and restrictions		Phone: +1 703 860 9273
	contained in BCP 78, and except as set forth therein, the authors		Email: rpapneja@isocore.com
	retain all their rights.		URI: www.isocore.com
	This document and the information contained herein are provided on		Mohan Nanduri
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		Tata Communications
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE		12010 Sunset Hills Road, 4th Floor
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL		Reston 20190
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY		USA
	WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.
	Benchmarking Methodology		Email: Mohan.Nanduri@tatacommunications.com
	Intellectual Property		Full Copyright Statement
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		Copyright (C) The IETF Trust (2008).
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.
	Acknowledgement		This document is subject to the rights, licenses and restrictions
	Funding for the RFC Editor function is currently provided by the		contained in BCP 78, and except as set forth therein, the authors
	Internet Society.		retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
			THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
			OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
			THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
			The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
			Acknowledgment
			Funding for the RFC Editor function is provided by the IETF
			Administrative Support Activity (IASA).
End of changes. 103 change blocks.
	325 lines changed or deleted		327 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/