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

Just picking up on 3.6.5 and 3.6.6, no!;-)

I think that the original 3.6.6. is just fine and wonder if Al has misread it in
the light of 3.6.5.

3.6.5 does need amending to bring in line with 3.6.6 but it is an additional
'if' that is needed not a 'when', in just the place where 3.6.6 has one.

Your reformulation I find less clear; better for clarity to put that conditional
clause earlier rather than later, as you originally did.

Tom Petch

----- Original Message -----
From: "Kris Michielsen" <kmichiel@cisco.com>
To: "'Al Morton'" <acmorton@att.com>; <bmwg@ietf.org>
Sent: Friday, July 17, 2009 4:51 PM
Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-igp-dataplane drafts

> Al,
>
> Many thanks for reviewing the draft!
>
> See below.
>
> > -----Original Message-----
> > From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On
> > Behalf Of Al Morton
> > Sent: 15 July 2009 17:58
> > To: bmwg@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@ietf.org
> > https://www.ietf.org/mailman/listinfo/bmwg
> >
>
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg