Re: [bmwg] Comments on draft-ietf-bmwg-igp-dataplane-conv-meth-00.txt

Scott Poretsky <> Thu, 24 July 2003 17:35 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id NAA17198 for <>; Thu, 24 Jul 2003 13:35:32 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 19fjzZ-0001n0-L1; Thu, 24 Jul 2003 13:35:01 -0400
Received: from ([] by with esmtp (Exim 4.20) id 19fjyl-0001mT-Ec for; Thu, 24 Jul 2003 13:34:11 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA17167 for <>; Thu, 24 Jul 2003 13:34:07 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19fjyj-0000EW-00 for; Thu, 24 Jul 2003 13:34:09 -0400
Received: from [] ( by ietf-mx with esmtp (Exim 4.12) id 19fjyY-0000EE-00 for; Thu, 24 Jul 2003 13:33:58 -0400
Received: from ([]) by (8.12.8/8.12.8) with ESMTP id h6OHXSb9010994; Thu, 24 Jul 2003 13:33:29 -0400
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 24 Jul 2003 13:35:59 -0400
To: Thomas Eriksson <>,
From: Scott Poretsky <>
Subject: Re: [bmwg] Comments on draft-ietf-bmwg-igp-dataplane-conv-meth-00.txt
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Benchmarking Methodology Working Group <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

At 05:04 PM 7/24/2003 +0200, Thomas Eriksson wrote:
>Here are some comments on draft-ietf-bmwg-igp-dataplane-conv-meth-00.txt.
>The draft is focusing mainly on convergence time when things break. It may 
>also be interesting to study the convergence time when traffic goes from 
>backup path to preferred path.

Absolutely!  I believe this is covered with test case "4.1.5 Convergence 
Due to Cost Change".  Would you like an additional test case?

>An interesting test case is when ECMP is used on the SUT and we want to 
>benchmark convergence time. I do not think that the current methodology 
>will work for this case because some traffic will go over the "backup 
>path" as well. This could be fixed by measuring the traffic on the 
>"prefered path" and when this traffic is rerouted to the "backup path" 
>calculate convergence time based on that. I am not sure however is if is 
>possible to produce comparable results when using ECMP ? (I guess it 
>somewhat implementation dependent function).

Great suggestion.  We will add a test case for measuring convergence on 
ECMP links.


>bmwg mailing list

bmwg mailing list