From acee.lindem@ericsson.com Thu Dec 2 08:53:57 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 7B45728C18E for ; Thu, 2 Dec 2010 08:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 aYmrFlcYDR3E for ; Thu, 2 Dec 2010 08:53:56 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 23A0828C154 for ; Thu, 2 Dec 2010 08:53:55 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oB2GtAeL018824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Dec 2010 10:55:11 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 2 Dec 2010 11:55:10 -0500 From: Acee Lindem To: "rtg-ads@tools.ietf.org" Date: Thu, 2 Dec 2010 11:55:07 -0500 Thread-Topic: Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt Thread-Index: AcuSQa4I6qGrjMRQSJKPJHPq4kiBLg== Message-ID: 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: "drafts-ietf-opsec-protocol-plane@tools.ietf.org" , "rtg-dir@ietf.org" , "opsec-ads@tools.ietf.org" Subject: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt 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, 02 Dec 2010 16:53:57 -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=20 information about the Routing Directorate, please see=20 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=20 Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsec-protocol-plane-04.txt Reviewer: Acee Lindem Review Date: 2010-12-02 IETF LC End Date: 2010-12-03 Intended Status: Informational Summary: This document accomplishes its intended purpose of providing guidance on defining filters to protect the router control plane. The=20 fact that the OPSEC WG adopted this as a WG document indicates that this is a viewed as a worthwhile effort. I found one major issue that needs=20 to be fixed before this document should move forward. Major Issues:=20 Page 5, unless there are virtual links, all OSPFv3 packets use=20 an IPv6 link local address as the source address. Hence, you need to allow OSPFv3 packets sourced from the IPv6 link-local range (FE80::/10). I'd simply remove the IPv6 global prefix since virtual links are not the norm. Of course, the examples in the appendices need to be updated as well.=20 I didn't see any other problems with IPv6 link-local addresses.=20 Other than ICMPv6 which has no source address filter, the=20 other protocols filtered run on top of UDP or TCP. Minor Issues: General: It would be nice if there were a network diagram showing the target router and where the referenced subnets sit in relation to=20 the target. However, I realize it is a bit late to ask for this.=20 Page 10, Third Paragraph - What do you mean by "when=20 rate limiters become active which serve as indicator that either normal traffic has increased or out of policy traffic rates have been detected."? This isn't clear to me. How would you know the difference?=20 Section 3.3 - Should there be informative references to ICMP, ICMPv6, and ND since details of their functionality are referenced? Editorial Nits: General - There seem to be a lot of commas missing from the text. However, I'll leave these to the RFC Editor.=20 Page 3, last paragraph - Expand out first occurrence of the acronym "Denial of Service (DoS)".=20 Page 4, first paragraph - Change "diverted out of" to=20 "diverted from" and "up to" to "to". =20 Page 4, penultimate paragraph - Change "are on by default or always on" to "are enabled by default or always enabled".=20 Page 4, last paragraph - Change "sample legitimate traffic" to "legitimate traffic example" consistent with the terminology used elsewhere. This is clearly more of an "example" than a=20 "sample".=20 Page 5, 3.1 bullets - Change "DNS resolvers" to "DNS servers" consistent with what is configured in most router implementations.=20 Page 6, Section 3.2, First Paragraph - Change "match only on" to "match only". Also change, "any traffic matching traffic for"=20 to simply "any traffic matching".=20 Page 7, first paragraph - Change "may not be this obvious" to=20 "may not be as obvious as the example described herein".=20 Page 7, first paragraph - Change "herein provided" to "provided herein".=20 =20 Page 7, last paragraph - Change "turn up of" to "deployment of".=20 Page 7, last paragraph - Replace "neighbor discovery" with=20 "Neighbor Discovery (ND)" and "multicast listener discovery version 2 (MLDv2)" with "Multicast Listener Discovery version 2 (MLDv2)".=20 =20 Page 8, General - Use consistent capitalization for "IP optioned traffic"/"IP Optioned traffic".=20 Page 8, first paragraph - The phrase "(and statistic gathering)" seems as though it should not be in parentheses.=20 Page 8, second paragraph - Change "may not be possible" to "may not be feasible". Also replace "referenced here" with "included herein".=20 Finally, should RSVP be spelled out consistent with other explicitly referenced protocols?=20 Page 8, third paragraph - Replace "isolating a more" with "filtering a more" and "or isolating valid" with "or classifying valid".=20 Page 8, last paragraph - Change "matched in a" to "matched to a".=20 Change "allows the default traffic" to simply "accepts default=20 traffic". Change "rather than just dropping it" to "as opposed to dropping it". Change "functionality of the device" to simply "device=20 functionality". Change "was highlighted" to "was chosen". Change "implementor" to "operator" consistent to other references to the party applying the filters in the document. draft-ietf-opsec-protocol-pl= ane-04.txt Page 9, first paragraph - Change "is being" to "has been identified=20 and"=20 =20 Page 9, third paragraph - Change "forensic analysis afterwards" to "ongoing forensic analysis".=20 Page 9, Fourth paragraph - Change "on the Internet" to "in the Internet".=20 Page 9, last paragraph - The phrase "at the source where the traffic has been originated" is redundant. Change to simply=20 "at the source".=20 =20 Page 10, second paragraph - Change "PMTUD" to Path Maximum=20 Transmission Unit Discovery (PMTUD)".=20 Thanks, Acee From acee.lindem@ericsson.com Thu Dec 2 09:02:47 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 8B9BE28C11B for ; Thu, 2 Dec 2010 09:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] 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 ZWBAMiC2CZPk for ; Thu, 2 Dec 2010 09:02:46 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 550BF28C11A for ; Thu, 2 Dec 2010 09:02:46 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oB2H3uAv019451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Dec 2010 11:04:01 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 2 Dec 2010 12:03:57 -0500 From: Acee Lindem To: "rtg-ads@tools.ietf.org" Date: Thu, 2 Dec 2010 12:03:55 -0500 Thread-Topic: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (resending with authors copied since draft-ietf... bounced) Thread-Index: AcuSQuhOYCjSt/4NRNuclDfcXtdMNA== Message-ID: 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: "rtg-dir@ietf.org" , "opsec-ads@tools.ietf.org" , Carlos Pignataro , "draft-ietf-opsec-protocol-plane@tools.ietf.org" , Rodney Dunn , Dave, Dugal Subject: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (resending with authors copied since draft-ietf... bounced) 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, 02 Dec 2010 17:02:47 -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=20 information about the Routing Directorate, please see=20 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=20 Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsec-protocol-plane-04.txt Reviewer: Acee Lindem Review Date: 2010-12-02 IETF LC End Date: 2010-12-03 Intended Status: Informational Summary: This document accomplishes its intended purpose of providing guidance on defining filters to protect the router control plane. The=20 fact that the OPSEC WG adopted this as a WG document indicates that this is a viewed as a worthwhile effort. I found one major issue that needs=20 to be fixed before this document should move forward. Major Issues:=20 Page 5, unless there are virtual links, all OSPFv3 packets use=20 an IPv6 link local address as the source address. Hence, you need to allow OSPFv3 packets sourced from the IPv6 link-local range (FE80::/10). I'd simply remove the IPv6 global prefix since virtual links are not the norm. Of course, the examples in the appendices need to be updated as well.=20 I didn't see any other problems with IPv6 link-local addresses.=20 Other than ICMPv6 which has no source address filter, the=20 other protocols filtered run on top of UDP or TCP. Minor Issues: General: It would be nice if there were a network diagram showing the target router and where the referenced subnets sit in relation to=20 the target. However, I realize it is a bit late to ask for this.=20 Page 10, Third Paragraph - What do you mean by "when=20 rate limiters become active which serve as indicator that either normal traffic has increased or out of policy traffic rates have been detected."? This isn't clear to me. How would you know the difference?=20 Section 3.3 - Should there be informative references to ICMP, ICMPv6, and ND since details of their functionality are referenced? Editorial Nits: General - There seem to be a lot of commas missing from the text. However, I'll leave these to the RFC Editor.=20 Page 3, last paragraph - Expand out first occurrence of the acronym "Denial of Service (DoS)".=20 Page 4, first paragraph - Change "diverted out of" to=20 "diverted from" and "up to" to "to". =20 Page 4, penultimate paragraph - Change "are on by default or always on" to "are enabled by default or always enabled".=20 Page 4, last paragraph - Change "sample legitimate traffic" to "legitimate traffic example" consistent with the terminology used elsewhere. This is clearly more of an "example" than a=20 "sample".=20 Page 5, 3.1 bullets - Change "DNS resolvers" to "DNS servers" consistent with what is configured in most router implementations.=20 Page 6, Section 3.2, First Paragraph - Change "match only on" to "match only". Also change, "any traffic matching traffic for"=20 to simply "any traffic matching".=20 Page 7, first paragraph - Change "may not be this obvious" to=20 "may not be as obvious as the example described herein".=20 Page 7, first paragraph - Change "herein provided" to "provided herein".=20 Page 7, last paragraph - Change "turn up of" to "deployment of".=20 Page 7, last paragraph - Replace "neighbor discovery" with=20 "Neighbor Discovery (ND)" and "multicast listener discovery version 2 (MLDv2)" with "Multicast Listener Discovery version 2 (MLDv2)".=20 Page 8, General - Use consistent capitalization for "IP optioned traffic"/"IP Optioned traffic".=20 Page 8, first paragraph - The phrase "(and statistic gathering)" seems as though it should not be in parentheses.=20 Page 8, second paragraph - Change "may not be possible" to "may not be feasible". Also replace "referenced here" with "included herein".=20 Finally, should RSVP be spelled out consistent with other explicitly referenced protocols?=20 Page 8, third paragraph - Replace "isolating a more" with "filtering a more" and "or isolating valid" with "or classifying valid".=20 Page 8, last paragraph - Change "matched in a" to "matched to a".=20 Change "allows the default traffic" to simply "accepts default=20 traffic". Change "rather than just dropping it" to "as opposed to dropping it". Change "functionality of the device" to simply "device=20 functionality". Change "was highlighted" to "was chosen". Change "implementor" to "operator" consistent to other references to the party applying the filters in the document. draft-ietf-opsec-protocol-pla= ne-04.txt Page 9, first paragraph - Change "is being" to "has been identified=20 and"=20 Page 9, third paragraph - Change "forensic analysis afterwards" to "ongoing forensic analysis".=20 Page 9, Fourth paragraph - Change "on the Internet" to "in the Internet".=20 Page 9, last paragraph - The phrase "at the source where the traffic has been originated" is redundant. Change to simply=20 "at the source".=20 Page 10, second paragraph - Change "PMTUD" to Path Maximum=20 Transmission Unit Discovery (PMTUD)".=20 Thanks, Acee From acee.lindem@ericsson.com Thu Dec 2 09:16:18 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 8D9EA28C0FB for ; Thu, 2 Dec 2010 09:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] 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 sUAI4ojvij6k for ; Thu, 2 Dec 2010 09:16:17 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 4BC3D3A696E for ; Thu, 2 Dec 2010 09:16:17 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oB2HjqGG015416; Thu, 2 Dec 2010 11:45:54 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 2 Dec 2010 12:17:29 -0500 From: Acee Lindem To: "rtg-ads@tools.ietf.org" Date: Thu, 2 Dec 2010 12:17:28 -0500 Thread-Topic: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (Reply to this one - removed unwanted recipient) Thread-Index: AcuSRMwDTt+YHMhpQvKPhIN6XjsH9w== Message-ID: <1EBFA49B-8E6E-4D88-B968-6839C40AB1F2@ericsson.com> 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: "rtg-dir@ietf.org" , "opsec-ads@tools.ietf.org" , Carlos Pignataro , "draft-ietf-opsec-protocol-plane@tools.ietf.org" , Rodney Dunn , Dave Dugal Subject: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (Reply to this one - removed unwanted recipient) 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, 02 Dec 2010 17:16:18 -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=20 information about the Routing Directorate, please see=20 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=20 Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsec-protocol-plane-04.txt Reviewer: Acee Lindem Review Date: 2010-12-02 IETF LC End Date: 2010-12-03 Intended Status: Informational Summary: This document accomplishes its intended purpose of providing guidance on defining filters to protect the router control plane. The=20 fact that the OPSEC WG adopted this as a WG document indicates that this is a viewed as a worthwhile effort. I found one major issue that needs=20 to be fixed before this document should move forward. Major Issues:=20 Page 5, unless there are virtual links, all OSPFv3 packets use=20 an IPv6 link local address as the source address. Hence, you need to allow OSPFv3 packets sourced from the IPv6 link-local range (FE80::/10). I'd simply remove the IPv6 global prefix since virtual links are not the norm. Of course, the examples in the appendices need to be updated as well.=20 I didn't see any other problems with IPv6 link-local addresses.=20 Other than ICMPv6 which has no source address filter, the=20 other protocols filtered run on top of UDP or TCP. Minor Issues: General: It would be nice if there were a network diagram showing the target router and where the referenced subnets sit in relation to=20 the target. However, I realize it is a bit late to ask for this.=20 Page 10, Third Paragraph - What do you mean by "when=20 rate limiters become active which serve as indicator that either normal traffic has increased or out of policy traffic rates have been detected."? This isn't clear to me. How would you know the difference?=20 Section 3.3 - Should there be informative references to ICMP, ICMPv6, and ND since details of their functionality are referenced? Editorial Nits: General - There seem to be a lot of commas missing from the text. However, I'll leave these to the RFC Editor.=20 Page 3, last paragraph - Expand out first occurrence of the acronym "Denial of Service (DoS)".=20 Page 4, first paragraph - Change "diverted out of" to=20 "diverted from" and "up to" to "to". =20 Page 4, penultimate paragraph - Change "are on by default or always on" to "are enabled by default or always enabled".=20 Page 4, last paragraph - Change "sample legitimate traffic" to "legitimate traffic example" consistent with the terminology used elsewhere. This is clearly more of an "example" than a=20 "sample".=20 Page 5, 3.1 bullets - Change "DNS resolvers" to "DNS servers" consistent with what is configured in most router implementations.=20 Page 6, Section 3.2, First Paragraph - Change "match only on" to "match only". Also change, "any traffic matching traffic for"=20 to simply "any traffic matching".=20 Page 7, first paragraph - Change "may not be this obvious" to=20 "may not be as obvious as the example described herein".=20 Page 7, first paragraph - Change "herein provided" to "provided herein".=20 Page 7, last paragraph - Change "turn up of" to "deployment of".=20 Page 7, last paragraph - Replace "neighbor discovery" with=20 "Neighbor Discovery (ND)" and "multicast listener discovery version 2 (MLDv2)" with "Multicast Listener Discovery version 2 (MLDv2)".=20 Page 8, General - Use consistent capitalization for "IP optioned traffic"/"IP Optioned traffic".=20 Page 8, first paragraph - The phrase "(and statistic gathering)" seems as though it should not be in parentheses.=20 Page 8, second paragraph - Change "may not be possible" to "may not be feasible". Also replace "referenced here" with "included herein".=20 Finally, should RSVP be spelled out consistent with other explicitly referenced protocols?=20 Page 8, third paragraph - Replace "isolating a more" with "filtering a more" and "or isolating valid" with "or classifying valid".=20 Page 8, last paragraph - Change "matched in a" to "matched to a".=20 Change "allows the default traffic" to simply "accepts default=20 traffic". Change "rather than just dropping it" to "as opposed to dropping it". Change "functionality of the device" to simply "device=20 functionality". Change "was highlighted" to "was chosen". Change "implementor" to "operator" consistent to other references to the party applying the filters in the document. draft-ietf-opsec-protocol-plan= e-04.txt Page 9, first paragraph - Change "is being" to "has been identified=20 and"=20 Page 9, third paragraph - Change "forensic analysis afterwards" to "ongoing forensic analysis".=20 Page 9, Fourth paragraph - Change "on the Internet" to "in the Internet".=20 Page 9, last paragraph - The phrase "at the source where the traffic has been originated" is redundant. Change to simply=20 "at the source".=20 Page 10, second paragraph - Change "PMTUD" to Path Maximum=20 Transmission Unit Discovery (PMTUD)".=20 Thanks, Acee From cpignata@cisco.com Sat Dec 4 19:30: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 372583A69CC for ; Sat, 4 Dec 2010 19:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 7zHLyN-uzrXQ for ; Sat, 4 Dec 2010 19:30:47 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 3E15D3A686C for ; Sat, 4 Dec 2010 19:30:47 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oB53Vwmt002160; Sat, 4 Dec 2010 22:31:58 -0500 (EST) Received: from [10.116.85.227] (rtp-cpignata-8712.cisco.com [10.116.85.227]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id oB53VmiB020949; Sat, 4 Dec 2010 22:31:49 -0500 (EST) Message-ID: <4CFB07A3.3040207@cisco.com> Date: Sat, 04 Dec 2010 22:31:47 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Acee Lindem , Adrian Farrel References: In-Reply-To: X-Enigmail-Version: 0.96.0 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 05 Dec 2010 02:04:48 -0800 Cc: "rtg-dir@ietf.org" , "opsec-ads@tools.ietf.org" , "draft-ietf-opsec-protect-control-plane@tools.ietf.org" , Rodney Dunn , "rtg-ads@tools.ietf.org" , Dave Dugal Subject: Re: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (resending with authors copied since draft-ietf... bounced) 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: Sun, 05 Dec 2010 03:30:50 -0000 [Correcting the draft-ietf-... email address] Acee, Many thanks for a most thorough and useful review. Please see inline. On 12/2/2010 12:03 PM, Acee Lindem wrote: > 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-opsec-protocol-plane-04.txt > Reviewer: Acee Lindem > Review Date: 2010-12-02 > IETF LC End Date: 2010-12-03 > Intended Status: Informational > > Summary: This document accomplishes its intended purpose of providing > guidance on defining filters to protect the router control plane. The > fact that the OPSEC WG adopted this as a WG document indicates that this > is a viewed as a worthwhile effort. I found one major issue that needs > to be fixed before this document should move forward. Thanks for this summary, we believe we have fixed this major issue, as well as minor issues and nits. We have all the changes in our working copy. Comments below. > > Major Issues: > > Page 5, unless there are virtual links, all OSPFv3 packets use > an IPv6 link local address as the source address. Hence, you need > to allow OSPFv3 packets sourced from the IPv6 link-local range > (FE80::/10). I'd simply remove the IPv6 global prefix since > virtual links are not the norm. > Great catch, thank you. This is the change we are making here: From: o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and OSPFv3 traffic from subnet 2001:DB8:1::/48 To: o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and OSPFv3 traffic from IPv6 Link-Local unicast addresses (FE80::/10) [and corresponding example config updates] We thought about adding a note mentioning Virtual Links but decided against it. > Of course, the examples in the appendices need to be updated as well. > I didn't see any other problems with IPv6 link-local addresses. > Other than ICMPv6 which has no source address filter, the > other protocols filtered run on top of UDP or TCP. > > Minor Issues: > > General: It would be nice if there were a network diagram showing > the target router and where the referenced subnets sit in relation to > the target. However, I realize it is a bit late to ask for this. > We discussed this but decided against adding such network diagram. > Page 10, Third Paragraph - What do you mean by "when > rate limiters become active which serve as indicator that either > normal traffic has increased or out of policy traffic rates have > been detected."? This isn't clear to me. How would you know the > difference? Reworded to this, please let us know if this does not help: when these rate limiters become active (i.e., when traffic is policed). This in turn serves as an indicator that either the normal traffic rates have increased or out of policy traffic rates have been detected. More thorough analysis of the traffic flows and rate-limited traffic is needed to identify which of these two cases triggered the rate limiters. > > Section 3.3 - Should there be informative references to ICMP, ICMPv6, > and ND since details of their functionality are referenced? > We thought about this earlier and decided against it. We are agreeable to adding these references and corresponding citations if the shepherd or ADs think it adds to the doc. However, our thinking was that there are very many protocols mentioned in this document and although reading about them would enhance the operators understanding, it would not change the main message from this document. The exception here is ICMPv6, and Informative would be warranted, but instead we are covering this with the Informative reference to RFC 4890 (that has of course RFC 4443 as Normative, but speaks as to the filtering aspects). > Editorial Nits: > Many thanks for the thorough review ! Follow-ups inline, plus implicit Ack for changes silently made as suggested. > General - There seem to be a lot of commas missing from the text. > However, I'll leave these to the RFC Editor. > Ack, sounds good. > Page 3, last paragraph - Expand out first occurrence of the > acronym "Denial of Service (DoS)". > > Page 4, first paragraph - Change "diverted out of" to > "diverted from" and "up to" to "to". Used "from". > > Page 4, penultimate paragraph - Change "are on by default or > always on" to "are enabled by default or always enabled". Used "active" instead of "enabled" as per Gen-ART suggestion that flagged the same nit. > > Page 4, last paragraph - Change "sample legitimate traffic" to > "legitimate traffic example" consistent with the terminology > used elsewhere. This is clearly more of an "example" than a > "sample". > > Page 5, 3.1 bullets - Change "DNS resolvers" to "DNS servers" > consistent with what is configured in most router implementations. > > Page 6, Section 3.2, First Paragraph - Change "match only on" to > "match only". Also change, "any traffic matching traffic for" > to simply "any traffic matching". > > Page 7, first paragraph - Change "may not be this obvious" to > "may not be as obvious as the example described herein". > > Page 7, first paragraph - Change "herein provided" to "provided > herein". Sure, (changed in the working copy as both ways sound OK to me ,) but why is "herein provided" incorrect here? > > Page 7, last paragraph - Change "turn up of" to "deployment of". Perhaps "test a new circuit turn-up"? Or "provisioning of"? `Turn up of a circuit` seems to be a fairly common phrase. Changed to "deployment" but curious about the suggestion. > > Page 7, last paragraph - Replace "neighbor discovery" with > "Neighbor Discovery (ND)" and "multicast listener discovery > version 2 (MLDv2)" with "Multicast Listener Discovery version 2 > (MLDv2)". > > Page 8, General - Use consistent capitalization for "IP optioned > traffic"/"IP Optioned traffic". > > Page 8, first paragraph - The phrase "(and statistic gathering)" > seems as though it should not be in parentheses. > > Page 8, second paragraph - Change "may not be possible" to "may not > be feasible". Also replace "referenced here" with "included herein". > Finally, should RSVP be spelled out consistent with other explicitly > referenced protocols? Sure, now up-to-date does not mark RSVP as well-known. > > Page 8, third paragraph - Replace "isolating a more" with "filtering > a more" and "or isolating valid" with "or classifying valid". > Used "filtering a more". > Page 8, last paragraph - Change "matched in a" to "matched to a". > Change "allows the default traffic" to simply "accepts default > traffic". Change "rather than just dropping it" to "as opposed to > dropping it". Change "functionality of the device" to simply "device > functionality". Change "was highlighted" to "was chosen". Change > "implementor" to "operator" consistent to other references to the > party applying the filters in the document. draft-ietf-opsec-protocol-plane-04.txt > Changed all of these except the first two suggestions. > Page 9, first paragraph - Change "is being" to "has been identified > and" > > Page 9, third paragraph - Change "forensic analysis afterwards" to > "ongoing forensic analysis". > > Page 9, Fourth paragraph - Change "on the Internet" to "in the > Internet". > > Page 9, last paragraph - The phrase "at the source where the > traffic has been originated" is redundant. Change to simply > "at the source". Redundancy on purpose to add emphasis. > > Page 10, second paragraph - Change "PMTUD" to Path Maximum > Transmission Unit Discovery (PMTUD)". > > Thanks, > Acee Thanks much ! -- Carlos. > > From ben@niven-jenkins.co.uk Sun Dec 5 14:06:57 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 03B4528C157 for ; Sun, 5 Dec 2010 14:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 V1yM0m7rzGaH for ; Sun, 5 Dec 2010 14:06:55 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 15D5328C156 for ; Sun, 5 Dec 2010 14:06:55 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.2]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PPMkg-0001XN-TR; Sun, 05 Dec 2010 22:08:15 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 5 Dec 2010 22:08:12 +0000 Message-Id: To: rtg-ads@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: rtg-dir@ietf.org, draft-ietf-mpls-fastreroute-mib.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-fastreroute-mib-15.txt 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: Sun, 05 Dec 2010 22:06:57 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft = (draft-ietf-mpls-fastreroute-mib-15). 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-mpls-fastreroute-mib-15.txt=E2=80=A8 Reviewer: Ben Niven-Jenkins=E2=80=A8Review Date: 3 December 2010 =E2=80=A8IETF LC End Date: Not Known =E2=80=A8Intended Status: Standards Track Summary: I have one major issue which is related to an omission from the = MIB and some minor concerns about this document that I think should be = resolved before publication. Comments: My review was restricted to whether the MIBs specified in the = document capture the necessary elements of MPLS FRR (RFC 4090), for = example I did not attempt to compile the MIB to check for syntax errors = etc. The document in general is easy to read but I feel there is still = room for improvement that would add additional clarity for individuals = trying to understand how to make use of the MIB. I feel that some of the = items I list under "Minor Issues" are more than just minor but not = significant enough to be classed as Major because they are comments = against the descriptive text in the document and not the MIB definitions = themselves. Major Issues:=20 1) There is no way in the MIB to read or set a value for "SE Style = preferred" as defined in RFC4090 Section 4.3. This means there is no way = to tell from looking at an instance of the MIB whether the ingress node = is allowed to reroute the protecting LSP without tearing it down. = Equally there is no way to read or set a value for "Bandwidth protection = desired" as defined in RFC4090. Minor Issues: 1) The document defines three MIB modules but it only provides an = example of how it could be used for the MPLS-FRR-ONE2ONE-STD-MIB. = Personally I find examples of how to use MIBs extremely helpful when I = have had to make use of a MIB for configuration or diagnostics. I would = suggest adding examples of usage for the other two MIBs specified in the = document. 2) Section 4.2.2 explains how to identify a a detour LSP in the MIB, = however the fields used for identification differ from those described = in RFC4090 Section 6.1 so it is not clear to me how one could map = between an RSVP-TE message and the corresponding MIB entry for that = detour LSP. I would suggest including some wording to clarify how this = could be done. 3) Section 4.2.2. includes the following two paragraphs: A detour LSP is also considered as an instance of a protected TE tunnel. Therefore, each detour LSP SHOULD have an entry in the mplsTunnelTable (defined in the MPLS-TE-STD-MIB[RFC3812]). In the mplsTunnelTable, the higher 16 bits of the tunnel instance SHOULD be used as a detour instance. Note that for the protected TE tunnel instances, the higher 16 bits of the tunnel instance MUST all be set to zero. The first paragraph is fine and included here for context. The second = paragraph is extremely difficult to parse, partly because it is not = explicit as to when it is referring to a detour LSP Vs a protected LSP. = If my interpretation is correct what you mean is that for protected LSPs = the high order 16 bits should be set to 0 and for protecting LSPs the = high order 16 bits should be used as a detour instance. So in the case = of a detour LSP, it has two mplsTunnelTable entries - one with the high = order bits set to 0 and one with the high order bits set to the detour = instance? 4) Section 4.2.3. The example in this section places the = mplsTunnelInstance for the protected LSP in the high order bits and the = mplsTunnelInstance for the detour LSP in the low order bits. However = section 4.2.2 specifics that they should be the other way round, i.e. = protected LSP instance in the low order bits and detour LSP instance in = the high order bits. Ben From acee.lindem@ericsson.com Mon Dec 6 02:59:25 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 EFDBD3A69E7 for ; Mon, 6 Dec 2010 02:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] 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 UMPn12TNBpzr for ; Mon, 6 Dec 2010 02:59:24 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 901F33A69AC for ; Mon, 6 Dec 2010 02:59:24 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oB6BTtct014452; Mon, 6 Dec 2010 05:29:56 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 6 Dec 2010 06:00:37 -0500 From: Acee Lindem To: Carlos Pignataro Date: Mon, 6 Dec 2010 06:00:35 -0500 Thread-Topic: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (resending with authors copied since draft-ietf... bounced) Thread-Index: AcuVNNABpWvitub7QWyMlzkFL2l6Rg== Message-ID: <4C05B976-ADA5-494A-B811-52E6D4A2CCA1@ericsson.com> References: <4CFB07A3.3040207@cisco.com> In-Reply-To: <4CFB07A3.3040207@cisco.com> 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: "rtg-dir@ietf.org" , "opsec-ads@tools.ietf.org" , "draft-ietf-opsec-protect-control-plane@tools.ietf.org" , Rodney Dunn , Adrian Farrel , "rtg-ads@tools.ietf.org" , Dave Dugal Subject: Re: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (resending with authors copied since draft-ietf... bounced) 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, 06 Dec 2010 10:59:26 -0000 Hi Carlos,=20 The corrections all sound good to me. See inline.=20 On Dec 4, 2010, at 10:31 PM, Carlos Pignataro wrote: > [Correcting the draft-ietf-... email address] >=20 > Acee, >=20 > Many thanks for a most thorough and useful review. Please see inline. >=20 > On 12/2/2010 12:03 PM, Acee Lindem wrote: >> Hello, >>=20 >> 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=20 >> information about the Routing Directorate, please see=20 >> http://www.ietf.org/iesg/directorate/routing.html >>=20 >> 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=20 >> Last Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >>=20 >> Document: draft-ietf-opsec-protocol-plane-04.txt >> Reviewer: Acee Lindem >> Review Date: 2010-12-02 >> IETF LC End Date: 2010-12-03 >> Intended Status: Informational >>=20 >> Summary: This document accomplishes its intended purpose of providing >> guidance on defining filters to protect the router control plane. The=20 >> fact that the OPSEC WG adopted this as a WG document indicates that this >> is a viewed as a worthwhile effort. I found one major issue that needs=20 >> to be fixed before this document should move forward. >=20 > Thanks for this summary, we believe we have fixed this major issue, as > well as minor issues and nits. We have all the changes in our working cop= y. >=20 > Comments below. >=20 >>=20 >> Major Issues:=20 >>=20 >> Page 5, unless there are virtual links, all OSPFv3 packets use=20 >> an IPv6 link local address as the source address. Hence, you need >> to allow OSPFv3 packets sourced from the IPv6 link-local range >> (FE80::/10). I'd simply remove the IPv6 global prefix since >> virtual links are not the norm. >>=20 >=20 > Great catch, thank you. This is the change we are making here: >=20 > From: >=20 > o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and > OSPFv3 traffic from subnet 2001:DB8:1::/48 >=20 > To: >=20 > o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and > OSPFv3 traffic from IPv6 Link-Local unicast addresses (FE80::/10) >=20 >=20 > [and corresponding example config updates] >=20 > We thought about adding a note mentioning Virtual Links but decided > against it. This is exactly how I would have corrected the document. =20 >=20 >=20 >> Of course, the examples in the appendices need to be updated as well.=20 >> I didn't see any other problems with IPv6 link-local addresses.=20 >> Other than ICMPv6 which has no source address filter, the=20 >> other protocols filtered run on top of UDP or TCP. >>=20 >> Minor Issues: >>=20 >> General: It would be nice if there were a network diagram showing >> the target router and where the referenced subnets sit in relation to= =20 >> the target. However, I realize it is a bit late to ask for this.=20 >>=20 >=20 > We discussed this but decided against adding such network diagram. >=20 >> Page 10, Third Paragraph - What do you mean by "when=20 >> rate limiters become active which serve as indicator that either >> normal traffic has increased or out of policy traffic rates have >> been detected."? This isn't clear to me. How would you know the >> difference?=20 >=20 > Reworded to this, please let us know if this does not help: >=20 > when these rate limiters > become active (i.e., when traffic is policed). This in turn serves > as an indicator that either the normal traffic rates have increased > or out of policy traffic rates have been detected. More thorough > analysis of the traffic flows and rate-limited traffic is needed to > identify which of these two cases triggered the rate limiters. Yes - this is clearer.=20 >=20 >>=20 >> Section 3.3 - Should there be informative references to ICMP, ICMPv6, >> and ND since details of their functionality are referenced? >>=20 >=20 > We thought about this earlier and decided against it. We are agreeable > to adding these references and corresponding citations if the shepherd > or ADs think it adds to the doc. However, our thinking was that there > are very many protocols mentioned in this document and although reading > about them would enhance the operators understanding, it would not > change the main message from this document. The exception here is > ICMPv6, and Informative would be warranted, but instead we are covering > this with the Informative reference to RFC 4890 (that has of course RFC > 4443 as Normative, but speaks as to the filtering aspects). Ok.=20 >=20 >> Editorial Nits: >>=20 >=20 > Many thanks for the thorough review ! Follow-ups inline, plus implicit > Ack for changes silently made as suggested. >=20 >> General - There seem to be a lot of commas missing from the text. >> However, I'll leave these to the RFC Editor.=20 >>=20 >=20 > Ack, sounds good. >=20 >> Page 3, last paragraph - Expand out first occurrence of the >> acronym "Denial of Service (DoS)".=20 >>=20 >> Page 4, first paragraph - Change "diverted out of" to=20 >> "diverted from" and "up to" to "to". =20 >=20 > Used "from". >=20 >>=20 >> Page 4, penultimate paragraph - Change "are on by default or >> always on" to "are enabled by default or always enabled".=20 >=20 > Used "active" instead of "enabled" as per Gen-ART suggestion that > flagged the same nit. >=20 >>=20 >> Page 4, last paragraph - Change "sample legitimate traffic" to >> "legitimate traffic example" consistent with the terminology >> used elsewhere. This is clearly more of an "example" than a=20 >> "sample".=20 >>=20 >> Page 5, 3.1 bullets - Change "DNS resolvers" to "DNS servers" >> consistent with what is configured in most router implementations.=20 >>=20 >> Page 6, Section 3.2, First Paragraph - Change "match only on" to >> "match only". Also change, "any traffic matching traffic for"=20 >> to simply "any traffic matching".=20 >>=20 >> Page 7, first paragraph - Change "may not be this obvious" to=20 >> "may not be as obvious as the example described herein".=20 >>=20 >> Page 7, first paragraph - Change "herein provided" to "provided >> herein".=20 >=20 > Sure, (changed in the working copy as both ways sound OK to me ,) but > why is "herein provided" incorrect here? Both are correct. However, "provided herein" is the more common alternative= and, IMHO, sounds much more natural. The form, "herein provided", sounds l= ike it came out of a legal document. You can confirm the usage using a Goog= le "exact phrase" search.=20 >=20 >>=20 >> Page 7, last paragraph - Change "turn up of" to "deployment of".=20 >=20 > Perhaps "test a new circuit turn-up"? Or "provisioning of"? `Turn up of > a circuit` seems to be a fairly common phrase. Changed to "deployment" > but curious about the suggestion. I believe "deployment of" just reads better than "turn up of". I wouldn't u= se "provisioning of" since links may be "provisioned" well in advance of ac= tually being "deployed".=20 >=20 >>=20 >> Page 7, last paragraph - Replace "neighbor discovery" with=20 >> "Neighbor Discovery (ND)" and "multicast listener discovery >> version 2 (MLDv2)" with "Multicast Listener Discovery version 2 >> (MLDv2)".=20 >>=20 >> Page 8, General - Use consistent capitalization for "IP optioned >> traffic"/"IP Optioned traffic".=20 >>=20 >> Page 8, first paragraph - The phrase "(and statistic gathering)" >> seems as though it should not be in parentheses.=20 >>=20 >> Page 8, second paragraph - Change "may not be possible" to "may not >> be feasible". Also replace "referenced here" with "included herein".=20 >> Finally, should RSVP be spelled out consistent with other explicitly >> referenced protocols?=20 >=20 > Sure, > now up-to-date does not mark RSVP as well-known. >=20 >>=20 >> Page 8, third paragraph - Replace "isolating a more" with "filtering >> a more" and "or isolating valid" with "or classifying valid".=20 >>=20 >=20 > Used "filtering a more". >=20 >> Page 8, last paragraph - Change "matched in a" to "matched to a".=20 >> Change "allows the default traffic" to simply "accepts default=20 >> traffic". Change "rather than just dropping it" to "as opposed to >> dropping it". Change "functionality of the device" to simply "device=20 >> functionality". Change "was highlighted" to "was chosen". Change >> "implementor" to "operator" consistent to other references to the >> party applying the filters in the document. draft-ietf-opsec-protocol-p= lane-04.txt >>=20 >=20 > Changed all of these except the first two suggestions. >=20 >> Page 9, first paragraph - Change "is being" to "has been identified=20 >> and"=20 >>=20 >> Page 9, third paragraph - Change "forensic analysis afterwards" to >> "ongoing forensic analysis".=20 >>=20 >> Page 9, Fourth paragraph - Change "on the Internet" to "in the >> Internet".=20 >>=20 >> Page 9, last paragraph - The phrase "at the source where the >> traffic has been originated" is redundant. Change to simply=20 >> "at the source".=20 >=20 > Redundancy on purpose to add emphasis. Ok - consider the following sentence.=20 Over the Christmas holidays, many christians will visit Jesus' birthplace,= where He was born.=20 Thanks, Acee=20 >=20 >>=20 >> Page 10, second paragraph - Change "PMTUD" to Path Maximum=20 >> Transmission Unit Discovery (PMTUD)".=20 >>=20 >> Thanks, >> Acee >=20 > Thanks much ! >=20 > -- Carlos. >=20 >>=20 >>=20 >=20 From cpignata@cisco.com Mon Dec 6 05:56:18 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 E3B1C3A67ED for ; Mon, 6 Dec 2010 05:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.352 X-Spam-Level: X-Spam-Status: No, score=-110.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 umonkg4VNqr4 for ; Mon, 6 Dec 2010 05:56:17 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E34A03A67AE for ; Mon, 6 Dec 2010 05:56:16 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,305,1288569600"; d="scan'208";a="189631422" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 06 Dec 2010 13:57:41 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id oB6DvdWX024432; Mon, 6 Dec 2010 13:57:39 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Dec 2010 07:57:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Dec 2010 07:57:38 -0600 Message-ID: <960EC8F9A775AB40BF58D8953342D863035B95D9@XMB-RCD-206.cisco.com> In-Reply-To: <4C05B976-ADA5-494A-B811-52E6D4A2CCA1@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (resending with authors copied since draft-ietf... bounced) Thread-Index: AcuVNNABpWvitub7QWyMlzkFL2l6RgAGF2Jg References: <4CFB07A3.3040207@cisco.com> <4C05B976-ADA5-494A-B811-52E6D4A2CCA1@ericsson.com> From: "Carlos Pignataro (cpignata)" To: "Acee Lindem" X-OriginalArrivalTime: 06 Dec 2010 13:57:40.0135 (UTC) FILETIME=[8BD73B70:01CB954D] X-Mailman-Approved-At: Mon, 06 Dec 2010 06:08:09 -0800 Cc: rtg-dir@ietf.org, opsec-ads@tools.ietf.org, draft-ietf-opsec-protect-control-plane@tools.ietf.org, "Rodney Dunn \(rodunn\)" , Adrian Farrel , rtg-ads@tools.ietf.org, Dave Dugal Subject: Re: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (resending with authors copied since draft-ietf... bounced) 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, 06 Dec 2010 13:56:19 -0000 Hi Acee, Very many thanks again for the follow-up. I agree with (and appreciate) all your comments. We have all these changes in our working copy, that we will ship early this week. Thanks, -- Carlos. -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Monday, December 06, 2010 6:01 AM To: Carlos Pignataro (cpignata) Cc: Adrian Farrel; rtg-ads@tools.ietf.org; draft-ietf-opsec-protect-control-plane@tools.ietf.org; rtg-dir@ietf.org; opsec-ads@tools.ietf.org; Rodney Dunn (rodunn); Dave Dugal Subject: Re: [RTG-DIR] Routing Area Directorate Review of draft-ietf-opsec-protocol-plane-04.txt (resending with authors copied since draft-ietf... bounced) Hi Carlos,=20 The corrections all sound good to me. See inline.=20 On Dec 4, 2010, at 10:31 PM, Carlos Pignataro wrote: > [Correcting the draft-ietf-... email address] >=20 > Acee, >=20 > Many thanks for a most thorough and useful review. Please see inline. >=20 > On 12/2/2010 12:03 PM, Acee Lindem wrote: >> Hello, >>=20 >> 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=20 >> information about the Routing Directorate, please see=20 >> http://www.ietf.org/iesg/directorate/routing.html >>=20 >> 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. >>=20 >> Document: draft-ietf-opsec-protocol-plane-04.txt >> Reviewer: Acee Lindem >> Review Date: 2010-12-02 >> IETF LC End Date: 2010-12-03 >> Intended Status: Informational >>=20 >> Summary: This document accomplishes its intended purpose of providing >> guidance on defining filters to protect the router control plane. The >> fact that the OPSEC WG adopted this as a WG document indicates that this >> is a viewed as a worthwhile effort. I found one major issue that needs=20 >> to be fixed before this document should move forward. >=20 > Thanks for this summary, we believe we have fixed this major issue, as > well as minor issues and nits. We have all the changes in our working copy. >=20 > Comments below. >=20 >>=20 >> Major Issues:=20 >>=20 >> Page 5, unless there are virtual links, all OSPFv3 packets use=20 >> an IPv6 link local address as the source address. Hence, you need >> to allow OSPFv3 packets sourced from the IPv6 link-local range >> (FE80::/10). I'd simply remove the IPv6 global prefix since >> virtual links are not the norm. >>=20 >=20 > Great catch, thank you. This is the change we are making here: >=20 > From: >=20 > o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and > OSPFv3 traffic from subnet 2001:DB8:1::/48 >=20 > To: >=20 > o Permit OSPF traffic from routers within subnet 192.0.2.0/24 and > OSPFv3 traffic from IPv6 Link-Local unicast addresses (FE80::/10) >=20 >=20 > [and corresponding example config updates] >=20 > We thought about adding a note mentioning Virtual Links but decided > against it. This is exactly how I would have corrected the document. =20 >=20 >=20 >> Of course, the examples in the appendices need to be updated as well.=20 >> I didn't see any other problems with IPv6 link-local addresses.=20 >> Other than ICMPv6 which has no source address filter, the=20 >> other protocols filtered run on top of UDP or TCP. >>=20 >> Minor Issues: >>=20 >> General: It would be nice if there were a network diagram showing >> the target router and where the referenced subnets sit in relation to=20 >> the target. However, I realize it is a bit late to ask for this.=20 >>=20 >=20 > We discussed this but decided against adding such network diagram. >=20 >> Page 10, Third Paragraph - What do you mean by "when=20 >> rate limiters become active which serve as indicator that either >> normal traffic has increased or out of policy traffic rates have >> been detected."? This isn't clear to me. How would you know the >> difference?=20 >=20 > Reworded to this, please let us know if this does not help: >=20 > when these rate limiters > become active (i.e., when traffic is policed). This in turn serves > as an indicator that either the normal traffic rates have increased > or out of policy traffic rates have been detected. More thorough > analysis of the traffic flows and rate-limited traffic is needed to > identify which of these two cases triggered the rate limiters. Yes - this is clearer.=20 >=20 >>=20 >> Section 3.3 - Should there be informative references to ICMP, ICMPv6, >> and ND since details of their functionality are referenced? >>=20 >=20 > We thought about this earlier and decided against it. We are agreeable > to adding these references and corresponding citations if the shepherd > or ADs think it adds to the doc. However, our thinking was that there > are very many protocols mentioned in this document and although reading > about them would enhance the operators understanding, it would not > change the main message from this document. The exception here is > ICMPv6, and Informative would be warranted, but instead we are covering > this with the Informative reference to RFC 4890 (that has of course RFC > 4443 as Normative, but speaks as to the filtering aspects). Ok.=20 >=20 >> Editorial Nits: >>=20 >=20 > Many thanks for the thorough review ! Follow-ups inline, plus implicit > Ack for changes silently made as suggested. >=20 >> General - There seem to be a lot of commas missing from the text. >> However, I'll leave these to the RFC Editor.=20 >>=20 >=20 > Ack, sounds good. >=20 >> Page 3, last paragraph - Expand out first occurrence of the >> acronym "Denial of Service (DoS)".=20 >>=20 >> Page 4, first paragraph - Change "diverted out of" to=20 >> "diverted from" and "up to" to "to". =20 >=20 > Used "from". >=20 >>=20 >> Page 4, penultimate paragraph - Change "are on by default or >> always on" to "are enabled by default or always enabled".=20 >=20 > Used "active" instead of "enabled" as per Gen-ART suggestion that > flagged the same nit. >=20 >>=20 >> Page 4, last paragraph - Change "sample legitimate traffic" to >> "legitimate traffic example" consistent with the terminology >> used elsewhere. This is clearly more of an "example" than a=20 >> "sample".=20 >>=20 >> Page 5, 3.1 bullets - Change "DNS resolvers" to "DNS servers" >> consistent with what is configured in most router implementations.=20 >>=20 >> Page 6, Section 3.2, First Paragraph - Change "match only on" to >> "match only". Also change, "any traffic matching traffic for"=20 >> to simply "any traffic matching".=20 >>=20 >> Page 7, first paragraph - Change "may not be this obvious" to=20 >> "may not be as obvious as the example described herein".=20 >>=20 >> Page 7, first paragraph - Change "herein provided" to "provided >> herein".=20 >=20 > Sure, (changed in the working copy as both ways sound OK to me ,) but > why is "herein provided" incorrect here? Both are correct. However, "provided herein" is the more common alternative and, IMHO, sounds much more natural. The form, "herein provided", sounds like it came out of a legal document. You can confirm the usage using a Google "exact phrase" search.=20 >=20 >>=20 >> Page 7, last paragraph - Change "turn up of" to "deployment of".=20 >=20 > Perhaps "test a new circuit turn-up"? Or "provisioning of"? `Turn up of > a circuit` seems to be a fairly common phrase. Changed to "deployment" > but curious about the suggestion. I believe "deployment of" just reads better than "turn up of". I wouldn't use "provisioning of" since links may be "provisioned" well in advance of actually being "deployed".=20 >=20 >>=20 >> Page 7, last paragraph - Replace "neighbor discovery" with=20 >> "Neighbor Discovery (ND)" and "multicast listener discovery >> version 2 (MLDv2)" with "Multicast Listener Discovery version 2 >> (MLDv2)".=20 >>=20 >> Page 8, General - Use consistent capitalization for "IP optioned >> traffic"/"IP Optioned traffic".=20 >>=20 >> Page 8, first paragraph - The phrase "(and statistic gathering)" >> seems as though it should not be in parentheses.=20 >>=20 >> Page 8, second paragraph - Change "may not be possible" to "may not >> be feasible". Also replace "referenced here" with "included herein". >> Finally, should RSVP be spelled out consistent with other explicitly >> referenced protocols?=20 >=20 > Sure, > now up-to-date does not mark RSVP as well-known. >=20 >>=20 >> Page 8, third paragraph - Replace "isolating a more" with "filtering >> a more" and "or isolating valid" with "or classifying valid".=20 >>=20 >=20 > Used "filtering a more". >=20 >> Page 8, last paragraph - Change "matched in a" to "matched to a".=20 >> Change "allows the default traffic" to simply "accepts default=20 >> traffic". Change "rather than just dropping it" to "as opposed to >> dropping it". Change "functionality of the device" to simply "device=20 >> functionality". Change "was highlighted" to "was chosen". Change >> "implementor" to "operator" consistent to other references to the >> party applying the filters in the document. draft-ietf-opsec-protocol-plane-04.txt >>=20 >=20 > Changed all of these except the first two suggestions. >=20 >> Page 9, first paragraph - Change "is being" to "has been identified=20 >> and"=20 >>=20 >> Page 9, third paragraph - Change "forensic analysis afterwards" to >> "ongoing forensic analysis".=20 >>=20 >> Page 9, Fourth paragraph - Change "on the Internet" to "in the >> Internet".=20 >>=20 >> Page 9, last paragraph - The phrase "at the source where the >> traffic has been originated" is redundant. Change to simply=20 >> "at the source".=20 >=20 > Redundancy on purpose to add emphasis. Ok - consider the following sentence.=20 Over the Christmas holidays, many christians will visit Jesus' birthplace, where He was born.=20 Thanks, Acee=20 >=20 >>=20 >> Page 10, second paragraph - Change "PMTUD" to Path Maximum=20 >> Transmission Unit Discovery (PMTUD)".=20 >>=20 >> Thanks, >> Acee >=20 > Thanks much ! >=20 > -- Carlos. >=20 >>=20 >>=20 >=20 From mshand@cisco.com Fri Dec 10 06:48:28 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 D16213A6CA7 for ; Fri, 10 Dec 2010 06:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.948 X-Spam-Level: X-Spam-Status: No, score=-10.948 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_54=0.6, 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 184jliG3KFEz for ; Fri, 10 Dec 2010 06:48:27 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1ACF13A6C88 for ; Fri, 10 Dec 2010 06:48:25 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYDAHDMAU2Q/khMgWdsb2JhbACfDoRzFQEBFiIppACbI4VKBIp5gxQ X-IronPort-AV: E=Sophos;i="4.59,324,1288569600"; d="scan'208,217";a="71381235" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2010 14:49:57 +0000 Received: from [10.55.82.105] (dhcp-10-55-82-105.cisco.com [10.55.82.105]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oBAEnuL2026097; Fri, 10 Dec 2010 14:49:56 GMT Message-ID: <4D023E14.7030009@cisco.com> Date: Fri, 10 Dec 2010 14:49:56 +0000 From: mike shand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary="------------000800090207080606040708" Cc: rtg-dir@ietf.org, draft-ietf-isis-trill.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-isis-trill-03.txt 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: Fri, 10 Dec 2010 14:48:28 -0000 This is a multi-part message in MIME format. --------------000800090207080606040708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-isis-trill-03.txt Reviewer: Mike Shand Review Date: 2010-12-06 IETF LC End Date: 2010-12-14 Intended Status: proposed standard *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments: * The document is well written and structured, and generally conforms to the conventional definition of IS-IS TLVs. *Major Issues:* No major issues found. *Minor Issues: * 2.2.1 The Special VLANs and Flags sub-TLV AF, AC, VM, BY, and TR: In previous reviews of IS-IS documents it has been suggested that bits such as these, as well as being identified by a letter or letters, should also have a descriptive name. While such a name could be inferred by the descriptive text provided, no unique nomenclature is called out here. Personally, I don't believe this to be a problem. 2.2.2 Enabled-VLANs sub-TLV If this sub-TLV occurs more than once in a Hello, the set of enabled VLANs is the union of the VLANs indicated by the Enabled-VLAN sub- TLVs. This assumes that the start VLAN IDs of the multiple sub-TLVs are correctly aligned so that there is no overlap between the bit maps. In the unlikely event that this is not the case, what is the correct action? a) ignore the IIH because it is malformed? b) only do so if there is a VLAN which has the bit set in one sub-TLV and clear in another? c) form the union of the SET bits, ignoring the unset bits? The intent is probably (c), but this is not unambiguously clear. 2.3.4 The Tree Identifiers Sub-TLV This is set to 1 for the first sub-TLV. Subsequent sub-TLVs will have the starting number of the ordered list. I assume "first" here does NOT imply that there is any required ordering for the presentation of the sub-TLVs within the PDU. 2.3.6 Interested VLANs and Spanning Tree Roots sub-TLV Appointed Forwarder Status Lost Counter: It is initialized to zero at an IS when the LSP sequence number is initialized. Since the sequence numbers of individual LSPs are independent, it would be possible for a "new" LSP to be generated to carry additional information. Such an LSP would have its LSP sequence number "initialised". It is not clear whether this text is supposed to relate to the initialisation of the sequence number of the LSP carrying this sub-TLV or whether it refers to the initialization of the sequence number of the zeroth LSP. The latter seems to make more sense. 2.3.7 The VLAN Group sub-TLV Length: 4 + 2*n, where n may be 0. n is not specified (as it is in other cases of this form of description). Presumably it is the number of secondary VLAN ID fields" There is no textual description of the "more secondary VLAN IDs field". While it is fairly obvious what this is intended to be, it would be clearer and more consistent if this were described. 2.5 TRILL Neighbor TLV S: Smallest flag. If this bit is a one, then the list of neighbors includes the neighbor with the smallest MAC address. Is it necessary to define what is meant by "smallest" and "largest" when applied to MAC addresses? RESV: These seven bits are reserved for future use and MUST be set to zero on transmission and ignored on receipt. Elsewhere, such bits are simply described as being reserved, without any mention of future use. Are these bits specifically required to be called out as different from other reserved bits? Also, elsewhere, the phrase "MUST be sent as zero" is used rather than "MUST be set to zero on transmission". Although there is "obviously" no intent that any difference is implied, the use of gratuitously different phraseology is best avoided. in a TRILL Neighbor TLV with the L flag zero will also appear as a Should that "will" be a "MUST"? And similarly for S flag If an RBridge believes it has no neighbors, its MUST send an empty TRILL Neighbor TLV, which will have both the S and L bits on. Rather than saying "empty", which implies no content at all, would it be clearer to say " a TRILL Neighbor TLV containing no neighbor records"? It would also help to specify in Length: 1 + 9*n, where n is the number of neighbor records. that n can take the value zero, as has been done elsewhere... since the absence of that statement here could imply that it is NOT permitted to be zero. 3. The MTU PDUs I have previously commented on the unnecessary use of two PDU type code points for the probe and ack PDUs. Indeed the two can be distinguished by the probe having a zero value for the ACK source ID, and the ACK having a non-zero value. Do we need to update the existing registries to specify that AUTH and PAD TLVs are permitted in these PDU types? 4.3 Protocols Supported MUST appear in TRILL IIH PDUs and fragment zero LSP PDUs. ISO/IEC 10589 doesn't use the term "fragment zero", but uses the term "LSP number zero". 6.1 Allocations From Existing Registries This document creates two new IS-IS PDUs, namely the MTU-PROBE-PDU, and MTU-ACK-PDU, as described in Section 3. IANA will assign new PDU types to these PDUs and reflect them in the PDU registry. [suggested values below] MTU-PROBE-PDU Level-1 PDU Number: 23 MTU-ACK-PDU Level-1 PDU Number: 28 Why are these PDUs described as Level-1? In any case whether or not they are restricted to level 1 is a matter for the definition (or indeed title) of the PDU. I don't see that this information needs to be included in the registry if indeed such a registry exists... I don't think it does). This is the first time that a new PDU has been defined for IS-IS and all current definitions are contained within ISO/IEC 10589 itself. ALL other changes to IS-IS PDU definitions have previously been restricted to TLVs (or sub-TLVs). It is partially for this reason that it seems gratuitous to specify TWO new PDUs, where a single one would easily suffice. In any case note that PDU 23 was assigned by DECnet PhaseV to an XID PDU type. Although never specified in ISO/IEC 10589 itself, and probably never now seen in the wild it would be as well to avoid any chance of a potential clash and assign the MTU_PROBE-PDU a different number. *Nits:* 2.2.3 Appointed Forwarders sub-TLV 1. +----------------------------+ | Appointee Nickname | (2 bytes) +----------------------------+ | RESV | Start.VLAN | (2 bytes) +----------------------------+ | RESV | End.VLAN | (2 bytes) +----------------------------+ It would be helpful if this diagram were formatted like the other fields, indicating bit positions. 2.3.6 Interested VLANs and Spanning Tree Roots sub-TLV An INT-VLAN sub-TLV asserts that the information provided (multicast router attachment, appointed forwarder status lost counter, and root bridges), is the same for all VLANs in the range give. TYPO: s/give/given/ or perhaps better "specified". 2.5 TRILL Neighbor TLV If an RBridge believes it has no neighbors, its MUST send an empty TRILL Neighbor TLV, which will have both the S and L bits on. TYPO: s/its/it/ 3. The MTU PDUs Again, use of the conventional form of diagram would be helpful. 4.2 Area Address Again, the standard diagram form would be helpful --------------000800090207080606040708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

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-isis-trill-03.txt
Reviewer: Mike Shand
Review Date: 2010-12-06
IETF LC End Date: 2010-12-14
Intended Status: proposed standard

Summary:

I have some minor concerns about this document that I think should be resolved before publication.

Comments:

The document is well written and structured, and generally conforms to the conventional definition of IS-IS TLVs.

Major Issues:

No major issues found.

Minor Issues:

2.2.1 The Special VLANs and Flags sub-TLV
AF, AC, VM, BY, and TR:

In previous reviews of IS-IS documents it has been suggested that bits such as these, as well as being identified by a letter or letters, should also have a descriptive name. While such a name could be inferred by the descriptive text provided, no unique nomenclature is called out here.

Personally, I don't believe this to be a problem.

2.2.2 Enabled-VLANs sub-TLV

If this sub-TLV occurs more than once in a Hello, the set of enabled
   VLANs is the union of the VLANs indicated by the Enabled-VLAN sub-
   TLVs.

This assumes that the start VLAN IDs of the multiple sub-TLVs are correctly aligned so that there is no overlap between the bit maps. In the unlikely event that this is not the case, what is the correct action?

a) ignore the IIH because it is malformed?

b) only do so if there is a VLAN which has the bit set in one sub-TLV and clear in another?

c) form the union of the SET bits, ignoring the unset bits?

The intent is probably (c), but this is not unambiguously clear.


2.3.4 The Tree Identifiers Sub-TLV

This is set to 1 for
      the first sub-TLV.  Subsequent sub-TLVs will have the starting
      number of the ordered list.

