Re: [bmwg] FW: WGLC: draft-ietf-bmwg-reset-00

Timmons,

Thanks for the feedback, please see inline,

> This states I need to provide the frame loss counters, which is fine,
> But if my test tool
> 	
> a) only counts transmitted test frames as trasmitted
> -and-
> b) uses a non-frame loss based method to measure the recovery time
> 
> then providing the frame loss counters seems not entirely useful.

Then, such a test tool is not compliant with RFC2544 (please see section
26.3 for frame loss rate calculation).

Also, the test tool will be out of sync with other upcoming BMWG
specifications such as IGP convergence benchmarking. Please see 2nd para
of section 1.
http://datatracker.ietf.org/doc/draft-ietf-bmwg-igp-dataplane-conv-meth/

<...
   IGP convergence time is measured on the data plane at the Tester by
   observing packet loss through the DUT.  All factors contributing to
   convergence time are accounted for by measuring on the data plane, as
...>

Please note that draft-ietf-bmwg-reset document does recommend the test
tool to report the frame-loss for each testcase.

Cheers,
Rajiv

> -----Original Message-----
> From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf
Of
> Timmons C. Player
> Sent: Tuesday, July 20, 2010 10:17 AM
> To: Fernando Calabria (fcalabri)
> Cc: bmwg@ietf.org
> Subject: Re: [bmwg] FW: WGLC: draft-ietf-bmwg-reset-00
> 
> On 7/20/2010 10:01 AM, Fernando Calabria (fcalabri) wrote:
> > Timmons,
> >
> > It's a MAY, not a MUST anymore so we are not saying that this is the
> > only available one ,..
> >
> > Fer,
> >
> 
> I was referring to this particular part of the text:
> ---
> Finally, the characterization is completed by providing  the  frame
> loss
> counters (reported by the Test Apparatus)  and recovery time from the
> moment the RP is re-initialized or reinserted and all traffic
recovered
> (stop time).
> ---
> 
> This states I need to provide the frame loss counters, which is fine,
> But if my test tool
> 	
> a) only counts transmitted test frames as trasmitted
> -and-
> b) uses a non-frame loss based method to measure the recovery time
> 
> then providing the frame loss counters seems not entirely useful.
> 
> Additionally, in this case I MAY NOT use the formula to approximate
> recovery time.
> 
> So, it seems we're back to having the test tool behave a certain way
> instead of measuring a specific event.
> 
> Timmons
> 
> > -----Original Message-----
> > From: Timmons C. Player [mailto:timmons@monkeyplayground.net]
> > Sent: Tuesday, July 20, 2010 9:44 AM
> > To: Fernando Calabria (fcalabri)
> > Cc: bmwg@ietf.org
> > Subject: Re: [bmwg] FW: WGLC: draft-ietf-bmwg-reset-00
> >
> 
> >>
> >>
> >> Third, perform the Route Processor (RP) hardware reset at this
point
> >> (start time) . This entails for example physically removing the RP
> to
> >> later re-insert it, or triggering a hardware reset by other means
> > (e.g.,
> >> command line interface, physical switch, etc.)....
> >>
> >>
> >> Finally, the characterization is completed by providing  the  frame
> > loss
> >> counters (reported by the Test Apparatus)  and recovery time from
> the
> >> moment the RP is re-initialized or reinserted and all traffic
> > recovered
> >> (stop time) . The tester / operator MAY use the following formula
> for
> >> reporting and characterization proposes:
> >>
> >> Recovery_time = Packet_loss (packets)/Offered_rate (packets per
> > second).
> >>
> >> ...........
> >>
> >
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg