From julien.meuric@orange-ftgroup.com Thu Jul 1 03:51:54 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF45B3A68B1 for ; Thu, 1 Jul 2010 03:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] 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 EBKo-fMM1MUk for ; Thu, 1 Jul 2010 03:51:53 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id A82783A6800 for ; Thu, 1 Jul 2010 03:51:52 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DFAF7958077; Thu, 1 Jul 2010 12:53:48 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 68701958257; Thu, 1 Jul 2010 10:44:36 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 10:36:09 +0200 Received: from [10.193.71.77] ([10.193.71.77]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 10:36:09 +0200 Message-ID: Date: Thu, 01 Jul 2010 10:36:09 +0200 From: "Julien Meuric" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11pre) Gecko/20100626 Lightning/1.0b1 Shredder/3.0.6pre MIME-Version: 1.0 To: References: <4C2B7D40.6020704@orange-ftgroup.com> In-Reply-To: <4C2B7D40.6020704@orange-ftgroup.com> Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Jul 2010 08:36:09.0705 (UTC) FILETIME=[7494B590:01CB18F8] Cc: rtg-dir@ietf.org, draft-ietf-bmwg-igp-dataplane-conv-meth.all@tools.ietf.org, CAUCHIE Gregory RD-CORE-ISS Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bmwg-igp-dataplane-conv-meth-21 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 10:51:55 -0000 Hi all. Just a quick update on the review below: a paragraph was kept away from the list of nits by my (old) piece of paper. --- Section 4.2: s/Ta'>Tb. Route Rtb/Ta'>Tb, then route Rtb/ (else not a sentence) s/implementation would be such/implementation was such/ (twice) s/By using only observing/By only observing/ --- Regards, Julien Le 30/06/2010 19:22, Julien Meuric a écrit : > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review. The purpose of the review is to provide assistance to the > Routing ADs. For more information about the Routing Directorate, > please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-bmwg-igp-dataplane-conv-meth-21.txt > Reviewer: Julien Meuric (with the help of an anonymous colleague > eating IGPs at breakfast) > Review Date: 06/30/2010 > Intended Status: Informational > > *Summary:* > I have some minor concerns about this document that I think should be > resolved before publication. > > *Comments:* > The document is rather heavy: it covers multiple scenarios, gives > several sequences of testing actions, analyses details about > uncertainty... As a result, for someone not used to the BMWG (please > keep in mind that this is my 1st review on a document from BMWG) it is > not so easy to follow in every detail and it requires some back-up > reading (draft-ietf-bmwg-igp-dataplane-conv-term for instance). > > *Major Issues:* > No major issues found. > > *Minor Issues:* > --- > 1/ I imagine it has already been discussed on the WG (sorry if I bring > back a troll), but it seems unusual to use RFC 2119 language for an > Informational document, and that is why it is explicitly stated in > section 2. Considering the status remains the same, instead of > advertising that fact, would not it be simpler to avoid the capital > letters in the corresponding words? > --- > 2/ My GMPLS background brings me to think that an IGP adjacency may be > independent from the corresponding data link. The document seems to > focus on the classical IGP use, but it would be better to make that > context clearer through a simple sentence than considering it is the > default. > --- > 3/ There is unfortunately no reference to traffic-engineering > extensions, while it might impact IGP convergence. Adding a few words > on this so as to state it is out of scope (if so) would be welcome. > --- > 4/ By reading section 3, we understand that the causes considered for > testing in this methodology concern failures and administrative > changes (status, costs). Therefore, the link insertion/recovery is > apparently not part of the testing. However, we can find it in section > 8 if we take a close look to the procedure steps. As a consequence, in > order to stay clearly consistent to > draft-ietf-bmwg-igp-dataplane-conv-app-17 referenced here, it would be > useful to clarify somewhere in section 3 that interface or link > insertion/recovery is treated along with the failure events and is > therefore taken into account. > --- > 5/ The document will also gain in stating from the introduction the > scope of this methodology regarding router stress in front of > convergence performance (i.e. what is addressed in section 5). For > example, add something like: > "Convergence performance is tightly linked to the number of tasks a > router has to deal with. As the most impacting tasks are mainly > related to the control plane and the data plane, the more the DUT is > stressed as in a live environment, the more accurate performance > results (i.e. the ones that would be observed in a live environment) > will be. Section 5 gives detailson the recommended environment for IGP > convergence performance benchmarking." > --- > > *Nits:* > --- > Even though it may be usual in the WG, the way document references are > built ("AuthID#") is much less readable than "Summarized-Title" as > used in some places else. Let us hope most of them will be update with > RFC numbers (not more convenient in fact, but stable reference). > --- > The phrase "next-hop router" may be confusing (at least until going > into the details), especially because in some contexts like BGP, a > next-hop router may not be adjacent but remote. How about "adjacent > routers" to reuse IS-IS terminology or "neighbor routers" to reuse > OSPF terminology? > --- > The "ECMP" acronym is expanded in section 3.4 (where it is actually > tested) while it has been used since section 3.1: expansion should be > moved (or duplicated) there. > --- > A mix of "Loss of connectivity" and "LoC" acronym are used > alternatively: strict consistency along the document may not be a > goal, but association between them should at least be explicit at 1st > use (section 4). > --- > "IS-IS" is always referred to as "ISIS", I would add the dash. > --- > Some titles on figures (e.g. 9) and equations (e.g. 3) are closer to > the following paragraph than the corresponding item, swapping or > reducing the amount of blank lines would be easier to read. > --- > Section 2: > s/in other BMWG work/in other documents issued by the Benchmarking > Methodology Working Group/ > --- > Section 3.1: > At 1st occurence, it might be more accurate to specify that "N >= 1" > or "N > 0". > --- > Section 3.4: > "the tester emulates N next-hop routers" > Whitout the figure, it is difficult to quickly picture the > configuration. I may ease the understanding by adding something like > "(N-1 adjacent to R1; 1 adjacent to R2)". > --- > Section 5.4: "LSA", "LSP" and "SPF" are not expanded: they may be > usual, but IGP is expanded in the abstract and introduction (and "LSP" > has 2 usual meanings in the Routing area)... The same question may > raise for "IS-IS" and "OSPF" expansion, but they are considered as > "well-known" on > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt (while > the formers are not). > --- > Section 5.6: > s/topologies 3, 4, and 6/topologies 3, 4 and 6/ > s/packets are transmitted/packets be transmitted/ > --- > Section 5.9: > s/test case has/test case have/ > --- > Section 7: > s/loss or not./loss or not?/ > s/Complete the table below/The table below should be completed/ > --- > Section 8: > "DUT's" and "Tester's" read weird to me with respect to what I was > taught at school, but someone put "the car's wheels" on Wikipedia. I > thus leave this issue to native English speakers. :-) > --- > Section 8.1.4: > s/may influenced/may be influenced/ > --- > > Best regards, > > Julien >