Subject: [bmwg] IGP Data Plane Convergence - Comments from IETF 60

From: [email-masked]
Date: Mon, 9 Aug 2004 16:41:35 -0400

Folks,

I have updated to the IGP Data Plane Convergence documents based upon
comments received at IETF 60 and will soon be posting rev -04 for the
Applicability, Terminology, and Methodology documents.  The pending changes
from the -03 rev to the -04 rev are listed below.  As this work will soon
again be in Last Call for IESG review, please review this list and let me
know if these changes are unacceptable or additions need to be made to the
list.

Thanks,
Scott

APPLICABILITY Document
1. Comment from Al - Changed title to "Considerations for Benchmarking IGP
Data Plane Route Convergence"

TERMINOLOGY Document
2. Comment from Robert/Al - Convergence Packet Loss term Discussion now
includes statement "Convergence Packet Loss may or may not reach 100%." 
	
3. Comment from Al - Convergence Event Transition term Discussion now
includes statement "The Convergence Event Transition may not be linear."

4. Comment from Al - Convergence Recovery Transition term Discussion now
includes statement "The Convergence Recovery Transition may not be linear."

METHODOLOGY Document
5. Suggestion from Brooks Hickman - Insert step in all procedures after
measuring Convergence Time and before measuring Restoration Time:  "Stop
Offered Load.  Wait 30 seconds for buffers to drain.  Restart Offered Load."
See Step 6 in the following example:

4.1.1 Convergence Due to Local Interface Failure
	Objective
	To obtain the IGP Route Convergence due to a local link 
	failure event at the DUT's Local Interface.

	Procedure 
	1. Advertise matching IGP routes from Tester to DUT on 
           Preferred Egress Interface [2] and Next-Best Egress Interface 
	   [2] using the topology shown in Figure 1.  Set the cost of the 
	   routes so that the Preferred Egress Interface is the preferred 
   	   next-hop.
	2. Send traffic at maximum forwarding rate to destinations 
           matching all IGP routes from Tester to DUT on Ingress Interface
	   [2].
	3. Verify traffic routed over Preferred Egress Interface.
	4. Remove SONET on DUT's Local Interface [2] by performing an 
	   administrative shutdown of the interface.
	5. Measure Rate-Derived Convergence Time [2] as DUT detects the 
	   link down event and converges all IGP routes and traffic over 
	   the Next-Best Egress Interface.
	6. Stop Offered Load.  Wait 30 seconds for queues to drain.  
	   Restart Offered Load.
	7. Restore SONET on DUT's Local Interface by administratively
	   enabling the interface. 
	8. Measure Restoration Convergence Time [2] as DUT detects the link 
	   up event and converges all IGP routes and traffic back to the 
	   Preferred Egress Interface.

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Al Morton <[email-masked]>
Date: Wed, 11 Aug 2004 16:41:34 -0400

>includes statement "The Convergence Recovery Transition may not be linear."
I was following-up on Bob Holley's suggestion to characterize the
transition times to maximum loss, and during that discussion,
the non-linear slope came up.
But the main point is that you already have two "Instants"
defined, and if you define two more (where Max Loss is first meas,
and where traffic begins to restore) then you can characterize
the transition times.

Al