From Adrian.Farrel@huawei.com Tue Jun 1 07:53:07 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 416573A687E for ; Tue, 1 Jun 2010 07:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] 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 V97R4ysqrXt5 for ; Tue, 1 Jun 2010 07:53:03 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 549673A684C for ; Tue, 1 Jun 2010 07:53:03 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3C00JJ7C02FO@usaga01-in.huawei.com> for rtg-dir@ietf.org; Tue, 01 Jun 2010 07:52:51 -0700 (PDT) Received: from your029b8cecfe ([156.106.216.95]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3C003JQC005Z@usaga01-in.huawei.com> for rtg-dir@ietf.org; Tue, 01 Jun 2010 07:52:50 -0700 (PDT) Date: Tue, 01 Jun 2010 15:52:38 +0100 From: Adrian Farrel To: Joel Jaeggli , "Bhatia, Manav (Manav)" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=UTF-8; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <004601caebcb$48df90a0$4b0c7c0a@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CCE7C07FC@INBANSXCHMBSA1.in.alcatel-lucent.com> <4BE70F8E.6090303@bogus.com> <001b01caf081$6ef3f690$4b0c7c0a@china.huawei.com> <7C362EEF9C7896468B36C9B79200D8350CCE8B9764@INBANSXCHMBSA1.in.alcatel-lucent.com> <4BE8BC63.1010305@bogus.com> Cc: rtg-dir@ietf.org, draft-ietf-opsec-routing-protocols-crypto-issues.all@tools.ietf.org, Young Lee , rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review:draft-ietf-opsec-routing-protocols-crypto-issues-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 14:53:07 -0000 I love you all, but can you get your AD to enter RFC Editor notes so that the comments don't get lost over the inevitable days between now and then. I'll enter a Comment to try to help capture this. Cheers. Adrian ----- Original Message ----- From: "Joel Jaeggli" To: "Bhatia, Manav (Manav)" Cc: ; ; "Young Lee" ; Sent: Tuesday, May 11, 2010 3:09 AM Subject: Re: [RTG-DIR] RtgDir review:draft-ietf-opsec-routing-protocols-crypto-issues-04.txt > given the impact of the proposed text I think it can wait for auth48 > unless somebody on the on the iesg thinks otherwise. > > joel > > On 05/10/2010 02:57 PM, Bhatia, Manav (Manav) wrote: >> Hi Young, >> >> Will add this in the next revision. >> >> Joel - Do we come out with the next revision now, or do we do it after >> the IESG review? >> >> Cheers, Manav >> >>> -----Original Message----- >>> From: Young Lee [mailto:ylee@huawei.com] >>> Sent: Tuesday, May 11, 2010 2.13 AM >>> To: 'Joel Jaeggli'; Bhatia, Manav (Manav) >>> Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; >>> draft-ietf-opsec-routing-protocols-crypto-issues.all@tools.ietf.org >>> Subject: RE: RtgDir review: >>> draft-ietf-opsec-routing-protocols-crypto-issues-04.txt >>> >>> Hi Joel and Bhatia, >>> >>> I don't have any more issue on MD5. Thanks for your >>> explanation. It may help >>> the reader if you would say: >>> >>> "The MD5 digest algorithm was not designed to be used in the way most >>> routing protocols are using it which has potentially serious future >>> implications. There have been recent RFCs that support more secure >>> algorithms than MD5 such as HMAC-SHA for OSPF [RFC 5709] and ISIS [RFC >>> 5310], respectively." >>> >>> Best Regards, >>> Young >>> >>> -----Original Message----- >>> From: Joel Jaeggli [mailto:joelja@bogus.com] >>> Sent: Sunday, May 09, 2010 2:40 PM >>> To: Bhatia, Manav (Manav) >>> Cc: Young Lee; rtg-ads@tools.ietf.org; rtg-dir@ietf.org; >>> draft-ietf-opsec-routing-protocols-crypto-issues.all@tools.ietf.org >>> Subject: Re: RtgDir review: >>> draft-ietf-opsec-routing-protocols-crypto-issues-04.txt >>> >>> >>> >>> On 05/04/2010 07:39 PM, Bhatia, Manav (Manav) wrote: >>>> Hi Young, >>>> >>>> Thanks for the review! >>>> >>>>> Minor Issues: >>>>> Section 1: Can you give a bit more explanation why the MD5 digest >>> algorithm is not suitable for future implications? >>>> >>>> I think there is enough evidence about attacks on MD5. >>> Though we are still >>> far from direct impact on routing protocols there is clear >>> consensus in IETF >>> about deprecating its use towards a more secure algorithm. >>> You could look at >>> two recent RFCs that add support for HMAC-SHA for OSPF [RFC >>> 5709] and ISIS >>> [RFC 5310]. >>> >>> the reading for the security area directors (pasi) was that >>> recommendation to avoid using md5 is sensible notwithstanding >>> a lack of >>> specific circumstances in which it is possible to subvert. >>> >>>>> Section 1.1: At the end of the first paragraph, can you give the >>>>> reference for the literature on the discovery of feasible collision >>> attacks against MD4, etc.? >>>> >>>> Will add a reference in the next revision. >>>> >>>> [REF] Xiaoyun Wang, Xuejia Lai, Dengguo Feng and Hongbo Yu, >>> "Collisions >>> for hash functions MD4, MD5, HAVAL-128, and RIPEMD", Crypto 2004 Rump >>> Session >>>> >>>>> >>>>> Section 3: In the second paragraph, what is ESP? It would >>> be helpful to >>> include Terminology Section upfront to describe all the acronyms. >>>> >>>> Encapsulating Security Payload (ESP) [RFC4303] >>>> >>>>> >>>>> Section 3.1: In the first paragraph, what is SA? >>>> >>>> Security Association >>>> >>>>> >>>>> Nits: >>>>> Abstract >>>>> s/router ./router. >>>> >>>> Will do. >>>> >>>> Thanks, Manav >>>> >>>> >>> >>> > From rcallon@juniper.net Mon Jun 14 09:20:50 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 D43593A69F3 for ; Mon, 14 Jun 2010 09:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.014 X-Spam-Level: X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 SgpOt1BAgPLg for ; Mon, 14 Jun 2010 09:20:49 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 8AE853A67C2 for ; Mon, 14 Jun 2010 09:20:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTBZW1A5yX4WJRtwAWMWMHNA4SHXfQpsF@postini.com; Mon, 14 Jun 2010 09:20:53 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 14 Jun 2010 09:18:05 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 14 Jun 2010 12:18:04 -0400 From: Ross Callon To: Adrian Farrel , "stbryant@cisco.com" Date: Mon, 14 Jun 2010 12:18:01 -0400 Thread-Topic: Routing Directorate Review of draft-ietf-mpls-tp-data-plane-03 Thread-Index: AcsL3SkShWV5/EUNQtW/QKi4dV6pig== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB177049A6EA7A334EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "'rtg-dir@ietf.org'" , "draft-ietf-mpls-tp-data-plane-03.all@tools.ietf.org" Subject: [RTG-DIR] Routing Directorate Review of draft-ietf-mpls-tp-data-plane-03 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: Mon, 14 Jun 2010 16:20:50 -0000 --_000_DF7F294AF4153D498141CBEFADB177049A6EA7A334EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the Routing Directorate reviewer for draft-ietf-mpl= s-tp-data-plane. The Routing Directorate seeks to review all routing or rou= ting-related drafts as they pass through IETF last call and IESG review. Th= e purpose of the review is to provide assistance to the Routing ADs. For mo= re information about the Routing Directorate, please see http://www.ietf.or= g/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-mpls-tp-data-plane-03 Reviewer: Ross Callon Review Date: June 14, 2010 IETF LC End Date: June 14, 2010 Intended Status: Standards Track Summary: This document is basically ready for publication, but has minor ed= itorial nits that should be considered prior to publication. Comments: This draft is easy to read, and is quite well done. I have only e= ditorial nits and one question that the authors should consider. Major Issues: None Minor Issues: Section 3.2, first two paragraphs: It is clear from the first paragraph th= at the lowest level LSP occurs at level 0 (thus we could n from zero, rathe= r than from one). However, the second sentence begins: Note that the MPLS label stack associated with an MPLS-TP section at layer n consists of n labels, in the absence of stack optimisation mecha= nisms. Should this really specify that a stack at level n consists of n+1 labels? = Alternatively, should we be counting LSPs starting at n=3D1 in the first pa= ragraph? Nits: Section 2, page 5, first full paragraph on this page, first sentence: At an LSR, S-PE, or T-PE, further processing occurs to determine the context of a packet occurs when a swap operation is interrupted by TTL e= xpiry. There seems to be a grammatical error, the word "occurs" should only occur = once. This would seem to read better if the first occurrence of "occurs" we= re deleted. Section 4, third paragraph (page 9): When the the control message is carried over a section or an LSP,..= . First of all the word "the" occurs twice in succession. It seems to me that the term "section" was defined in section 3.2 to includ= e either an underlying data link or an LSP at the next lower level. Thus th= e phrase "section or LSP" seems to be redundant -- although clear. --_000_DF7F294AF4153D498141CBEFADB177049A6EA7A334EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have been selected as the Routing Directorate reviewer for draft-ietf-mpls-tp-data-plane. The Routing Directorate seeks to review all routing or routing-related d= rafts 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, pleas= e see http://www.ie= tf.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 La= st Call comments that you receive, and strive to resolve them through discu= ssion or by updating the draft.
 
Document:        draft-ietf-mpls-tp= -data-plane-03
Reviewer:        Ross Callon
Review Date:     June 14, 2010
IETF LC End Date: June 14, 2010
Intended Status: Standards Track
 
Summary: This document is basically ready for publicatio= n, but has minor editorial nits that should be considered prior to publicat= ion.
 
Comments: This draft is easy to read, and is quite well done. I= have only editorial nits and one question that the authors should consider= .
 
Major Issues:  None
 
Minor Issues: 
 
Section 3.2, first two paragraphs:  It is clear from the first pa= ragraph that the lowest level LSP occurs at level 0 (thus we could n from z= ero, rather than from one). However, the second sentence begins:
 
   Note tha= t the MPLS label stack associated with an MPLS-TP section at
   layer n = consists of n labels, in the absence of stack optimisation mechanisms.
 
Should this really specify that a stack at level n consists of n+1= labels? Alternatively, should we be counting LSPs starting at n=3D1 in the= first paragraph?
 
Nits:
 
Section 2, page 5, first full paragraph on this page, first sentence: =
 
   At an LS= R, S-PE, or T-PE, further processing occurs to determine the
   context = of a packet occurs when a swap operation is interrupted by TTL expiry.
 
There seems to be a grammatical error, the word "occurs" sho= uld only occur once. This would seem to read better if the first occurrence= of "occurs" were deleted.
 
Section 4, third paragraph (page 9):
 
   &nb= sp;    When the the control message is carried over a sectio= n or an LSP,...
 
First of all the word "the" occurs twice in succession.
 
It seems to me that the term "section" was defined in sectio= n 3.2 to include either an underlying data link or an LSP at the next lower= level. Thus the phrase "section or LSP" seems to be redundant --= although clear.
 
 
 
 --_000_DF7F294AF4153D498141CBEFADB177049A6EA7A334EMBX01WFjnprn_-- From rcallon@juniper.net Mon Jun 14 09:33:12 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 2D3503A68B7 for ; Mon, 14 Jun 2010 09:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.012 X-Spam-Level: X-Spam-Status: No, score=-4.012 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 KoJ2OPU0Jf+R for ; Mon, 14 Jun 2010 09:33:10 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 29DFD3A68BC for ; Mon, 14 Jun 2010 09:33:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTBZZwNMGiYj376BEOoZzSdnD/mN8lN6O@postini.com; Mon, 14 Jun 2010 09:33:14 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 14 Jun 2010 09:32:30 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 14 Jun 2010 12:32:29 -0400 From: Ross Callon To: Adrian Farrel , "stbryant@cisco.com" Date: Mon, 14 Jun 2010 12:32:26 -0400 Thread-Topic: [RTG-DIR] Routing Directorate Review of draft-ietf-mpls-tp-data-plane-03 Thread-Index: AcsL3SkShWV5/EUNQtW/QKi4dV6pigAAU3RQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB177049A6EA7A36EEMBX01WFjnprn_" MIME-Version: 1.0 Cc: George Swallow , "'rtg-dir@ietf.org'" , "danfrost@cisco.com" , Loa Andersson , "matthew.bocci@alcatel-lucent.com" Subject: Re: [RTG-DIR] Routing Directorate Review of draft-ietf-mpls-tp-data-plane-03 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: Mon, 14 Jun 2010 16:33:12 -0000 --_000_DF7F294AF4153D498141CBEFADB177049A6EA7A36EEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The "draft-ietf-mpls-tp-data-plane-03.all@tools.ietf.org" address bounced, = so I am resending with the authors and WG chair addresses explicitly spelle= d out, and with one typo in my original email fixed. Ross. ________________________________ From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf = Of Ross Callon Sent: 14 June 2010 12:18 To: Adrian Farrel; stbryant@cisco.com Cc: 'rtg-dir@ietf.org'; draft-ietf-mpls-tp-data-plane-03.all@tools.ietf.org Subject: [RTG-DIR] Routing Directorate Review of draft-ietf-mpls-tp-data-pl= ane-03 I have been selected as the Routing Directorate reviewer for draft-ietf-mpl= s-tp-data-plane. The Routing Directorate seeks to review all routing or rou= ting-related drafts as they pass through IETF last call and IESG review. Th= e purpose of the review is to provide assistance to the Routing ADs. For mo= re information about the Routing Directorate, please see http://www.ietf.or= g/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-mpls-tp-data-plane-03 Reviewer: Ross Callon Review Date: June 14, 2010 IETF LC End Date: June 14, 2010 Intended Status: Standards Track Summary: This document is basically ready for publication, but has minor ed= itorial nits that should be considered prior to publication. Comments: This draft is easy to read, and is quite well done. I have only e= ditorial nits and one question that the authors should consider. Major Issues: None Minor Issues: Section 3.2, first two paragraphs: It is clear from the first paragraph th= at the lowest level LSP occurs at level 0 (thus we count n from zero, rathe= r than from one). However, the second sentence begins: Note that the MPLS label stack associated with an MPLS-TP section at layer n consists of n labels, in the absence of stack optimisation mecha= nisms. Should this really specify that a stack at level n consists of n+1 labels? = Alternatively, should we be counting LSPs starting at n=3D1 in the first pa= ragraph? Nits: Section 2, page 5, first full paragraph on this page, first sentence: At an LSR, S-PE, or T-PE, further processing occurs to determine the context of a packet occurs when a swap operation is interrupted by TTL e= xpiry. There seems to be a grammatical error, the word "occurs" should only occur = once. This would seem to read better if the first occurrence of "occurs" we= re deleted. Section 4, third paragraph (page 9): When the the control message is carried over a section or an LSP,..= . First of all the word "the" occurs twice in succession. It seems to me that the term "section" was defined in section 3.2 to includ= e either an underlying data link or an LSP at the next lower level. Thus th= e phrase "section or LSP" seems to be redundant -- although clear. --_000_DF7F294AF4153D498141CBEFADB177049A6EA7A36EEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The "draft-iet= f-mpls-tp-data-plane-03.all@tools.ietf.org" address bounced, so I am resending with the authors and = WG chair addresses explicitly spelled out, and with one typo in my original em= ail fixed.   Ross.

 

From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Ross Callon
Sent: 14 June 2010 12:18
To: Adrian Farrel; stbryant@cisco.com
Cc: 'rtg-dir@ietf.org'; draft-ietf-mpls-tp-data-plane-03.all@tools.ietf.org
Subject: [RTG-DIR] Routing Directorate Review of draft-ietf-mpls-tp-data-plane-03

 

I have been selected as the Routing Directorate reviewer for draft-ietf-mpls-tp-data-plane. The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review. The purpose of the rev= iew 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 AD= s, it would be helpful if you could consider them along with any other IETF La= st Call comments that you receive, and strive to resolve them through discussi= on or by updating the draft.

 

Document:        draft-ietf-mpls-tp-data-plane-03
Reviewer:        Ross Callon
Review Date:     June 14, 2010
IETF LC End Date: June 14, 2010
Intended Status: Standards Track

 

Summary: This document is basically ready for publication, but has minor editorial nits t= hat should be considered prior to publication.

 

Comments: Thi= s draft is easy to read, and is quite well done. I have only editorial nits a= nd one question that the authors should consider.

 

Major Issues:=   None

 

Minor Issues:=  

 

Section 3.2, first two paragraphs:  It is clear from the first paragraph that the lowest level LSP occurs at level 0 (thus we count n from zero, rathe= r than from one). However, the second sentence begins:

 

   Note that the MPLS label stack associated with an MPLS-TP section at

   layer n consists of n labels, in th= e absence of stack optimisation mechanisms.

 

Should this really specify that a stack at level n consists of n+1 labels? Alternatively, should we be counting LSPs starting at n=3D1 in the = first paragraph?

 

Nits:

 

Section 2, page 5, first full paragraph on this page, first sentenc= e:

 

   At an LSR, S-PE, or T-PE, further processing occurs to determine the

   context of a packet occurs when a s= wap operation is interrupted by TTL expiry.

 

There seems to be a grammatical error, the word "occurs" should only occur once. This would seem to read better if the first occurre= nce of "occurs" were deleted.

 

Section 4, third paragraph (page 9):

 

        When = the the control message is carried over a section or an LSP,...

 

First of all the word "the" occurs twice in succession. <= o:p>

 

It seems to me that the term "section" was defined in sec= tion 3.2 to include either an underlying data link or an LSP at the next lower level. Thus the phrase "section or LSP" seems to be redundant -- although clear.

 

 

 

--_000_DF7F294AF4153D498141CBEFADB177049A6EA7A36EEMBX01WFjnprn_-- From rcallon@juniper.net Tue Jun 22 21:47:56 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 475153A6A31 for ; Tue, 22 Jun 2010 21:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.441 X-Spam-Level: X-Spam-Status: No, score=-4.441 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] 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 wG9JnhIO5trj for ; Tue, 22 Jun 2010 21:47:51 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id E32B23A6405 for ; Tue, 22 Jun 2010 21:47:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTCGR9vsFjcsCjjD0zd8HPleA+iksbv9E@postini.com; Tue, 22 Jun 2010 21:47:58 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Jun 2010 21:46:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 23 Jun 2010 00:46:16 -0400 From: Ross Callon To: Dan Frost Date: Wed, 23 Jun 2010 00:46:14 -0400 Thread-Topic: [RTG-DIR] Routing Directorate Review of draft-ietf-mpls-tp-data-plane-03 Thread-Index: AcsRMVynsqVifL+CS1e3gdDOOnqyiABXWCMg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: George Swallow , "'rtg-dir@ietf.org'" , Loa, "matthew.bocci@alcatel-lucent.com" , Adrian Farrel , "stbryant@cisco.com" , Andersson Subject: Re: [RTG-DIR] Routing Directorate Review of draft-ietf-mpls-tp-data-plane-03 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: Wed, 23 Jun 2010 04:47:56 -0000 Ahh, of course. A layer 0 LSP does not have an MPLS label. It might be prov= ided by optical cross-connects, or a TDM infrastructure.=20 Thanks, Ross -----Original Message----- From: Dan Frost [mailto:danfrost@cisco.com]=20 Sent: 21 June 2010 07:03 To: Ross Callon Cc: Adrian Farrel; stbryant@cisco.com; 'rtg-dir@ietf.org'; matthew.bocci@al= catel-lucent.com; Loa Andersson; George Swallow Subject: Re: [RTG-DIR] Routing Directorate Review of draft-ietf-mpls-tp-dat= a-plane-03 Hi Ross, Ross Callon writes: > [...] > Minor Issues: > > Section 3.2, first two paragraphs: It is clear from the first > paragraph that the lowest level LSP occurs at level 0 (thus we count n > from zero, rather than from one). However, the second sentence begins: > > Note that the MPLS label stack associated with an MPLS-TP section > at layer n consists of n labels, in the absence of stack > optimisation mechanisms. > > Should this really specify that a stack at level n consists of n+1 > labels? Alternatively, should we be counting LSPs starting at n=3D1 in > the first paragraph? We have been through this text at some length and believe it is correct. A walk-through was posted to the list and may be helpful: http://www.ietf.org/mail-archive/web/mpls-tp/current/msg03835.html > Nits: > > Section 2, page 5, first full paragraph on this page, first sentence: > > At an LSR, S-PE, or T-PE, further processing occurs to determine > the context of a packet occurs when a swap operation is interrupted > by TTL expiry. > > There seems to be a grammatical error, the word "occurs" should only > occur once. This would seem to read better if the first occurrence of > "occurs" were deleted. > > Section 4, third paragraph (page 9): > > When the the control message is carried over a section or an LSP,= ... > > First of all the word "the" occurs twice in succession. We will fix these. > It seems to me that the term "section" was defined in section 3.2 to > include either an underlying data link or an LSP at the next lower > level. Thus the phrase "section or LSP" seems to be redundant -- > although clear. It's redundant in a sense, but whether one views an LSP as a section or not is a matter of perspective, specifically with respect to the layer of hierarchy under consideration. We retain the phrase "section or LSP" to cater to the practical fact that LSPs are often not viewed as sections. Thanks! -d From danfrost@cisco.com Mon Jun 21 04:03:12 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 849B33A6A5D for ; Mon, 21 Jun 2010 04:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] 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 pUQLRzMb-HJ3 for ; Mon, 21 Jun 2010 04:03:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 51BFE3A6A5C for ; Mon, 21 Jun 2010 04:03:11 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,453,1272844800"; d="scan'208";a="123698160" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2010 11:03:17 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5LB3H6P021341; Mon, 21 Jun 2010 11:03:17 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id o5LB3Gvk013622; Mon, 21 Jun 2010 07:03:16 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id o5LB3FRG013621; Mon, 21 Jun 2010 12:03:15 +0100 X-Authentication-Warning: isolaria.cisco.com: danfrost set sender to danfrost@cisco.com using -f From: Dan Frost To: Ross Callon In-Reply-To: (Ross Callon's message of "Mon, 14 Jun 2010 12:32:26 -0400") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Date: Mon, 21 Jun 2010 12:03:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 24 Jun 2010 10:14:37 -0700 Cc: George Swallow , "'rtg-dir@ietf.org'" , "matthew.bocci@alcatel-lucent.com" , Adrian Farrel , "stbryant@cisco.com" , Loa Andersson Subject: Re: [RTG-DIR] Routing Directorate Review of draft-ietf-mpls-tp-data-plane-03 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: Mon, 21 Jun 2010 11:03:12 -0000 Hi Ross, Ross Callon writes: > [...] > Minor Issues: > > Section 3.2, first two paragraphs: It is clear from the first > paragraph that the lowest level LSP occurs at level 0 (thus we count n > from zero, rather than from one). However, the second sentence begins: > > Note that the MPLS label stack associated with an MPLS-TP section > at layer n consists of n labels, in the absence of stack > optimisation mechanisms. > > Should this really specify that a stack at level n consists of n+1 > labels? Alternatively, should we be counting LSPs starting at n=1 in > the first paragraph? We have been through this text at some length and believe it is correct. A walk-through was posted to the list and may be helpful: http://www.ietf.org/mail-archive/web/mpls-tp/current/msg03835.html > Nits: > > Section 2, page 5, first full paragraph on this page, first sentence: > > At an LSR, S-PE, or T-PE, further processing occurs to determine > the context of a packet occurs when a swap operation is interrupted > by TTL expiry. > > There seems to be a grammatical error, the word "occurs" should only > occur once. This would seem to read better if the first occurrence of > "occurs" were deleted. > > Section 4, third paragraph (page 9): > > When the the control message is carried over a section or an LSP,... > > First of all the word "the" occurs twice in succession. We will fix these. > It seems to me that the term "section" was defined in section 3.2 to > include either an underlying data link or an LSP at the next lower > level. Thus the phrase "section or LSP" seems to be redundant -- > although clear. It's redundant in a sense, but whether one views an LSP as a section or not is a matter of perspective, specifically with respect to the layer of hierarchy under consideration. We retain the phrase "section or LSP" to cater to the practical fact that LSPs are often not viewed as sections. Thanks! -d From julien.meuric@orange-ftgroup.com Wed Jun 30 10:22:20 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 0FCA53A6988 for ; Wed, 30 Jun 2010 10:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35] 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 t0yJPxuiaeES for ; Wed, 30 Jun 2010 10:22:18 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 2D9063A6868 for ; Wed, 30 Jun 2010 10:22:18 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EF8786C0003; Wed, 30 Jun 2010 19:22:38 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id E2B6D6C0001; Wed, 30 Jun 2010 19:22:38 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 19:22:09 +0200 Received: from [10.193.71.77] ([10.193.71.77]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 19:22:08 +0200 Message-ID: Date: Wed, 30 Jun 2010 19:22:08 +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: Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2010 17:22:08.0553 (UTC) FILETIME=[C4B50190:01CB1878] Cc: rtg-dir@ietf.org, draft-ietf-bmwg-igp-dataplane-conv-meth.all@tools.ietf.org, CAUCHIE Gregory RD-CORE-ISS Subject: [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: Wed, 30 Jun 2010 17:22:20 -0000 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