I assume "first" here does NOT imply that there is any required ordering for the presentation of the sub-TLVs within the PDU.

2.3.6 Interested VLANs and Spanning Tree Roots sub-TLV

Appointed Forwarder Status Lost Counter:

      It is
      initialized to zero at an IS when the LSP sequence number is
      initialized.

Since the sequence numbers of individual LSPs are independent, it would be possible for a "new" LSP to be generated
to carry additional information. Such an LSP would have its LSP sequence number "initialised".
It is not clear whether this text is supposed to relate to the initialisation of the sequence number of the LSP carrying this sub-TLV
or whether it refers to the initialization of the sequence number of the zeroth LSP. The latter seems to make more sense.

2.3.7 The VLAN Group sub-TLV

Length: 4 + 2*n, where n may be 0.

n is not specified (as it is in other cases of this form of description).

Presumably it is the number of secondary VLAN ID fields"

There is no textual description of the "more secondary VLAN IDs field". While it is fairly obvious what this is intended to be, it would be clearer and more consistent if this were described.

2.5 TRILL Neighbor TLV

S: Smallest flag.  If this bit is a one, then the list of
      neighbors includes the neighbor with the smallest MAC address.

Is it necessary to define what is meant by "smallest" and "largest" when applied to MAC addresses?


 RESV: These seven bits are reserved for future use and MUST be set
      to zero on transmission and ignored on receipt.

