From martin.vigoureux@alcatel-lucent.com Wed Jun 1 05:57:32 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 6E17BE130E for ; Wed, 1 Jun 2011 05:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 GxQRsIFcNLqH for ; Wed, 1 Jun 2011 05:57:31 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 35AB01304A2 for ; Wed, 1 Jun 2011 05:32:44 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p51CWdVq012502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2011 07:32:39 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p51CWcxs015078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 1 Jun 2011 07:32:38 -0500 Received: from [135.244.22.181] (135.3.63.241) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 1 Jun 2011 07:32:38 -0500 Message-ID: <4DE63160.3040608@alcatel-lucent.com> Date: Wed, 1 Jun 2011 14:32:32 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: rtg-dir@ietf.org, draft-ietf-mpls-lsp-ping-enhanced-dsmap.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.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: Wed, 01 Jun 2011 12:57:32 -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-mpls-lsp-ping-enhanced-dsmap-09.txt Reviewer: Martin Vigoureux Review Date: June 1st, 2011 IETF LC End Date: May 30th, 2011 Intended Status: Standards Track Sorry for the delay. Regards, Martin --- Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Major Issues: No major issues found Minor Issues: I only found one minor issue. From Sections 3.2.1 and 3.3 it is not clear whether the new Return Code "See DDM TLV for Return Code and Return SubCode" is to be used (in the echo reply header) only if there are multiple DDMAP TLVs in this reply or if it may/could/should/must also be used in case there is only a single DDMAP TLV. Comments: This document is well written. The motivation section is really valuable. The procedures are sufficiently well described to avoid confusion. Nits: There is quite a number of nits in this document. Figure numbering is arguable. Figure 10 is missing, Figure 3 does not have a description and in my opinion, figures 3, 5, 9, 14 and the unidentified Figure 10, are not figures. A reference to stiching procedures would be valuable. LSP-Ping is used inconsistently throughout the document (LSP ping, LSP-Ping, LSP Ping, LSP-ping, ...). Please use only one. The document uses both echo reply and echo response. Based on RFC 4379, I believe the appropriate terminology would be echo reply. Section 1 This documents describes methods for performing LSP ping (specified s/documents/document/ Section 1 in [RFC4379] traceroute over MPLS tunnels. The techniques in s/in [RFC4379]/in [RFC4379])/ Section 2 happening at router C. With current LSP Ping [[RFC4379]] mechanisms, s/[[RFC4379]]/[RFC4379]/ Section 3.3 Downstream Mapping object is a request that Downstream Detailed s/Downstream Mapping/Downstream Detailed Mapping/ Section 3.3.1.1 The multipath data sub-TLV includes information multipath s/information// Section 3.3.1.1 information. The TLV fields and their usage is as defined in s/TLV/sub-TLV/ Section 4.1.1 PUSHed. The label MUST be encoded as per Figure 7.The label value s/Figure 7.The/Figure 7. The/ Section 4.3.3 topology based off the Return Code per ECMP path/P2MP branch. s/based off/based on/ From carlsonj@workingcode.com Tue May 31 09:52: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 A1605E085F for ; Tue, 31 May 2011 09:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 tWD0UUW22px9 for ; Tue, 31 May 2011 09:52:58 -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 6601DE068E for ; Tue, 31 May 2011 09:52:57 -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 p4VGqqMp018472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 May 2011 12:52:52 -0400 (EDT) Message-ID: <4DE51CE4.2060807@workingcode.com> Date: Tue, 31 May 2011 12:52:52 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: stbryant@cisco.com References: <4DE4E8C3.6030205@cisco.com> <4DE4F7FC.7050708@workingcode.com> <4DE50655.6040500@cisco.com> <4DE50C1D.6040107@workingcode.com> <4DE51220.2010706@cisco.com> In-Reply-To: <4DE51220.2010706@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: carlson; whitelist X-Mailman-Approved-At: Wed, 01 Jun 2011 06:50:15 -0700 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 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:52:58 -0000 Stewart Bryant wrote: > 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. It lacks the reference to Bill's draft, which I understood to be a minimal requirement of the agreement we'd reached. I expect that to provoke trouble, but I'll try passing it by the PPPEXT list to see what happens. -- James Carlson 42.703N 71.076W From jari.arkko@piuha.net Thu Jun 2 09:41: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 55408E07FC for ; Thu, 2 Jun 2011 09:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 IaOwIX4NjKwA for ; Thu, 2 Jun 2011 09:41:44 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 12828E065B for ; Thu, 2 Jun 2011 09:41:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B54682CC4D; Thu, 2 Jun 2011 19:41:41 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KbdKDKNoN1W; Thu, 2 Jun 2011 19:41:37 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A05482CC3B; Thu, 2 Jun 2011 19:41:37 +0300 (EEST) Message-ID: <4DE7BD40.1090003@piuha.net> Date: Thu, 02 Jun 2011 19:41:36 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) 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: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Jun 2011 14:21:16 -0700 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 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 16:41:46 -0000 James, Mike, et al, Thank you Mike for the review! Yes, we absolutely have to update the document for the right reference. Re: systemID issue. I'd love to throw that text out. In my AD review I already attempted to make it clear that Simpson's draft is just one proposal. If you and perhaps others agree that the systemID discussion belongs entirely in ISIS WG then I would be very happy to say remove all that text. James: > 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. Really? IIRC it was only Simpson, was it others as well? We don't need unanimous agreement... Jari > 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.) > > From jari.arkko@piuha.net Thu Jun 2 09:43:19 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 A0900E0804 for ; Thu, 2 Jun 2011 09:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 PeBChOTTdgsp for ; Thu, 2 Jun 2011 09:43:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 96C81E0800 for ; Thu, 2 Jun 2011 09:43:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1E0FC2CC4D; Thu, 2 Jun 2011 19:43:16 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlAzztu2+Z7O; Thu, 2 Jun 2011 19:43:15 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 7D0992CC3B; Thu, 2 Jun 2011 19:43:15 +0300 (EEST) Message-ID: <4DE7BDA2.6000304@piuha.net> Date: Thu, 02 Jun 2011 19:43:14 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: James Carlson References: <4DE4E8C3.6030205@cisco.com> <4DE4F7FC.7050708@workingcode.com> <4DE50655.6040500@cisco.com> <4DE50C1D.6040107@workingcode.com> <4DE51220.2010706@cisco.com> <4DE51CE4.2060807@workingcode.com> In-Reply-To: <4DE51CE4.2060807@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 02 Jun 2011 14:21:17 -0700 Cc: rtg-dir@ietf.org, draft-ietf-pppext-trill-protocol.all@tools.ietf.org, mike shand , rtg-ads@tools.ietf.org, stbryant@cisco.com 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: Thu, 02 Jun 2011 16:43:19 -0000 James Carlson kirjoitti: > Stewart Bryant wrote: > >> 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. >> > I like this. > It lacks the reference to Bill's draft, which I understood to be a > minimal requirement of the agreement we'd reached. > > I expect that to provoke trouble, but I'll try passing it by the PPPEXT > list to see what happens. > I'm not sure it was others than Bill. His opinion may be in the rough. Jari From jari.arkko@piuha.net Fri Jun 3 03:59: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 A9CECE067A; Fri, 3 Jun 2011 03:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.187 X-Spam-Level: X-Spam-Status: No, score=-102.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 MqT3yUDgI+8X; Fri, 3 Jun 2011 03:59:55 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 0B73AE072C; Fri, 3 Jun 2011 03:59:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 252632CC3C; Fri, 3 Jun 2011 13:59:51 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-XWEvz+W80V; Fri, 3 Jun 2011 13:59:50 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 30D9D2CC3B; Fri, 3 Jun 2011 13:59:50 +0300 (EEST) Message-ID: <4DE8BEA5.2070100@piuha.net> Date: Fri, 03 Jun 2011 13:59:49 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "ipdir@ietf.org" , rtg-dir@ietf.org, IAB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 05 Jun 2011 03:29:21 -0700 Subject: [RTG-DIR] feedback for a home networking working group proposal 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: Fri, 03 Jun 2011 10:59:55 -0000 Some time ago the IETF had a few BOFs around the topic of home gateways in the transport area. While this effort went pretty far, we never created a working group due to various scope disagreements. I now have a new proposal, more focused on IP layer configuration in the type of networks that we believe we will see in SOHO networks in the coming years. The proposal has been worked in the background by Mark Townsley, Stuart Cheshire and a few others. I believe it is important that we do something in this area, because sensor networks, multiple specialized network segments, and other trends are driving us to a situation where it may no longer be trivial for equipment to configure itself correctly automatically. In IPv4 we know there is a partial solution but we'd like to define how to do this right in IPv6. Comments appreciated: FUture home Networks (FUN) ------------------------- Current Status: Proposed Last Edit: Friday, June 3rd, 2011 Chairs: TBD Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: fun@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology in small networks such as those in homes. This evolution sets some requirements on IETF protocols. An obvious trend for home networking is the proliferation of networking technology in increasing number of different devices, from home entertainment systems to appliances and energy applications, just to name a few examples. This leads to a higher number of networked devices in each network. However, some more fundamental changes are occurring at the same time as well: o First, the link layer networking technology is become more heterogeneous, as networks are starting to employ, for instance, both traditional Ethernet technology and link layers designed for low-powered sensor networks. o Networks are also moving from a "one size fits all" model to dedicated segments for specific purposes. For instance, a common feature in high-end home routers in the ability to support both guest and private network segments. Similar needs for separation may occur in other cases, such as separating building control from the Internet access network. Typically, different subnets, routing and firewalls are used between the different segments. o Service providers are rolling out networks that support IPv6, and home gateway support for IPv6 is starting to appear. But for home networks, IPv6 is not just a new protocol, it also changes address allocation principles and allows end-to-end communication to the devices in the home. o End-to-end communication is both an opportunity and a problem, as it enables new applications but also exposes nodes in the internal networks to unwanted traffic from the Internet. Firewalls are in many cases needed to prevent exposure. However, this reduces the usefulness of end-to-end connectivity, as the firewall policy model is usually default deny, only allowing a small set of known protocols. In addition, consumer equipment typically reacts slowly if at all to changes in the typical Internet application, and it is likely that traffic for a popular application is not recognized by devices manufactured before that application was launched. Future home networks need to provide the tools to handle these situations in an easy manner. It is obvious that manual configuration is rarely possible. For IPv4, NAT and private address based solutions already provide limited solutions. The purpose of this working group is to develop an architecture and necessary additional tools for IPv6, to address the full scope of requirements: o prefix configuration for routers o managing routing (including turning it on by default) o name resolution o service discovery o perimeter security Specifically, the group should produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture. In addition, the group will apply existing protocols to handle the five requirements above. For prefix configuration, DHCPv6 PD is an obvious candidate solution, possibly supplemented by some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on. For name resolution and service discovery, extensions are needed to mDNS and DNS-SD to enable them to work across subnets. For perimeter security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a default allow security policy. This may be accomplished, for instance, through driving security policy from an up-to-date database in the Internet or using simple security along with firewall control protocols such as PCP. It is expected that the working group defines a set of protocol specifications to accomplish the five requirements from above. However, it is NOT in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are visible to hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The working group will liaise with the relevant IETF working groups and other standards bodies. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and get feedback on DNS issues from the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the FUN working group providing the architecture and requirements for such enhancements. Milestones: Oct 2011 First WG draft on the architecture Dec 2011 First WG draft on prefix configuration Dec 2011 First WG draft on routing Jan 2011 First WG draft on name resolution Feb 2011 First WG draft on service discovery Feb 2011 First WG draft on perimeter security Feb 2012 Submission of the architecture draft to the IESG as Informational RFC Feb 2012 Start of routing related work in the relevant routing area working group, if needed Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 Submission of the routing draft to the IESG as Informational RFC Jun 2012 Submission of the name resolution draft to the IESG as Standards Track RFC Jun 2012 Submission of the service discovery draft to the IESG as Standards Track RFC Aug 2012 Submission of the perimeter security draft to the IESG as Informational RFC From nitinb@juniper.net Mon Jun 6 17:21:21 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 D24C621F84BC for ; Mon, 6 Jun 2011 17:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LP6pc9lyVbVy for ; Mon, 6 Jun 2011 17:21:21 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2A83421F84BA for ; Mon, 6 Jun 2011 17:21:20 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTe1u+NdShowVe3Sl8kT8RN+YSR6yoxx/@postini.com; Mon, 06 Jun 2011 17:21:20 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 6 Jun 2011 17:21:03 -0700 From: Nitin Bahadur To: Martin Vigoureux , "rtg-ads@tools.ietf.org" Date: Mon, 6 Jun 2011 17:21:02 -0700 Thread-Topic: RtgDir review: draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt Thread-Index: AcwgWBUAKnigYD50R6KQNYBqpSFMzQEULNFE Message-ID: In-Reply-To: <4DE63160.3040608@alcatel-lucent.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 07 Jun 2011 05:13:32 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-enhanced-dsmap.all@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.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, 07 Jun 2011 00:21:22 -0000 Hi Martin, Thanks for review. I have addressed the nits and added the reference to L= SP stitching. Regarding the one minor comment, please see below.. Thanks Nitin On 6/1/11 5:32 AM, "Martin Vigoureux" = wrote: Minor Issues: I only found one minor issue. From Sections 3.2.1 and 3.3 it is not clear whether the new Return Code "See DDM TLV for Return Code and Return SubCode" is to be used (in the echo reply header) only if there are multiple DDMAP TLVs in this reply or if it may/could/should/must also be used in case there is only a single DDMAP TLV. Updated Section 3.2.1 to say This Return Code MUST be used when there are multiple downstreams for a given node (such as P2MP or ECMP), and the node needs to return a different Return Code/Return SubCode f= or each downstream. This Return Code MAY be used when there is only 1 downstream for a given node. From Adrian.Farrel@huawei.com Tue Jun 7 13:58: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 C9F8C11E820C for ; Tue, 7 Jun 2011 13:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 BaKDyw5wGT9Q for ; Tue, 7 Jun 2011 13:58:52 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF3C11E815D for ; Tue, 7 Jun 2011 13:58:52 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMF0063YUA3YL@usaga03-in.huawei.com> for rtg-dir@ietf.org; Tue, 07 Jun 2011 15:58:51 -0500 (CDT) Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMF00KOWUA2GR@usaga03-in.huawei.com> for rtg-dir@ietf.org; Tue, 07 Jun 2011 15:58:51 -0500 (CDT) Date: Tue, 07 Jun 2011 21:58:44 +0100 From: Adrian Farrel In-reply-to: <666AC2E8-ECF9-4C64-98B3-839315ED56C3@gmail.com> To: rtg-dir@ietf.org Message-id: <027101cc2555$b1203e70$1360bb50$@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: AQItPGAsrJKGugBKJfMkjDSnBE2Cs5PwMipA References: <666AC2E8-ECF9-4C64-98B3-839315ED56C3@gmail.com> Subject: [RTG-DIR] FW: Liaison and request for review of ITU-T document 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: Tue, 07 Jun 2011 20:58:52 -0000 Although not directly related to routing, it is important that this ITU-T document gets proper review so I thought I would flag it to you folk in the hope that one of you has some time. Review comments to ietf@ietf.org Thanks, Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Ralph > Droms > Sent: 07 June 2011 21:28 > To: IETF Discussion > Subject: Liaison and request for review of ITU-T document > > The IETF has recently received a liaison from ITU-T Q5/SG-11 regarding a Draft > Recommendation. That liaison is available as > https://datatracker.ietf.org/liaison/1054/. The official liaison is available at > https://datatracker.ietf.org/documents/LIAISON/file1232.pdf. > > The liaison asks for IETF review of Draft Recommendation "Signalling protocols > and procedures relating to Flow State Aware QoS control in a bounded sub- > network of a NGN", which is available at > https://datatracker.ietf.org/documents/LIAISON/file1231.pdf. This note opens > an IETF comment period on the document, ending midnight, anywhere on earth, > 2011/7/5. After the comment period, a summary will be prepared and returned > in a liaison to ITU-T Q5/SG-11. > > Of specific interest to the IETF are any ways in which the "signalling protocols and > procedures" defined in the Draft Recommendation might interact with existing > IETF Internet protocols. We are especially interested in potential adverse > interactions or interference with IETF Internet protocols. The technical merits of > the "signalling protocols and procedures" defined in the Draft Recommendation > are of interest inasmuch as the IETF community might provide technical advice > and recommendations to improve the Draft Recommendation itself. > > Please respond with any comments on the Draft Recommendation to > ietf@ietf.org. Thanks in advance for your review of the Draft Recommendation. > > - Ralph Droms, Internet Area Director > for the IESG > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From martin.vigoureux@alcatel-lucent.com Tue Jun 7 23:59:18 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 1245411E80C3 for ; Tue, 7 Jun 2011 23:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 LVpLHAd1KJ+q for ; Tue, 7 Jun 2011 23:59:17 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7D58C11E8071 for ; Tue, 7 Jun 2011 23:59:17 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p586xDxJ020336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2011 01:59:14 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p586xDaJ030707 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 8 Jun 2011 01:59:13 -0500 Received: from [135.244.32.34] (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 8 Jun 2011 01:59:12 -0500 Message-ID: <4DEF1DBC.5070704@alcatel-lucent.com> Date: Wed, 8 Jun 2011 08:59:08 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nitin Bahadur References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-enhanced-dsmap.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.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: Wed, 08 Jun 2011 06:59:18 -0000 Hi Nitin, thanks. That addresses the issue I raised. martin Le 07/06/2011 02:21, Nitin Bahadur a écrit : > Hi Martin, > > Thanks for review. I have addressed the nits and added the reference to LSP stitching. Regarding the one minor comment, please see below.. > > Thanks > Nitin > > On 6/1/11 5:32 AM, "Martin Vigoureux" wrote: > > Minor Issues: > I only found one minor issue. > From Sections 3.2.1 and 3.3 it is not clear whether the new Return > Code "See DDM TLV for Return Code and Return SubCode" is to be used > (in the echo reply header) only if there are multiple DDMAP TLVs in > this reply or if it may/could/should/must also be used in case there > is only a single DDMAP TLV. > > > Updated Section 3.2.1 to say > > This Return Code MUST be used when there are > multiple downstreams for a given node (such as P2MP or ECMP), and > the node needs to return a different Return Code/Return SubCode for > each downstream. This Return Code MAY be used when there is > only 1 downstream for a given node. > From adrian@olddog.co.uk Fri Jun 24 13:12:47 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 9D1FE21F851A; Fri, 24 Jun 2011 13:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_05=-1.11] 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 l7JiaZ7xr4zX; Fri, 24 Jun 2011 13:12:47 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id BEC7221F850F; Fri, 24 Jun 2011 13:12:45 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5OKCiaH000711; Fri, 24 Jun 2011 21:12:44 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5OKCgrd000703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Jun 2011 21:12:43 +0100 From: "Adrian Farrel" To: , , Date: Fri, 24 Jun 2011 21:12:43 +0100 Message-ID: <024f01cc32ab$13ed0a80$3bc71f80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcwyqrCxjXsFkbQnT1eVpb640f5YmA== Content-Language: en-gb Subject: [RTG-DIR] Routing ADs Office Hours - Quebec X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 20:12:47 -0000 Hi, Tradition is a powerful thing. Stewart and I have booked the IESG Breakout Room (room name to be advised) in Quebec on Sunday 24th from 14:00 to 16:00. Please drop by and tell us what is on your mind. Or book some private time with us during the week. Cheers, Adrian and Stewart From adrian@olddog.co.uk Fri Jun 24 13:13: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 5D9C521F8536; Fri, 24 Jun 2011 13:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599] 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 OmqXvIVD3wLs; Fri, 24 Jun 2011 13:13:36 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3BA21F853E; Fri, 24 Jun 2011 13:13:28 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5OKDQhs000942; Fri, 24 Jun 2011 21:13:26 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5OKDPga000935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Jun 2011 21:13:26 +0100 From: "Adrian Farrel" To: , , Date: Fri, 24 Jun 2011 21:13:25 +0100 Message-ID: <025601cc32ab$2d43b470$87cb1d50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcwyqytZ6r2q+SBtQB2auTEApljmgg== Content-Language: en-gb Subject: [RTG-DIR] Routing Area Open Meeting in Quebec X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 20:13:36 -0000 Please let Stewart and me know of any topics you would like to cover in this meeting. Our preference is for routing-related discussions that will benefit from having the whole area present. It has been suggested that there might be a need/desire for a BFD tutorial. We have a willing presenter, but we don't want to waste anyone's time preaching to the choir. Who would see this as a good thing? Thanks, Adrian From thomas@thomasclausen.org Tue Jun 28 09:47: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 7870A11E80DB for ; Tue, 28 Jun 2011 09:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 f5QY+BDG1Rf4 for ; Tue, 28 Jun 2011 09:47:22 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0B19411E808C for ; Tue, 28 Jun 2011 09:47:22 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[10.0.1.5]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1QbbRZ-00021O-41; Tue, 28 Jun 2011 16:47:21 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18iXzsmzhyldhsfIDRKuGFA From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jun 2011 18:47:17 +0200 Message-Id: To: rtg-ads@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-pim-mtid.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.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, 28 Jun 2011 16:47:23 -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-pim-mtid-08.txt=20 Reviewer: Thomas Heide Clausen Review Date: 2011-06-27 IETF LC End Date: 2011-06-27 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think = should be resolved before publication. Comments: This is the first PIM document I have reviewed, so I went back = and read some of the previous=20 RFCs. It may mean that my review is not sufficiently in-depth. The document is relatively difficult to read. Specifically the = introduction reads more like a=20 problem statement (e.g. "if PIM was able to access .... it would = be ...") than it does a specification.=20 I would much prefer to have perhaps a very short motivational = subsection to the introduction, then introduce that which this document actually introduces (and = how). Currently, that is difficult to extract. I feel that RFC2119 language is not used consistently, and that = terminology in general is=20 used somewhat inconsistently. Is "MT-ID" and "PIM MT-ID" the = same or different things, for example? I would suggest that this is in part due to the absence of the = by now traditional "Terminology" section, which (in my opinion) has as its primary role to ensure that = spec-authors are conscious and consistent in their choice of words inside a spec. I find that there are some internal inconsistencies in the = document, i.e. where it is stating different things in different sections (e.g. that one MUST NOT include a = MT-ID Join Attribute with value 0 --=20 yet that when performing a validity check, a Join packet with an = MT-ID=3D0 is still considered valid).=20 One concern that I do have with the document is, that there are = no references to any kind of previous work (typically, I would expect this to have been well = studied in academia) suggesting the usefulness and justifying the validity of the proposed = approach. Note: I am not saying that the approach isn't useful and valid - I am saying that I do not = know, and would feel comforted by some supporting references to this effect. Major Issues: o I have actually not found any single "major issues", = however I feel that the document is hard to read and that the collection of the "minor = issues" below would constitute a single "major issue". Minor Issues: o The RFC2119 language is typically seen in a terminology = section; something which I feel that this document should have, if for no reason = other than to help new readers to PIM family of documents. It could be as simple as = importing (pointing to) relevant=20 terminology from RFC5496/5384/4601 o Also, the RFC2119 paragraph does not reflect the errata = ("NOT RECOMMENDED"=20 is missing) o Penultimate paragraph of section 2 "It might further = need to perform the function of splitting and merging. But the detailed processing is = beyond the scope of the=20 document". It would be beneficial with elaboration of = under which conditions=20 "splitting and merging" is required, as well as some = guidance - for example, in form of a pointer to where these conditions are detailed. o Ultimate paragraph of section 2: "the MT-ID Join = Attribute may be simply referred to as MT-ID" -- suggest "the MT-ID Join Attribute will be referred to = as MT-ID =09 o This may be a matter of individual style, but I do not = like empty section introductions,=20 such as 3.=20 o 3rd paragraph in 3.1, suggest removing "please" o Suggest that the figure in 3.1 be given a proper figure = environment and number, and that references (especially later in the document) be = given to that figure number. o As a relatively newcomer to PIM, examples are = appreciated. Alas, the example in=20 section 3.1 actually didn't help my understanding much. = Also, that example is filled with details, whose importance I am not sure I = capture: is the choice of=20 "OSPF 1000" and "OSPF 2000" (etc.) important, or are = they simply illustrative. o First paragraph on page 5 states "The above example = shows that the naming spaces of=20 MT-ID are not required to be the same between PIM and = IGPs". That appears reasonable=20 -- however the last bullet point in section 3.2 on the = same page goes on to say that=20 "...the PIM MT-ID is RECOMMENDED to be assigned using = the same value as the IGP=20 topology identifier". Citing RFC2119: 3. SHOULD This word, or the adjective = "RECOMMENDED", mean that there may exist valid reasons in particular = circumstances to ignore a particular item, but the full implications = must be understood and carefully weighed before choosing a different = course. It appears to me that if this RFC2119 meaning is = intended, then it would be important to (i) explain why and (ii) give guidance as to = understand what the implications are of not following the recommendation. o Also, the document contains many uses of "must", "may" = and "should" in lowercase - I am wondering if some (all?) of these should be capitalized = to RFC2119 terms. I am trying to point out those I catch, but I would recommend that the = authors review the document to ensure that they capitalize those where they mean = RFC2119 terminology. o On the same first paragraph on page 5, when I read " = .... shows that ....", then I actually expect a bit more rigor - tainted by having spent too = much time in academia, perhaps, but I read "...shows that ..." to entail (close to) a = formal proof. Maybe "....illustrates that..." is a better choice of words? Same holds for the last bullet point on page 5. o Same paragraph, what exactly is meant by "...the prefix = covering S...."? I assume that it has something to do with that routing state for S is = not maintained by the two routing topologies? o Generally to section 3.1, it is somewhat unclear what = this specification does, vs. what PIM already does, which caused me to chase off reading = PIM RFCs. =09 Reading through the specification, would it be correct = to say that: - This I-D introduces a new name-space, = the "PIM MT-ID" - A given topology is provisioned with = that "PIM MT-ID" by way of a "MT-ID PIM Join Attribute", defined by = this specification? If yes, then I would suggest calling that out = explicitly. o Section 3.2, second bullet-point talks about "...a value = is not required to be the same as=20 the MT-ID used by the unicast routing protocol ...." = However the ultimate paragraph in section 2 defines MT-ID to be a "Join Attribute", which = is a PIM-entity (RFC5384). Do you mean to say that this MT-ID should be used also in = an unicast routing protocol, or is it a terminology issue? o Page 6, second bullet "This value must be unique and = consistent within the network domain...." - must or MUST? - "network domain" is a wonderfully vague = term. A quick google leads to the first many results relating to either = "LAN-style domain controllers" or DNS. Suggest that his might be a good = candidate term for replacement, or for definition in a terminology section. o Section 4.2.1, "...it may chose" - may or MAY? Also, can = guideline be given as to when a PIM router would chose to, or not, encode the PIM = MT-ID? Finally, "PIM MT-ID", is that the same as what the ultimate paragraph of section 2 = calls "MT-ID". o Section 4.2.1: missing colon before bullet points o Section 4.2.1 first bullet point: why MUST NOT? What are = the consequences of including a Join Attribute when the MT-ID=3D0? Specifically, in 4.2.3, the ultimate bullet, the = validation rules simply state that if the value is 0, then the Join Attribute "...is ignored" = (there is a SHOULD or MUST=20 needed here?) and that the rest of the message is = processed as if that Join Attribute was not included. o Section 4.2.1 2nd and 3rd bullet points, why "SHOULD = NOT"? Can any guidance be provided with respect to the consequences of ignoring = such recommendation (or, if there are no negative consequences, then the = benefits of following them)? o Section 4.2.2 first bullet - prefer section references = (if using xml2rfc tags) rather than "next section" or "in section Conflict = Resolution". This is a general comment, but this seemed like a good point to mention this. o Section 4.2.3, first bullet: as t his is about = "Validating a PIM MT-ID Join Attribute", I find it curious that it suggests to check that there is at most = 1 PIM MT-ID Join Attribute included -=20 then goes on to say that it's OK if there are more, just = ignore all but the last. I would suggest that either this is a validation check and so if more = than 1 PIM MT-ID Join Attribute then the packet is malformed and should be discarded - or, = that this be specified somewhere other than a section specifying how to determine if an = attribute is valid or not. o Same section & bullet: the title is "Validating a PIM = MT-ID Join Attribute", i.e. validating _a_ single such. Yet, the bullet talks about having possibly = multiple PIM MT-ID Join Attributes encoded. Encoded where? Should this section be retitled = "Validating a Join Packet with a PIM MT-ID=20 Join Attribute" instead? o Section 5: Suggest that encoding, byte-order, ..., be = called out (NBO, unsigned integer, ....) for newly defined fields. o Section 5: Suggest calling out that reserved bits SHOULD = be cleared on transmission and=20 MUST be ignored on reception. o Section 5: Suggest citing the spec defining the format = used (RFC5384?), least it appears odd to have an 8 bit "Length" field, and yet defining = its value to always be 2. o Section 6, IANA considerations. - Suggest that "The IANA" be replaced by = simply "IANA" - 2nd paragraph, should it be "IANA has = assigned the PIM HELLO Option Type ...." - I do not understand what the IANA action = for the ultimate paragraph in 6.1 is about? Respectfully Yours, Thomas= From dimitri.papadimitriou@alcatel-lucent.com Tue Jun 28 13:11: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 0870411E8120; Tue, 28 Jun 2011 13:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 jUYFD72G+lcA; Tue, 28 Jun 2011 13:11:48 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 60AA911E80F3; Tue, 28 Jun 2011 13:11:46 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5SKBdmF003169 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Jun 2011 22:11:39 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 28 Jun 2011 22:11:39 +0200 From: "Papadimitriou, Dimitri (Dimitri)" To: "adrian@olddog.co.uk" , Stewart Bryant Date: Tue, 28 Jun 2011 22:07:49 +0200 Thread-Topic: [RTG-DIR] Routing Area Open Meeting in Quebec Thread-Index: AcwyqytZ6r2q+SBtQB2auTEApljmggDHsDhA Message-ID: References: <025601cc32ab$2d43b470$87cb1d50$@olddog.co.uk> In-Reply-To: <025601cc32ab$2d43b470$87cb1d50$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 X-Mailman-Approved-At: Tue, 28 Jun 2011 13:24:05 -0700 Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Open Meeting in Quebec 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, 28 Jun 2011 20:11:49 -0000 Hi Adrian & Stewart It may be interesting to hear from CONEX (congestion volume measure/policin= g/etc., delta wrt ECN/RFC3168, IPv6 header processing (since the initial wo= rk focus on v6), etc.) and implications on forwarding plane and associated = control. This work is ongoing since Anaheim and it would be good to have a = clearer understanding of their use cases, and their experiments (initial re= sults). Many thanks, -dimitri. > -----Original Message----- > From: rtg-dir-bounces@ietf.org=20 > [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, June 24, 2011 10:13 PM > To: rtg-chairs@ietf.org; rtg-dir@ietf.org; routing-discussion@ietf.org > Subject: [RTG-DIR] Routing Area Open Meeting in Quebec >=20 > Please let Stewart and me know of any topics you would like=20 > to cover in this > meeting. >=20 > Our preference is for routing-related discussions that will=20 > benefit from having > the whole area present. >=20 > It has been suggested that there might be a need/desire for a=20 > BFD tutorial. We > have a willing presenter, but we don't want to waste anyone's=20 > time preaching to > the choir. Who would see this as a good thing? >=20 > Thanks, > Adrian >=20 > = From gogwim@unijos.edu.ng Mon Jun 27 00:28:54 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 DF6EE21F8612; Mon, 27 Jun 2011 00:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 PsELp3k0sxtg; Mon, 27 Jun 2011 00:28:53 -0700 (PDT) Received: from staffmail.unijos.edu.ng (staffmail.unijos.edu.ng [196.46.147.201]) by ietfa.amsl.com (Postfix) with ESMTP id 45D7021F85FF; Mon, 27 Jun 2011 00:28:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by staffmail.unijos.edu.ng (Postfix) with ESMTP id 6113F700B41AF; Mon, 27 Jun 2011 08:24:23 +0100 (WAT) X-Virus-Scanned: amavisd-new at unijos.edu.ng Received: from staffmail.unijos.edu.ng ([127.0.0.1]) by localhost (staffmail.unijos.edu.ng [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GODY9oMxKZ39; Mon, 27 Jun 2011 08:24:20 +0100 (WAT) Received: from imap.unijos.edu.ng (unknown [10.0.0.4]) by staffmail.unijos.edu.ng (Postfix) with ESMTP id C1F6B700B41A3; Mon, 27 Jun 2011 08:24:20 +0100 (WAT) Received: from mail.unijos.edu.ng (localhost.localdomain [127.0.0.1]) by imap.unijos.edu.ng (Postfix) with ESMTP id E53243E5C18; Mon, 27 Jun 2011 08:47:16 +0100 (WAT) Received: from 41.78.80.106 (SquirrelMail authenticated user gogwim) by mail.unijos.edu.ng with HTTP; Mon, 27 Jun 2011 08:47:16 +0100 (WAT) Message-ID: <1367.41.78.80.106.1309160836.squirrel@mail.unijos.edu.ng> In-Reply-To: <025601cc32ab$2d43b470$87cb1d50$@olddog.co.uk> References: <025601cc32ab$2d43b470$87cb1d50$@olddog.co.uk> Date: Mon, 27 Jun 2011 08:47:16 +0100 (WAT) From: "GOGWIM, JOEL GODWIN" To: adrian@olddog.co.uk User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Tue, 28 Jun 2011 13:25:12 -0700 Cc: rtg-dir@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Open Meeting in Quebec X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gogwim@unijos.edu.ng List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 07:28:55 -0000 Hi Adrian, Having the tutorial to me is a good idea and the presenter should go ahead. On Fri, June 24, 2011 9:13 pm, Adrian Farrel said: > Please let Stewart and me know of any topics you would like to cover in > this > meeting. > > Our preference is for routing-related discussions that will benefit from > having > the whole area present. > > It has been suggested that there might be a need/desire for a BFD > tutorial. We > have a willing presenter, but we don't want to waste anyone's time > preaching to > the choir. Who would see this as a good thing? > > Thanks, > Adrian > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > From matthew.bocci@alcatel-lucent.com Wed Jun 29 05:00: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 7A9BB21F865A for ; Wed, 29 Jun 2011 05:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 ZVJuMPAsfs02 for ; Wed, 29 Jun 2011 05:00:54 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADC621F86FF for ; Wed, 29 Jun 2011 05:00:53 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5TC0OZm017387 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Jun 2011 14:00:49 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 29 Jun 2011 14:00:45 +0200 From: "Bocci, Matthew (Matthew)" To: "rtg-ads@tools.ietf.org" Date: Wed, 29 Jun 2011 14:00:39 +0200 Thread-Topic: RtgDir review: draft-li-pwe3-ms-pw-pon-03.txt Thread-Index: Acw2VCxIo3npL9LKTv6nUaLQ8eJ4mw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA30D27712351matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "draft-li-pwe3-ms-pw-pon-03@tools.ietf.org" , "rtg-dir@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-li-pwe3-ms-pw-pon-03.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: Wed, 29 Jun 2011 12:00:55 -0000 --_000_CA30D27712351matthewboccialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RtgDir review: draft-li-pwe3-ms-pw-pon-03.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e 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 re= view is to provide assistance to the Routing ADs. For more information abou= t 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 wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-li-pwe3-ms-pw-pon-03.txt Reviewer: Matthew Bocci Review Date: 28-06-11 IETF LC End Date: 28-06-11 Intended Status: Informational Summary: I have some concerns about this document that I think should be resolved be= fore publication. Comments: Major Issues: - It is not clear from the draft how PW OAM works when one segment of an MS= -PW is established using OMCI. End-to-end VCCV on an MS-PW (as defined in R= FC5085 and RFC6073) requires that each segment negotiate or be configured w= ith its VCCV capabilities, so that the end-to-end PW uses a common set of O= AM tools supported by each segment. It would be useful if the draft explain= ed how VCCV is handled on the OMCI-controlled segment and whether there are= any implications for 'regular' IP/MPLS PW segments. - How is the OMCI-controlled segment treated at the S-PE where it is switch= ed to the LDP controlled segment? Does it look like a static segment, and s= o confirms to relevant parts of RFC6073? - It would be useful to include some more detail on what PW parameters are = carried by OMCI, and what parameters need to be configured at the T-PE and = S-PE e.g. how are interface parameters handled? What specific PW types and = encapsulation modes are supported (so we know what can be supported end-to-= end on the MS-PW). - How is PW OAM message mapping handled by OMCI? Does it release the PW lab= el, or does it use status signaling (the draft only very briefly mentions t= his), or is the assumption that native service OAM is always carried in-ban= d? Minor Issues: Abstract This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising a Passive Optical Network (PON) and an MPLS Packet Switched Network (PSN). PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of PW Terminating Provider Edge nodes (T-PEs). The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager. This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (GPON) using the GPON management protocol, Optical Network Termination Management and Control Interface (OMCI). This simplifies and speeds up PW provisioning. MB> Compared to what? I believe the author means compared to manual provisioning, but it would help to be explicit. This document also shows how a MS-PW may be constructed from an end segment supported over a PON, and stitched to one or more segments supported over an MPLS PSN. 1. Introduction [=85snip=85] Figure A depicts the physical infrastructure of an Optical Distribution Network (ODN). MB> I think this is as used in mobile backhaul (because it shows base stations), but please can you be specific. Also, it would be useful if the figure indicated the technology between the base stations and the ONU. [=85snip..] Routing protocols and dynamic label distribution protocols like LDP would significantly increase the ONUs' cost and complexity as they place requirements on both hardware and software. Besides coding and maintenance of these new protocols, a much powerful CPU and more memory are also necessary for them to run smoothly. MB> I think the issue here is that you need a whole set of IP and MPLS cont= rol protocols that are not used for anything other than managing PWs. This = might not make sense on a basic box like an ONU. I would suggest rephrasing= this paragraph as follows: "Additional protocols only needed for one task, such as routing and dynamic= label distribution for PWs, require additional CPU and memory resources wh= ich may not be justified on a simple device such as an ONU." [=85snip=85] Since there may be very many ONUs (and hence very many PWs) in a PON, this comprises a large amount of operational effort. MB> c/comprises/requires Additionally, there must be a concern that the configuration at the ONU and the OLT will be inconsistent because for any PW, both the ONU and the OLT must be configured. MB> I think the issue is that the OLT and ONU are configured separately, so care must be taken to ensure that the config is consistent at each end. Perhaps this would be better phrased as: "Additionally, care must be taken to ensure that the PW configuration is co= nsistent at the OLT and ONU, since these nodes are configured separately." [..snip..] This document shows how the two technologies (PON and PSN) can be combined to provide an end-to-end multi-segment MPLS PW. MB> I think we should be careful not to claim this is end-to-end MPLS. I do= not think OMCI would normally be classed as an MPLS protocol (even though = I agree the data path for the PW is MPLS). I think the term MPLS should be removed here and just call is an end-to-end MS-PW. 3. Multi-Segment Pseudowire over PON Network Reference Model [snip] It should be noted that all PW segments are of the same technology, which is packet encapsulated. MB> I am not sure I understand this. Does it mean to say: "It should be not= ed that all PW segments encapsulate the same packet technology."? 4. Label Provisioning for Pseudowires over PON The labor of provisioning static labels at the ONUs for PWs can be significantly reduced by using a management protocol over PON. At the time, this approach keeps the ONU simple by not requiring the implementation of a new dynamic control protocol. MB> 'At this time ' is not necessary and should be deleted. The usual management protocol in a GPON system used to manage and control ONUs is OMCI. It is used to perform all GPON physical layer and data GTC layer configuration on ONUs. Per [G.984.4amd2] and [G.988], OMCI can also be used to set up PWs and the MPLS LSP Tunnels from ONUs to OLT. When using OMCI to provision PWs in a GPON, the network manager sends configuration information to the OLT only. The OLT will select suitable PW labels and send all PW and MPLS LSP tunnel parameters to the ONUs through OMCI. The AC can be identified in the OMCI signaling so that the network manager does not need to configure the PWs at each ONU. MB> Please explain exactly what parameters are signaled, since these are be= ing expanded upon all the time by the PWE3 working group. Nits: References: - The reference to draft-ietf-pwe3-segmented-pw should be updated to RFC607= 3 - The draft uses the term 'stitching' or 'stitched'. Please replace with 's= witching' or 'switched' as appropriate, as these are the accepted terms use= d for MS-PWs. - In Section 3: At present, Ethernet over GEM is the dominant encapsulation in GPON. For fast deployment of MPLS over GPON, put MPLS PWs over Ethernet s/put/putting over GEM is an alternative way of transport MPLS PWs over GPON with s/transport/transporting existing hardware. - In Section 4: A MS-PW with a segment running over a PON, where the OLT acts as an S-PE and the ONU as a T-PE, PW provisioning can be performed through static configuration, e.g., from an NMS. MN> This sentence doesn't parse. I would suggest changing the first phrase = to: "Where an MS-PW includes a segment running over a PON,... --_000_CA30D27712351matthewboccialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
RtgDir review: draft-li-pwe3-ms-pw-= pon-03.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 pur= pose of the review is to provide assistance to the Routing ADs. For more in= formation about the Routing Directorate, please see http://www.ietf.org/ies= g/directorate/routing.html

Althou= gh 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 com= ments that you receive, and strive to resolve them through discussion or by= updating the draft.
Document: dr= aft-li-pwe3-ms-pw-pon-03.txt 
Reviewer: Matthew Bocci 
Review Date: 28-06-11 
IETF LC End Date: 28-06-11 
Intended Status: Informa= tional

<= /div>
Summary:
=
I have some concerns about this document that I th= ink should be resolved before publication.


Comm= ents:

Major Issues:
<= div>
- It is not clear from the draft how PW OAM wo= rks when one segment of an MS-PW is established using OMCI. End-to-end VCCV= on an MS-PW (as defined in RFC5085 and RFC6073) requires that each segment= negotiate or be configured with its VCCV capabilities, so that the end-to-= end PW uses a common set of OAM tools supported by each segment. It would b= e useful if the draft explained how VCCV is handled on the OMCI-controlled = segment and whether there are any implications for 'regular' IP/MPLS PW seg= ments.
- How is the= OMCI-controlled segment treated at the S-PE where it is switched to the LD= P controlled segment? Does it look like a static segment, and so confirms t= o relevant parts of RFC6073? 
- It would be useful to include some more detail on what PW= parameters are carried by OMCI, and what parameters need to be configured = at the T-PE and S-PE e.g. how are interface parameters handled? What specif= ic PW types and encapsulation modes are supported (so we know what can be s= upported end-to-end on the MS-PW).
- How is PW OAM message mapping handled by OMCI? Does it re= lease the PW label, or does it use status signaling (the draft only very br= iefly mentions this), or is the assumption that native service OAM is alway= s carried in-band?
=
  
Minor Issues:=

Abstract

   This document describes the application of MPLS = multi-segment
 = ;  pseudowires (MS-PWs) in a dual-technology environment comprising a<= /span>
   Passiv= e Optical Network (PON) and an MPLS Packet Switched Network
   (PSN).

   PON technology may be used in mobi= le backhaul networks to support the
   end segments closest to the aggregation devic= es.  In these cases,
   there may be a very large number of PW Terminating Prov= ider Edge
 &nb= sp; nodes (T-PEs).  The MPLS control plane could be used to provision<= /span>
   these = end segments, but support for the necessary protocols would
   complicate the manage= ment of the T-PEs and would significantly
   increase their expense.  Alternati= vely, static, or management plane,
   configuration could be used to configure the e= nd segments, but the
   bu= rden on the network manager.

&nbs= p;  This document describes how to set up the end segment of an end-to= -
   end = MPLS PW over a Gigabit-capable Passive Optical Network (GPON)
<= div>   using the GPON mana= gement protocol, Optical Network Termination
   Management and Control Interface (= OMCI).  This simplifies and speeds
   up PW provisioning.

MB> Compared to what? I believe the author means co= mpared to manual 
provisioning, but it would help to be explicit.

   This document also shows how a MS-PW may be= constructed from an end
   segment supported over a PON, and stitched to one or mor= e segments
 &n= bsp; supported over an MPLS PSN.

=
1.  Intro= duction

=
[=85snip=85]
=
Figure A depicts the physical i= nfrastructure of an Optical
   Distribution Network (ODN).

MB> I think this is as used in mobile backhaul (because= it shows base
stat= ions), but please can you be specific. Also, it would be useful if the
figure indicated the te= chnology between the base stations and the ONU.

[=85snip..]

Routin= g protocols and dynamic label distribution protocols like LDP
<= div>   would significantly= increase the ONUs' cost and complexity as they
   place requirements on both hardwa= re and software.  Besides coding and
   maintenance of these new protocols, a m= uch powerful CPU and more
   memory are also necessary for them to run smoothly.

= MB> I think the issue here is tha= t you need a whole set of IP and MPLS control protocols that are not used f= or anything other than managing PWs. This might not make sense on a basic b= ox like an ONU. I would suggest rephrasing this paragraph as follows:
"Additional protoco= ls only needed for one task, such as routing and dynamic label distribution= for PWs, require additional CPU and memory resources which may not be just= ified on a simple device such as an ONU."

[=85snip=85]
Since there may
   be very many ONUs (and hence very many PWs) in a PON, thi= s comprises
 &= nbsp; a large amount of operational effort.  

MB> c/comprises/requires

Additionally, there must be a
   concern that the configuration at the= ONU and the OLT will be
   inconsistent because for any PW, both the ONU and the OL= T must be
 &nb= sp; configured.
MB> I think th= e issue is that the OLT and ONU are configured separately, 
so care must be taken to ensu= re that the config is consistent at each end.
Perhaps this would be better phrased as:=
"Additionally, care = must be taken to ensure that the PW configuration is consistent at the OLT = and ONU, since these nodes are configured separately."

[..snip..]
This document shows how the two technologies (PON and P= SN) can be
 &n= bsp; combined to provide an end-to-end multi-segment MPLS PW.
<= div>
MB> I think we should be careful not to cla= im this is end-to-end MPLS. I do not think OMCI would normally be classed a= s an MPLS protocol (even though I agree the data path for the PW is MPLS). = I think the term MPLS should be
removed here and just call is an end-to-end MS-PW.
 

3.  Multi-Segment Pseudowire over PON Network Refer= ence Model

[snip]
It should be noted that all PW seg= ments are of the same technology,
   which is packet encapsulated.
=
MB> I am not sure I understand this. Does it me= an to say: "It should be noted that all PW segments encapsulate the sa= me packet technology."?

4. &= nbsp;Label Provisioning for Pseudowires over PON
The labor of provisioning static labels at th= e ONUs for PWs can be
 =   the time, this approach keeps the ONU simple by not requiring the
   implemen= tation of a new dynamic control protocol.

MB> 'At this time ' is not necessary and should be deleted.

= The usual management protocol in a G= PON system used to manage and
   control ONUs is OMCI.  It is used to perform a= ll GPON physical layer
   and data GTC layer configuration on ONUs.  Per [G.984= .4amd2] and
 &= nbsp; [G.988], OMCI can also be used to set up PWs and the MPLS LSP Tunnels=
   from = ONUs to OLT.  When using OMCI to provision PWs in a GPON, the
   network manage= r sends configuration information to the OLT only.  The
   OLT will select suit= able PW labels and send all PW and MPLS LSP
   tunnel parameters to the ONUs through= OMCI.  The AC can be identified
   in the OMCI signaling so that the network m= anager does not need to
   configure the PWs at each ONU.

MB> Please explain exactly what parameters are signaled,= since these are being expanded upon all the time by the PWE3 working group= .

=
Nits:

References:
- The reference to draft-ietf-pwe3-segmented-pw should be updated= to RFC6073

- The draft uses the = term 'stitching' or 'stitched'. Please replace with 'switching' or 'switche= d' as appropriate, as these are the accepted terms used for MS-PWs.<= /div>

- In Section 3:
At present, Ethernet over GEM is the domina= nt encapsulation in GPON.
   For fast deployment of MPLS over GPON, put MPLS PWs ove= r Ethernet
s/put/pu= tting
   = over GEM is an alternative way of transport MPLS PWs over GPON with<= /div>
s/transport/transporting
   existin= g hardware.

- In Section 4:
A MS-PW with a segment r= unning over a PON, where the OLT acts as an
   S-PE and the ONU as a T-PE, PW provis= ioning can be performed through
   static configuration, e.g., from an NMS.
