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

Scott Poretsky <sporetsky@avici.com> Thu, 24 July 2003 18:24 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 OAA19922 for <bmwg-archive@odin.ietf.org>; Thu, 24 Jul 2003 14:24:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fklJ-0004pj-AY for bmwg-archive@odin.ietf.org; Thu, 24 Jul 2003 14:24:21 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OIOLBO018578 for bmwg-archive@odin.ietf.org; Thu, 24 Jul 2003 14:24:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkky-0004pC-Nc; Thu, 24 Jul 2003 14:24:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkkh-0004oj-TC for bmwg@optimus.ietf.org; Thu, 24 Jul 2003 14:23:43 -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 OAA19897 for <bmwg@ietf.org>; Thu, 24 Jul 2003 14:23:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkkf-0000hV-00 for bmwg@ietf.org; Thu, 24 Jul 2003 14:23:41 -0400
Received: from [12.38.212.174] (helo=mailhost.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19fkkR-0000gy-00 for bmwg@ietf.org; Thu, 24 Jul 2003 14:23:29 -0400
Received: from sporetsky-lt.avici.com ([10.2.104.35]) by mailhost.avici.com (8.12.8/8.12.8) with ESMTP id h6OIMAb9017252; Thu, 24 Jul 2003 14:22:10 -0400
Message-Id: <5.0.2.1.2.20030724142014.02eb05c8@pop.avici.com>
X-Sender: sporetsky@pop.avici.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 24 Jul 2003 14:24:41 -0400
To: "Perser, Jerry" <jerry.perser@spirentcom.com>, "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: <629E717C12A8694A88FAA6BEF9FFCD44031B319E@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,

Thomas suggested a Convergence Time measurement case for ECMP links, which 
is much different from a Recovery case in which the Convergence Time from 
the next-best path back to the best path is measured.  Both are great 
suggestions and both will be added.

As far as the term for the recovery case - I like "Restoration Convergence 
Time" or "Recovery Convergence Time".  Do you have objections with 
either?  I do not think this will cause problems with SONET APS or MPLS 
Protection benchmarking terminology since the word "Convergence" should not 
appear with those terms.

Scott

At 11:10 AM 7/24/2003 -0700, Perser, Jerry wrote:
>This was actually Thomas suggestion.  If you proceed (it sounds like you
>will), you will need another metric to go along with this addition test
>case.
>
>My concern was that people would confuse failure and recovery times.  Two
>separate metrics may solve this.  You may want to consider a term that will
>not be confused with MPLS protection or Sonet protection.
>
>Jerry.
>
> > -----Original Message-----
> > From: Scott Poretsky [mailto:sporetsky@avici.com]
> > Sent: Thursday, July 24, 2003 10:59 AM
> > To: Perser, Jerry; bmwg@ietf.org
> > Subject: RE: [bmwg] Comments on
> > draft-ietf-bmwg-igp-dataplane-conv-meth-00 .txt
> >
> >
> > 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