Elsewhere, such bits are simply described as being reserved, without any mention of future use.
Are these bits specifically required to be called out as different from other reserved bits?

Also, elsewhere, the phrase "MUST be sent as zero" is used rather than "MUST be set to zero on transmission".

Although there is "obviously" no intent that any difference is implied, the use of gratuitously different phraseology is best avoided.

in a TRILL Neighbor TLV with the L flag zero will also appear as a

Should that "will" be a "MUST"? And similarly for S flag

If an RBridge believes
   it has no neighbors, its MUST send an empty TRILL Neighbor TLV, which
   will have both the S and L bits on.

Rather than saying "empty", which implies no content at all, would it be clearer to say
" a TRILL Neighbor TLV containing no neighbor records"?

It would also help to specify in

Length: 1 + 9*n, where n is the number of neighbor records.

that n can take the value zero, as has been done elsewhere... since the absence of that statement here could imply that it is NOT permitted to be zero.


3. The MTU PDUs
I have previously commented on the unnecessary use of two PDU type code points for the probe and ack PDUs. Indeed the two can be distinguished by the probe having a zero value for the ACK source ID, and the ACK having a non-zero value.

Do we need to update the existing registries to specify that AUTH and PAD TLVs are permitted in these PDU types?


4.3 Protocols Supported

   MUST appear in
   TRILL IIH PDUs and fragment zero LSP PDUs.

