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

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