MN> This sentence doesn'= t parse. I would suggest changing the first phrase to:
"Where an MS-PW includes a segment= running over a PON,...
--_000_CA30D27712351matthewboccialcatellucentcom_-- From adrian@olddog.co.uk Wed Jun 29 08:04: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 5442121F8685 for ; Wed, 29 Jun 2011 08:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599] 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 Cka3h+TMZlDU for ; Wed, 29 Jun 2011 08:04:52 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D3C4221F8684 for ; Wed, 29 Jun 2011 08:04:51 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5TF1nKk001590; Wed, 29 Jun 2011 16:01:49 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p5TF1l3D001545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jun 2011 16:01:48 +0100 From: "Adrian Farrel" To: "'Bocci, Matthew \(Matthew\)'" , , References: In-Reply-To: Date: Wed, 29 Jun 2011 16:03:32 +0100 Message-ID: <09fe01cc366d$b6d17fe0$24747fa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLIycthn5GSokR/iewI2E/aOBz8xJLbOgFA Content-Language: en-gb Cc: rtg-dir@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-li-pwe3-ms-pw-pon-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 15:04:53 -0000 Hi Matthew, [cranky old author hat on] Thanks for the review, I guess. > - It is not clear from the draft how PW OAM works when one segment of = an MS-PW > is established using OMCI. End-to-end VCCV on an MS-PW (as defined in = RFC5085 > and RFC6073) requires that each segment negotiate or be configured = with its VCCV > capabilities, so that the end-to-end PW uses a common set of OAM tools supported > by each segment. It would be useful if the draft explained how VCCV is = handled on > the OMCI-controlled segment and whether there are any implications for 'regular'=20 > IP/MPLS PW segments. What makes you think there would be anything special here? What is different using OMCI versus a management protocol or LDP? This document is about carrying the MPLS PW over different tunnelling technologies, so why wouldn't section 9.3 of RFC 6073 simply apply? So, possibly you are asking: "How does OMCI signal PW information such = as VCCV capabilities?" Might be a reasonable question if this document was = intended to define the OMCI extensions for signaling PWs in a PON. But it is not! = That is clearly out of scope for the IETF. As Section 4 says... The usual management protocol in a GPON system used to manage and control ONUs is OMCI. It is used to perform all GPON physical layer and data GTC layer configuration on ONUs. Per [G.984.4amd2] and [G.988], OMCI can also be used to set up PWs and the MPLS LSP Tunnels from ONUs to OLT. When using OMCI to provision PWs in a GPON, the network manager sends configuration information to the OLT only. The OLT will select suitable PW labels and send all PW and MPLS LSP tunnel parameters to the ONUs through OMCI. The AC can be identified in the OMCI signaling so that the network manager does not need to configure the PWs at each ONU. OMCI supports the configuration of a number of PW types including TDM, ATM, and Ethernet, and the protocol can also be used to allow the ONU to notify the OLT of the status of the AC. > - How is the OMCI-controlled segment treated at the S-PE where it is = switched to > the LDP controlled segment? Does it look like a static segment, and = so confirms > to relevant parts of RFC6073?=A0 Isn't that the way *any* two segments are stitched according to 5659 and = 6073? How could this vary from that architecture, especially given the = introductory text in this document? > - It would be useful to include some more detail on what PW parameters > are carried by OMCI, and what parameters need to be configured at the > T-PE and S-PE e.g. how are interface parameters handled? What specific > PW types and encapsulation modes are supported (so we know what can > be supported end-to-end on the MS-PW). Why is this document the right place to do that? The definition and extension of OMCI belongs in the ITU-T. > - How is PW OAM message mapping handled by OMCI? Does it release > the PW label, or does it use status signaling (the draft only very = briefly=20 > mentions this), or is the assumption that native service OAM is always = > carried in-band? Was it your intention that draft-ietf-pwe3-oam-msg-map was applicable to = MS-PWs? I guess isn't too late to pull it back from the RFC Editor Queue and = return it to the PWE3 working group for addition of that text. You will recall = that I raised this issue while reviewing that draft and was told that MS-PW was = out of scope at the moment. The only additional text added to cover MS-PW is: This document is scoped only to single segment PWs. The mechanisms described in this document could also be applied to T-PEs for MS-PWs ([RFC5254]). So, isn't it a bit unreasonable to ask this I-D to give more attention = to message mapping (especially when the e2e PW is the same type)? > Minor Issues: > > Abstract [SNIP] > Alternatively, static, or management plane, >=A0=A0 configuration could be used to configure the end segments, but = the >=A0=A0 very large number of such segments in a PON places a very heavy >=A0=A0 burden on the network manager. > >=A0=A0 This document describes how to set up the end segment of an = end-to- >=A0=A0 end MPLS PW over a Gigabit-capable Passive Optical Network = (GPON) >=A0=A0 using the GPON management protocol, Optical Network Termination >=A0=A0 Management and Control Interface (OMCI). =A0This simplifies and = speeds >=A0=A0 up PW provisioning. > > MB> Compared to what? I believe the author means compared to manual=A0 > provisioning, but it would help to be explicit. Indeed, per the previous paragraph. A note could be added. > 1. =A0Introduction > > [=85snip=85] > Figure A depicts the physical infrastructure of an Optical >=A0=A0 Distribution Network (ODN). > > MB> I think this is as used in mobile backhaul (because it shows base > stations), but please can you be specific. Also, it would be useful if = the > figure indicated the technology between the base stations and the ONU. Phooey! The caption says "typical". The second paragraph after the figure talks = about use in mobile backhaul. > [=85snip..] > > Routing protocols and dynamic label distribution protocols like LDP >=A0=A0 would significantly increase the ONUs' cost and complexity as = they >=A0=A0 place requirements on both hardware and software. =A0Besides = coding and >=A0=A0 maintenance of these new protocols, a much powerful CPU and more >=A0=A0 memory are also necessary for them to run smoothly. > > MB> I think the issue here is that you need a whole set of IP and MPLS = control > protocols that are not used for anything other than managing PWs. This = might > not make sense on a basic box like an ONU.=20 Yes, you have understood the issue correctly. The point is that those = protocols are not there in an ODN. I think this is clear to anyone who has = understood what the ODN is. > I would suggest rephrasing this paragraph as follows: > "Additional protocols only needed for one task, such as routing and = dynamic > label distribution for PWs, require additional CPU and memory = resources which > may not be justified on a simple device such as an ONU." > > [=85snip=85] > Since there may >=A0=A0 be very many ONUs (and hence very many PWs) in a PON, this = comprises >=A0=A0 a large amount of operational effort. =A0 > > MB> c/comprises/requires Maybe a matter of style. It looks OK to me. > Additionally, there must be a >=A0=A0 concern that the configuration at the ONU and the OLT will be >=A0=A0 inconsistent because for any PW, both the ONU and the OLT must = be >=A0=A0 configured. > > MB> I think the issue is that the OLT and ONU are configured = separately,=A0 > so care must be taken to ensure that the config is consistent at each = end. > Perhaps this would be better phrased as: > "Additionally, care must be taken to ensure that the PW configuration = is > consistent at the OLT and ONU, since these nodes are configured = separately." If care could be taken, there would be no concern! So we could write "Additionally, there is an issue that the configuration of each PW at = the OLT and ONU might be inconsistent since these nodes are configured = separately." Looks pretty much what we had. > [..snip..] > This document shows how the two technologies (PON and PSN) can be >=A0=A0 combined to provide an end-to-end multi-segment MPLS PW. > > MB> I think we should be careful not to claim this is end-to-end MPLS. > I do not think OMCI would normally be classed as an MPLS protocol = (even > though I agree the data path for the PW is MPLS). I think the term = MPLS > should be removed here and just call is an end-to-end MS-PW. =A0 I strongly disagree. If you take this path then you will find that all management configured PWs that are MPLS in the data plane cannot be = called MPLS PWs. You will then need to go back and revise all of the PW RFCs.=20 The fact is that the e2e PW here is an MPLS PW, and it is MS. There is = simply no necessity to debate the provisioning mechanism. > 3. =A0Multi-Segment Pseudowire over PON Network Reference Model > > [snip] > It should be noted that all PW segments are of the same technology, >=A0=A0 which is packet encapsulated. > > MB> I am not sure I understand this. Does it mean to say: "It should = be noted that all PW segments=20 > encapsulate the same packet technology."? No. It means what it says. The PW technology of each PW segment is the = same, and that technology is "packet encapsulated". > 4. =A0Label Provisioning for Pseudowires over PON > > The labor of provisioning static labels at the ONUs for PWs can be >=A0=A0 significantly reduced by using a management protocol over PON. = =A0At >=A0=A0 the time, this approach keeps the ONU simple by not requiring = the >=A0=A0 implementation of a new dynamic control protocol. > > MB> 'At this time ' is not necessary and should be deleted. Fine > The usual management protocol in a GPON system used to manage and >=A0=A0 control ONUs is OMCI. =A0It is used to perform all GPON physical = layer >=A0=A0 and data GTC layer configuration on ONUs. =A0Per [G.984.4amd2] = and >=A0=A0 [G.988], OMCI can also be used to set up PWs and the MPLS LSP = Tunnels >=A0=A0 from ONUs to OLT. =A0When using OMCI to provision PWs in a GPON, = the >=A0=A0 network manager sends configuration information to the OLT only. = =A0The >=A0=A0 OLT will select suitable PW labels and send all PW and MPLS LSP >=A0=A0 tunnel parameters to the ONUs through OMCI. =A0The AC can be = identified >=A0=A0 in the OMCI signaling so that the network manager does not need = to >=A0=A0 configure the PWs at each ONU. > > MB> Please explain exactly what parameters are signaled, since these = are being > expanded upon all the time by the PWE3 working group. Same point. Why is this in scope for this document or for the IETF? The = issue of extending the protocol to signal PWs is clearly an issue for the ITU-T. > Nits: > > References: > - The reference to draft-ietf-pwe3-segmented-pw should be updated to = RFC6073 Will that mean that we are subject to ALU IPR? :-) Yes. This sort of nit often arises as document progresses through the = system and is picked up and fixed using idnits on each revision. > - The draft uses the term 'stitching' or 'stitched'. Please replace = with 'switching' or > 'switched' as appropriate, as these are the accepted terms used for = MS-PWs. RFC 6073 In Figure 2, pseudowires in two separate PSNs are stitched together using native service attachment circuits. But we can make the change. > - In Section 3: > At present, Ethernet over GEM is the dominant encapsulation in GPON. >=A0=A0 For fast deployment of MPLS over GPON, put MPLS PWs over = Ethernet > s/put/putting >=A0=A0 over GEM is an alternative way of transport MPLS PWs over GPON = with > s/transport/transporting >=A0=A0 existing hardware. Yes > - In Section 4: > A MS-PW with a segment running over a PON, where the OLT acts as an >=A0=A0 S-PE and the ONU as a T-PE, PW provisioning can be performed = through >=A0=A0 static configuration, e.g., from an NMS. > MN> This sentence doesn't parse. I would suggest changing the first = phrase to: > "Where an MS-PW includes a segment running over a PON,... I can parse it. We will try to rewrite. Thanks, Adrian From matthew.bocci@alcatel-lucent.com Wed Jun 29 08:59:14 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 B28AB9E804C for ; Wed, 29 Jun 2011 08:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 F+tCx1dFWNrv for ; Wed, 29 Jun 2011 08:59:13 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5647F9E800B for ; Wed, 29 Jun 2011 08:59:13 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5TFijtb024601 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Jun 2011 17:46:31 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 29 Jun 2011 17:46:22 +0200 From: "Bocci, Matthew (Matthew)" To: "adrian@olddog.co.uk" , "lihy@huawei.com" , "robin@huawei.com" Date: Wed, 29 Jun 2011 17:46:17 +0200 Thread-Topic: RtgDir review: draft-li-pwe3-ms-pw-pon-03.txt Thread-Index: Acw2c7EmHbUYBoE8Qb+b7hvZ29XD9w== Message-ID: In-Reply-To: <09fe01cc366d$b6d17fe0$24747fa0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-li-pwe3-ms-pw-pon-03.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: Wed, 29 Jun 2011 15:59:14 -0000 Adrian, On 29/06/2011 16:03, "Adrian Farrel" wrote: >Hi Matthew, > >[cranky old author hat on] > >Thanks for the review, I guess. > >> - It is not clear from the draft how PW OAM works when one segment of >>an MS-PW > >> is established using OMCI. End-to-end VCCV on an MS-PW (as defined in >>RFC5085 >> and RFC6073) requires that each segment negotiate or be configured with >>its >VCCV >> capabilities, so that the end-to-end PW uses a common set of OAM tools >supported >> by each segment. It would be useful if the draft explained how VCCV is >>handled >on >> the OMCI-controlled segment and whether there are any implications for >'regular'=20 >> IP/MPLS PW segments. > >What makes you think there would be anything special here? >What is different using OMCI versus a management protocol or LDP? LDP has VCCV capability negotiation procedures. Any management platform should be able to configure VCCV capabilities. I assume that OMCI can do this. Can it? =20 > >This document is about carrying the MPLS PW over different tunnelling >technologies, so why wouldn't section 9.3 of RFC 6073 simply apply? I'm not talking about the data plane. > >So, possibly you are asking: "How does OMCI signal PW information such as >VCCV >capabilities?" Might be a reasonable question if this document was >intended to >define the OMCI extensions for signaling PWs in a PON. But it is not! >That is >clearly out of scope for the IETF. Yes, I agree it is out of scope. However, I think it is reasonable to explain if OMCI can do this, so that VCCV can be used end to end on the MS-PW.=20 > >As Section 4 says... > > The usual management protocol in a GPON system used to manage and > control ONUs is OMCI. It is used to perform all GPON physical layer > and data GTC layer configuration on ONUs. Per [G.984.4amd2] and > [G.988], OMCI can also be used to set up PWs and the MPLS LSP Tunnels > from ONUs to OLT. When using OMCI to provision PWs in a GPON, the > network manager sends configuration information to the OLT only. The > OLT will select suitable PW labels and send all PW and MPLS LSP > tunnel parameters to the ONUs through OMCI. The AC can be identified > in the OMCI signaling so that the network manager does not need to > configure the PWs at each ONU. > > OMCI supports the configuration of a number of PW types including > TDM, ATM, and Ethernet, and the protocol can also be used to allow > the ONU to notify the OLT of the status of the AC. > >> - How is the OMCI-controlled segment treated at the S-PE where it is >>switched >to >> the LDP controlled segment? Does it look like a static segment, and so >confirms >> to relevant parts of RFC6073? > >Isn't that the way *any* two segments are stitched according to 5659 and >6073? >How could this vary from that architecture, especially given the >introductory >text in this document? OK fine, but why not state that? > >> - It would be useful to include some more detail on what PW parameters >> are carried by OMCI, and what parameters need to be configured at the >> T-PE and S-PE e.g. how are interface parameters handled? What specific >> PW types and encapsulation modes are supported (so we know what can >> be supported end-to-end on the MS-PW). > >Why is this document the right place to do that? >The definition and extension of OMCI belongs in the ITU-T. No, it is not the right place to define it, but it is useful information to help the reader to understand what PW types can be supported. > >> - How is PW OAM message mapping handled by OMCI? Does it release >> the PW label, or does it use status signaling (the draft only very >>briefly=20 >> mentions this), or is the assumption that native service OAM is always >> carried in-band? > >Was it your intention that draft-ietf-pwe3-oam-msg-map was applicable to >MS-PWs? >I guess isn't too late to pull it back from the RFC Editor Queue and >return it >to the PWE3 working group for addition of that text. You will recall that >I >raised this issue while reviewing that draft and was told that MS-PW was >out of >scope at the moment. The only additional text added to cover MS-PW is: > This document is scoped only to single segment PWs. The mechanisms > described in this document could also be applied to T-PEs for MS-PWs > ([RFC5254]). > >So, isn't it a bit unreasonable to ask this I-D to give more attention to >message mapping (especially when the e2e PW is the same type)? OK that's a fair point in terms of the scope of the message mapping draft, but the draft does mention that AC > >> Minor Issues: >> >> Abstract > >[SNIP] >> Alternatively, static, or management plane, >> configuration could be used to configure the end segments, but the >> very large number of such segments in a PON places a very heavy >> burden on the network manager. >> >> This document describes how to set up the end segment of an end-to- >> end MPLS PW over a Gigabit-capable Passive Optical Network (GPON) >> using the GPON management protocol, Optical Network Termination >> Management and Control Interface (OMCI). This simplifies and speeds >> up PW provisioning. >> >> MB> Compared to what? I believe the author means compared to manual >> provisioning, but it would help to be explicit. > >Indeed, per the previous paragraph. A note could be added. > >> 1. Introduction >> >> [=8Asnip=8A] >> Figure A depicts the physical infrastructure of an Optical >> Distribution Network (ODN). >> >> MB> I think this is as used in mobile backhaul (because it shows base >> stations), but please can you be specific. Also, it would be useful if >>the >> figure indicated the technology between the base stations and the ONU. > >Phooey! > >The caption says "typical". The second paragraph after the figure talks >about >use in mobile backhaul. > >> [=8Asnip..] >> >> Routing protocols and dynamic label distribution protocols like LDP >> would significantly increase the ONUs' cost and complexity as they >> place requirements on both hardware and software. Besides coding and >> maintenance of these new protocols, a much powerful CPU and more >> memory are also necessary for them to run smoothly. >> >> MB> I think the issue here is that you need a whole set of IP and MPLS >>control >> protocols that are not used for anything other than managing PWs. This >>might >> not make sense on a basic box like an ONU. > >Yes, you have understood the issue correctly. The point is that those >protocols >are not there in an ODN. I think this is clear to anyone who has >understood what >the ODN is. > >> I would suggest rephrasing this paragraph as follows: >> "Additional protocols only needed for one task, such as routing and >>dynamic >> label distribution for PWs, require additional CPU and memory resources >>which >> may not be justified on a simple device such as an ONU." >> >> [=8Asnip=8A] >> Since there may >> be very many ONUs (and hence very many PWs) in a PON, this comprises >> a large amount of operational effort. >> >> MB> c/comprises/requires > >Maybe a matter of style. It looks OK to me. > >> Additionally, there must be a >> concern that the configuration at the ONU and the OLT will be >> inconsistent because for any PW, both the ONU and the OLT must be >> configured. >> >> MB> I think the issue is that the OLT and ONU are configured >>separately,=20 >> so care must be taken to ensure that the config is consistent at each >>end. >> Perhaps this would be better phrased as: >> "Additionally, care must be taken to ensure that the PW configuration is >> consistent at the OLT and ONU, since these nodes are configured >>separately." > >If care could be taken, there would be no concern! So we could write > >"Additionally, there is an issue that the configuration of each PW at the >OLT >and ONU might be inconsistent since these nodes are configured >separately." > >Looks pretty much what we had. > >> [..snip..] >> This document shows how the two technologies (PON and PSN) can be >> combined to provide an end-to-end multi-segment MPLS PW. >> >> MB> I think we should be careful not to claim this is end-to-end MPLS. >> I do not think OMCI would normally be classed as an MPLS protocol (even >> though I agree the data path for the PW is MPLS). I think the term MPLS >> should be removed here and just call is an end-to-end MS-PW. >=20 >I strongly disagree. If you take this path then you will find that all >management configured PWs that are MPLS in the data plane cannot be >called MPLS >PWs. You will then need to go back and revise all of the PW RFCs. > >The fact is that the e2e PW here is an MPLS PW, and it is MS. There is >simply no >necessity to debate the provisioning mechanism. Ok > >> 3. Multi-Segment Pseudowire over PON Network Reference Model >> >> [snip] >> It should be noted that all PW segments are of the same technology, >> which is packet encapsulated. >> >> MB> I am not sure I understand this. Does it mean to say: "It should be >>noted >that all PW segments >> encapsulate the same packet technology."? > >No. It means what it says. The PW technology of each PW segment is the >same, and >that technology is "packet encapsulated". > >> 4. Label Provisioning for Pseudowires over PON >> >> The labor of provisioning static labels at the ONUs for PWs can be >> significantly reduced by using a management protocol over PON. At >> the time, this approach keeps the ONU simple by not requiring the >> implementation of a new dynamic control protocol. >> >> MB> 'At this time ' is not necessary and should be deleted. > >Fine > >> The usual management protocol in a GPON system used to manage and >> control ONUs is OMCI. It is used to perform all GPON physical layer >> and data GTC layer configuration on ONUs. Per [G.984.4amd2] and >> [G.988], OMCI can also be used to set up PWs and the MPLS LSP Tunnels >> from ONUs to OLT. When using OMCI to provision PWs in a GPON, the >> network manager sends configuration information to the OLT only. The >> OLT will select suitable PW labels and send all PW and MPLS LSP >> tunnel parameters to the ONUs through OMCI. The AC can be identified >> in the OMCI signaling so that the network manager does not need to >> configure the PWs at each ONU. >> >> MB> Please explain exactly what parameters are signaled, since these >>are being >> expanded upon all the time by the PWE3 working group. > >Same point. Why is this in scope for this document or for the IETF? The >issue of >extending the protocol to signal PWs is clearly an issue for the ITU-T. I agree that it is up to the ITU to define these. This is an informational draft, anyway. It is useful information because it can impact the end to end capabilities of the PW. > >> Nits: >> >> References: >> - The reference to draft-ietf-pwe3-segmented-pw should be updated to >>RFC6073 > >Will that mean that we are subject to ALU IPR? :-) >Yes. This sort of nit often arises as document progresses through the >system and >is picked up and fixed using idnits on each revision. > >> - The draft uses the term 'stitching' or 'stitched'. Please replace with >'switching' or >> 'switched' as appropriate, as these are the accepted terms used for >>MS-PWs. > >RFC 6073 > In Figure 2, pseudowires in two separate PSNs are stitched together > using native service attachment circuits. > >But we can make the change. Thanks.=20 > >> - In Section 3: >> At present, Ethernet over GEM is the dominant encapsulation in GPON. >> For fast deployment of MPLS over GPON, put MPLS PWs over Ethernet >> s/put/putting >> over GEM is an alternative way of transport MPLS PWs over GPON with >> s/transport/transporting >> existing hardware. > >Yes > >> - In Section 4: >> A MS-PW with a segment running over a PON, where the OLT acts as an >> S-PE and the ONU as a T-PE, PW provisioning can be performed through >> static configuration, e.g., from an NMS. >> MN> This sentence doesn't parse. I would suggest changing the first >>phrase to: >> "Where an MS-PW includes a segment running over a PON,... > >I can parse it. We will try to rewrite. Thank you. Matthew > >Thanks, >Adrian > From matthew.bocci@alcatel-lucent.com Wed Jun 29 09:28:59 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 BA2CD21F8524 for ; Wed, 29 Jun 2011 09:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 dLZTlBKZyqnW for ; Wed, 29 Jun 2011 09:28:59 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id CC77421F8521 for ; Wed, 29 Jun 2011 09:28:58 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p5TGRoh3011802 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Jun 2011 18:27:52 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 29 Jun 2011 18:27:51 +0200 From: "Bocci, Matthew (Matthew)" To: "Bocci, Matthew (Matthew)" , "adrian@olddog.co.uk" , "lihy@huawei.com" , "robin@huawei.com" Date: Wed, 29 Jun 2011 18:27:48 +0200 Thread-Topic: [RTG-DIR] RtgDir review: draft-li-pwe3-ms-pw-pon-03.txt Thread-Index: Acw2eXzsGYu+7QsdSxOZx0BFaCya8g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-li-pwe3-ms-pw-pon-03.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: Wed, 29 Jun 2011 16:28:59 -0000 Adrian, One other thing. On 29/06/2011 16:46, "Bocci, Matthew (Matthew)" wrote: [snip] >> >> >>> - How is PW OAM message mapping handled by OMCI? Does it release >>> the PW label, or does it use status signaling (the draft only very >>>briefly >>> mentions this), or is the assumption that native service OAM is always >>> carried in-band? >> >>Was it your intention that draft-ietf-pwe3-oam-msg-map was applicable to >>MS-PWs? >>I guess isn't too late to pull it back from the RFC Editor Queue and >>return it >>to the PWE3 working group for addition of that text. You will recall that >>I >>raised this issue while reviewing that draft and was told that MS-PW was >>out of >>scope at the moment. The only additional text added to cover MS-PW is: >> This document is scoped only to single segment PWs. The mechanisms >> described in this document could also be applied to T-PEs for MS-PWs >> ([RFC5254]). >> >>So, isn't it a bit unreasonable to ask this I-D to give more attention to >>message mapping (especially when the e2e PW is the same type)? > > Actually you already state that it ONU can notify the OLT of the status of the AC at the end of section 4, so I think this is fine. Regards Matthew >