ISO/IEC 10589 doesn't use the term "fragment zero", but uses the term "LSP number zero".


6.1 Allocations From Existing Registries

   This document creates two new IS-IS PDUs, namely the MTU-PROBE-PDU,
   and MTU-ACK-PDU, as described in Section 3.  IANA will assign new PDU
   types to these PDUs and reflect them in the PDU registry. [suggested
   values below]

      MTU-PROBE-PDU     Level-1 PDU Number: 23
      MTU-ACK-PDU       Level-1 PDU Number: 28



Why are these PDUs described as Level-1?
In any case whether or not they are restricted to level 1 is a matter for the definition (or indeed title) of the PDU.
I don't see that this information needs to be included in the registry
if indeed such a registry exists... I don't think it does).

This is the first time that a new PDU has been defined for IS-IS and all current definitions are contained within 
ISO/IEC 10589 itself. ALL other changes to IS-IS PDU definitions have previously been restricted to TLVs (or sub-TLVs).

It is partially for this reason that it seems gratuitous to specify TWO new PDUs, where a single one would easily suffice.

In any case note that PDU 23 was assigned by DECnet PhaseV to an XID PDU type.
Although never specified in ISO/IEC 10589 itself, and probably never now seen in the wild it would be as well to avoid any
chance of a potential clash and assign the MTU_PROBE-PDU a different number.

Nits:

2.2.3 Appointed Forwarders sub-TLV

  1.    +----------------------------+
   |   Appointee Nickname       |  (2 bytes)
   +----------------------------+
   | RESV |     Start.VLAN      |  (2 bytes)
   +----------------------------+
   | RESV |     End.VLAN        |  (2 bytes)
   +----------------------------+

    It would be helpful if this diagram were formatted like the other fields, indicating bit positions.


2.3.6 Interested VLANs and Spanning Tree Roots sub-TLV
   An INT-VLAN sub-TLV asserts that the information provided (multicast
   router attachment, appointed forwarder status lost counter, and root
   bridges), is the same for all VLANs in the range give.

TYPO: s/give/given/


or perhaps better "specified".


2.5 TRILL Neighbor TLV
If an RBridge believes
   it has no neighbors, its MUST send an empty TRILL Neighbor TLV, which
   will have both the S and L bits on.


TYPO: s/its/it/

3. The MTU PDUs

Again, use of the conventional form of diagram would be helpful.


4.2 Area Address

Again, the standard diagram form would be helpful

