From Adrian.Farrel@huawei.com Sun May 8 07:15:49 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB46E071C for ; Sun, 8 May 2011 07:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.774 X-Spam-Level: X-Spam-Status: No, score=-103.774 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPgufwkliIQT for ; Sun, 8 May 2011 07:15:49 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2C7E070F for ; Sun, 8 May 2011 07:15:49 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKV00BAWRMB3G@usaga01-in.huawei.com> for rtg-dir@ietf.org; Sun, 08 May 2011 09:15:47 -0500 (CDT) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKV00LR2RM9B6@usaga01-in.huawei.com> for rtg-dir@ietf.org; Sun, 08 May 2011 09:15:47 -0500 (CDT) Date: Sun, 08 May 2011 15:15:44 +0100 From: Adrian Farrel In-reply-to: <4D5EE6A5.9040305@labn.net> To: 'Lou Berger' , rtg-ads@tools.ietf.org Message-id: <009a01cc0d8a$6caa2680$45fe7380$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQK0xy/f4h2v3ZGewyx4D7Ds7N7MIpKxZwrQ References: <4D5EE6A5.9040305@labn.net> Cc: rtg-dir@ietf.org, draft-ietf-pce-inter-layer-req@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-inter-layer-req-15 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 14:15:50 -0000 Several years passed; the snow settled into great drifts and all life vanished from the courtyard of the great palace... in line... > - General comment/question: In reading the document I found a number of > places where the text seemed to imply that the PCC was always the > layer/region boundary, which is inconsistent with RFC5623. Is this > intentional? > > Examples from the document include: > 257 An ingress LSR for the higher-layer LSP, or a PCC, needs to > 258 know whether triggered signaling is required or not. > > While this is true for the boundary LSR, I'm not sure how it fits into > this document. Isn't such determination made by the boundary LSR per > RFCs 4206 and 6001? If so, the sentence is out of scope of this > document. If you do keep it, I suggest replacing " An ingress LSR for > the higher-layer LSP, or a PCC," with something along the lines of "A > layer boundary LSR". I think you misread this one. The ingress LSR for the higher-layer LSP is unlikely to be the boundary LSR. That would more likely be the ingress LSR for the lower-layer LSP. But the case where it is, is caught by your next comment. > 275 Also note that an ingress LSR may be present in multiple layers. > > Is "ingress LSR" mean "a layer boundary LSR", or "the PCC LSR"? Hmm, yes, both, or either. Clarifying text. > 299 3.1.4. Adaptation Capability > > 301 It MUST be possible for the path computation request to indicate the > 302 desired adaptation function at the end points of the lower-layer LSP > 303 that is being computed. This will be particularly important where the > 304 ingress and egress LSR participate in more than one layer network but > 305 may not be capable of all associated adaptations. > > This section cases me concern a number of levels. The first is that > "adaptation function" is not defined in this document, nor is it used in > the other MRN documents. Furthermore, is it reasonable to have > adaptation indicated by a PCC when the layer/region boundary is at an > intermediate LSR? Perhaps this paragraph is only intended to apply to a > multi-layer PCC/LSR? In either case, the scope and intent of this > paragraph really needs to be clarified. Yup, this applies to the ingress/egress of the lower layer LSP (it is clearly important to build an LSP that can be used by the higher layer! We mean it in the sense that "adapt" is used in RFC 5212. I'll add a clarification. > 126 [RFC4657] and [RFC4674]. > > Suggest adding ", and the framework provided in [RFC5623]." OK > 271 virtual TE links from regular TE links, it MUST be understood that a > > Who MUST understand this? If this is the reader/implementer/user then > this should be "must". If there are protocol implications, they should > be made more explicit, i.e., they're not clear. Good catch of passive voice. > 276 Thus, when a mono-layer path is requested or supplied, PCEP MUST be > 277 able to indicate the required/provided path layer. > > Doesn't this requirement also apply to multi-layer paths? (Consider case > where ingress/PCC is present in multiple layers.) Yes. This should read "even when" since that is case we wanted to highlight. > 330 purpose, the PCE discovery mechanism MAY support the disclosure of > > As this applies to the mechanism and not a particular implementation, > shouldn't this be a "MUST"? Disagree. There are other options to Discovery including capabilities exchange and configuration. So this really is only a "MAY". > 333 path-computation-related PCE capabilities: > > Should supported layers be included in the advertised capability list? Yes. In fact, the supported layers are no use without the adaptation functions, and the adaptation functions would not be any use without the layers. So the adaptation is sufficient. > 350 4.1. Control of Function and Policy > > Do you want to add a reference to 5394? Yup. Many thanks for the careful review. Adrian From gih@apnic.net Sun May 8 23:12:04 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EADE067A for ; Sun, 8 May 2011 23:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.716 X-Spam-Level: X-Spam-Status: No, score=-97.716 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zj5qEdtgUy4 for ; Sun, 8 May 2011 23:12:03 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFD5E0656 for ; Sun, 8 May 2011 23:12:01 -0700 (PDT) Received: from [10.59.1.150] (135.Red-217-126-147.staticIP.rima-tde.net [217.126.147.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B7044B68C0; Mon, 9 May 2011 16:11:55 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 9 May 2011 16:11:50 +1000 Message-Id: To: rtg-ads@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: rtg-dir@ietf.org, draft-ietf-mboned-maccnt-req@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mboned-maccnt-req-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 06:12:04 -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, and sometimes on special request. 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-mboned-maccnt-req-10.txt Reviewer: Geoff Huston Review Date: 9 May 2011 IETF LC End Date: Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: The document tends to be narrowly focussed and while it considers one particular scenario in depth the reviewer was left wondering about all the other potential business scenarios regarding content delivery and AAA that the document does not note, even if to state that all such scenarios outside of this limited scope are not to be considered here. Major Issues: I suppose the largest unanswered question is: Why is the AAA task for multicast content DIFFERENT than that used to allow the User access to the NSP's network in the first place? The draft appears to assume that there is a seperate multicast AAA enrolment going on here, but there is no motivation for this, and the reviewer is left wondering why there this appears to be distinct from the initial user authentication process for unicast network services. The text could do with some revision to explicitly address this consideration. Minor Issues: In Section 4 I felt that the draft should note the limitations of the models considered here. Noteably, where the Content Providers do NOT directly connect to the same network as the end users of the content, then this draft does not address the business or technical requirements. Should it? i.e. where users of service provider A attempt to connect content that is delivered from service provider B what guidance does this document offer? Also on page 12 Figure 3 is completely unreadable - perhaps it should be broken into a number of figures? The accompanying text is also unhelpful to decode the Figure. When the fogure is revised, this text would also be revised. Nits: page 1 Because many services such as television broadcasting require huge bandwidth (e.g., 6Mbit/s) 6Mbps is NOT "huge" IP multicast is used as an efficient delivery mechanism for CDS. s/is/may/ page 2 This memo lists the requirements of a business model in which the NSP provides CDS using multicast as one such contractible service. please define "NSP" with the first use. 2.1. Definitions Authentication: action for identifying a user as a genuine one. is there a better term other than "genuine"? perhaps "correctly identifying the end user" Authorization: action for giving permission for a user to access content or the network. page 3 User-based accounting: actions for grasping each user's behavior, when she/he starts/stops to receive a channel, which channel she/he receives, etc. I have no idea what "grasping" is intended to mean in this context. page 5 In this model the networks for CDS contain three different types of entities: Content Provider (CP), Network Service Provider (NSP), and user clients. please expand the acroynums on FIRST use only. page 7 With current protocols (IGMP/MLD), the sender cannot distinguish which receivers (end hosts) are actually receiving the information. The sender must rely on the information from the multicasting routers. This can be complicated if the sender and routers are maintained by different entities. Furthermore, the current user associated with receiver must be identified. What is the purpose of this paragraph? I thought that the section was "Information Required by Entities to Support the Proposed Business Model" and not part of the motivation section From lars.eggert@nokia.com Mon May 9 03:44:58 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2398E07AF; Mon, 9 May 2011 03:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.74 X-Spam-Level: X-Spam-Status: No, score=-102.74 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5si+SPtDQ4UH; Mon, 9 May 2011 03:44:57 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E673CE071F; Mon, 9 May 2011 03:44:56 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p49AirPw026330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 13:44:55 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-1-213170627; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 9 May 2011 13:44:44 +0300 Message-Id: <2CB29B1A-9590-424F-8CCC-1E7181278E96@nokia.com> To: irsg@irtf.org, rtg-dir@ietf.org, ipdir@ietf.org, tsv-dir@ietf.org, ops-dir@ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.fit.nokia.com); Mon, 09 May 2011 13:44:50 +0300 (EEST) X-Nokia-AV: Clean X-Mailman-Approved-At: Mon, 09 May 2011 04:43:23 -0700 Subject: [RTG-DIR] looking for ANRP reviewers X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: anrp@isoc.org List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 10:44:58 -0000 --Apple-Mail-1-213170627 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, you may have seen the call for nominations for the Applied Networking = Research Prize that the IRTF and ISOC are sponsoring. Basically, it's an = offer to the research community to get a travel grant and an invited = talk with the intent to stimulate new IRTF and IETF work, or otherwise = bring value to the IETF week. The details are at = http://www.irtf.org/anrp. The nomination period just ended, and we received 22 nominations. I'd = like to ask for some (5-10) volunteers to help select the winning = submissions. The intent is to pick two for Quebec City, and possibly two = more for Taiwan. The notification deadline for the awards is May 31, and = I'd like to finish the selection be Friday, May 27. In other words, = you'd need to spend a few cycles during the next 2-3 weeks. I'm looking for folks with a research and engineering background in the = topics below. Routing and other layer-3 topics were very common, so = experience in those areas is especially needed: LISP P2P traffic localization traffic classification impact of packet sizes NetFlow PMTUD measurements BGP (churn, update reductions) path computation inter-ISP connectivity tracking Ethernet scalability push messaging Internet of things routing (new approaches, FIB aggregation) TCP (over MANET, wireless) IPv6 transition HIP congestion notification energy-aware traffic engineering broadband Internet performance Note that we're NOT doing an academic peer review here. These papers = were already published - and hence peer reviewed - at more or less = prestigious journals, conferences and workshops. What the selection = process will need to determine is which of these submissions are = especially interesting to the IRTF and IETF community, whether they may = lead to new work, if they get a well-known research name to attend, etc. = In other words, the process is more like selecting a "best paper award" = than deciding on whether a paper should be accepted. Since this is the first time we're awarding ANRPs, we're making the = process up as we go. My current intention is to get 3-4 folks to look at = each of the submissions, do a pre-selection by email this week and next, = and do the final selection based on the preselection shortlist during a = phone call sometime between May 23-27. If you'd like to volunteer or have questions, please email = anrp@isoc.org. Thanks, Lars= --Apple-Mail-1-213170627 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwOTEwNDQ0NVowIwYJKoZIhvcNAQkE MRYEFGDZJGA3JoLhf6Yp43nn6CvKPloGMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AKjLCx/4eKbunfu7Tx/JCroctGRIqiSOEQ9Bke7V+nG4F3YpuAA2dLYYsV+i7u1wFhre0xQRs6n2 Y1sfOyOSd1mM+PCDCQfRQITHrsXgtNWRdS9eIXh8AXGu6tJLMwiD/BFYtgXKbrIEcCxZCgT15lVK eA2+mt19o8nwi4JqrmmwEg/uPhqT5NWouptjq2W6ZgUwCCzOvtd36De/rfWwM/CovnqWVOIx+8v1 gaoY94XWCPMmE0uaMVyXK0MGrflCkvjDZoNrf/w9iNdAAwGBLguOGzP3SR8gltUm1oUVVV+fdvbe ioYLFPEs2B4kOvmc/T4GuP/fmScES1wcKgspvAUAAAAAAAA= --Apple-Mail-1-213170627-- From lberger@labn.net Mon May 9 06:59:58 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77131E0769 for ; Mon, 9 May 2011 06:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.944 X-Spam-Level: X-Spam-Status: No, score=-101.944 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLd4pmoSl9GC for ; Mon, 9 May 2011 06:59:57 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 48FACE075F for ; Mon, 9 May 2011 06:59:56 -0700 (PDT) Received: (qmail 11734 invoked by uid 0); 9 May 2011 13:53:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 9 May 2011 13:53:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=LjXVRMQXSUD71ZdCgRfmqWcWD4rDkL3NKoQHthstT68xhpiOh6JYF6eAT5JEsKrBhANMkxD9/XO3bKllk9xrSMmdDUiJ1DMJgDNxw8PlJP3HwIkpT66lsioJFpbS3fjQ; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QJQtg-000428-8P; Mon, 09 May 2011 07:53:16 -0600 Message-ID: <4DC7F1C9.1060308@labn.net> Date: Mon, 09 May 2011 09:53:13 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Adrian.Farrel@huawei.com References: <4D5EE6A5.9040305@labn.net> <009a01cc0d8a$6caa2680$45fe7380$@huawei.com> In-Reply-To: <009a01cc0d8a$6caa2680$45fe7380$@huawei.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-pce-inter-layer-req@tools.ietf.org, rtg-dir@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-inter-layer-req-15 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 13:59:58 -0000 Hi Adrian, On 5/8/2011 10:15 AM, Adrian Farrel wrote: > Several years passed; the snow settled into great drifts and all life vanished > from the courtyard of the great palace... > Humm, means I have to remember this draft. I'll try! > in line... responses too... > >> - General comment/question: In reading the document I found a number of >> places where the text seemed to imply that the PCC was always the >> layer/region boundary, which is inconsistent with RFC5623. Is this >> intentional? >> >> Examples from the document include: >> 257 An ingress LSR for the higher-layer LSP, or a PCC, needs to >> 258 know whether triggered signaling is required or not. >> >> While this is true for the boundary LSR, I'm not sure how it fits into >> this document. Isn't such determination made by the boundary LSR per >> RFCs 4206 and 6001? If so, the sentence is out of scope of this >> document. If you do keep it, I suggest replacing " An ingress LSR for >> the higher-layer LSP, or a PCC," with something along the lines of "A >> layer boundary LSR". > > I think you misread this one. > The ingress LSR for the higher-layer LSP is unlikely to be the boundary LSR. > That would more likely be the ingress LSR for the lower-layer LSP. > But the case where it is, is caught by your next comment. I guess I just don't understand the point being made in the text. We agree that the higher-layer LSP is unlikely to be the boundary LSR. So why does "An ingress LSR for the *higher-layer* LSP, or a PCC, needs to know whether triggered signaling is required or not."? >> 275 Also note that an ingress LSR may be present in multiple layers. >> >> Is "ingress LSR" mean "a layer boundary LSR", or "the PCC LSR"? > > Hmm, yes, both, or either. > Clarifying text. > >> 299 3.1.4. Adaptation Capability >> >> 301 It MUST be possible for the path computation request to indicate the >> 302 desired adaptation function at the end points of the lower-layer LSP >> 303 that is being computed. This will be particularly important where the >> 304 ingress and egress LSR participate in more than one layer network but >> 305 may not be capable of all associated adaptations. >> >> This section cases me concern a number of levels. The first is that >> "adaptation function" is not defined in this document, nor is it used in >> the other MRN documents. Furthermore, is it reasonable to have >> adaptation indicated by a PCC when the layer/region boundary is at an >> intermediate LSR? Perhaps this paragraph is only intended to apply to a >> multi-layer PCC/LSR? In either case, the scope and intent of this >> paragraph really needs to be clarified. > > Yup, this applies to the ingress/egress of the lower layer LSP (it is clearly > important to build an LSP that can be used by the higher layer! I think I read this paragraph from the standpoint of the earlier sentence which was referring to the path computation request of the "ingress LSR for the higher-layer LSP". If the PCC is the ingress of the lower layer LSP, this section makes perfect sense. Perhaps you can rephrase text to clarify? > [...] > >> 330 purpose, the PCE discovery mechanism MAY support the disclosure of >> >> As this applies to the mechanism and not a particular implementation, >> shouldn't this be a "MUST"? > > Disagree. There are other options to Discovery including capabilities exchange > and configuration. So this really is only a "MAY". Okay, I buy configuration as an alternative that doesn't require the such advertisements. I certainly defer to the WG/authors on this, but it seems to me "MAY" is quite weak guidance given the value of the advertisements. > >> 333 path-computation-related PCE capabilities: >> >> Should supported layers be included in the advertised capability list? > > Yes. In fact, the supported layers are no use without the adaptation functions, > and the adaptation functions would not be any use without the layers. So the > adaptation is sufficient. I've always considered "adaptation" path-computation logically separable from "layer-specific" path-computation, but can accept that the latter isn't expected without the former. You may want to make this implication explicit. > >> 350 4.1. Control of Function and Policy >> >> Do you want to add a reference to 5394? > > Yup. > > Many thanks for the careful review. > > Adrian > You're welcome. Hope you found it useful. Lou From hejia@huawei.com Mon May 30 06:30:55 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789FE0651 for ; Mon, 30 May 2011 06:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAUA10pecCWl for ; Mon, 30 May 2011 06:30:53 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 982F5E074C for ; Mon, 30 May 2011 06:30:51 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM000IW5G778U@szxga04-in.huawei.com> for rtg-dir@ietf.org; Mon, 30 May 2011 21:30:44 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM0004Q4G771X@szxga04-in.huawei.com> for rtg-dir@ietf.org; Mon, 30 May 2011 21:30:43 +0800 (CST) Received: from hejia ([10.70.77.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LM00043MG76F4@szxml04-in.huawei.com> for rtg-dir@ietf.org; Mon, 30 May 2011 21:30:43 +0800 (CST) Date: Mon, 30 May 2011 21:30:42 +0800 From: Jia He To: rtg-ads@tools.ietf.org Message-id: <2EA9F2644F624189B7080C2AE777402C@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_t71HBvHMsisd2PIkUid0Sg)" X-Priority: 3 X-MSMail-priority: Normal Cc: rtg-dir@ietf.org, draft-ietf-mpls-p2mp-lsp-ping@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-p2mp-lsp-ping-16.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 13:30:55 -0000 This is a multi-part message in MIME format. --Boundary_(ID_t71HBvHMsisd2PIkUid0Sg) Content-type: text/plain; charset=gb2312 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-mpls-p2mp-lsp-ping-16 Reviewer: Jia He Review Date: May 30, 2011 IETF LC End Date: May 30, 2011 Intended Status: Standards Track Summary: The document is well written, and I only have several minor issues. Major Issues: No major issues found. Minor issues: 1: echo response message or echo reply message [RFC4379] uses "echo reply" in most places. It is recommended to check through the whole draft and keep the terminologies aligned between this draft and [RFC4379]. 2: Section 2.2 (Page 5, 3rd paragraph), it says MPLS packets inserted at the ingress of a P2MP LSP are delivered equally (barring faults) to all egresses. In consequence, the basic idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an ^^^^^^^^^^^^^^^^^ intention to test that packets that enter (at the ingress) a particular P2MP LSP actually end their MPLS path on the LSRs that are the (intended) egresses for that LSP. The idea may be extended to check selectively that such packets reach specific egresses. It seems to me that this paragraph applies to both P2MP LDP LSPs and P2MP MPLS TE LSPs rather than "P2MP MPLS TE LSPs" only. Am I missing something, or should the text be changed to "P2MP MPLS LSPs" so that it covers both types of P2MP LSP? 3: Section 3.2 (Page 10, under the format of P2MP Responder Identifier TLV) Sub-TLVs: Zero, one or more sub-TLVs as defined below. If no sub-TLVs are present, the TLV MUST be processed as if it were absent. If more than one sub-TLV is present the first MUST be processed as described in this document, and subsequent sub-TLVs SHOULD be ignored. Does it mean only zero or one sub-TLV applies in this document? Why do we add more than one sub-TLV if subsequent sub-TLVs SHOULD be ignored? Or Am I missing something? More clafications would be much appreciated. 4: Section 4.2.1 (Page 16, 2nd paragraph) When the responding node reports that it is an egress, it is clear that the echo response applies only to the reporting node. Similarly, when a node reports that it does not form part of the LSP described by the FEC (i.e. there is a misconnection) then the echo response applies to the reporting node. This intention of this paragraph is not clear to me. Could the authors provide more explanations? E.g., How is "similarly" deduced? What is the difference or similarity between those two cases? Nits: 1: Section 2.2 (Page 6, 1st paragraph) The second procedures allows the initiator to ... ^^^^^^^^^^ should be "procedure" 2: Section 3.1.2 (Page 8) The new sub-TLVs are assigned a sub-type identifiers as follows ^^^^^^^^^^^^^^^^^^^^^^ should be "sub-type identifiers" 3: Section 4.1.2 (Page 15, 1st paragraph) The initiating LSR can supply the desired value of the jitter in the Echo Jitter TLV as defined section 3.3. ^^^ "in section 3.3" 4: Secion 4.2.1.3 (Page 18~19) Node behavior guidelines: - If the Responder Identifier TLV is not present, then the node will behave as a combination egress and branch node. ^^^ - If the Responder Identifier TLV containing a Node Address sub-TLV is present, and: - If the address specified in the sub-TLV matches to an address in the node, then the node will behave like an combination egress and branch node. ^^^ .... - If the node is behaving as a combination egress and branch node, and: ^^^ "a combination of", "of" is missing... 5: Section 4.3.1 (Page 19, last paragraph) For P2MP TE LSP, the initiating LSR has a priori knowledge about number of egress nodes and their addresses. Hence it possible to ^^^ continue processing till a valid response has been received from each end-point, provided the responses can be matched correctly to the egress nodes. "it is possible" That's what I have... Jia --Boundary_(ID_t71HBvHMsisd2PIkUid0Sg) Content-type: text/html; charset=gb2312 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-mpls-p2mp-lsp-ping-16
Reviewer: Jia He
Review Date: May 30, 2011
IETF LC End Date: May 30, 2011
Intended Status: Standards Track
 
 
 
Summary:
 
The document is well written, and I only have several minor issues.
 

Major Issues:
 
No major issues found.
 

Minor issues:
 
1: echo response message or echo reply message
 
[RFC4379] uses "echo reply" in most places. It is recommended to check through the whole draft and keep the terminologies aligned between this draft and [RFC4379].
 

2: Section 2.2 (Page 5, 3rd paragraph), it says
 

   MPLS packets inserted at the ingress of a P2MP LSP are delivered
   equally (barring faults) to all egresses.  In consequence, the basic
   idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an
                        ^^^^^^^^^^^^^^^^^
   intention to test that packets that enter (at the ingress) a
   particular P2MP LSP actually end their MPLS path on the LSRs that are
   the (intended) egresses for that LSP.  The idea may be extended to
   check selectively that such packets reach specific egresses.
 
It seems to me that this paragraph applies to both P2MP LDP LSPs and P2MP MPLS TE LSPs rather than "P2MP MPLS TE LSPs" only.
Am I missing something, or should the text be changed to "P2MP MPLS LSPs" so that it covers both types of P2MP LSP?
 

3: Section 3.2 (Page 10, under the format of P2MP Responder Identifier TLV)
 
      Sub-TLVs:
 
        Zero, one or more sub-TLVs as defined below.
 
        If no sub-TLVs are present, the TLV MUST be processed as if it
        were absent.  If more than one sub-TLV is present the first MUST
        be processed as described in this document, and subsequent
        sub-TLVs SHOULD be ignored.
 
Does it mean only zero or one sub-TLV applies in this document? Why do we add more than one sub-TLV if subsequent sub-TLVs SHOULD be ignored? Or Am I missing something?
More clafications would be much appreciated.
 

4: Section 4.2.1 (Page 16, 2nd paragraph)
 
   When the responding node reports that it is an egress, it is clear
   that the echo response applies only to the reporting node.
   Similarly, when a node reports that it does not form part of the LSP
   described by the FEC (i.e. there is a misconnection) then the echo
   response applies to the reporting node.
 
This intention of this paragraph is not clear to me. Could the authors provide more explanations? E.g., How is "similarly" deduced? What is the difference or similarity between those two cases?
 
 
 
Nits:
 
1: Section 2.2 (Page 6, 1st paragraph)
 
    The second procedures allows the initiator to ...
               ^^^^^^^^^^
should be "procedure"
 

2: Section 3.1.2 (Page 8)
 
    The new sub-TLVs are assigned a sub-type identifiers as follows
                                  ^^^^^^^^^^^^^^^^^^^^^^
should be "sub-type identifiers"
 

3: Section 4.1.2 (Page 15, 1st paragraph)
 
   The initiating LSR can supply the desired value of the jitter in the
   Echo Jitter TLV as defined section 3.3.
                            ^^^
"in section 3.3"
 

4: Secion 4.2.1.3 (Page 18~19)
 
      Node behavior guidelines:
 
      - If the Responder Identifier TLV is not present, then the node
        will behave as a combination egress and branch node.
                                   ^^^
 
      - If the Responder Identifier TLV containing a Node Address
        sub-TLV is present, and:
 
         - If the address specified in the sub-TLV matches to an address
           in the node, then the node will behave like an combination egress and branch node.
                                                                    ^^^
      ....
 
     - If the node is behaving as a combination egress and branch node, and:
                                              ^^^
"a combination of", "of" is missing...
 

5: Section 4.3.1 (Page 19, last paragraph)
 
   For P2MP TE LSP, the initiating LSR has a priori knowledge about
   number of egress nodes and their addresses.  Hence it possible to
                                                       ^^^
   continue processing till a valid response has been received from each
   end-point, provided the responses can be matched correctly to the
   egress nodes.
 
"it is possible"
 
 
 

That's what I have...
 
Jia
 
 
 
--Boundary_(ID_t71HBvHMsisd2PIkUid0Sg)-- From ssaxena@cisco.com Tue May 31 05:34:45 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED30E0721 for ; Tue, 31 May 2011 05:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7SQ9lp00zCL for ; Tue, 31 May 2011 05:34:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 03D83E0714 for ; Tue, 31 May 2011 05:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ssaxena@cisco.com; l=25564; q=dns/txt; s=iport; t=1306845281; x=1308054881; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=0ehAQ0M4YR8xN3/dt4OySmBfC+D+da3HznHfeRkTb+s=; b=YFlOLVP8xIfHRnOTfYExByey8wrKZYmFbRkZAHyzsfgKTshs/wKiIgLN gnDbsURqppgJE4XyQNPJdCoPU2YqaoMkpkZrDKdaB8sKhxav2fTQNDfv1 bpit75WBlfAdhK1pKIspKXJkavH1hnyAMkem7O+f9vOoAxjys4olPFg8r M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAIrf5E2tJV2Y/2dsb2JhbABTglKUeY5Sd6dQnU6GHgSGZI4yinE X-IronPort-AV: E=Sophos;i="4.65,297,1304294400"; d="scan'208,217";a="367238716" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 31 May 2011 12:34:40 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4VCYeD4023178; Tue, 31 May 2011 12:34:40 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 May 2011 07:34:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1F8F.1BF5A940" Date: Tue, 31 May 2011 07:34:38 -0500 Message-ID: In-Reply-To: <2EA9F2644F624189B7080C2AE777402C@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RtgDir review: draft-ietf-mpls-p2mp-lsp-ping-16.txt Thread-Index: Acwezly0RB+gxwEdSlWvzQR82jQ0jwAwJlUA References: <2EA9F2644F624189B7080C2AE777402C@china.huawei.com> From: "Shaleen Saxena (ssaxena)" To: "Jia He" , X-OriginalArrivalTime: 31 May 2011 12:34:39.0549 (UTC) FILETIME=[1BE21ED0:01CC1F8F] X-Mailman-Approved-At: Tue, 31 May 2011 05:54:37 -0700 Cc: rtg-dir@ietf.org, "Shaleen Saxena \(ssaxena\)" , draft-ietf-mpls-p2mp-lsp-ping@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-p2mp-lsp-ping-16.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 12:34:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1F8F.1BF5A940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jia, =20 Thank you very much for the thorough reading and comments. I will update the draft as necessary. =20 Regards, Shaleen =20 =20 From: Jia He [mailto:hejia@huawei.com]=20 Sent: Monday, May 30, 2011 9:31 AM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; draft-ietf-mpls-p2mp-lsp-ping@tools.ietf.org Subject: RtgDir review: draft-ietf-mpls-p2mp-lsp-ping-16.txt =20 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=20 drafts as they pass through IETF last call and IESG review. The purpose=20 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=20 discussion or by updating the draft. =20 Document: draft-ietf-mpls-p2mp-lsp-ping-16 Reviewer: Jia He Review Date: May 30, 2011 IETF LC End Date: May 30, 2011 Intended Status: Standards Track =20 =20 =20 Summary: =20 The document is well written, and I only have several minor issues. =20 Major Issues: =20 No major issues found. =20 Minor issues: =20 1: echo response message or echo reply message =20 [RFC4379] uses "echo reply" in most places. It is recommended to check through the whole draft and keep the terminologies aligned between this draft and [RFC4379]. =20 2: Section 2.2 (Page 5, 3rd paragraph), it says =20 MPLS packets inserted at the ingress of a P2MP LSP are delivered equally (barring faults) to all egresses. In consequence, the basic idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an ^^^^^^^^^^^^^^^^^ intention to test that packets that enter (at the ingress) a particular P2MP LSP actually end their MPLS path on the LSRs that are the (intended) egresses for that LSP. The idea may be extended to check selectively that such packets reach specific egresses. =20 It seems to me that this paragraph applies to both P2MP LDP LSPs and P2MP MPLS TE LSPs rather than "P2MP MPLS TE LSPs" only.=20 Am I missing something, or should the text be changed to "P2MP MPLS LSPs" so that it covers both types of P2MP LSP? =20 3: Section 3.2 (Page 10, under the format of P2MP Responder Identifier TLV) =20 Sub-TLVs: =20 Zero, one or more sub-TLVs as defined below. =20 If no sub-TLVs are present, the TLV MUST be processed as if it were absent. If more than one sub-TLV is present the first MUST be processed as described in this document, and subsequent sub-TLVs SHOULD be ignored. =20 Does it mean only zero or one sub-TLV applies in this document? Why do we add more than one sub-TLV if subsequent sub-TLVs SHOULD be ignored? Or Am I missing something?=20 More clafications would be much appreciated. =20 4: Section 4.2.1 (Page 16, 2nd paragraph) =20 When the responding node reports that it is an egress, it is clear that the echo response applies only to the reporting node. Similarly, when a node reports that it does not form part of the LSP described by the FEC (i.e. there is a misconnection) then the echo response applies to the reporting node. =20 This intention of this paragraph is not clear to me. Could the authors provide more explanations? E.g., How is "similarly" deduced? What is the difference or similarity between those two cases? =20 =20 =20 Nits: =20 1: Section 2.2 (Page 6, 1st paragraph) =20 The second procedures allows the initiator to ... ^^^^^^^^^^ should be "procedure" =20 2: Section 3.1.2 (Page 8) =20 The new sub-TLVs are assigned a sub-type identifiers as follows ^^^^^^^^^^^^^^^^^^^^^^ should be "sub-type identifiers" =20 3: Section 4.1.2 (Page 15, 1st paragraph) =20 The initiating LSR can supply the desired value of the jitter in the Echo Jitter TLV as defined section 3.3.=20 ^^^ "in section 3.3" =20 4: Secion 4.2.1.3 (Page 18~19) =20 Node behavior guidelines: =20 - If the Responder Identifier TLV is not present, then the node will behave as a combination egress and branch node. ^^^ =20 - If the Responder Identifier TLV containing a Node Address sub-TLV is present, and: =20 - If the address specified in the sub-TLV matches to an address in the node, then the node will behave like an combination egress and branch node. ^^^ .... =20 - If the node is behaving as a combination egress and branch node, and: ^^^ "a combination of", "of" is missing... =20 5: Section 4.3.1 (Page 19, last paragraph) =20 For P2MP TE LSP, the initiating LSR has a priori knowledge about number of egress nodes and their addresses. Hence it possible to ^^^ continue processing till a valid response has been received from each end-point, provided the responses can be matched correctly to the egress nodes. =20 "it is possible" =20 =20 =20 That's what I have... =20 Jia =20 =20 =20 ------_=_NextPart_001_01CC1F8F.1BF5A940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jia,

 

Thank you very much for the thorough reading and comments. I will = update the draft as necessary.

 

Regards,

Shaleen

 

 

From:= = Jia He [mailto:hejia@huawei.com]
Sent: Monday, May 30, 2011 = 9:31 AM
To: rtg-ads@tools.ietf.org
Cc: = rtg-dir@ietf.org; = draft-ietf-mpls-p2mp-lsp-ping@tools.ietf.org
Subject: RtgDir = review: = draft-ietf-mpls-p2mp-lsp-ping-16.txt

 

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.iet= f.org/iesg/directorate/routing.html

<= p class=3DMsoNormal> 

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-p2mp-lsp-ping-16
Reviewer: Jia He
Review Date: May = 30, 2011
IETF LC End Date: May 30, 2011
Intended Status: Standards = Track

 

 

 

Summary:

 

The document is well = written, and I only have several minor = issues.

 


Major = Issues:

 

No major issues = found.

 


Minor = issues:

 

1: echo response = message or echo reply message

 

[RFC4379] uses = "echo reply" in most places. It is recommended to check = through the whole draft and keep the terminologies aligned between this = draft and [RFC4379].

 


2: Section 2.2 = (Page 5, 3rd paragraph), it says

 


   MPLS = packets inserted at the ingress of a P2MP LSP are = delivered
   equally (barring faults) to all = egresses.  In consequence, the basic
   idea of LSP = Ping for P2MP MPLS TE LSPs may be expressed as = an
           &= nbsp;            = ^^^^^^^^^^^^^^^^^
   intention to test that packets that = enter (at the ingress) a
   particular P2MP LSP actually = end their MPLS path on the LSRs that are
   the (intended) = egresses for that LSP.  The idea may be extended to
   = check selectively that such packets reach specific = egresses.

 

It seems to me that = this paragraph applies to both P2MP LDP LSPs and P2MP MPLS TE LSPs = rather than "P2MP MPLS TE LSPs" only.
Am I missing = something, or should the text be changed to "P2MP MPLS LSPs" = so that it covers both types of P2MP = LSP?

 


3: Section 3.2 = (Page 10, under the format of P2MP Responder Identifier = TLV)

 

      = Sub-TLVs:

 

        = Zero, one or more sub-TLVs as defined = below.

 

        If = no sub-TLVs are present, the TLV MUST be processed as if = it
        were absent.  If = more than one sub-TLV is present the first = MUST
        be processed as = described in this document, and = subsequent
        sub-TLVs SHOULD = be ignored.

 

Does it mean only = zero or one sub-TLV applies in this document? Why do we add more than = one sub-TLV if subsequent sub-TLVs SHOULD be ignored? Or Am I missing = something?
More clafications would be much = appreciated.

 


4: Section 4.2.1 = (Page 16, 2nd paragraph)

 

   When the = responding node reports that it is an egress, it is = clear
   that the echo response applies only to the = reporting node.
   Similarly, when a node reports that it = does not form part of the LSP
   described by the FEC (i.e. = there is a misconnection) then the echo
   response applies = to the reporting node.

 

This intention of = this paragraph is not clear to me. Could the authors provide = more explanations? E.g., How is "similarly" deduced? What is = the difference or similarity between those two = cases?

 

 

 

Nits:

 

1: Section 2.2 (Page = 6, 1st paragraph)

 

    = The second procedures allows the initiator to = ...
           =     ^^^^^^^^^^
should be = "procedure"

 


2: Section 3.1.2 = (Page 8)

 

    = The new sub-TLVs are assigned a sub-type identifiers as = follows
          &n= bsp;           &nb= sp;           = ^^^^^^^^^^^^^^^^^^^^^^
should be "sub-type = identifiers"

 


3: Section 4.1.2 = (Page 15, 1st paragraph)

 

   The = initiating LSR can supply the desired value of the jitter in = the
   Echo Jitter TLV as defined section 3.3. =
           &nb= sp;           &nbs= p;    ^^^
"in section = 3.3"

 


4: Secion 4.2.1.3 = (Page 18~19)

 

      Node behavior = guidelines:

 

      - If the = Responder Identifier TLV is not present, then the = node
        will behave as a = combination egress and branch = node.
          &nbs= p;            = ;            = ^^^

 

      - If the = Responder Identifier TLV containing a Node = Address
        sub-TLV is = present, and:

 

       &nbs= p; - If the address specified in the sub-TLV matches to an = address
           = in the node, then the node will behave like an combination egress and = branch = node.
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;        = ^^^
      = ....
 
     - If the node is behaving as = a combination egress and branch node, = and:
           = ;            =             &= nbsp;          = ^^^
"a combination of", "of" is = missing...

 


5: Section 4.3.1 = (Page 19, last paragraph)

 

   For P2MP = TE LSP, the initiating LSR has a priori knowledge about
   = number of egress nodes and their addresses.  Hence it possible = to
           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       ^^^
   continue = processing till a valid response has been received from = each
   end-point, provided the responses can be matched = correctly to the
   egress = nodes.

 

"it is = possible"

 

 

 


That's what I = have...

 

Jia

 

 

 

------_=_NextPart_001_01CC1F8F.1BF5A940-- From mshand@cisco.com Tue May 31 06:10:36 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D14FE084D for ; Tue, 31 May 2011 06:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84cxMamGy3UW for ; Tue, 31 May 2011 06:10:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 12C25E0858 for ; Tue, 31 May 2011 06:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mshand@cisco.com; l=4636; q=dns/txt; s=iport; t=1306847431; x=1308057031; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=LzU+cPhzeruYlcP0/3kWu8WbQ67Q/QXdDghdjwj97bA=; b=MEe7w+WkLeIFB7tLqkw3JvOeKN/C6AYQpmk58qrpwu5iEhTq8LWrG/OJ mzLS0I5M/dIUeIL3x68rybSpW5syu6uO5IDVPmOYyMjOxmUZa9UfZQgjR wJMklpYwl2CZ66gOtfNUbsAlg6pjQ+xcmlstxVWACtAc/nyQUHVuMwCUw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK7n5E2Q/khM/2dsb2JhbABTph13qDWdUIYeBJBPhD6KXQ X-IronPort-AV: E=Sophos;i="4.65,297,1304294400"; d="scan'208";a="91566045" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 31 May 2011 13:10:28 +0000 Received: from [64.103.65.19] (dhcp-gpk02-vlan300-64-103-65-19.cisco.com [64.103.65.19]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4VDARDC010709; Tue, 31 May 2011 13:10:28 GMT Message-ID: <4DE4E8C3.6030205@cisco.com> Date: Tue, 31 May 2011 14:10:27 +0100 From: mike shand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-pppext-trill-protocol.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-pppext-trill-protocol-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:10:36 -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, and sometimes on special request. 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-pppext-trill-protocol-06.txt Reviewer: Mike Shand Review Date: 31 May 2011 IETF LC End Date: 8 June 2011 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: The reference to RFC 1142 is misleading and dangerous. RFC 1142 is a poor copy of a pre-standard version of IS-IS ( ISO DP 10589, as opposed to ISO/IEC 10589 version 2). There are significant technical differences between RFC 1142 and the ISO standard. Note that, for this reason, it is proposed that RFC 1142 be re-classified as historic. (see http://tools.ietf.org/html/draft-shand-rfc1142-to-historic-01). It should never be used as a reference for IS-IS. The correct reference for ISO/IEC 10589 is :- International Organization for Standardization, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov 2002. Consequently some references to sections in this draft need to be modified, as noted below. Major Issues: No major issues found. Minor Issues: 1) Section 2 para 3 last sentence. says "If a TNP or TLSP packet is received when TNCP is not in Opened state and LCP is Opened, an implementation SHOULD respond using LCP Protocol-Reject." I assume that such a packet MUST be discarded, but that in addition the implementation SHOULD respond with a LCP Protocol-Reject. Is this correct, and if so, does it need clarification? I note that RFC 1661 explicitly states "Any supported network-layer protocol packets received when the corresponding NCP is not in the Opened state MUST be silently discarded." So RFC 1661 requires a silent discard, whereas this draft encourages an explicit reject. 2) Section 2.2 para 1 says "When TNCP is in Opened state, TNP packets MAY be sent by setting the PPP Protocol field to hex TBD-00XX (TNP) and placing the TRILL-encapsulated data in the PPP Information field." I think this is the wrong use of "MAY". MAY implies that TNP packets may be sent as described here, or by some other undisclosed encoding. Surely what is meant is that if TNP packets are sent, they MUST be encoded as described here. Similarly in Section 2.3. concerning TLSP packets. 3) Section 3, bullet 1. The text:- per "Point-to-Point IS to IS Hello PDU" (section 9.3 of [6] in PDF, 9.7 in text), do not use Neighbor IDs." should simply refer to section 9.7 in ISO/IEC 10589 second edition. 4) In addition, it may be helpful here to draw attention to the requirement in [1] 4.2.4.1 that the IS-IS three way hand shake MUST be used on such links. In particular, the reference (in the present draft) in the last sentence of section 2.3 to "only an arbitrary circuit ID", rather than an "extended circuit ID" as described in RFC 5303, and the clause "do not use Neighbor IDs" at the end of section 3 bullet 1, may give the erroneous impression that RFC 5303, (and the "Neighbor System ID", and "Neighbor Extended Circuit ID" defined therein) is not mandated for PPP links. That said, I appreciate that this draft should not unnecessarily re-state every requirement of the base TRILL spec 5) Section 3, bullet 3 The discussion of the issue that there may be no MAC address as a possible source for a unique system ID is out of place in this draft. It is not a direct consequence of using either PPP or TRILL. It is a situation which may arise in any usage of IS-IS where there is no MAC address available to source the system ID. It seems arbitrary to reference [8] in this context, particularly since [8] has not been submitted as an IS-IS WG document. Thanks, Mike From carlsonj@workingcode.com Tue May 31 07:15:46 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9806FE06C6 for ; Tue, 31 May 2011 07:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcEBjQT21w34 for ; Tue, 31 May 2011 07:15:42 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id B47F7E0685 for ; Tue, 31 May 2011 07:15:41 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4VEFORR016061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2011 10:15:25 -0400 (EDT) Message-ID: <4DE4F7FC.7050708@workingcode.com> Date: Tue, 31 May 2011 10:15:24 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: mike shand References: <4DE4E8C3.6030205@cisco.com> In-Reply-To: <4DE4E8C3.6030205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: carlson; whitelist X-Mailman-Approved-At: Tue, 31 May 2011 07:50:22 -0700 Cc: rtg-dir@ietf.org, draft-ietf-pppext-trill-protocol.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-trill-protocol-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 14:15:46 -0000 mike shand wrote: > The reference to RFC 1142 is misleading and dangerous. RFC 1142 is a > poor copy of a pre-standard version of IS-IS ( ISO DP 10589, as opposed > to ISO/IEC 10589 version 2). There are significant technical differences > between RFC 1142 and the ISO standard. Not a problem; I'll update this and the references to sections of the draft. > 1) Section 2 para 3 last sentence. > > says "If a TNP or TLSP packet is received when TNCP is not in Opened > state and LCP is Opened, an implementation SHOULD respond using LCP > Protocol-Reject." > > I assume that such a packet MUST be discarded, but that in addition the > implementation SHOULD respond with a LCP Protocol-Reject. Is this > correct, and if so, does it need clarification? Yes, that's correct, and I'll clarify the text. > I note that RFC 1661 explicitly states > "Any supported network-layer protocol packets received when the > corresponding NCP is not in the Opened state MUST be silently discarded." > So RFC 1661 requires a silent discard, whereas this draft encourages an > explicit reject. You're right; the intent was to conform with 1661, but this text doesn't manage to do that. I'll repair it. > 2) Section 2.2 para 1 > > says "When TNCP is in Opened state, TNP packets MAY be sent by setting > the PPP Protocol field to hex TBD-00XX (TNP) and placing the > TRILL-encapsulated data in the PPP Information field." > > I think this is the wrong use of "MAY". MAY implies that TNP packets may > be sent as described here, or by some other undisclosed encoding. Surely > what is meant is that if TNP packets are sent, they MUST be encoded as > described here. I can recast to avoid the use of "MAY" in this instance. > 4) In addition, it may be helpful here to draw attention to the > requirement in [1] 4.2.4.1 that the IS-IS three way hand shake MUST be > used on such links. In particular, the reference (in the present draft) > in the last sentence of section 2.3 to "only an arbitrary circuit ID", > rather than an "extended circuit ID" as described in RFC 5303, and the > clause "do not use Neighbor IDs" at the end of section 3 bullet 1, may > give the erroneous impression that RFC 5303, (and the "Neighbor System > ID", and "Neighbor Extended Circuit ID" defined therein) is not mandated > for PPP links. > > That said, I appreciate that this draft should not unnecessarily > re-state every requirement of the base TRILL spec The text here is a response to previous concerns that the original draft did not adequately describe the existing IS-IS mechanism for point-to-point links. In particular, some reviewers were confused about the use of Neighbor IDs in Ethernet Hello messages. To the extent possible, I'd like to avoid duplicating that sort of text, but I do have those concerns from other reviewers to deal with. The text is not at all intended to preclude the use of a Neighbor System ID as part of RFC 5303 or any other standard IS-IS extension. I'll try to recast this. > 5) Section 3, bullet 3 > > The discussion of the issue that there may be no MAC address as a > possible source for a unique system ID is out of place > in this draft. It is not a direct consequence of using either PPP or TRILL. > It is a situation which may arise in any usage of IS-IS where there is > no MAC > address available to source the system ID. It seems arbitrary to > reference [8] in this context, particularly since [8] has not been > submitted as an IS-IS WG document. Unfortunately, I agree completely. However, the reviewers in PPPEXT -- particularly Bill Simpson -- rather vehemently did not agree. He argued at length that this had to be a normative reference, because there were potential cases where IS-IS over PPP could not be used as described. I argued (as I think you do) that this is really a higher level IS-IS system design issue, and is not peculiar to TRILL, PPP, or anything in this draft, and should not be solved here. The (lengthy) thread begins here: http://www.ietf.org/mail-archive/web/pppext/current/threads.html#00484 The rough compromise we were able to achieve was to mention the potential issue as a warning to implementors, and reference Bill's draft as one possible solution as an informative reference only. Though I agree with you that this issue is clearly out of scope, I'd very much like to avoid re-opening that kettle of fish by removing the text. The outcome of a re-spin might end up being worse. I could potentially add some text to note that this is not a special problem with PPP or TRILL, and that it's true of any IS-IS implementation with only point-to-point links. (For what it's worth, we had similar problems with the security issues. There are no special security issues with the protocol itself, as an implementation of it relies on existing security mechanisms, but Bill felt an enumeration was required.) -- James Carlson 42.703N 71.076W From mshand@cisco.com Tue May 31 08:16:52 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0B3E083C for ; Tue, 31 May 2011 08:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP9EPscXRO8y for ; Tue, 31 May 2011 08:16:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C3790E0857 for ; Tue, 31 May 2011 08:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mshand@cisco.com; l=15369; q=dns/txt; s=iport; t=1306855006; x=1308064606; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=f+TovAOuL2kxE0LUGmMjrWBVndg4frjc/X8YZbW97q0=; b=MMfRKQpCIPHH08o5xOG1s9iptQAXcCbeLVu8NOtOEg3yiwkbnHfHMUIo iEmiiXLGXoIVcE3p6qCQj9u1Syrl/yn7YRmk1vYztrWz6KBGVzZfLqhPC s2n8vthIoXrC6MF13SO39vIwdefLYnERarAEsIjdUq/MGzhAFeER8gzbq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABgG5U2Q/khM/2dsb2JhbABTph13qGCdW4YeBJBPhD6KXQ X-IronPort-AV: E=Sophos;i="4.65,297,1304294400"; d="scan'208,217";a="33094929" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 31 May 2011 15:16:38 +0000 Received: from [64.103.65.19] (dhcp-gpk02-vlan300-64-103-65-19.cisco.com [64.103.65.19]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4VFGbh9009870; Tue, 31 May 2011 15:16:37 GMT Message-ID: <4DE50655.6040500@cisco.com> Date: Tue, 31 May 2011 16:16:37 +0100 From: mike shand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: James Carlson References: <4DE4E8C3.6030205@cisco.com> <4DE4F7FC.7050708@workingcode.com> In-Reply-To: <4DE4F7FC.7050708@workingcode.com> Content-Type: multipart/alternative; boundary="------------000504010208070508030105" Cc: rtg-dir@ietf.org, draft-ietf-pppext-trill-protocol.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-trill-protocol-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 15:16:52 -0000 This is a multi-part message in MIME format. --------------000504010208070508030105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit James, Thanks. Regarding the last issue, perhaps one of the causes of confusion here is the common belief that the IS-IS spec specifies that the system ID be derived from a MAC address. In fact IS-IS is completely silent on HOW the system ID is assigned, and it simply states, in clause 7.1.4:- Each system in an area must have an unambiguous ID; that is, no two systems (IS or ES) in an area may use the same ID value. and Each Level 2 Intermediate system within a routeing domain must have an unambiguous value for its ID field; that is, no two level 2 ISs in a routeing domain can have the same value in their ID fields. It states:- It is the responsibility of the routeing domain administrative authority to enforce the requirements stated below in this clause and the rules stated above in 7.1.3.1. These requirements place specific constraints on the NSAP addresses and NETs of systems deployed in a routeing domain, when these systems operate the protocol defined in this International Standard. The protocol defined in this International Standard assumes that these requirements are met, but has no means to verify compliance with them. The use of a MAC address to derive the system ID is simply a convenience that many vendors have adopted. There may be other ways to derive the ID, but their use or otherwise is out of scope of both the present draft, and IS-IS itself. Note that ISO/IEC 10589 permits the use of a system ID of any length between 1 and 8 octets, with the default length being 6 octets. I'm not aware of any current implementations using a size other than 6. Mike On 31/05/2011 15:15, James Carlson wrote: > mike shand wrote: >> The reference to RFC 1142 is misleading and dangerous. RFC 1142 is a >> poor copy of a pre-standard version of IS-IS ( ISO DP 10589, as opposed >> to ISO/IEC 10589 version 2). There are significant technical differences >> between RFC 1142 and the ISO standard. > Not a problem; I'll update this and the references to sections of the draft. > >> 1) Section 2 para 3 last sentence. >> >> says "If a TNP or TLSP packet is received when TNCP is not in Opened >> state and LCP is Opened, an implementation SHOULD respond using LCP >> Protocol-Reject." >> >> I assume that such a packet MUST be discarded, but that in addition the >> implementation SHOULD respond with a LCP Protocol-Reject. Is this >> correct, and if so, does it need clarification? > Yes, that's correct, and I'll clarify the text. > >> I note that RFC 1661 explicitly states >> "Any supported network-layer protocol packets received when the >> corresponding NCP is not in the Opened state MUST be silently discarded." >> So RFC 1661 requires a silent discard, whereas this draft encourages an >> explicit reject. > You're right; the intent was to conform with 1661, but this text doesn't > manage to do that. I'll repair it. > >> 2) Section 2.2 para 1 >> >> says "When TNCP is in Opened state, TNP packets MAY be sent by setting >> the PPP Protocol field to hex TBD-00XX (TNP) and placing the >> TRILL-encapsulated data in the PPP Information field." >> >> I think this is the wrong use of "MAY". MAY implies that TNP packets may >> be sent as described here, or by some other undisclosed encoding. Surely >> what is meant is that if TNP packets are sent, they MUST be encoded as >> described here. > I can recast to avoid the use of "MAY" in this instance. > >> 4) In addition, it may be helpful here to draw attention to the >> requirement in [1] 4.2.4.1 that the IS-IS three way hand shake MUST be >> used on such links. In particular, the reference (in the present draft) >> in the last sentence of section 2.3 to "only an arbitrary circuit ID", >> rather than an "extended circuit ID" as described in RFC 5303, and the >> clause "do not use Neighbor IDs" at the end of section 3 bullet 1, may >> give the erroneous impression that RFC 5303, (and the "Neighbor System >> ID", and "Neighbor Extended Circuit ID" defined therein) is not mandated >> for PPP links. >> >> That said, I appreciate that this draft should not unnecessarily >> re-state every requirement of the base TRILL spec > The text here is a response to previous concerns that the original draft > did not adequately describe the existing IS-IS mechanism for > point-to-point links. In particular, some reviewers were confused about > the use of Neighbor IDs in Ethernet Hello messages. To the extent > possible, I'd like to avoid duplicating that sort of text, but I do have > those concerns from other reviewers to deal with. > > The text is not at all intended to preclude the use of a Neighbor System > ID as part of RFC 5303 or any other standard IS-IS extension. I'll try > to recast this. > >> 5) Section 3, bullet 3 >> >> The discussion of the issue that there may be no MAC address as a >> possible source for a unique system ID is out of place >> in this draft. It is not a direct consequence of using either PPP or TRILL. >> It is a situation which may arise in any usage of IS-IS where there is >> no MAC >> address available to source the system ID. It seems arbitrary to >> reference [8] in this context, particularly since [8] has not been >> submitted as an IS-IS WG document. > Unfortunately, I agree completely. However, the reviewers in PPPEXT -- > particularly Bill Simpson -- rather vehemently did not agree. > > He argued at length that this had to be a normative reference, because > there were potential cases where IS-IS over PPP could not be used as > described. I argued (as I think you do) that this is really a higher > level IS-IS system design issue, and is not peculiar to TRILL, PPP, or > anything in this draft, and should not be solved here. > > The (lengthy) thread begins here: > > http://www.ietf.org/mail-archive/web/pppext/current/threads.html#00484 > > The rough compromise we were able to achieve was to mention the > potential issue as a warning to implementors, and reference Bill's draft > as one possible solution as an informative reference only. > > Though I agree with you that this issue is clearly out of scope, I'd > very much like to avoid re-opening that kettle of fish by removing the > text. The outcome of a re-spin might end up being worse. > > I could potentially add some text to note that this is not a special > problem with PPP or TRILL, and that it's true of any IS-IS > implementation with only point-to-point links. > > (For what it's worth, we had similar problems with the security issues. > There are no special security issues with the protocol itself, as an > implementation of it relies on existing security mechanisms, but Bill > felt an enumeration was required.) > --------------000504010208070508030105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit James,
    Thanks.

Regarding the last issue, perhaps one of the causes of confusion here is the common belief that the IS-IS spec specifies that the system ID be derived from a MAC address. In fact IS-IS is completely silent on HOW the system ID is assigned, and it simply states, in clause 7.1.4:-
Each system in an area must have an unambiguous ID; that is, no two systems (IS or ES) in an area may use the same ID value.
and
Each Level 2 Intermediate system within a routeing domain must have an unambiguous value for its ID field; that is, no two level 2 ISs in a routeing domain can have the same value in their ID fields.

It states:-

It is the responsibility of the routeing domain administrative authority to enforce the requirements stated below in this clause and the rules stated above in 7.1.3.1. These requirements place specific constraints on the NSAP addresses and NETs of systems deployed in a routeing domain, when these systems operate the protocol defined in this International Standard. The protocol defined in this International Standard assumes that these requirements are met, but has no means to verify compliance with them.

The use of a MAC address to derive the system ID is simply a convenience that many vendors have adopted. There may be other ways to derive the ID, but their use or otherwise is out of scope of both  the present draft, and IS-IS itself.

Note that ISO/IEC 10589 permits the use of a system ID of any length between 1 and 8 octets, with the default length being 6 octets. I'm not aware of any current implementations using a size other than 6.

    Mike




On 31/05/2011 15:15, James Carlson wrote: 
mike shand wrote:

The reference to RFC 1142 is misleading and dangerous. RFC 1142 is a
poor copy of a pre-standard version of IS-IS ( ISO DP 10589, as opposed
to ISO/IEC 10589 version 2). There are significant technical differences
between RFC 1142 and the ISO standard.

Not a problem; I'll update this and the references to sections of the draft.


1) Section 2 para 3 last sentence.

says "If a TNP or TLSP packet is received when TNCP is not in Opened
state and LCP is Opened, an implementation SHOULD respond using LCP
Protocol-Reject."

I assume that such a packet MUST be discarded, but that in addition the
implementation SHOULD respond with a LCP Protocol-Reject. Is this
correct, and if so, does it need clarification?

Yes, that's correct, and I'll clarify the text.


I note that RFC 1661 explicitly states
"Any supported network-layer protocol packets received when the
corresponding NCP is not in the Opened state MUST be silently discarded."
So RFC 1661 requires a silent discard, whereas this draft encourages an
explicit reject.

You're right; the intent was to conform with 1661, but this text doesn't
manage to do that.  I'll repair it.


2) Section 2.2 para 1

says "When TNCP is in Opened state, TNP packets MAY be sent by setting
the PPP Protocol field to hex TBD-00XX (TNP) and placing the
TRILL-encapsulated data in the PPP Information field."

I think this is the wrong use of "MAY". MAY implies that TNP packets may
be sent as described here, or by some other undisclosed encoding. Surely
what is meant is that if TNP packets are sent, they MUST be encoded as
described here.

I can recast to avoid the use of "MAY" in this instance.


4) In addition, it may be helpful here to draw attention to the
requirement in [1] 4.2.4.1 that the IS-IS three way hand shake MUST be
used on such links. In particular, the reference (in the present draft)
in the last sentence of section 2.3 to "only an arbitrary circuit ID",
rather than an "extended circuit ID" as described in RFC 5303, and the
clause "do not use Neighbor IDs" at the end of section 3 bullet 1, may
give the erroneous impression that RFC 5303, (and the  "Neighbor System
ID", and "Neighbor Extended Circuit ID" defined therein) is not mandated
for PPP links.

That said, I appreciate that this draft should not unnecessarily
re-state every requirement of the base TRILL spec

The text here is a response to previous concerns that the original draft
did not adequately describe the existing IS-IS mechanism for
point-to-point links.  In particular, some reviewers were confused about
the use of Neighbor IDs in Ethernet Hello messages.  To the extent
possible, I'd like to avoid duplicating that sort of text, but I do have
those concerns from other reviewers to deal with.

The text is not at all intended to preclude the use of a Neighbor System
ID as part of RFC 5303 or any other standard IS-IS extension.  I'll try
to recast this.


5) Section 3, bullet 3

The discussion of the issue that there may be no MAC address as a
possible source for a unique system ID is out of place
in this draft. It is not a direct consequence of using either PPP or TRILL.
It is a situation which may arise in any usage of IS-IS where there is
no MAC
address available to source the system ID. It seems arbitrary to
reference [8] in this context, particularly since [8] has not been
submitted as an IS-IS WG document.

Unfortunately, I agree completely.  However, the reviewers in PPPEXT --
particularly Bill Simpson -- rather vehemently did not agree.

He argued at length that this had to be a normative reference, because
there were potential cases where IS-IS over PPP could not be used as
described.  I argued (as I think you do) that this is really a higher
level IS-IS system design issue, and is not peculiar to TRILL, PPP, or
anything in this draft, and should not be solved here.

The (lengthy) thread begins here:

http://www.ietf.org/mail-archive/web/pppext/current/threads.html#00484

The rough compromise we were able to achieve was to mention the
potential issue as a warning to implementors, and reference Bill's draft
as one possible solution as an informative reference only.

Though I agree with you that this issue is clearly out of scope, I'd
very much like to avoid re-opening that kettle of fish by removing the
text.  The outcome of a re-spin might end up being worse.

I could potentially add some text to note that this is not a special
problem with PPP or TRILL, and that it's true of any IS-IS
implementation with only point-to-point links.

(For what it's worth, we had similar problems with the security issues.
 There are no special security issues with the protocol itself, as an
implementation of it relies on existing security mechanisms, but Bill
felt an enumeration was required.)
--------------000504010208070508030105-- From stbryant@cisco.com Tue May 31 09:06:53 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74239E088E for ; Tue, 31 May 2011 09:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.597 X-Spam-Level: X-Spam-Status: No, score=-110.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fuyuq7OHIYGy for ; Tue, 31 May 2011 09:06:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 20F8EE07DC for ; Tue, 31 May 2011 09:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2448; q=dns/txt; s=iport; t=1306858009; x=1308067609; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=B+0N99NTlRAkyGJRCmYtpY/6GC+ISfcqNZyuhpdjWUY=; b=Nr4UVdiuiqEwkFp/FJKQy5yjJtE+O5wOMu4KCbXVdRPROmnTN+8rdMpc JzHz/DkoACqA4xsDUmhBXoEtsUXWlzLGXbGgfEuXaz9B7ybzSlunFrAro aENGTKrqNFAbYSN6hmC3wBlwXIHo3yutIaAsGC6wk2PNhKBZzVnFuYuJX E=; X-IronPort-AV: E=Sophos;i="4.65,297,1304294400"; d="scan'208";a="91601818" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 31 May 2011 16:06:47 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4VG6lrN020033; Tue, 31 May 2011 16:06:47 GMT Received: from dhcp-gpk02-vlan300-64-103-65-100.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p4VG6jW09056; Tue, 31 May 2011 17:06:46 +0100 (BST) Message-ID: <4DE51220.2010706@cisco.com> Date: Tue, 31 May 2011 17:06:56 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: James Carlson References: <4DE4E8C3.6030205@cisco.com> <4DE4F7FC.7050708@workingcode.com> <4DE50655.6040500@cisco.com> <4DE50C1D.6040107@workingcode.com> In-Reply-To: <4DE50C1D.6040107@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-pppext-trill-protocol.all@tools.ietf.org, rtg-ads@tools.ietf.org, mike shand Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-trill-protocol-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:06:53 -0000 On 31/05/2011 16:41, James Carlson wrote: > mike shand wrote: >> The use of a MAC address to derive the system ID is simply a convenience >> that many vendors have adopted. There may be other ways to derive the >> ID, but their use or otherwise is out of scope of both the present >> draft, and IS-IS itself. > Understood. > > For what it's worth, I think that there is a second underlying concern > here that's directly related to TRILL, and not just IS-IS in general: > some of the reviewers (correctly, in my opinion) see great value in > making sure that TRILL is always able to operate in a zero-configuration > manner. > > Given that getting a System ID from a manually-configured parameter > would negate that goal, they're willing to drive quite a distance out of > the way in order to make sure that any methods based on manual > configuration are just never required in practice. > > At least that part of the desire is, I think, well-intentioned. > Unfortunately, the result of it is a strong compulsion to avoid any sort > of "provided you meet these constraints, this part is entirely up to > implementors" text, even if that's what the relevant standards allow, > and even if it's perfectly reasonable. Therein lay the problem. > > Personally, if I were designing a PPP-only system, I'd make sure that > the hardware design includes a serialization number that can be used to > construct a proper ID. I wouldn't bother with any random-number tricks; > I think they're a bunch of guff. > > But that -- overall system design -- is just so far out of scope that > I'm not really interested in inserting text into any IETF Standards > Track document to describe it. > > I'll try to do some rewording in this area, but given the constraints of > the consensus we've gotten (and the painful difficulty in getting that > far), I don't think I can just remove the text entirely. > How about saying something like: ISO/IEC 10589 states that it is the responsibility of the routeing domain administrative authority to enforce the uniqueness of the system ID. In cases where a zero configuration system is supplied the system manufacturer MUST install a suitable unique identifier at manufacturing time. One way to achieve this is for the manufacturer to use a unique IEEE MAC address following the allocation procedures normally used in the manufacture of an Ethernet interface. Stewart From carlsonj@workingcode.com Tue May 31 08:41:23 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4366BE0751 for ; Tue, 31 May 2011 08:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgy6TEzARr+Y for ; Tue, 31 May 2011 08:41:22 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 63045E0701 for ; Tue, 31 May 2011 08:41:22 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p4VFfHqE017309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2011 11:41:17 -0400 (EDT) Message-ID: <4DE50C1D.6040107@workingcode.com> Date: Tue, 31 May 2011 11:41:17 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: mike shand References: <4DE4E8C3.6030205@cisco.com> <4DE4F7FC.7050708@workingcode.com> <4DE50655.6040500@cisco.com> In-Reply-To: <4DE50655.6040500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: carlson; whitelist X-Mailman-Approved-At: Tue, 31 May 2011 09:13:32 -0700 Cc: rtg-dir@ietf.org, draft-ietf-pppext-trill-protocol.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pppext-trill-protocol-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 15:41:23 -0000 mike shand wrote: > The use of a MAC address to derive the system ID is simply a convenience > that many vendors have adopted. There may be other ways to derive the > ID, but their use or otherwise is out of scope of both the present > draft, and IS-IS itself. Understood. For what it's worth, I think that there is a second underlying concern here that's directly related to TRILL, and not just IS-IS in general: some of the reviewers (correctly, in my opinion) see great value in making sure that TRILL is always able to operate in a zero-configuration manner. Given that getting a System ID from a manually-configured parameter would negate that goal, they're willing to drive quite a distance out of the way in order to make sure that any methods based on manual configuration are just never required in practice. At least that part of the desire is, I think, well-intentioned. Unfortunately, the result of it is a strong compulsion to avoid any sort of "provided you meet these constraints, this part is entirely up to implementors" text, even if that's what the relevant standards allow, and even if it's perfectly reasonable. Therein lay the problem. Personally, if I were designing a PPP-only system, I'd make sure that the hardware design includes a serialization number that can be used to construct a proper ID. I wouldn't bother with any random-number tricks; I think they're a bunch of guff. But that -- overall system design -- is just so far out of scope that I'm not really interested in inserting text into any IETF Standards Track document to describe it. I'll try to do some rewording in this area, but given the constraints of the consensus we've gotten (and the painful difficulty in getting that far), I don't think I can just remove the text entirely. -- James Carlson 42.703N 71.076W