[bmwg] Benoit Claise's No Objection on draft-ietf-bmwg-bgp-basic-convergence-04: (with COMMENT)
"Benoit Claise" <bclaise@cisco.com> Wed, 03 December 2014 14:24 UTC
Return-Path: <bclaise@cisco.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3151A1B2F; Wed, 3 Dec 2014 06:24:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOd6lnd7fYnZ; Wed, 3 Dec 2014 06:24:39 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AEE1A1B38; Wed, 3 Dec 2014 06:24:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141203142439.14132.76527.idtracker@ietfa.amsl.com>
Date: Wed, 03 Dec 2014 06:24:39 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/bmwg/mwiV1c08oF8SlFMZk1C-DbBtRQI
Cc: bmwg-chairs@tools.ietf.org, sob@harvard.edu, bmwg@ietf.org, draft-ietf-bmwg-bgp-basic-convergence.all@tools.ietf.org
Subject: [bmwg] Benoit Claise's No Objection on draft-ietf-bmwg-bgp-basic-convergence-04: (with COMMENT)
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 03 Dec 2014 14:24:41 -0000
Benoit Claise has entered the following ballot position for draft-ietf-bmwg-bgp-basic-convergence-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-bmwg-bgp-basic-convergence/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As notes by Scott Bradner in his OPS directorate review. Some comments/questions on the contents of the draft: 1.1 "FIB (Data plane) convergence is defined as the completion of all FIB changes so that all forwarded traffic now takes the new proposed route. " should route be singular or plural - i.e. is the assumption that the routing table converges to a single next hop? (at least for the test traffic) if so, does the draft specifically say that (or does rfc 4098 and I missed it) note: figure 1 shows multiple peering links - sec 4.1 seems to argue for multiple peers "Data plane convergence is different than control plane convergence within a node." might want to say how they are different since reporting requiremenst are covered in section 6 should they also be mentioned here? (if so, how about in section 4.2) secton 4.4 & 4.8 maybe replace TCP MD5 with TCP Authentication Option (2 places) or at least mention it section 4.4 basic test settings - maybe say why these values were chosen section 4.7 agree as to the importance fo rrepeating trials - is there a recognized source that discusses "generally accepted testing practices regarding repeatability ..."? section 5 what about Graceful Restart (RFC 4724) - would that impact the clean start desire? section 5.1.1 "D. Start the traffic from the Emulator tx towards the DUT targeted at a routes specified in route mixture (ex. routeA)" change "a routes" to "a route" or "the routes" E & F - as noted earlier in the document - these times should be very close to the same - is it actually worth the additional complexity to collect the time when the update is received? also 5.1.2 H & I, etc section 5.1.2 mentions NTP but section 5.1.1 does not - is there a reason? section 5.2.1 - since the shutdown event is not timed - does this test provide a useful measurement? (or should the time be recorded and its just not mentioned?) section 5.3 - F - implies that the time is recorded but not actually say say that it is general comment - review all steps of all tests to be sure that NTP is called for when it is needed and that event times are specifically called for when they are needed and use consistent langage in each case the overall requiremenst - e.g. NTP could also just be noted before the test descriptions and not inlcuded in each one if it is needed in all of them - same with advice about nukbers of routes (do tests with different numbers or routes up to the full Internet table) section 6 - should this also include the number of AS Paths?
- [bmwg] Benoit Claise's No Objection on draft-ietf… Benoit Claise
- Re: [bmwg] Benoit Claise's No Objection on draft-… Bradner, Scott
- Re: [bmwg] Benoit Claise's No Objection on draft-… Susan Hares