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

From: "Perser, Jerry" <[email-masked]>
Date: Thu, 24 Jul 2003 10:10:03 -0700

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:[email-masked]]
> Sent: Thursday, July 24, 2003 8:04 AM
> To: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bmwg
> 

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: "Perser, Jerry" <[email-masked]>
Date: Thu, 24 Jul 2003 10:10:03 -0700

Jerry.

---

From: Scott Poretsky <[email-masked]>
Date: Thu, 24 Jul 2003 13:59:18 -0400

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

---

From: "Perser, Jerry" <[email-masked]>
Date: Thu, 24 Jul 2003 11:10:43 -0700

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.

> From: Scott Poretsky [mailto:[email-masked]]
> Sent: Thursday, July 24, 2003 10:59 AM
> To: Perser, Jerry; [email-masked]
> Subject: RE: [bmwg] Comments on
> draft-ietf-bmwg-igp-dataplane-conv-meth-00 .txt
> 
> 
> Jerry,
>

---

From: Scott Poretsky <[email-masked]>
Date: Thu, 24 Jul 2003 14:24:41 -0400

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

---

From: Scott Poretsky <[email-masked]>
Date: Thu, 24 Jul 2003 13:59:18 -0400

Jerry,

Scott

---

From: "Perser, Jerry" <[email-masked]>
Date: Thu, 24 Jul 2003 11:10:43 -0700

Jerry.

---

From: Scott Poretsky <[email-masked]>
Date: Thu, 24 Jul 2003 14:24:41 -0400

Jerry,

Scott