[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bmwg] WGLC: draft-ietf-bmwg-igp-dataplane drafts
Tom,
Thanks for pointing this out!
I'll do as you and Al suggested.
Thanks,
Kris
> -----Original Message-----
> From: Al Morton [mailto:acmorton at att.com]
> Sent: 18 July 2009 14:38
> To: Tom Petch; Kris Michielsen; bmwg at ietf.org
> Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-igp-dataplane drafts
>
> Hi Tom,
>
> Thanks for carefully reading all of this, much appreciated.
> You said:
> >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.
>
> I agree, the fact is that I didn't notice the text in 3.6.6
> included the conditional aspect I sought to add in 3.6.5
> (where the "if" is missing), as you suspected.
>
> So Kris, if you add the "if" in 3.6.5 as in 3.6.6, I think we
> have a deal.
>
> regards,
> Al
>
> At 06:33 AM 7/18/2009, Tom Petch wrote:
> >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 at cisco.com>
> >To: "'Al Morton'" <acmorton at att.com>; <bmwg at 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 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-ter
> > > > >m-18
> > > >
> >http://tools.ietf.org/html/draft-ietf-bmwg-igp-dataplane-conv-met
> > > > >h-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
> > > >
> > >
> > > _______________________________________________
> > > bmwg mailing list
> > > bmwg at ietf.org
> > > https://www.ietf.org/mailman/listinfo/bmwg
> >
> >_______________________________________________
> >bmwg mailing list
> >bmwg at ietf.org
> >https://www.ietf.org/mailman/listinfo/bmwg
>