--------------000800090207080606040708-- From mshand@cisco.com Fri Dec 10 06:49:26 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 568463A6C98 for ; Fri, 10 Dec 2010 06:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.613 X-Spam-Level: X-Spam-Status: No, score=-10.613 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, HTML_MESSAGE=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 zGli8-Ozde9F for ; Fri, 10 Dec 2010 06:49:25 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E98583A6C88 for ; Fri, 10 Dec 2010 06:49:24 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYDAJvNAU2Q/khMgWdsb2JhbACfDoRzFQEBFiIpo3ubIYVKBIp5gxQ X-IronPort-AV: E=Sophos;i="4.59,324,1288569600"; d="scan'208,217";a="71381285" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 Dec 2010 14:50:37 +0000 Received: from [10.55.82.105] (dhcp-10-55-82-105.cisco.com [10.55.82.105]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oBAEobPV026297; Fri, 10 Dec 2010 14:50:37 GMT Message-ID: <4D023E3D.8060600@cisco.com> Date: Fri, 10 Dec 2010 14:50:37 +0000 From: mike shand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary="------------060905070508020707060900" Cc: rtg-dir@ietf.org, draft-ietf-isis-layer2.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review of draft-ietf-isis-layer2-08.txt 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: Fri, 10 Dec 2010 14:49:26 -0000 This is a multi-part message in MIME format. --------------060905070508020707060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-isis-layer2-08.txt Reviewer: Mike Shand Review Date: 2010-12-06 IETF LC End Date: 2010-12-14 Intended Status: proposed standard *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments: * The document is well written and structured, and generally conforms to the conventional definition of IS-IS TLVs. *Major Issues:* No major issues found. *Minor Issues: * General For compatibility with the TRILL IS-IS document, perhaps the occurrences of the phrase "Must be sent as (or set to) zero on transmission and is ignored on receipt." should be replaced by "MUST be sent as zero and ignored on receipt". In any case, the "must" should always be a "MUST". 2.1. The MAC-Reachability TLV Although it is obvious, perhaps it should say that the TLV can be carried multiple times in an LSP and in multiple LSPs. 6. References Should there not be references to the TRILL and 802.1aq IS-IS specific specs? *Nits: * Abstract This document specifies the IS-IS extensions necessary to support link state routing to any protocols running directly over layer 2. ->link state routing for any .... * * --------------060905070508020707060900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

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-isis-layer2-08.txt
Reviewer: Mike Shand
Review Date: 2010-12-06
IETF LC End Date: 2010-12-14
Intended Status: proposed standard

Summary:

I have some minor concerns about this document that I think should be resolved before publication.

Comments:

The document is well written and structured, and generally conforms to the conventional definition of IS-IS TLVs.

Major Issues:

No major issues found.

Minor Issues:


General

For compatibility with the TRILL IS-IS document, perhaps the occurrences of the phrase
"Must be sent as (or set to) zero on transmission and is ignored on receipt."
should be replaced by "MUST be sent as zero and ignored on receipt".

In any case, the "must" should always be a "MUST".


2.1.  The MAC-Reachability TLV
Although it is obvious, perhaps it should say that the TLV can be carried multiple times in an LSP and in multiple LSPs.

6.  References
Should there not be references to the TRILL and 802.1aq IS-IS specific specs?


Nits:

Abstract

This document specifies the IS-IS extensions necessary to support
   link state routing to any protocols running directly over layer 2.
->link state routing for any ....




--------------060905070508020707060900-- From d3e3e3@gmail.com Tue Dec 14 01:08:19 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 72AE43A6D2D for ; Tue, 14 Dec 2010 01:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.052 X-Spam-Level: X-Spam-Status: No, score=-103.052 tagged_above=-999 required=5 tests=[AWL=1.347, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1, 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 Za+cp2pLmAdc for ; Tue, 14 Dec 2010 01:08:17 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 7286F3A6CE5 for ; Tue, 14 Dec 2010 01:08:17 -0800 (PST) Received: by qwg5 with SMTP id 5so308709qwg.31 for ; Tue, 14 Dec 2010 01:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tu8WPzEB8kTeKu3KxRnCC5A1+xWIwa6VHw9qwB/bFLY=; b=Q/1d3xjOo/knjUs162+7kmLirGGlt477r060ScbqMD7nc1KgQ1HnrGDQlYEPrPMKsE JHmIoj7N/oZBGxAD9ARWRmCW8lD1Pbqw4Q7wKHq5P9wIioq5zFF+ed70HFR5VkgLuXyZ sJl6LNTud6dmAVK/vVuxHJCN3RG0F852jQdeA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cbieLmNnd2Rd41jUB52iU1v0SELj92SUsmsU40wA25k6yvQBT+ko9yW8N0c6guAwZe csX/dh+BcySSqndkeJVOGwqwXFKWxq2kHhtRraYvv2rjHQQr20jPH8qG9QshqxTiOntz VADZVhzu0k04EVTe5z3MRIU+A/jD+Cw/iXCfU= MIME-Version: 1.0 Received: by 10.229.222.212 with SMTP id ih20mr4757393qcb.121.1292317796595; Tue, 14 Dec 2010 01:09:56 -0800 (PST) Received: by 10.220.91.197 with HTTP; Tue, 14 Dec 2010 01:09:56 -0800 (PST) In-Reply-To: <4D023E14.7030009@cisco.com> References: <4D023E14.7030009@cisco.com> Date: Tue, 14 Dec 2010 04:09:56 -0500 Message-ID: From: Donald Eastlake To: mike shand Content-Type: multipart/mixed; boundary=0016361e844633fb5404975b2fee Cc: rtg-dir@ietf.org, draft-ietf-isis-trill.all@tools.ietf.org, Erik Nordmark , rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-trill-03.txt 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: Tue, 14 Dec 2010 09:08:19 -0000 --0016361e844633fb5404975b2fee Content-Type: text/plain; charset=ISO-8859-1 Hi Mike, Thanks for this detailed review. See responses below. On Fri, Dec 10, 2010 at 9:49 AM, mike shand wrote: > 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-isis-trill-03.txt > Reviewer: Mike Shand > Review Date: 2010-12-06 > IETF LC End Date: 2010-12-14 > Intended Status: proposed standard > > Summary: > > I have some minor concerns about this document that I think should be > resolved before publication. > > Comments: > > The document is well written and structured, and generally conforms to the > conventional definition of IS-IS TLVs. > > Major Issues: > > No major issues found. > > Minor Issues: > > 2.2.1 The Special VLANs and Flags sub-TLV > > AF, AC, VM, BY, and TR: > > In previous reviews of IS-IS documents it has been suggested that bits such > as these, as well as being identified by a letter or letters, should also > have a descriptive name. While such a name could be inferred by the > descriptive text provided, no unique nomenclature is called out here. > > Personally, I don't believe this to be a problem. I am uncertain as to whether this needs to be changed. It would be relatively easy to add a descriptive word or two or three for each of these bits if desired. > 2.2.2 Enabled-VLANs sub-TLV > > If this sub-TLV occurs more than once in a Hello, the set of enabled > VLANs is the union of the VLANs indicated by the Enabled-VLAN sub- > TLVs. > > This assumes that the start VLAN IDs of the multiple sub-TLVs are correctly > aligned so that there is no overlap between the bit maps. In the unlikely > event that this is not the case, what is the correct action? > > a) ignore the IIH because it is malformed? > > b) only do so if there is a VLAN which has the bit set in one sub-TLV and > clear in another? > > c) form the union of the SET bits, ignoring the unset bits? > > The intent is probably (c), but this is not unambiguously clear. Your interpretation of the intent is correct and the above wording seems reasonably clear to me. Each sub-TLV identifies a set of VLANs. If there are more than one of the sub-TLVs, you take the union of these sets. How about if I add a few words so it reads as follows: "If this sub-TLV occurs more than once in a Hello, the set of enabled VLANs is the union of the sets of VLANs indicated by each the Enabled-VLAN sub-TLVs in the Hello." > 2.3.4 The Tree Identifiers Sub-TLV > > This is set to 1 for > the first sub-TLV. Subsequent sub-TLVs will have the starting > number of the ordered list. > > I assume "first" here does NOT imply that there is any required ordering for > the presentation of the sub-TLVs within the PDU. Yes, you assume correctly. Perhaps the following wording would be an improvement: "This is set to 1 for the sub-TLV containing the first list. Other Tree-Identifiers Sub-TLVs will have the number of the starting list they contain." > 2.3.6 Interested VLANs and Spanning Tree Roots sub-TLV > > Appointed Forwarder Status Lost Counter: > > It is > initialized to zero at an IS when the LSP sequence number is > initialized. > > Since the sequence numbers of individual LSPs are independent, it would be > possible for a "new" LSP to be generated > to carry additional information. Such an LSP would have its LSP sequence > number "initialised". > It is not clear whether this text is supposed to relate to the > initialisation of the sequence number of the LSP carrying this sub-TLV > or whether it refers to the initialization of the sequence number of the > zeroth LSP. The latter seems to make more sense. Yes, I agree. "the LSP" should be replaced by "the zeroth LSP". > 2.3.7 The VLAN Group sub-TLV > > Length: 4 + 2*n, where n may be 0. > > n is not specified (as it is in other cases of this form of description). > > Presumably it is the number of secondary VLAN ID fields" Yes, I suggest replacement wording: "Length: 4 + 2*n, where n is the number of secondary VLAN ID fields, which may be zero." > There is no textual description of the "more secondary VLAN IDs field". > While it is fairly obvious what this is intended to be, it would be clearer > and more consistent if this were described. OK, how about adding "o more Secondary VLAN IDs: zero or more byte pairs with the top four bits an RESV field and the low 12 bits a VLAN-ID." > 2.5 TRILL Neighbor TLV > > S: Smallest flag. If this bit is a one, then the list of > neighbors includes the neighbor with the smallest MAC address. > > Is it necessary to define what is meant by "smallest" and "largest" when > applied to MAC addresses? I'd be happy to add at the end of the entries of "S" and "L" the text "considered as an unsigned integer". > RESV: These seven bits are reserved for future use and MUST be set > to zero on transmission and ignored on receipt. > > Elsewhere, such bits are simply described as being reserved, without any > mention of future use. > Are these bits specifically required to be called out as different from > other reserved bits? > > Also, elsewhere, the phrase "MUST be sent as zero" is used rather than "MUST > be set to zero on transmission". > > Although there is "obviously" no intent that any difference is implied, the > use of gratuitously different phraseology is best avoided. I agree. I'm fine with changing this to "These seven bits are reserved and MUST be sent as zero and ignored on receipt." > in a TRILL Neighbor TLV with the L flag zero will also appear as a > > Should that "will" be a "MUST"? And similarly for S flag That would probably be an improvement. > If an RBridge believes > it has no neighbors, its MUST send an empty TRILL Neighbor TLV, which > will have both the S and L bits on. > > Rather than saying "empty", which implies no content at all, would it be > clearer to say > " a TRILL Neighbor TLV containing no neighbor records"? How about replacing "an empty TRILL Neighbor TLV" with "a TRILL neighbor TLV with an empty list of neighbor RECORDs". > It would also help to specify in > > Length: 1 + 9*n, where n is the number of neighbor records. > > that n can take the value zero, as has been done elsewhere... since the > absence of that statement here could imply that it is NOT permitted to be > zero. OK, easy to add "which may be zero" at the end of that entry. > 3. The MTU PDUs > > I have previously commented on the unnecessary use of two PDU type code > points for the probe and ack PDUs. Indeed the two can be distinguished by > the probe having a zero value for the ACK source ID, and the ACK having a > non-zero value. Well, actually what you said was "Are two seperate PDUs really required. Would not a single PDU type with a flag to indicate probe or ACK suffice?" although I took that question to mean that you would prefer a single MTU PDU. I responded with "Yes, you could use a single PDU type but I think they way they are currently specified fits somewhat better into the pattern of PDU definitions for IS-IS... Does anyone else out there have an opinion on this?" Since no one else spoke up, I left it unchanged. This seems to be a matter of taste. Why are the L1 and L2 variants of existing IS-IS PDUs different PDUs? That could easily be encoded elsewhere in the PDUs. You can push the bits around in various ways. But I don't care that much about this. Is it clear that zero is not a valid SystemID? If you use a MAC address for SystemID, OUI 00-00-00 appears to be a valid OUI assigned to Xerox Corporation. If I was to make them into one PDU, I'd probably steal the high order bit of the Probe ID to indicate probe versus ack. > Do we need to update the existing registries to specify that AUTH and PAD > TLVs are permitted in these PDU types? I do not think that is necessary at this time. > 4.3 Protocols Supported > > MUST appear in > TRILL IIH PDUs and fragment zero LSP PDUs. > > ISO/IEC 10589 doesn't use the term "fragment zero", but uses the term "LSP > number zero". OK, I'm fine with that change in wording. > 6.1 Allocations From Existing Registries > > This document creates two new IS-IS PDUs, namely the MTU-PROBE-PDU, > and MTU-ACK-PDU, as described in Section 3. IANA will assign new PDU > types to these PDUs and reflect them in the PDU registry. [suggested > values below] > > MTU-PROBE-PDU Level-1 PDU Number: 23 > MTU-ACK-PDU Level-1 PDU Number: 28 > > Why are these PDUs described as Level-1? I have no idea. They are pretty clearly Level independent. Someone added this at some point and it just got copied from draft to draft under various draft titles and I failed to notice it when putting this draft together. > In any case whether or not they are restricted to level 1 is a matter for > the definition (or indeed title) of the PDU. > I don't see that this information needs to be included in the registry > if indeed such a registry exists... I don't think it does). Yes, IANA has already commented on this. Attached is suggested changed text for the draft I created in response to IANA's and Steward Bryant's comments. > This is the first time that a new PDU has been defined for IS-IS and all > current definitions are contained within > ISO/IEC 10589 itself. ALL other changes to IS-IS PDU definitions have > previously been restricted to TLVs (or sub-TLVs). > > It is partially for this reason that it seems gratuitous to specify TWO new > PDUs, where a single one would easily suffice. Well, we could guarantee that the IETF would only use one new PDU ever by having an "IETF PDU" and having a sub-PDU number or something. Would that be a good idea? It looks to me like there are 32 possible PDUs and the ISO standard only specifies 9. So it is not like we are about to run out. I continue to believe that having separate MTU-probe and MTU-ack PDUs is consistent with the existing IS-IS PDU granularity but would agree this is a matter of taste so I'm willing to change it to one PDU if that's what people want. > In any case note that PDU 23 was assigned by DECnet PhaseV to an XID PDU > type. > Although never specified in ISO/IEC 10589 itself, and probably never now > seen in the wild it would be as well to avoid any > chance of a potential clash and assign the MTU_PROBE-PDU a different number. I have no idea where the suggested PDU numbers 23 and 28 came from and I don't care what number or numbers are assigned, although I note that 23 and 28 are unused in the ISO standard. These numbers have just been copied forward from draft to draft under various draft names. > Nits: > > 2.2.3 Appointed Forwarders sub-TLV > > +----------------------------+ > | Appointee Nickname | (2 bytes) > +----------------------------+ > | RESV | Start.VLAN | (2 bytes) > +----------------------------+ > | RESV | End.VLAN | (2 bytes) > +----------------------------+ > > > It would be helpful if this diagram were formatted like the other fields, > indicating bit positions. OK. > 2.3.6 Interested VLANs and Spanning Tree Roots sub-TLV > > An INT-VLAN sub-TLV asserts that the information provided (multicast > router attachment, appointed forwarder status lost counter, and root > bridges), is the same for all VLANs in the range give. > > TYPO: s/give/given/ > > or perhaps better "specified". Sure, thanks. > 2.5 TRILL Neighbor TLV > > If an RBridge believes > it has no neighbors, its MUST send an empty TRILL Neighbor TLV, which > will have both the S and L bits on. > > TYPO: s/its/it/ Right, > 3. The MTU PDUs > > Again, use of the conventional form of diagram would be helpful. OK. > 4.2 Area Address > > Again, the standard diagram form would be helpful OK. Thanks again for the review, Donald --0016361e844633fb5404975b2fee Content-Type: text/plain; charset=US-ASCII; name="delta3.txt" Content-Disposition: attachment; filename="delta3.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ghokn17a0 U3VnZ2VzdGVkIENoYW5nZSBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBJQU5BIENvbnNpZGVyYXRp b25zIFNlY3Rpb24Kb2YgZHJhZnQtaWV0Zi1pc2lzLXRyaWxsLTAzOgoKT0xECiAgIFRoaXMgZG9j dW1lbnQgY3JlYXRlcyB0d28gbmV3IElTLUlTIFBEVXMsIG5hbWVseSB0aGUgTVRVLVBST0JFLVBE VSwKICAgYW5kIE1UVS1BQ0stUERVLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLiAgSUFOQSB3 aWxsIGFzc2lnbiBuZXcgUERVCiAgIHR5cGVzIHRvIHRoZXNlIFBEVXMgYW5kIHJlZmxlY3QgdGhl bSBpbiB0aGUgUERVIHJlZ2lzdHJ5LiBbc3VnZ2VzdGVkCiAgIHZhbHVlcyBiZWxvd10KCiAgICAg IE1UVS1QUk9CRS1QRFUgICAgIExldmVsLTEgUERVIE51bWJlcjogMjMKICAgICAgTVRVLUFDSy1Q RFUgICAgICAgTGV2ZWwtMSBQRFUgTnVtYmVyOiAyOAoKTkVXCiAgIFRoaXMgZG9jdW1lbnQgY3Jl YXRlcyB0d28gbmV3IElTLUlTIFBEVXMsIG5hbWVseSB0aGUgTVRVLVBST0JFLVBEVSwKICAgYW5k IE1UVS1BQ0stUERVLCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLiAgSUFOQSB3aWxsIGFzc2ln biBuZXcgUERVCiAgIHR5cGVzIHRvIHRoZXNlIFBEVXMgYW5kIHJlZmxlY3QgdGhlbSBpbiBhIG5l d2x5IGNyZWF0ZWQgUERVIHJlZ2lzdHJ5CiAgIChzZWUgQXBwZW5kaXggQSkuIFtzdWdnZXN0ZWQg UERVIHZhbHVlcyBiZWxvd10KCiAgICAgIE1UVS1QUk9CRS1QRFUgICAgIFBEVSBOdW1iZXI6IDIz CiAgICAgIE1UVS1BQ0stUERVICAgICAgIFBEVSBOdW1iZXI6IDI4CgpBTFNPIEFERAoKQXBwZW5k aXggQTogSW5pdGlhbCBJUy1JUyBQRFUgUmVnaXN0cnkKCiAgVGhlIGZvbGxvd2luZyBpcyB0aGUg c3VnZ2VzdGVkIGluaXRpYWwgSVMtSVMgUERVIFJlZ2lzdHJ5IGJlZm9yZQogIE1UVS1QUk9CRS1Q RFUgYW5kIE1UVS1BQ0stUERVLCB3aGljaCBzaG91bGQgYmUgYWRkZWQgd2l0aAogIFtSRkMtdG8t YmVdIGFzIFJFRkVSRU5DRToKClJlZ2lzdHJ5IE5hbWU6IElTLUlTIFBEVXMKUmVmZXJlbmNlOiBb UkZDLXRvLWJlXQpSZWdpc3RyYXRpb24gUHJvY2VkdXJlczogSUVURiBSZXZpZXcKCiAgIE1ORU1P TklDICAgICAgICAgICAgIFBEVSMgICAgIFJFRkVSRU5DRQoKICAgVW5hc3NpZ25lZCAgICAgICAg ICAgIDAtMTQKICAgTDEtTEFOLUhFTExPLVBEVSAgICAgIDE1ICAgICAgW0lTTy0xMDU4OV0KICAg TDItTEFOLUhFTExPLVBEVSAgICAgIDE2ICAgICAgW0lTUC0xMDU4OV0KICAgUDJQLUhFTExPLVBE VSAgICAgICAgIDE3ICAgICAgW0lTUC0xMDU4OV0KICAgTDEtTFNQLVBEVSAgICAgICAgICAgIDE4 ICAgICAgW0lTUC0xMDU4OV0KICAgVW5hc3NpZ25lZCAgICAgICAgICAgIDE5CiAgIEwyLUxTUC1Q RFUgICAgICAgICAgICAyMCAgICAgIFtJU1AtMTA1ODldCiAgIFVuYXNzaWduZWQgICAgICAgICAg ICAyMS0yMwogICBMMS1DU05QLVBEVSAgICAgICAgICAgMjQgICAgICBbSVNQLTEwNTg5XQogICBM Mi1DU05QLVBEVSAgICAgICAgICAgMjUgICAgICBbSVNQLTEwNTg5XQogICBMMS1QU05QLVBEVSAg ICAgICAgICAgMjYgICAgICBbSVNQLTEwNTg5XQogICBMMi1QU05QLVBEVSAgICAgICAgICAgMjcg ICAgICBbSVNQLTEwNTg5XQogICBVbmFzc2lnbmVkICAgICAgICAgICAgMjgtMzE= --0016361e844633fb5404975b2fee-- From mshand@cisco.com Tue Dec 14 05:40:42 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 CF94C28C0EE for ; Tue, 14 Dec 2010 05:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.399 X-Spam-Level: X-Spam-Status: No, score=-11.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, J_CHICKENPOX_54=0.6, 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 yQ6YIwxWZq1D for ; Tue, 14 Dec 2010 05:40:41 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 395FD3A6DAA for ; Tue, 14 Dec 2010 05:40:40 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgEAG4DB02Q/khLgWdsb2JhbACkChYBFiIppiibSYVKBIp6gxU X-IronPort-AV: E=Sophos;i="4.59,342,1288569600"; d="scan'208";a="71611823" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 14 Dec 2010 13:42:19 +0000 Received: from [64.103.65.107] (dhcp-gpk02-vlan300-64-103-65-107.cisco.com [64.103.65.107]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBEDgJXk026558; Tue, 14 Dec 2010 13:42:19 GMT Message-ID: <4D07743B.3080402@cisco.com> Date: Tue, 14 Dec 2010 13:42:19 +0000 From: mike shand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Donald Eastlake References: <4D023E14.7030009@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-isis-trill.all@tools.ietf.org, Erik Nordmark , rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-trill-03.txt 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: Tue, 14 Dec 2010 13:40:42 -0000 Donald, See my responses below. Mike On 14/12/2010 09:09, Donald Eastlake wrote: > Hi Mike, > > Thanks for this detailed review. See responses below. > > On Fri, Dec 10, 2010 at 9:49 AM, mike shand wrote: >> 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-isis-trill-03.txt >> Reviewer: Mike Shand >> Review Date: 2010-12-06 >> IETF LC End Date: 2010-12-14 >> Intended Status: proposed standard >> >> Summary: >> >> I have some minor concerns about this document that I think should be >> resolved before publication. >> >> Comments: >> >> The document is well written and structured, and generally conforms to the >> conventional definition of IS-IS TLVs. >> >> Major Issues: >> >> No major issues found. >> >> Minor Issues: >> >> 2.2.1 The Special VLANs and Flags sub-TLV >> >> AF, AC, VM, BY, and TR: >> >> In previous reviews of IS-IS documents it has been suggested that bits such >> as these, as well as being identified by a letter or letters, should also >> have a descriptive name. While such a name could be inferred by the >> descriptive text provided, no unique nomenclature is called out here. >> >> Personally, I don't believe this to be a problem. > I am uncertain as to whether this needs to be changed. It would be > relatively easy to add a descriptive word or two or three for each of > these bits if desired. > >> 2.2.2 Enabled-VLANs sub-TLV >> >> If this sub-TLV occurs more than once in a Hello, the set of enabled >> VLANs is the union of the VLANs indicated by the Enabled-VLAN sub- >> TLVs. >> >> This assumes that the start VLAN IDs of the multiple sub-TLVs are correctly >> aligned so that there is no overlap between the bit maps. In the unlikely >> event that this is not the case, what is the correct action? >> >> a) ignore the IIH because it is malformed? >> >> b) only do so if there is a VLAN which has the bit set in one sub-TLV and >> clear in another? >> >> c) form the union of the SET bits, ignoring the unset bits? >> >> The intent is probably (c), but this is not unambiguously clear. > Your interpretation of the intent is correct and the above wording > seems reasonably clear to me. Each sub-TLV identifies a set of > VLANs. If there are more than one of the sub-TLVs, you take the union > of these sets. How about if I add a few words so it reads as follows: > > "If this sub-TLV occurs more than once in a Hello, the set of > enabled VLANs is the union of the sets of VLANs indicated by each > the Enabled-VLAN sub-TLVs in the Hello." > Yes, how about "If this sub-TLV occurs more than once in a Hello, the set of enabled VLANs is the union of the sets of enabled VLANs indicated by each of the Enabled-VLAN sub-TLVs in the Hello." >> 2.3.4 The Tree Identifiers Sub-TLV >> >> This is set to 1 for >> the first sub-TLV. Subsequent sub-TLVs will have the starting >> number of the ordered list. >> >> I assume "first" here does NOT imply that there is any required ordering for >> the presentation of the sub-TLVs within the PDU. > Yes, you assume correctly. Perhaps the following wording would be an > improvement: > > "This is set to 1 for the sub-TLV containing the first list. Other > Tree-Identifiers Sub-TLVs will have the number of the starting > list they contain." > OK >> 2.3.6 Interested VLANs and Spanning Tree Roots sub-TLV >> >> Appointed Forwarder Status Lost Counter: >> >> It is >> initialized to zero at an IS when the LSP sequence number is >> initialized. >> >> Since the sequence numbers of individual LSPs are independent, it would be >> possible for a "new" LSP to be generated >> to carry additional information. Such an LSP would have its LSP sequence >> number "initialised". >> It is not clear whether this text is supposed to relate to the >> initialisation of the sequence number of the LSP carrying this sub-TLV >> or whether it refers to the initialization of the sequence number of the >> zeroth LSP. The latter seems to make more sense. > Yes, I agree. "the LSP" should be replaced by "the zeroth LSP". OK >> 2.3.7 The VLAN Group sub-TLV >> >> Length: 4 + 2*n, where n may be 0. >> >> n is not specified (as it is in other cases of this form of description). >> >> Presumably it is the number of secondary VLAN ID fields" > Yes, I suggest replacement wording: > > "Length: 4 + 2*n, where n is the number of secondary VLAN ID > fields, which may be zero." > OK >> There is no textual description of the "more secondary VLAN IDs field". >> While it is fairly obvious what this is intended to be, it would be clearer >> and more consistent if this were described. > OK, how about adding > > "o more Secondary VLAN IDs: zero or more byte pairs with the top > four bits an RESV field and the low 12 bits a VLAN-ID." > OK >> 2.5 TRILL Neighbor TLV >> >> S: Smallest flag. If this bit is a one, then the list of >> neighbors includes the neighbor with the smallest MAC address. >> >> Is it necessary to define what is meant by "smallest" and "largest" when >> applied to MAC addresses? > I'd be happy to add at the end of the entries of "S" and "L" the text > "considered as an unsigned integer". > OK >> RESV: These seven bits are reserved for future use and MUST be set >> to zero on transmission and ignored on receipt. >> >> Elsewhere, such bits are simply described as being reserved, without any >> mention of future use. >> Are these bits specifically required to be called out as different from >> other reserved bits? >> >> Also, elsewhere, the phrase "MUST be sent as zero" is used rather than "MUST >> be set to zero on transmission". >> >> Although there is "obviously" no intent that any difference is implied, the >> use of gratuitously different phraseology is best avoided. > I agree. I'm fine with changing this to "These seven bits are reserved > and MUST be sent as zero and ignored on receipt." OK >> in a TRILL Neighbor TLV with the L flag zero will also appear as a >> >> Should that "will" be a "MUST"? And similarly for S flag > That would probably be an improvement. OK >> If an RBridge believes >> it has no neighbors, its MUST send an empty TRILL Neighbor TLV, which >> will have both the S and L bits on. >> >> Rather than saying "empty", which implies no content at all, would it be >> clearer to say >> " a TRILL Neighbor TLV containing no neighbor records"? > How about replacing "an empty TRILL Neighbor TLV" with "a TRILL > neighbor TLV with an empty list of neighbor RECORDs". OK >> It would also help to specify in >> >> Length: 1 + 9*n, where n is the number of neighbor records. >> >> that n can take the value zero, as has been done elsewhere... since the >> absence of that statement here could imply that it is NOT permitted to be >> zero. > OK, easy to add "which may be zero" at the end of that entry. OK >> 3. The MTU PDUs >> >> I have previously commented on the unnecessary use of two PDU type code >> points for the probe and ack PDUs. Indeed the two can be distinguished by >> the probe having a zero value for the ACK source ID, and the ACK having a >> non-zero value. > Well, actually what you said was > > "Are two seperate PDUs really required. Would not a single PDU type > with a flag to indicate probe or ACK suffice?" > > although I took that question to mean that you would prefer a single > MTU PDU. I responded with > > "Yes, you could use a single PDU type but I think they way they are > currently specified fits somewhat better into the pattern of PDU > definitions for IS-IS... Does anyone else out there have an opinion on > this?" > > Since no one else spoke up, I left it unchanged. > > This seems to be a matter of taste. Why are the L1 and L2 variants of > existing IS-IS PDUs different PDUs? That could easily be encoded > elsewhere in the PDUs. You can push the bits around in various > ways. But I don't care that much about this. > > Is it clear that zero is not a valid SystemID? If you use a MAC > address for SystemID, OUI 00-00-00 appears to be a valid OUI assigned > to Xerox Corporation. If I was to make them into one PDU, I'd probably > steal the high order bit of the Probe ID to indicate probe versus ack. > Clearly it works either way, so if nobody else cares I won't press it. >> Do we need to update the existing registries to specify that AUTH and PAD >> TLVs are permitted in these PDU types? > I do not think that is necessary at this time. I do think that needs to be done at some point. >> 4.3 Protocols Supported >> >> MUST appear in >> TRILL IIH PDUs and fragment zero LSP PDUs. >> >> ISO/IEC 10589 doesn't use the term "fragment zero", but uses the term "LSP >> number zero". > OK, I'm fine with that change in wording. OK >> 6.1 Allocations From Existing Registries >> >> This document creates two new IS-IS PDUs, namely the MTU-PROBE-PDU, >> and MTU-ACK-PDU, as described in Section 3. IANA will assign new PDU >> types to these PDUs and reflect them in the PDU registry. [suggested >> values below] >> >> MTU-PROBE-PDU Level-1 PDU Number: 23 >> MTU-ACK-PDU Level-1 PDU Number: 28 >> >> Why are these PDUs described as Level-1? > I have no idea. They are pretty clearly Level independent. Someone > added this at some point and it just got copied from draft to draft > under various draft titles and I failed to notice it when putting this > draft together. > >> In any case whether or not they are restricted to level 1 is a matter for >> the definition (or indeed title) of the PDU. >> I don't see that this information needs to be included in the registry >> if indeed such a registry exists... I don't think it does). > Yes, IANA has already commented on this. Attached is suggested changed > text for the draft I created in response to IANA's and Steward Bryant's > comments. > >> This is the first time that a new PDU has been defined for IS-IS and all >> current definitions are contained within >> ISO/IEC 10589 itself. ALL other changes to IS-IS PDU definitions have >> previously been restricted to TLVs (or sub-TLVs). >> >> It is partially for this reason that it seems gratuitous to specify TWO new >> PDUs, where a single one would easily suffice. > Well, we could guarantee that the IETF would only use one new PDU ever > by having an "IETF PDU" and having a sub-PDU number or > something. Would that be a good idea? No, I don't think that is necessary. We can always do that later if we do seem to be running out. In fact the restriction to 32 is not necessary. It was only for consistency with the format of an ISO 8473 data PDU, where the top 3 bits were "segmentation permitted", More segments", and "Error report requested". Since they use different NLPIs there is no actual confusion, so those 3 bits are spare. They are of course currently defined as "MUST be ignored on receipt". In any case, I see no need to take any action now. Mike > It looks to me like there are 32 possible PDUs and the ISO standard > only specifies 9. So it is not like we are about to run out. I > continue to believe that having separate MTU-probe and MTU-ack PDUs is > consistent with the existing IS-IS PDU granularity but would agree > this is a matter of taste so I'm willing to change it to one PDU if > that's what people want. > >> In any case note that PDU 23 was assigned by DECnet PhaseV to an XID PDU >> type. >> Although never specified in ISO/IEC 10589 itself, and probably never now >> seen in the wild it would be as well to avoid any >> chance of a potential clash and assign the MTU_PROBE-PDU a different number. > I have no idea where the suggested PDU numbers 23 and 28 came from and > I don't care what number or numbers are assigned, although I note that > 23 and 28 are unused in the ISO standard. These numbers have just been > copied forward from draft to draft under various draft names. > >> Nits: >> >> 2.2.3 Appointed Forwarders sub-TLV >> >> +----------------------------+ >> | Appointee Nickname | (2 bytes) >> +----------------------------+ >> | RESV | Start.VLAN | (2 bytes) >> +----------------------------+ >> | RESV | End.VLAN | (2 bytes) >> +----------------------------+ >> >> >> It would be helpful if this diagram were formatted like the other fields, >> indicating bit positions. > OK. > >> 2.3.6 Interested VLANs and Spanning Tree Roots sub-TLV >> >> An INT-VLAN sub-TLV asserts that the information provided (multicast >> router attachment, appointed forwarder status lost counter, and root >> bridges), is the same for all VLANs in the range give. >> >> TYPO: s/give/given/ >> >> or perhaps better "specified". > Sure, thanks. > >> 2.5 TRILL Neighbor TLV >> >> If an RBridge believes >> it has no neighbors, its MUST send an empty TRILL Neighbor TLV, which >> will have both the S and L bits on. >> >> TYPO: s/its/it/ > Right, > >> 3. The MTU PDUs >> >> Again, use of the conventional form of diagram would be helpful. > OK. > >> 4.2 Area Address >> >> Again, the standard diagram form would be helpful > OK. > > Thanks again for the review, > Donald From julien.meuric@orange-ftgroup.com Wed Dec 22 08:01:34 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 679E43A6ACA for ; Wed, 22 Dec 2010 08:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.174 X-Spam-Level: X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, 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 Fbcuu+Vtglgi for ; Wed, 22 Dec 2010 08:01:33 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 31A443A6A4B for ; Wed, 22 Dec 2010 08:01:33 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 60B528B8002; Wed, 22 Dec 2010 17:04:27 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 58EB58B8001; Wed, 22 Dec 2010 17:04:27 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 17:03:30 +0100 Received: from [250.127.0.0] ([10.42.12.26]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 17:03:30 +0100 Message-ID: <4D12214F.5080302@orange-ftgroup.com> Date: Wed, 22 Dec 2010 17:03:27 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Dec 2010 16:03:30.0247 (UTC) FILETIME=[C6AAE570:01CBA1F1] Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-uni-nni.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-uni-nni-02 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, 22 Dec 2010 16:01:34 -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-mpls-tp-uni-nni-02.txt Reviewer: Julien Meuric Review Date: 2010-12-22 IETF LC End Date: 2010-12-23 Intended Status: Informational *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments:* This document focuses on a specific topic within a limited scope. Nevertheless, it is a patch to RFC 5921 and thus requires reading some parts of the latter (sections 3.4.2 and 3.4.3 mainly), which is detrimental to its readability if considered alone. *Major Issues:* No major issues found. *Minor Issues:* - It is not obvious why P nodes are not mentioned when tackling the NNI. It requires to look for an answer in RFC 5921, which lies in the last paragraph of section 3.4.2. It may be worth considering introducing that paragraph in this document (in section 1 for instance). - Linked to the above, the exact scope of the document is defined a bit late: the fact that UNI and NNI are "Transport Service Interfaces" is not stated before section 1.1, while one would expect to be aware of this information from the abstract and introduction. - The phrase "Transport Service Instance" is only mentioned in section 3: defining it in section 1.2 may improve the readability; "TSI" is only used in drawings: is it necessary to use the acronym, especially in this context where the phrase "Transport Service Interface" is also used? - The term "attachment circuit" is mentioned in section 2, but it does not appear on figures, nor is defined in the I-D. Definition and/or illustration would be welcome. - The acronyms UNI-C and UNI-N are used for the first time in section 1.1, without expansion/definition and before the terminology section. They should either be removed from there, or be expanded/defined at first use. - The acronym UNI-N is defined in section 1.2 but not actually expanded, thus leading to wonder why "-N". I agree that "PE side" is more meaningful than "network", but adding expansion while keeping definition may be considered. - Figure 1: it looks like "Native service control" is defined as native service control and/or GMPLS, where I understand that GMPLS can be an option even if not native. Would not it be clearer to write "Service control" and keep current definition (native and/or GMPLS)? *Nits:* Abstract s/subjet/subject/ ----- Section 1.2 s/PE Side/PE side/ ----- Section 2 & 3 - either: s/User-Network/User-to-Network/ in section 2 + s/NNI is illustrated/Network-to-Network Interface (NNI) is illustrated/ in section 3 - or: s/User-Network Interface (UNI)/UNI/ in section 2 ----- Regards and merry Christmas, Julien From takeda.tomonori@lab.ntt.co.jp Mon Dec 27 18:52:22 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 81E493A690B for ; Mon, 27 Dec 2010 18:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 ViuX57NYyDXw for ; Mon, 27 Dec 2010 18:52:21 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 89B4C3A6909 for ; Mon, 27 Dec 2010 18:52:21 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id oBS2sPB7026386; Tue, 28 Dec 2010 11:54:25 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 2E7E365F1; Tue, 28 Dec 2010 11:54:25 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 2878265EB; Tue, 28 Dec 2010 11:54:25 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.55]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id oBS2rxgq024474; Tue, 28 Dec 2010 11:54:25 +0900 Message-ID: <4D19502A.3070801@lab.ntt.co.jp> Date: Tue, 28 Dec 2010 11:49:14 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-ccamp-gmpls-g-694-lambda-labels.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt 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: Tue, 28 Dec 2010 02:52:22 -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-ccamp-gmpls-g-694-lambda-labels-10.txt Reviewer: Tomonori Takeda Review Date: 28 December 2010 IETF LC End Date: Unknown Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document is well written and easy to read. I have several nits and one minor question. Major Issues: No major issues found. Minor Issues: Section 3.2 (and Section 3.3): Text on the identifier field is a bit hard to understand. - In the abstract, it says that the label format defined in this document can be used in GMPLS signaling and routing protocols. However, it seems that text from Section 3.2 (3) Identifier applies to signaling only. Does it mean that Identifier field is set to zero when used in routing, and set to a value according to Section 3.2 (3) Identifier when used in signaling? - I can not simply understand text regarding use of identifier in a label ERO subobject. Does it mean that when non-zero value is assigned to the identifier field in a label ERO subobject, the referenced node MUST use the assigned value for the identifier field in the corresponding LSP related messages? (e.g., the referenced node MUST use the assigned value for the identifier field in a Label object in Resv message?) Nits: Section 3.1, 3rd paragraph: s/standardize/standardized -- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 From danli@huawei.com Tue Dec 28 17:41:00 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 EE9043A69B7 for ; Tue, 28 Dec 2010 17:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 j4yshhfbcd2F for ; Tue, 28 Dec 2010 17:40:58 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id D29813A6979 for ; Tue, 28 Dec 2010 17:40:58 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LE6008Z823RA3@usaga03-in.huawei.com> for rtg-dir@ietf.org; Tue, 28 Dec 2010 19:43:03 -0600 (CST) Received: from [192.168.10.166] ([219.142.19.254]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0LE600KEO23KJO@usaga03-in.huawei.com> for rtg-dir@ietf.org; Tue, 28 Dec 2010 19:43:03 -0600 (CST) Date: Wed, 29 Dec 2010 09:42:56 +0800 From: Dan Li In-reply-to: <4D19502A.3070801@lab.ntt.co.jp> To: Tomonori TAKEDA Message-id: <6C34185B-A4A7-4E49-87FA-AC77948E1BD2@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.1082) Content-type: text/plain; charset=GB2312 Content-transfer-encoding: quoted-printable References: <4D19502A.3070801@lab.ntt.co.jp> Cc: rtg-dir@ietf.org, draft-ietf-ccamp-gmpls-g-694-lambda-labels.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt 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, 29 Dec 2010 01:41:00 -0000 Hi Tomonori, Thanks for the careful review! Please see below. Thanks, Dan =D4=DA 2010-12-28=A3=AC=C9=CF=CE=E710:49=A3=AC Tomonori TAKEDA =D0=B4=B5=C0= =A3=BA > Hello, >=20 > 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 >=20 > 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. >=20 > Document: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt > Reviewer: Tomonori Takeda > Review Date: 28 December 2010 > IETF LC End Date: Unknown > Intended Status: Standards Track >=20 >=20 > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. >=20 >=20 > Comments: > This document is well written and easy to read. I have several nits = and > one minor question. >=20 >=20 > Major Issues: > No major issues found. >=20 >=20 > Minor Issues: >=20 > Section 3.2 (and Section 3.3): > Text on the identifier field is a bit hard to understand. > - In the abstract, it says that the label format defined in this > document can be used in GMPLS signaling and routing protocols. > However, it seems that text from Section 3.2 (3) Identifier applies = to > signaling only. Does it mean that Identifier field is set to zero = when > used in routing, and set to a value according to Section 3.2 (3) > Identifier when used in signaling? [dan] What I mean is in routing process, the lambda label will be = presented, for example, lambda labels will be used to identify a lambda = link. The identifier field in lambda label format is used to distinguish = different lasers (in one node) when they can transmit the same frequency = lambda. So the identifier itself may not be used in routing. But I think = here we still can say the label format can be used in Signaling and = Routing protocols. > - I can not simply understand text regarding use of identifier in a > label ERO subobject. Does it mean that when non-zero value is = assigned > to the identifier field in a label ERO subobject, the referenced node > MUST use the assigned value for the identifier field in the > corresponding LSP related messages? (e.g., the referenced node MUST > use the assigned value for the identifier field in a Label object in > Resv message?) [dan] Yes, you're correct! >=20 >=20 > Nits: >=20 > Section 3.1, 3rd paragraph: > s/standardize/standardized [dan] ok, draft will be updated. >=20 > --=20 > Tomonori TAKEDA > NTT Network Service Systems Lab. > Phone: +81-422-59-7434 >=20 From takeda.tomonori@lab.ntt.co.jp Wed Dec 29 04:28:55 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 49A223A691E for ; Wed, 29 Dec 2010 04:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 QIPDc1VXbYOT for ; Wed, 29 Dec 2010 04:28:53 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id 7718B3A68D8 for ; Wed, 29 Dec 2010 04:28:53 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id oBTCUpvB018438; Wed, 29 Dec 2010 21:30:51 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 12AE36D33; Wed, 29 Dec 2010 21:30:51 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2-mgr.m.ecl.ntt.co.jp [129.60.144.42]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 05B396D31; Wed, 29 Dec 2010 21:30:51 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id oBTCUo9U008851; Wed, 29 Dec 2010 21:30:50 +0900 Message-Id: <201012291230.oBTCUo9U008851@imail2.m.ecl.ntt.co.jp> To: danli@huawei.com From: Tomonori TAKEDA Date: Wed, 29 Dec 2010 21:30:50 +0900 In-Reply-To: <6C34185B-A4A7-4E49-87FA-AC77948E1BD2@huawei.com> X-Mailer: WebMail V3.7 PL3 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Cc: rtg-dir@ietf.org, draft-ietf-ccamp-gmpls-g-694-lambda-labels.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt 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, 29 Dec 2010 12:28:55 -0000 Hi Dan, Thanks for your reply. Please see in-line. Tomonori > Hi Tomonori, > > Thanks for the careful review! > > Please see below. > > Thanks, > > Dan > > 在 2010-12-28，上午10:49， Tomonori TAKEDA 写道： > > > 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-ccamp-gmpls-g-694-lambda-labels-10.txt > > Reviewer: Tomonori Takeda > > Review Date: 28 December 2010 > > IETF LC End Date: Unknown > > Intended Status: Standards Track > > > > > > Summary: > > I have some minor concerns about this document that I think should be > > resolved before publication. > > > > > > Comments: > > This document is well written and easy to read. I have several nits and > > one minor question. > > > > > > Major Issues: > > No major issues found. > > > > > > Minor Issues: > > > > Section 3.2 (and Section 3.3): > > Text on the identifier field is a bit hard to understand. > > - In the abstract, it says that the label format defined in this > > document can be used in GMPLS signaling and routing protocols. > > However, it seems that text from Section 3.2 (3) Identifier applies to > > signaling only. Does it mean that Identifier field is set to zero when > > used in routing, and set to a value according to Section 3.2 (3) > > Identifier when used in signaling? > [dan] What I mean is in routing process, the lambda label will be presented, for example, lambda labels will be used to identify a lambda link. The identifier field in lambda label format is used to distinguish different lasers (in one node) when they can transmit the same frequency lambda. So the identifier itself may not be used in routing. But I think here we still can say the label format can be used in Signaling and Routing protocols. Thanks for clarification. It makes sense to me that lambda labels can be used to in singaling and routing protocols (also in PCEP). What I was not sure is about the use of the identifier field when used in routing. If the document specifies the use of identifier field for signaling but not for routing, I am fine with the current text. (Otherwise, I think text needs to be added for the use of the identifier field in routing.) > > > - I can not simply understand text regarding use of identifier in a > > label ERO subobject. Does it mean that when non-zero value is assigned > > to the identifier field in a label ERO subobject, the referenced node > > MUST use the assigned value for the identifier field in the > > corresponding LSP related messages? (e.g., the referenced node MUST > > use the assigned value for the identifier field in a Label object in > > Resv message?) > [dan] Yes, you're correct! Thanks for clarification. I think it would be good to add some text explaining the behavior when non-zero value is assigned to the identifier filed in a label ERO subobject (just for completeness). > > > > Nits: > > > > Section 3.1, 3rd paragraph: > > s/standardize/standardized > [dan] ok, draft will be updated. From danli@huawei.com Thu Dec 30 23:16: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 DD5993A68DD for ; Thu, 30 Dec 2010 23:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.828 X-Spam-Level: X-Spam-Status: No, score=-3.828 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.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 ERpk-zrrAmsr for ; Thu, 30 Dec 2010 23:16:06 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8299B3A68D9 for ; Thu, 30 Dec 2010 23:16:06 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEA003CM6XZGV@szxga03-in.huawei.com> for rtg-dir@ietf.org; Fri, 31 Dec 2010 15:17:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEA00FNI6XZGJ@szxga03-in.huawei.com> for rtg-dir@ietf.org; Fri, 31 Dec 2010 15:17:59 +0800 (CST) Received: from l00037133 ([10.70.77.125]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEA005PV6XYA4@szxml04-in.huawei.com> for rtg-dir@ietf.org; Fri, 31 Dec 2010 15:17:59 +0800 (CST) Date: Fri, 31 Dec 2010 15:17:58 +0800 From: Dan Li To: Tomonori TAKEDA Message-id: <011d01cba8ba$da07f890$7d4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <201012291230.oBTCUo9U008851@imail2.m.ecl.ntt.co.jp> Cc: rtg-dir@ietf.org, draft-ietf-ccamp-gmpls-g-694-lambda-labels.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt 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: Fri, 31 Dec 2010 07:16:08 -0000 Hi Tomonori, Thanks for your comments! I would like to update the description of Identifier in section 3.2 and 3.3. OLD (3) Identifier: 9 bits The identifier field is a per-node assigned and scoped value. This field MAY change on a per-hop basis. In all cases but one, a node MAY select any value, including zero (0), for this field. Once selected, the value MUST NOT change until the LSP is torn down and the value MUST be used in all LSP related messages, e.g., in Resv messages and label RRO subobjects. The sole special case occurs when this label format is used in a label ERO subobject. In this case, the special value of zero (0) means that the referenced node MAY assign any Identifier field value, including zero (0), when establishing the corresponding LSP. NEW (3) Identifier: 9 bits The identifier field in lambda label format is used to distinguish different lasers (in one node) when they can transmit the same frequency lambda. The identifier field is a per-node assigned and scoped value. This field MAY change on a per-hop basis. In all cases but one, a node MAY select any value, including zero (0), for this field. Once selected, the value MUST NOT change until the LSP is torn down and the value MUST be used in all LSP related messages, e.g., in Resv messages and label RRO subobjects. The sole special case occurs when this label format is used in a label ERO subobject. In this case, the special value of zero (0) means that the referenced node MAY assign any Identifier field value, including zero (0), when establishing the corresponding LSP. When non-zero value is assigned to the identifier field in a label ERO subobject, the referenced node MUST use the assigned value for the identifier field in the corresponding LSP related messages. Is this ok? Thanks, Dan ----- Original Message ----- From: "Tomonori TAKEDA" To: Cc: ; ; Sent: Wednesday, December 29, 2010 8:30 PM Subject: Re: RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt > Hi Dan, > > Thanks for your reply. > > Please see in-line. > > Tomonori > >> Hi Tomonori, >> >> Thanks for the careful review! >> >> Please see below. >> >> Thanks, >> >> Dan >> >> 在 2010-12-28，上午10:49， Tomonori TAKEDA 写道： >> >> > 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-ccamp-gmpls-g-694-lambda-labels-10.txt >> > Reviewer: Tomonori Takeda >> > Review Date: 28 December 2010 >> > IETF LC End Date: Unknown >> > Intended Status: Standards Track >> > >> > >> > Summary: >> > I have some minor concerns about this document that I think should be >> > resolved before publication. >> > >> > >> > Comments: >> > This document is well written and easy to read. I have several nits and >> > one minor question. >> > >> > >> > Major Issues: >> > No major issues found. >> > >> > >> > Minor Issues: >> > >> > Section 3.2 (and Section 3.3): >> > Text on the identifier field is a bit hard to understand. >> > - In the abstract, it says that the label format defined in this >> > document can be used in GMPLS signaling and routing protocols. >> > However, it seems that text from Section 3.2 (3) Identifier applies to >> > signaling only. Does it mean that Identifier field is set to zero when >> > used in routing, and set to a value according to Section 3.2 (3) >> > Identifier when used in signaling? >> [dan] What I mean is in routing process, the lambda label will be presented, for example, lambda labels will be used to identify a lambda link. The identifier field in lambda label format is used to distinguish different lasers (in one node) when they can transmit the same frequency lambda. So the identifier itself may not be used in routing. But I think here we still can say the label format can be used in Signaling and Routing protocols. > > Thanks for clarification. > > It makes sense to me that lambda labels can be used to in singaling and routing protocols (also in PCEP). > > What I was not sure is about the use of the identifier field when used in routing. If the document specifies the use of identifier field for signaling but not for routing, I am fine with the current text. (Otherwise, I think text needs to be added for the use of the identifier field in routing.) > >> >> > - I can not simply understand text regarding use of identifier in a >> > label ERO subobject. Does it mean that when non-zero value is assigned >> > to the identifier field in a label ERO subobject, the referenced node >> > MUST use the assigned value for the identifier field in the >> > corresponding LSP related messages? (e.g., the referenced node MUST >> > use the assigned value for the identifier field in a Label object in >> > Resv message?) >> [dan] Yes, you're correct! > > Thanks for clarification. > > I think it would be good to add some text explaining the behavior when non-zero value is assigned to the identifier filed in a label ERO subobject (just for completeness). > >> > >> > Nits: >> > >> > Section 3.1, 3rd paragraph: >> > s/standardize/standardized >> [dan] ok, draft will be updated. > From takeda.tomonori@lab.ntt.co.jp Fri Dec 31 07:02:04 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 AA8423A6931 for ; Fri, 31 Dec 2010 07:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 pu7tuVFf0zRT for ; Fri, 31 Dec 2010 07:02:04 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id C27373A6923 for ; Fri, 31 Dec 2010 07:02:03 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id oBVF3p53019910; Sat, 1 Jan 2011 00:03:51 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id E5FBB65F9; Sat, 1 Jan 2011 00:03:50 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id E089865EB; Sat, 1 Jan 2011 00:03:50 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id oBVF3oAA008419; Sat, 1 Jan 2011 00:03:50 +0900 Message-Id: <201012311503.oBVF3oAA008419@imail2.m.ecl.ntt.co.jp> To: danli@huawei.com From: Tomonori TAKEDA Date: Sat, 01 Jan 2011 00:03:50 +0900 In-Reply-To: <011d01cba8ba$da07f890$7d4d460a@china.huawei.com> X-Mailer: WebMail V3.7 PL3 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: rtg-dir@ietf.org, draft-ietf-ccamp-gmpls-g-694-lambda-labels.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt 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: Fri, 31 Dec 2010 15:02:04 -0000 Hi Dan, Thanks for your reply. The proposed text is good for me. Tomonori > Hi Tomonori, > > Thanks for your comments! I would like to update the description of Identifier in section 3.2 and 3.3. > > OLD > (3) Identifier: 9 bits > > The identifier field is a per-node assigned and scoped value. This > field MAY change on a per-hop basis. In all cases but one, a node MAY > select any value, including zero (0), for this field. Once selected, > the value MUST NOT change until the LSP is torn down and the value > MUST be used in all LSP related messages, e.g., in Resv messages and > label RRO subobjects. The sole special case occurs when this label > format is used in a label ERO subobject. In this case, the special > value of zero (0) means that the referenced node MAY assign any > Identifier field value, including zero (0), when establishing the > corresponding LSP. > NEW > (3) Identifier: 9 bits > > The identifier field in lambda label format is used to distinguish different > lasers (in one node) when they can transmit the same frequency lambda. > The identifier field is a per-node assigned and scoped value. This > field MAY change on a per-hop basis. In all cases but one, a node MAY > select any value, including zero (0), for this field. Once selected, > the value MUST NOT change until the LSP is torn down and the value > MUST be used in all LSP related messages, e.g., in Resv messages and > label RRO subobjects. The sole special case occurs when this label > format is used in a label ERO subobject. In this case, the special > value of zero (0) means that the referenced node MAY assign any > Identifier field value, including zero (0), when establishing the > corresponding LSP. When non-zero value is assigned to the identifier > field in a label ERO subobject, the referenced node MUST use the > assigned value for the identifier field in the corresponding LSP related > messages. > > Is this ok? > > Thanks, > > Dan >