Re: [bmwg] WGLC: draft-ietf-bmwg-igp-dataplane drafts

["Kris Michielsen" <kmichiel at cisco.com>]

Al,

Many thanks for reviewing the draft!

See below.

> -----Original Message-----
> From: bmwg-bounces at ietf.org [mailto:bmwg-bounces at ietf.org] On 
> Behalf Of Al Morton
> Sent: 15 July 2009 17:58
> To: bmwg at ietf.org
> Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-igp-dataplane drafts
> 
> At 01:44 PM 7/14/2009, Al Morton wrote:
> >...This message begins a Last call on the IGP-Dataplane Convergence 
> >Time Benchmarking drafts.
> >
> >http://tools.ietf.org/html/draft-ietf-bmwg-igp-dataplane-conv-term-18
> >http://tools.ietf.org/html/draft-ietf-bmwg-igp-dataplane-conv-meth-18
> >http://tools.ietf.org/html/draft-ietf-bmwg-igp-dataplane-conv-app-17
> >
> >The Last Call will end on July 31, 2009.
> 
> Comments on terms-18,
> Al (mostly as participant, as chair for section 4)
> 
> I think we now need a definition of the "Start Traffic 
> Instant" mentioned first in section 3.6.3.  It should be 
> defined up-front and probably included in Figure 1.

I added:
---
3.2.1.  Traffic Start Instant

   Definition:

   The time instant the Tester sends out the first data packet to the
   DUT.

   Discussion:

   If using the Loss-Derived Method or the Route-Specific Loss-Derived
   Method to benchmark IGP convergence time, and the applied Convergence
   Event does not cause instantaneous traffic loss for all routes at the
   Convergence Event Instant then the Tester SHOULD collect a timestamp
   on the Traffic Start Instant in order to measure the period of time
   between the Traffic Start Instant and Convergence Event Instant.

   Measurement Units:

   hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
   microseconds.

   Issues: None

   See Also:

   Convergence Event Instant, Route-Specific Convergence Time, Loss-
   Derived Convergence Time.
---

I also marked the instant in figure 1

> 
> Section 3.5.1
> s/The Offered Load SHOULD consists /The Offered Load SHOULD consist /
> 
> s/Packet Sampling Interval is too high./Packet Sampling 
> Interval is too large./
> 
> Section 3.5.2
> s/The Offered Load SHOULD consists /The Offered Load SHOULD consist / 

I corrected the above

> Section 3.6.5
> s/Event, traffic for all routes /Event, when traffic for all routes /

Would it be better/more clear if I rephrase the sentence as follows?
OLD:
The Route Loss of Connectivity Period may be equal to the Route-Specific Convergence Time if, as a characteristic of the Convergence
Event, traffic for all routes starts dropping instantaneously on the Convergence Event Instant.

NEW:
The Route Loss of Connectivity Period may be equal to the Route-Specific Convergence Time if traffic for all routes starts dropping
instantaneously on the Convergence Event Instant as a characteristic of the Convergence Event.

> 
> Section 3.6.6
> s/Event, traffic for all routes /Event, when traffic for all routes /

Same as 3.6.5 comment above.

> 
> Section 3.7.6
> OLD
>     ...The BMWG selected 5 seconds based upon RFC 2544 [Br99]
>     which recommends waiting 2 seconds for residual frames to 
> arrive NEW
>     ...The BMWG selected 5 seconds based upon RFC 2544 [Br99]
>     which recommends waiting 2 seconds for residual frames to arrive
>     (this is the Forwarding Delay Threshold for the last packet sent)
> 

OK

> Section 4 Security Considerations
> What's all this about SIP?
> I suggest to use the "standard" BMWG paragraphs:
> >    Benchmarking activities as described in this memo are limited to
> >    technology characterization using controlled stimuli in 
> a laboratory
> >    environment, with dedicated address space and the constraints
> >    specified in the sections above.
> >
> >    The benchmarking network topology will be an independent 
> test setup
> >    and MUST NOT be connected to devices that may forward the test
> >    traffic into a production network, or misroute traffic 
> to the test
> >    management network.
> >
> >    Further, benchmarking is performed on a "black-box" 
> basis, relying
> >    solely on measurements observable external to the DUT/SUT.
> >
> >    Special capabilities SHOULD NOT exist in the DUT/SUT 
> specifically for
> >    benchmarking purposes.  Any implications for network 
> security arising
> >    from the DUT/SUT SHOULD be identical in the lab and in production
> >    networks.
 
I corrected it as you suggested.

Kris

> 
> _______________________________________________
> bmwg mailing list
> bmwg at ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg
>