RE: [bmwg] useful testing (was: Opinions on Benchmarking the BFDprotocol)

["Poretsky, Scott" <[e-mail]>]

Curtis,  You will be happy to hear I changed my new email configuration.


Hi BMWG-ers,

Sorry I cannot join you this week in Prague.  I will be in Chicago.  

The BFD topic is certainly of interest.  There are 3 existing official
BMWG work items that could be directly related.  These are 

1.IGP Convergence Data Plane Benchmarking (status=completed WGLC and
Cross-Area Review)
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-m
eth-12.txt
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-t
erm-12.txt
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-a
pp-12.txt

Test cases for many Convergence Events are provided in the methodology.
Is it worth adding a test case for BFD? 

2.Accelerated Stress Benchmarking (status=had a first WGLC with lots of
feedback)
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-acc-bench-term-11.tx
t
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-acc-bench-meth-07.tx
t

The working group decided to breakout Layer 3 technology specific
methodologies into separate documents and work those after the
Terminology and General Methodology Guidelines are completed.  These
were written for EBGP and Operational Security (consistent with OpSec WG
work) and the intention of the work item is to be modular for support of
more methodologies.  The now expired methodology documents are
draft-ietf-bmwg-acc-bench-meth-ebgp-00.txt and
draft-ietf-bmwg-acc-bench-meth-opsec-00.txt.  Work will continue on
those after the Terminology and Methodology Guidelines docs are
complete.  BFD could certainly be addressed in this work item.

3.Sub-IP Protection Mechanisms (status=approaching request for a WGLC)
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-protection-term-01.t
xt
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-protection-meth-01.t
xt

This work item covers all protection mechanisms that operate below Layer
3 while benchmarking the Layer 3 performance of those mechanisms. It is
intended that this work item have a single terminology with multiple
methodologies.  The MPLS FRR methodology is the first.  BFD could
certainly be addressed in this work item. 

Scott

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Friday, March 16, 2007 3:36 PM
To: Al Morton
Cc: Dave Katz; David Ward; [e-mail]; Jeffrey Haas
Subject: Re: [bmwg] useful testing (was: Opinions on Benchmarking the
BFDprotocol) 


In message <[e-mail]>
Al Morton writes:
>  
> At 01:14 PM 3/16/2007, Curtis Villamizar wrote:
> >...To be truly useful, testing has to enable all protocols that are 
> >intended to be used and stress a set of protocols and other inputs
> >(ie: framing errors, intermittent interfaces, SNMP/NMS load, etc).
> >If BFD performance were to degrade under such stress, then overall 
> >network instability might result.
> >
> >That doesn't mean that individual protocols can't be benchmarked in 
> >isolation.  Its just that such tests don't indicate scalability and 
> >may give an overstated measure of performance capabilities.
> >
> >We are a bit off topic, but maybe BMWG should look at a modular 
> >approach to stress testing in which the stress test component that 
> >goes with the addition of any particular protocol was covered in a 
> >separate RFC for that protocol.
>  
> Or, should we look at ways to make our Accelerated Stress Benchmarking

> drafts more modular, and then consider the BFD topic as a possible
module?

Thats what I had in mind.

> In any case, more folks should read the Accelerated Stress 
> Benchmarking drafts, they are overdue milestone-wise.

draft-ietf-bmwg-acc-bench-term-11.txt
draft-ietf-bmwg-acc-bench-meth-07.txt

For those that lost track of the revision number.

Perhaps I should start another thread and give comments so I'll be
brief.

The acc-bench-meth might be trying to cover too much.  It might be worth
cutting it back to a framework and then taking the configuration sets
and instability conditions for each protocol and producing a separate
document for each.

This would let the base documents move forward and the WG can focus on
each protocol individually.  That BFD was missed entirely is an argument
for this separation.  The BGP experts can review BGP, the multicast
experts can review multicast.  Etc.  We might accomplish more and get a
better result with a divide and conquer strategy.

> Al
> bmwg co-chair who couldn't resist making a connection in an effort to 
> keep the existing work moving!

Curtis

ps - hopefully Scott P won't send a reply with base64 encoded html.  :-)

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

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