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

Scott Poretsky <sporetsky@avici.com> Thu, 24 July 2003 18:00 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18782 for <bmwg-archive@lists.ietf.org>; Thu, 24 Jul 2003 14:00:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkNl-00034Y-Hx; Thu, 24 Jul 2003 14:00:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkNF-00033A-KL for bmwg@optimus.ietf.org; Thu, 24 Jul 2003 13:59:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18715 for <bmwg@ietf.org>; Thu, 24 Jul 2003 13:59:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkND-0000VT-00 for bmwg@ietf.org; Thu, 24 Jul 2003 13:59:27 -0400
Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19fkN2-0000V1-00 for bmwg@ietf.org; Thu, 24 Jul 2003 13:59:16 -0400
Received: from sporetsky-lt.avici.com ([10.2.104.35]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h6OHulb9014021; Thu, 24 Jul 2003 13:56:47 -0400
Message-Id: <5.0.2.1.2.20030724133614.02eb60b0@pop.avici.com>
X-Sender: sporetsky@pop.avici.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 24 Jul 2003 13:59:18 -0400
To: "Perser, Jerry" <jerry.perser@spirentcom.com>, bmwg@ietf.org
From: Scott Poretsky <sporetsky@avici.com>
Subject: RE: [bmwg] Comments on draft-ietf-bmwg-igp-dataplane-conv-meth-00 .txt
In-Reply-To: <629E717C12A8694A88FAA6BEF9FFCD44031B319B@brigadoon.spirent com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: bmwg-admin@ietf.org
Errors-To: bmwg-admin@ietf.org
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>

Jerry,

Are you suggesting we add another test case to measure Convergence Time 
when the original primary path is restored?  I think this is a great idea 
and we will make this a test case.  I agree it would require a new term 
such as "Restoration Convergence Time" or "Recovery Convergence 
Time".  Which do you prefer, if either?

We will also add another test case to measure Convergence Time when the 
interface for a better path is brought up for the first time.  This should 
not produce any packet loss, but it is important to verify.  We will add a 
term such as "Link-Enabled Convergence Time".  Suggestions are welcome.

Scott

At 10:10 AM 7/24/2003 -0700, Perser, Jerry wrote:
>Convergence time when traffic goes from backup path to preferred path should
>be a separate metric.  In past tests, we were toggling the preferred path
>status up and down.  We notice that the convergence times were different.  I
>do not have an explanation for why failure was different than restore.  This
>asymmetrical convergence time was observed on several different routers.
>
>Jerry.
>___________________________________________________________
>Jerry Perser                         Spirent Communications
>Director of Test Methodology         SmartBits Division
>Phone: 818.676.2320                  26750 Agoura Road
>Lab:   818.676.2337                  Calabasas, CA, 91302
>Cell:  818.292.6457                  Corp:  818.676.2300
>
> > -----Original Message-----
> > From: Thomas Eriksson [mailto:thomas.a.eriksson@teliasonera.com]
> > Sent: Thursday, July 24, 2003 8:04 AM
> > To: bmwg@ietf.org
> > Subject: [bmwg] Comments on
> > draft-ietf-bmwg-igp-dataplane-conv-meth-00.txt
> >
> >
> > 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.
> >
> > 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).
> >
> > Thomas
> >
> >
> > _______________________________________________
> > bmwg mailing list
> > bmwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/bmwg
> >
>
>_______________________________________________
>bmwg mailing list
>bmwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/bmwg



_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg