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

Al Morton <acmorton@att.com> Sat, 18 July 2009 12:38 UTC

Return-Path: <acmorton@att.com>
X-Original-To: bmwg@core3.amsl.com
Delivered-To: bmwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6DF03A6A7D for <bmwg@core3.amsl.com>; Sat, 18 Jul 2009 05:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.796
X-Spam-Level:
X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1gzVD8+MeZq for <bmwg@core3.amsl.com>; Sat, 18 Jul 2009 05:38:26 -0700 (PDT)
Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id C09443A6A49 for <bmwg@ietf.org>; Sat, 18 Jul 2009 05:38:26 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-11.tower-161.messagelabs.com!1247920700!297692!1
X-StarScan-Version: 6.0.0; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 28846 invoked from network); 18 Jul 2009 12:38:21 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-11.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Jul 2009 12:38:21 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6ICcKiD017622 for <bmwg@ietf.org>; Sat, 18 Jul 2009 08:38:20 -0400
Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6ICcFRV017602 for <bmwg@ietf.org>; Sat, 18 Jul 2009 08:38:15 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n6ICcF4C000947 for <bmwg@ietf.org>; Sat, 18 Jul 2009 08:38:15 -0400
Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n6ICcBHU000918 for <bmwg@ietf.org>; Sat, 18 Jul 2009 08:38:11 -0400
Message-Id: <200907181238.n6ICcBHU000918@alph001.aldc.att.com>
Received: from acmt.att.com (vpn-135-70-108-100.vpn.swst.att.com[135.70.108.100](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090718123805gw1003ib63e>; Sat, 18 Jul 2009 12:38:10 +0000
X-Originating-IP: [135.70.108.100]
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 18 Jul 2009 08:38:01 -0400
To: Tom Petch <nwnetworks@dial.pipex.com>, Kris Michielsen <kmichiel@cisco.com>, bmwg@ietf.org
From: Al Morton <acmorton@att.com>
In-Reply-To: <000901ca0793$308b4160$0601a8c0@allison>
References: <200907141744.n6EHiFHV017091@alph001.aldc.att.com> <200907151557.n6FFvlAC003415@alph001.aldc.att.com> <00a001ca06ee$21bdf240$840efe90@emea.cisco.com> <000901ca0793$308b4160$0601a8c0@allison>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-igp-dataplane drafts
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bmwg>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jul 2009 12:38:28 -0000

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@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
>
>_______________________________________________
>bmwg mailing list
>bmwg@ietf.org
>https://www.ietf.org/mailman/listinfo/bmwg