Subject: [bmwg] convergence terminology in practice...

From: "Player, Timmons" <[email-masked]>
Date: Fri, 5 Nov 2004 09:05:08 -1000

Howdy, all.

I've spent the past week testing some OSPFv3 routers.  I've also attempted
to use the convergence terminology from the draft, and would like to know if
the results and interpretation I'm using are acceptable for the authors and
other testers in general.

So, let me tell you about router A.  After a convergence event, router A
always drops packets until the test traffic stops.  After the test traffic
stops, router A will resume forwarding at the pre convergence event rate
when test traffic is restarted.  This was the behavior with 1 minutes of
post convergence event traffic, 5 minutes post convergence event traffic, 15
minutes post convergence event traffic, and 30 minutes post convergence
event traffic.

According to the terminology draft, reconvergence never occurs in any of
these four trials, so the following terms are all undefined:

Convergence Packet Loss:  Undefined
Convergence Recovery Instant:  Undefined
Rate Derived Convergence Time:  Undefined
Convergence Recovery Transition:  Undefined
Loss Derived Convergence Time:  Undefined

However, the router clearly converges.  It just drops packets from there on
out.  After the convergence event, I cease to get packets on the
preferred-egress-interface, and all forwarded packets egress on the
next-best-egress-interface.

Granted this router is really bad at routing and probably even has a bug
somewhere, but shouldn't a methodology/terminology handle all possible
outcomes and not just the expected ones?

Timmons

P.S.  I'm not making this up.  Router A is a real router made by a pretty
big vendor.

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

---

From: [email-masked]
Date: Mon, 8 Nov 2004 10:03:15 -0500

You are correct that you observed very strange router behavior.  I do
believe that the existing terminology covers this case that you obtained
when applying the methodology to this particular device.  Based upon your
explanation as I understand it, the benchmarks would be reported as follow:

Convergence Packet Loss:  Infinite
Convergence Recovery Instant:  Undefined
Rate Derived Convergence Time:  Infinite
Convergence Recovery Transition:  Undefined
Loss Derived Convergence Time:  Infinite

Scott

-----Original Message-----
From: Player, Timmons [mailto:[email-masked]]
Sent: Friday, November 05, 2004 2:05 PM
To: [email-masked]'
Subject: [bmwg] convergence terminology in practice...

Howdy, all.

Timmons

---

From: "Player, Timmons" <[email-masked]>
Date: Mon, 8 Nov 2004 07:17:42 -1000

Hmm...  This still doesn't really fix the problem.  The Convergence Recovery
Instant is undefined, but the device definately converges.  How do we
resolve this abiguity?

Timmons

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 08, 2004 7:03 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [bmwg] convergence terminology in practice...
> 
>

---

From: [email-masked]
Date: Mon, 8 Nov 2004 13:14:30 -0500

Timmons,

Based upon your previous explanation and the definition of Full Convergence,
the device does not converge.  Why do you think it does converge?

Scott

-----Original Message-----
From: Player, Timmons [mailto:[email-masked]]
Sent: Monday, November 08, 2004 12:18 PM
To: [email-masked]'; [email-masked]
Subject: RE: [bmwg] convergence terminology in practice...

Timmons

---

From: "Player, Timmons" <[email-masked]>
Date: Mon, 8 Nov 2004 08:58:36 -1000

All forwarded packets exit the next-best-egress interface and all of the
routes and next-hops have been updated in the FIB.  Note, this is the
critieria in the discussion section of the term "route convergence."

Timmons

> Sent: Monday, November 08, 2004 10:15 AM