RE: [bmwg] Comments on draft-ietf-bmwg-igp-dataplane-conv-meth-00 .txt
Thomas Eriksson <thomas.a.eriksson@teliasonera.com> Fri, 22 August 2003 16:08 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 MAA04810 for <bmwg-archive@lists.ietf.org>; Fri, 22 Aug 2003 12:08:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qESK-0002RW-CE; Fri, 22 Aug 2003 12:08:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxVH-0007rg-5X for bmwg@optimus.ietf.org; Fri, 25 Jul 2003 04:00:39 -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 EAA27976 for <bmwg@ietf.org>; Fri, 25 Jul 2003 04:00:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxVE-0006FL-00 for bmwg@ietf.org; Fri, 25 Jul 2003 04:00:36 -0400
Received: from tms001bb.han.telia.se ([131.115.230.132]) by ietf-mx with esmtp (Exim 4.12) id 19fxV3-0006F8-00 for bmwg@ietf.org; Fri, 25 Jul 2003 04:00:26 -0400
Received: from tms001fe.tcad.telia.se ([131.115.230.143]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Jul 2003 10:00:01 +0200
Received: from TRAB3108.teliasonera.com ([131.115.157.40]) by tms001fe.tcad.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Fri, 25 Jul 2003 10:00:00 +0200
Message-Id: <5.2.1.1.0.20030725094851.020e4be8@tmspop.telia.se>
X-Sender: ther45@tmspop.telia.se
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Fri, 25 Jul 2003 09:55:51 +0200
To: "Perser, Jerry" <jerry.perser@spirentcom.com>, bmwg@ietf.org
From: Thomas Eriksson <thomas.a.eriksson@teliasonera.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"
X-OriginalArrivalTime: 25 Jul 2003 08:00:00.0570 (UTC) FILETIME=[BF5439A0:01C35282]
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>
I believe this has to do with that when going from preferred to backup, we start loosing packets directly, but when going from from backup to preferred we can continuously forward packets until we have installed the new route at hardware level and then switch over. This of course have to do with how router vendors implement things internally. Jerry, I have seen it as well when doing test. Thomas At 10:10 2003-07-24 -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
- RE: [bmwg] Comments on draft-ietf-bmwg-igp-datapl… Perser, Jerry
- RE: [bmwg] Comments on draft-ietf-bmwg-igp-datapl… Scott Poretsky
- RE: [bmwg] Comments on draft-ietf-bmwg-igp-datapl… Perser, Jerry
- RE: [bmwg] Comments on draft-ietf-bmwg-igp-datapl… Scott Poretsky
- RE: [bmwg] Comments on draft-ietf-bmwg-igp-datapl… Thomas Eriksson
- [bmwg] something wrong with this list? John Schnizlein