From Adrian.Farrel@huawei.com Fri Nov 5 15:49:24 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097703A695A; Fri, 5 Nov 2010 15:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.121 X-Spam-Level: X-Spam-Status: No, score=-101.121 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFOnmtbUrt-W; Fri, 5 Nov 2010 15:49:23 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id B38773A6931; Fri, 5 Nov 2010 15:49:22 -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 <0LBF00M3AOQN86@usaga03-in.huawei.com>; Fri, 05 Nov 2010 17:49:36 -0500 (CDT) Received: from 950129200 ([222.128.202.160]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBF001Z4OPLDR@usaga03-in.huawei.com>; Fri, 05 Nov 2010 17:49:35 -0500 (CDT) Date: Fri, 05 Nov 2010 22:48:55 +0000 From: Adrian Farrel To: rtg-chairs@ietf.org, routing-discussion@ietf.org, rtg-dir@ietf.org Message-id: <005401cb7d3b$b97e8490$2c7b8db0$@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: Act9O5qKr5DoVXdAQy6NxIm6Tu3TlQ== Subject: [RTG-DIR] Meet the Routing ADs X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 05 Nov 2010 22:49:24 -0000 The Routing ADs will be holding their now-infamous Routing Area Office Hours on Sunday from 2pm to 4pm. We will be in the IESG Breakout Room - watch this space or ask the Secretariat to find out which room that is. Come and say hello, or bring us your questions, issues or concerns. Adrian and Stewart From stbryant@cisco.com Fri Nov 5 20:52:12 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64EB3A67EC for ; Fri, 5 Nov 2010 20:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFbHaAGHvPP7 for ; Fri, 5 Nov 2010 20:52:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 109CB3A67EE for ; Fri, 5 Nov 2010 20:52:07 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPxt1ExAZnwN/2dsb2JhbAChfXGecYI9DQGYQoVIBIpW X-IronPort-AV: E=Sophos;i="4.58,306,1286150400"; d="scan'208";a="178943502" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Nov 2010 03:52:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA63qLbJ000041 for ; Sat, 6 Nov 2010 03:52:21 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id oA63qI807304; Sat, 6 Nov 2010 03:52:19 GMT Message-ID: <4CD4D0F1.1000608@cisco.com> Date: Sat, 06 Nov 2010 03:52:17 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "rtg-dir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [RTG-DIR] Routing Directorate X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 03:52:13 -0000 Adrian and I are not currently planning to schedule a Routing Directorate meeting at this IETF, but if anyone thinks that there is an issue that we need to discuss as a group, then please let us know and we will set something up. You can of course grab either or both of us for anything that you need to talk about, and we have the open house on Sunday Afternoon. Stewart & Adrian From Adrian.Farrel@huawei.com Fri Nov 5 23:10:20 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A0D3A677E; Fri, 5 Nov 2010 23:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzzTkADuc28U; Fri, 5 Nov 2010 23:10:19 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id C02353A677D; Fri, 5 Nov 2010 23:10:19 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBG0095795L0U@usaga01-in.huawei.com>; Fri, 05 Nov 2010 23:10:34 -0700 (PDT) Received: from 950129200 ([222.128.202.2]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBG004QR95JRF@usaga01-in.huawei.com>; Fri, 05 Nov 2010 23:10:33 -0700 (PDT) Date: Sat, 06 Nov 2010 06:10:32 +0000 From: Adrian Farrel To: rtg-chairs@ietf.org, routing-discussion@ietf.org, rtg-dir@ietf.org Message-id: <00bc01cb7d79$539157a0$fab406e0$@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: Act9eT2hw7cuw+v3SIaAngPuFMT9cg== Subject: [RTG-DIR] Location: Meet the Routing ADs X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 06 Nov 2010 06:10:20 -0000 The meeting room we will use is called "Rose" See you there. Adrian > -----Original Message----- > From: routing-discussion-bounces@ietf.org [mailto:routing-discussion- > bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: 05 November 2010 22:49 > To: rtg-chairs@ietf.org; routing-discussion@ietf.org; rtg-dir@ietf.org > Subject: Meet the Routing ADs > > The Routing ADs will be holding their now-infamous Routing Area Office Hours on > Sunday from 2pm to 4pm. > We will be in the IESG Breakout Room - watch this space or ask the Secretariat > to find out which room that is. > > Come and say hello, or bring us your questions, issues or concerns. > > Adrian and Stewart > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From Adrian.Farrel@huawei.com Sat Nov 6 18:43:44 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE563A695C; Sat, 6 Nov 2010 18:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3XCiUdFqyC3; Sat, 6 Nov 2010 18:43:43 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id E54763A6958; Sat, 6 Nov 2010 18:43:43 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBH009UARHC91@usaga01-in.huawei.com>; Sat, 06 Nov 2010 18:44:00 -0700 (PDT) Received: from 950129200 (dhcp-731c.meeting.ietf.org [130.129.115.28]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBH00HGARH9P7@usaga01-in.huawei.com>; Sat, 06 Nov 2010 18:44:00 -0700 (PDT) Date: Sun, 07 Nov 2010 01:43:59 +0000 From: Adrian Farrel To: rtg-chairs@ietf.org, routing-discussion@ietf.org, rtg-dir@ietf.org Message-id: <005401cb7e1d$41750310$c45f0930$@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: Act+HSrUvENQi+x8QQmwasSUvRTshg== Cc: rtg-ads@tools.ietf.org Subject: [RTG-DIR] Routing Area Open Meeting X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 01:43:45 -0000 Hi, The agenda for the Routing Area Open Meeting can be found at http://www.ietf.org/proceedings/79/agenda/rtgarea.txt In addition to the usual run around the working groups (for which we need WG chairs present!), we have three discussion topics. - Joel Halpern will give us an update on the progress in LISP, a working group doing stuff related to routing. - Stewart will preach to us about the trade-offs between public and private discussions. - I will take a few minutes to explain the risks about including specific codepoints in I-Ds without actually getting them registered by IANA. This is based on a recent experience in the MPLS WG. I'm aware that the meeting runs into the start of the social shuttle service. Looking at the current agenda, I think we'll be done in time for you all to go out and party. See you there. Adrian From Juliusz.Chroboczek@pps.jussieu.fr Fri Nov 12 06:23:17 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8CC3A6912 for ; Fri, 12 Nov 2010 06:23:17 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN1OnUf9FD4V for ; Fri, 12 Nov 2010 06:23:16 -0800 (PST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by core3.amsl.com (Postfix) with ESMTP id 66C2F3A682B for ; Fri, 12 Nov 2010 06:23:15 -0800 (PST) Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id oACENcjC004485 ; Fri, 12 Nov 2010 15:23:39 +0100 (CET) X-Ids: 165 Received: from lanthane.pps.jussieu.fr (lanthane.pps.jussieu.fr [134.157.168.57]) by hydrogene.pps.jussieu.fr (8.13.4/jtpda-5.4) with ESMTP id oACENaHJ028997 ; Fri, 12 Nov 2010 15:23:36 +0100 Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.72) (envelope-from ) id 1PGuXP-0006zz-VX; Fri, 12 Nov 2010 15:23:36 +0100 From: Juliusz Chroboczek To: stbryant@cisco.com References: <7i7hh5hm58.fsf@lanthane.pps.jussieu.fr> <4CC716A6.4090909@cisco.com> <7ir5fa8elb.fsf@lanthane.pps.jussieu.fr> Date: Fri, 12 Nov 2010 15:23:35 +0100 In-Reply-To: <7ir5fa8elb.fsf@lanthane.pps.jussieu.fr> (Juliusz Chroboczek's message of "Thu, 28 Oct 2010 18:30:24 +0200") Message-ID: <7iiq027h94.fsf@lanthane.pps.jussieu.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Miltered: at jchkmail.jussieu.fr with ID 4CDD4DEA.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4CDD4DEA.003/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ X-Mailman-Approved-At: Sat, 13 Nov 2010 02:00:35 -0800 Cc: Ross Callon , "rtg-dir@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] Rtg Directorate review of draft-chroboczek-babel-routing-protocol-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 14:23:17 -0000 > I've re-read the current version, and I am happy with it. I'd be > grateful if you could process it. Dear Stuart, I haven't heard from you since then; is there anything more that's expected from me? Thanks, Juliusz From thomas.morin@orange-ftgroup.com Sat Nov 20 07:57:52 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583D43A69F1 for ; Sat, 20 Nov 2010 07:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=-1.451, BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DwGBDkOsHq3 for ; Sat, 20 Nov 2010 07:57:46 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 27F463A69EE for ; Sat, 20 Nov 2010 07:57:43 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 997E2768001; Sat, 20 Nov 2010 17:03:02 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8A197760001; Sat, 20 Nov 2010 17:03:02 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Nov 2010 16:58:34 +0100 Received: from [10.193.116.61] ([10.193.116.61]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 20 Nov 2010 16:58:32 +0100 Message-ID: <4CE7F027.80008@orange-ftgroup.com> Date: Sat, 20 Nov 2010 16:58:31 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; ; ; ) Gecko/2010 Thunderbird/3.1.x MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary="------------070705020804040208010900" X-OriginalArrivalTime: 20 Nov 2010 15:58:32.0794 (UTC) FILETIME=[C8272BA0:01CB88CB] Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-oam-framework.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-oam-framework-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 15:57:52 -0000 This is a multi-part message in MIME format. --------------070705020804040208010900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-tp-oam-framework-09 Reviewer: Thomas Morin Review Date: 2010-11-20 IETF LC End Date: 2010-11-22 Intended Status: Informational *Summary:* "I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors." *Comments:* Beyond the issues I found with the document (see below), I have a general concern on the readability of the document. *Major Issues:* A1 - It seems to me that the role of this document, among the documents defining the MPLS Transport Profile, should be clarified and/or better explained. One of my assumptions was that what such a "framework" was written to factor out, and document in one place, all of what is common to the MPLS-TP OAM solutions, many of which are expected to be defined because of the multiplicity of OAM functions that are needed. I would expect the document to give a high-level roadmap of the specification documents that will be added to obtain full specifications (for instance: one document for CC, one for CV, or for LM, one for tracing etc. ; with the possibility of grouping the specs for some of these into common docs when applicable). I would also expect the document introduction to indicate where it stands with reference to already defined document on MPLS and MPLS-TP OAM (the important relation ship with GACH specs and PW VCCV is only explained in the sub-section on SPME...). A2 - The document has in two places a wording that could lead to misunderstandings: the phrase "each OAM solution" is used in 3.3§5 and 3.3§14, which could be understood as an acknowledgement that multiple solution for a same OAM function would be acceptable (eg. multiple solutions for MPLS-TP CC) : this is an important point wrt. interop issues, and need to be clarified. A4 - I see also a possible issue related to the status of the document : in some places, the wording used, and the level of detail, gives the impression that all of what is said in the document will be enforceable on all MPLS-TP OAM solution specifications; but at the same time, the document is only "Informative" (and is accordingly not written in a way that appears to me as appropriate for a Standard Track document; it does not look like a specification document and does not claim to be). Maybe the solution would be to state clearly which role this document has with reference to other OAM specifications documents : only guidelines ?. See also comment A5 below. A5 - Not unrelated to the previous comment, it seems to me that this document sometimes goes into very low-level specifications details related to the structure of OAM data exchanged between nodes (OAM messages, OAM packets etc.) and the procedures on how they are exchanged : (a) this does not seem appropriate in a framework document, and (b) is here not even done in an homogeneous manner (not done in all places, not grouped) and often done in a way that lacks the required precision (the required precision for this to play the role of a specification), or lacks explanations on the motivations behind the choice made. In fact, all this gives the feeling that the authors had a very specific solution in mind when writing this framework, and wrote the framework (or at least parts of it) based on this. Getting consensus on the specifics of a solution seems to me as belonging to a specification document, which this document does not claim to be. It seems that it would be worth considering moving all the details that are low-level specs to appropriate solution specification document (and for cases where very specific indications would have to be kept, documenting the reasons and motivations of why they are in this document). More specifically: - the document implies that there are multiple types of OAM packets, and even specifies one of these types, going as far as to indicating that there is a common type for Continuity Checks and Connectivity Verification ("CC-V OAM packets") : isn't it a level of detail more appropriate in a specification rather than in a framework ? and if done in a framework, shouldn't we expect this to be more exhaustive ? - the definition section seem to impose a certain structure in the OAM data (OAM "packets" containing OAM "messages" themselves containing OAM "information elements") ; this seems a too low level of detail in a framework, which I think is confirmed by the fact that this structure is not really leveraged in the rest of the document (where "information element" is rarely used, and where most of the time "packet" is used) [as a side node, this seem to possibly exclude a solution allowing a piece of OAM information to be split across multiple packets, e.g. to cope with MTU issues] - in many different places, the text introduces names (with a capital letter) of some specific fields or information in OAM packets or messages ("Period" (5.1.1.3), "Target MIP" (3.4)), but this is not done evenly across the document since in some places the text is, appropriately, worded in a more abstract manner (such as "OAM messages must carry information on...") - even though this is not introduced clearly, after reading the document, the reader will understand that most OAM packets are periodic ; why this choice is made should at the very least be explained (periodic messages is not unexpected for pro-active monitoring messages, but less obvious for alarms report, remote defect indication...) - imposing that all OAM packets directly carry information about the period is a too low-level detail for a framework (not to mention defining the name of the "field" of the OAM "packet") : why exclude an OAM solution where the periodicity would be announced once but not repeated in all packets, or other solutions...? - the document indicates that on-demand connectivity verification messages/packets will be sent in "bursts" but no reason for this choice is given: why not only one ? why send the packets in a burst rather than spaced in time ?... (and... what *exactly* makes a sequence of packets a "burst"...) ; note that section 7.1.1 does not use on burst, and introduce reliability in the OAM exchange by using an ACK message A6 - The document, when introducing the notions of "Up MEP", "Down MEP" and "MIP" (sections 3.3 and 3.4), introduces an assumption of the internal design of an LSR : first of all, I note that this is unusual, since protocol specifications are usually written independently of such aspects and this seems like a good idea because the internals of an LSR are not standardized, and second I see a possible practical limitation due to the specific assumption being made : the assumption being made is that an LSR is made of multiple interfaces with a "forwarding engine" in the middle, and I fail to clearly see the implications in cases where the forwarding engine function is distributed in the LSR with parts of the work done in interfaces ; furthermore in cases where the node is multi-chassis, it seems possibly limiting to not be able to put MIPs in each possible place inside the LSR. It seems to me that either the specs chooses to talk about what is inside a node, but then should not restrict what can be done, or the spec should try to not make any assumption of how a node is internally designed. A7 - Beyond these comments on the nature of the document, I would have the following concerns about how CCCV is designed here: * there seem to be a lot of complexity brought by the choice of mixing CC and CV in the same packets * things would seem simpler if a source MEP identifier was always be used, including for CC * on the periodicity of "CC-V" messages: the document implies that periodicity is configured on *both* source and sink MEPs, and both must match (at least for bidir.), but nevertheless OAM messages "self-identify" their periodicity, and specifies procedures to detect misconfiguration of the period: this looks to me as more complex than needed and seems to me as offering opportunities for things to break [Of course, all of this is relatively "low-level", and as per my other comment, could possibly be moved and discussed into specification documents, in which case this comment can be ignored] A8 - Issues related to point-to-multipoint: * the functional model imposes that a MEP terminates all the OAM packets that it has received : what about a Down MEP on a node that is a bud node for a point-to-multipoint LSP (bud: at the same time a branch node and a leaf node for this LSP) ? if it actually terminates all the OAM packets received, then it seems that sink MEPs that are below him down the point-to-multipoint LSP won't receive any OAM packets. if I'm correct, then it probably needs to be fixed in some kind of way. * P2MP and OAM scaling : it seems that some of the mechanisms describe will have issues to scale when applied to P2MP, more specifically the ones where messages are sent back to the source MEP; examples are connectivity verification, loss measurements, throughput estimations and tracing; the scaling issue is that the source MEP will receive an amount of messages proportional to the amount of leaves (made worse by the fact that these are bursts in some cases) * Lock Reporting : is this mechanism designed also for P2MP ? how does a lock on a part of a tree impacts other parts of the tree that are not between the portion locked and the leaves below the portion locked ? (I could guess an answer, but I believe the document should be explicit) A9 - "TTL addressing": with a fresh eye, my first reaction was to find this mechanism a bit clunky given that the idea consist in overriding the TTL mechanism (which is aimed at reducing the impact of loops) for an OAM purpose, and that in such a case one may wonder what happens when/if these two mechanisms enter in competition. It could be claimed that IP traceroute is somehow a precedent, but traceroute is not a key building block of the IP architecture (OAM is a key part of MPLS-TP architecture), traceroute is also only used for tracing. So, I would say that such a particular mechanism would at the very least deserve being introduced in a dedicated sub-section (vs. being buried at the end of a section), and that this section could say more on the side effects of this choice and how they are handled : for instance referring to section 3.2 on SPME (that talks about that) and also describing the expected behavior when/if an OAM message TTL-expires at a node that was not the intended one (and possibly a node not supporting MPLS-TP OAM?). A10 - Throughput estimation (section 6.3.1): I'm highly skeptical of how such a feature will be applicable in practice because of the following: * the use of this feature may create congestion in the network: will an operator use this feature if it may impact have side-effects on customers ? * existing congestion in the network may impact the measurements: will the throughput estimation be useful ? * the estimation obtained will only reflect the bandwidth available at the moment when the measure is made, but the bandwidth available may not be constant over time * the option of having "two-way" throughput estimation looks to me as uselessly increasing the complexity : as noted, the same result is achievable with two one-way measurements, and it will not be limited by the bandwidth of the return path * if the two-way option is kept, it should be noted that it will not scale for point-to-multipoint * as noted in the document, the feasibility of line-rate processing the OAM packets may severely limit the use of this feature; and just saying that "Whether OAM packets can be processed at the same rate as payload is implementation dependent" does not make issues go away: what about interop between an equipment able to line rate process OAM packet and another not able to ? I'm wondering why injecting data packets (non OAM packets) one-way and counting what is received on the other end wouldn't meet the goal ; it seems to me that it would avoid issues related to line rate processing of OAM packets A11 - QoS of OAM packets : in multiple sections, indications are given on the PHB that will be chosen for OAM packets: while I can see how this applies to E-LSPs (PHB determined by the Traffic Class field of the MPLS header), I don't understand how this can work in the case of L-LSPs where only the drop precedence (not the whole PHB) is determined by the TC field, while the scheduling class is determined based on the label of the packet (common to all packets of the LSP, whether they are "real" data or OAM). The text gives the impression that only the E-LSP case is considered (contrarily to assumptions of the MPLS-TP framework). A12 - Security: Section 8 is honest, but at the same it is hard to ignore that what it is saying is something close to "we describe features that can disrupt a network, which is vulnerable to MITM attacks and we think that crypto is not going to be applicable, so we will just assume that the network is physically secured". Of course, a possible comparison would be a routing protocol like ISIS: it is also vulnerable to MITM attacks and today operator seem to be happy enough with assuming that the network is physically secured. But contrarily to what is described here, IS-IS is not used between non-trusted domains, and there are described crypto solution to mitigate these risks. Furthermore, since MPLS-TP OAM is supposed to be able to run even without IP, it cannot I guess get away with saying "let's use IPSec between LSRs". So, I don't really know how this would be fixable, but at the very least, it seems to me that the document should indicate that the area which needs to be trusted extends usual administrative domain boundaries, since the OAM designed here is supposed to be able to cross domain borders, and that as a result, it should be recommended that the OAM that a domain accepts from another domain should be filtered/policed in some kind of way. (I'm looking forward on how security area people will react if this review this, but maybe we should warm up the defibrillators.) A13 - Comments on "Sub-Path Maintenance Elements" (section 3.2): it seems to me that there are two strong limitations to the use of SPME, which may prove problematic (too limiting): * one is the fact that SPME seem to be only applicable to co-routed transport path ("[SPMEs], [...] are instantiated to provide monitoring of a portion of a set of co-routed transport paths [...). ") : with an external eye, it seems that having the possibility to do OAM on parts of a path is equally important for all other types of transport path (bidir assoc., unidir p2p, unidir p2mp) * another one is the fact that to do OAM on a portion of a transport path it is required to modify the dataplane an add another layer of MPLS encapsulation: at the very least, I would expect reasons to be given for excluding a solution that would allow OAM to be done on a portion of a transport path, as it would seem to me as offering more flexibility (the document *does* identify limitation or complexity due to the addition of a new layer to do OAM on a portion of a path) A14 - It seems to me that there is sometimes a discrepancy between the high level of expectation on how fine-grained and precise the OAM will be and the obstacles that are identified and that will make these expectations hard to meet in some cases, not always with solutions being described. Here are a few examples: * SPME and TTL addressing : section 3.2 (§6 item 2) indirectly tells us that the use of the uniform model for TTL handling (copying the TTL between layes) will break "TTL addressing" of the MIPs, but still claim that it should be possible for the operator to use the uniform model ; unless it is explained how the "MIP addressing" mechanism can be adjusted to cope with the uniform model for TTL handling, this seems totally contradictory * Multilink : the document acknowledges the fact that link aggregation has to be allowed, and at the same time that it will reduces the effectiveness or even defeat the purpose of the OAM defined here (sections 4.6, 5.5.3 and 6.2.3). One issue is that it seems to me that what stops working well when multilink is used is only partially documented (if I'm correct nothing is said on the fact that the OAM defined here will not meet the purpose of continuity checks done on an LSP end-to-end if multilink is used somewhere in the path ; same for delay measurements) * discrepancy between the aims of packet loss measurements and the identified obstacles to have very precise measurements (5.5.2, 5.5.3) I'm not sure that this qualifies as a "Major issue", but I can't help express my skepticism. *Minor Issues:* B1 - Section 2.1, acronyms: * the "CC-V" acronym is not defined => this one is really a bit problematic because it seems to carry a lot of assumptions (see comment above) B3 - Section 2.2 "Definitions": * "Source MEP" is defined as "A MEP acts as MEP source for an OAM message when it originates and inserts the message into the transport path for its associated MEG" => it seems to me that this definition does not properly cover the case where an out-of-band path is used for OAM replies (OAM message is not sent "into the transport path") * as defined in 2.2, the terms source and sink MEPs are a bit confusing in the case of an OAM function instrumenting a particular direction of a transport path, and involving a packet sent by a MEP to another MEP and this other MEP replying, because the "source MEP" (being defined as the MEP which "originates" an OAM message) is not the same one in both cases, and has nothing to do with the source node of the transport path - this risk of confusion is made worse by the fact that sometimes "originating MEP" is used ; and that diagrams position "sink MEPs" on destination nodes ; the text also uses sentence contradictory with this definition "x is [...] transmitted by a sink MEP [...] its source MEP [...]" (section 5.2 §1) ; I wonder if the solution wouldn't be to rather define source and sink MEPs, not wrt to who sends OAM packets, but wrt. the direction of the transport path being monitored, the consistency between these terms must definitely be made better B3 - on "ME" and "MEG" definitions * Section 3.1 §1 : "a relationship between two points .... The two points that define a ME ... . In between the two points ..." => what are "points" ? what is exactly their relationship with LSRs ? => additionally, If I'm correct, "two points" should be replaced by "two points (or more in the P2MP case)" to properly cover the P2MP case * I found the central notions of "ME" and "MEG" worded in a way that does not make the concept very easy to grasp. I don't have practical suggestions to improve the text, but maybe the text could have a sentence clarifying the following: is a MEP a MEG end point or a ME end point ? (my understanding is that even though an MEP is a MEG end point, it also an endpoint for the MEs in the said MEP (or, in the P2MP case, for one of them). The fact that MEP are described more in sub-section 3.3, significantly further down the document, does not help : maybe this could also be improved. Just as an example, reading a sentence like "a node at the edge of a MEG always supports a MEP" gives a strange feeling that the abstraction introduced are not self supporting. * Taking a step back, I wonder if MEPs shouldn't be introduced first, then the notion of ME introduced, and then the notion of MEG ; if this is doable, but this for sure would help understand/explain the concepts B4 - there is a significant document readability issue in that questions related to how MIP are "addressed" are discussed in the document before being introduced (3.2 §6 talks about "MIP addressing" and TTL handling, ditto in 3.2 §10, plus in 3.4 "a MIP... may be addressed..." ), and even when the corresponding mechanism is explained (section 3.4), the link with the "TTL addressing" nickname of the mechanism is not made. I would suggest considering the following options: * move the section on MIPs (currently 3.4) before section 3.2 * in this section, dedicate a sub-section on how OAM messages can target a specific MIP, and introduce the TTL addressing idea here * also add "TTL addressing" in Section 2.2 "Definitions" B5 - section 3.2 "SPME and TC monitoring": * §2: Does the notion of SPME really excludes, as the text implies, the cases of associated bidir. and unidir. ? If so, this looks to me as a possibly strong limitation. * §5: "The SPME is monitored using normal LSP monitoring." -> what you mean by "normal LSP monitoring" would deserve to be explicited * this section is particularly painful to read due to the use of a mix of multiple terms for same (or at least very similar notions) : Nested MEGs, SPME, and Tandem Connection Monitoring . I think that the relationship between these terms should first be explained, and that later on only one of these terms should be used. Moreover, my feeling on the "Tandem Connection" is that, even if it may very well have historical reasons to exist (in the ITU-T I assume?), it nevertheless is really opaque, since a "Tandem Connection" hasn't much to do with a "tandem" (which as I understand is closer to one or more things put one *after* the other, not one *over* the other or *nested* one in the other); I would find this section hugely easier to read if the very clear term of "Nested MEG" was used (instead of Tandem Connection Monitoring and or SPME). * this section would also be easier to understand if it was reminded to the reader that what we are talking about is "a hierarchical LSP instantiated to monitor a portion of a transport path" ; I took me a significant time to infer this (honestly because I did not lookup the definition in the MPLS-TP framework) and you'll certainly spare your readers some effort if you add this precision, very useful by the way since you later talk about the effects of this hierarchy on MPLS-TP OAM * "PM statistics need to be adjusted for the encapsulation overhead of the additional SPME sub-layer." => the only thing defined as "performance monitoring" in this document is packet loss measurements, which is not impacted by encapsulation overhead ; maybe this sentence should say "bandwidth estimation" instead (defined in this document as a diagnosis test) ? B6 - section 3.3 §10: "An MPLS-TP MEP sink passes a fault indication to its client (sub-)layer network as a consequent action of fault detection." => is it always done, or is it optional ? what if there is no OAM on the client side to carry any fault indication ? B7 - section 3.3: "a per- interface MEP is called "Up MEP" or "Down MEP" depending on its location as upstream or downstream relative to the forwarding engine": my initial interpretation of this sentence was based on the idea that "downstream" referred to the stream of OAM packets flowing from the source MEP to the sink MEP; with this in mind, the definition given here was not consistent with the one in 2.1, nor with the diagram in figure 3 . After some time, it finally occurred to me that the intent was possibly to use "downstream" and "upstream" to refer to the client to server direction (with the client over the server, ie client up, and server down)... Assuming I'm correct and have guessed the intended meaning, I think that the text should be made more explicit on what downstream/upstream means here, or alternatively, avoid the use of this ambiguous term, and even look for better terms such as client-side MEP and network-side MEP ? B8 - section 4: this section is quite painful to read due to and abundant use of multi-layered acronyms, an example being LSMEG, for "LSP SPME ME Group" which expands as (take a deep breath)... "Label Switching Protocol Sub-Path Maintenance Element Maintenance Entity Group".... (!!) => as a general comment, I think that when introducing acronyms, it is sane to think twice and check if on is making the doc easier to write and/or easier to read => here, the acronyms did not help me as a reader, and I would suggest considering removing the acronyms defined at the start of section 4 from the document and using the expanded forms instead: "LSP ME" or "PW SPME ME" for instance, are not long to write, and are easier to interpret than "LME" or "PSME" => I note that these acronyms are not even used in the document : more specifically only the variants without the "Group" at the end are used... at the very least the text should be revised to remove the "Groups" and "G"s from the list at the start of section 4 B9 - section 5.1 §4 "When MPLS-TP is deployed in transport network environments where IP addressing is not used in the forwarding plane, the ICC-based format for MEP identification is used" => no reason is given why IP addressing would be excluded in cases where IP is available in the control or management plane (even if IP is not used in the forwarding plane) : why not allow this ? B10 - section 5.1.2 §5 and §6: "the MEP [...] declares a signal fail condition at the transport path level" => for a MEP part of an MEG monitoring a PW, I would have expected the signal fail condition to be declared at the PW level B11 - section 5.1.3 talks about "Performance Monitoring", but is a sub-section of section 5.1 on CCCV : (a) this seems awkward in terms of document structure, and (b) it seems to possibly conflict with section 5.5 that implies that specific packets are used for loss measurements (not "CC-V" packets) B12 - section 5.1.3: Protection Switching item says "default transmission period is 3.33ms [...], in order to achieve sub-50ms the CC-V defect entry criteria should resolve in less than 10msec, and complete a protection switch within a subsequent period of 50 msec." => if the "sub-50ms" window includes the defect detection time, then there are only 40ms left to complete protection switching (not 50); alternatively, if it does not, then the requirement to detect the defect in less than 10ms due not result from the sub-50ms requirement => the said paragraph need I think to be corrected in some ways => moreover, if I'm correct, the entry criteria defined in 5.1.1.1 does not meet the "detect in less than 10ms" criteria (3.33ms*3.5 = 11.655ms) ; for sure, 1.655ms is not much, but it is surprising to see at the same time a very high level of precision in the proposed parameters (3.5 factor, 3.33ms, 10ms detection time) and an arithmetic inconsistency when these parameters are combined: maybe a good idea would be to let more freedom to protocol implementers in the values they can use for transmission period, and in the target values for detection times ? B13 - section 5.2: why exclude unidirectional transport paths from benefiting of RDI ? (if the restriction is needed then explain why, else remove the restriction ?) B14 - section 5.2.1: "the RDI transmission rate and PHB of the OAM packets carrying RDI should be the same as that configured for CC-V" ; since the rate of CC-V message depends on the application (section 5.1.3), how should this sentence be interpreted ? beyond this, why mandate the exact same rate for both ? B15 - section 5.3: * §4 talks about "loss of continuity alarms": I can't be sure what alarms mean here, does refer to an OAM message (RDI ?) or to "something" sent to the NMS (assuming there is one) ?? => I can't determine whether or not a sink MEP sends RDI to the source MEP if it receives AIS for a MEG * the whole section does not say clearly which entities may send AIS: I would assume all MEPs *and* all MIPs , but it may be nice to make it explicit B16 - section 5.3: "generate packets with AIS information" => should this be understood as "AIS OAM messages" or "OAM packets with AIS information elements", or more generally as "OAM messages with AIM information"? (see general comment on how this document specifies the content of OAM messages) B17 - section 5.5 (on packet loss measurements) : * section 5.5: the text could be more explicit and say more about which packets are sent by the source MEP with which information and what is sent back by sink MEPs and with which information ? * section 5.5 §2: *when* exactly are packets sent *and* received by the peer MEP ? the text implies that this would only not be done for unidir ; but it seems to my fresh eyes, that using a return path could be considered ; either way, could this point be explicited ? * section 5.5 §2 says "The LM transactions are issued such that the OAM packets will experience the same queuing discipline as the measured traffic [...]" while 5.5.1 says "LM OAM packets should be transmitted with the PHB that yields the lowest discard probability within the measured PHB Scheduling Class (see RFC 3260 [16])." => it looks to me possibly contradictory to impose that real data and OAM LM packets have the same queueing discipline but possibly a distinct drop precedence ; maybe this could be rephrase with less risk of confusion by using terms such as "drop precedence" and "scheduling class" => see also comment A11 => in any case, having a distinct drop preference for OAM packets looks to me as possibly defeating the purpose in some situations: indeed, it seems that the measurement error coming from the difference of treatment between OAM packets and real data could deserve the same worries that the error coming from sampling skew ; why not, for instance, allow the operator to selectively use a TC with the highest discard probability to estimate the worst case of packet loss ? * section 5.5.3 provides possible causes of inaccurate LM ; I think additional ones are worth mentioning: - the fact that each link in the bundle of links may intrinsically have a different packet loss (e.g. one fiber is clean, the other is not) - the fact that a different hardware queues can be used for each link in the bundle of links, possibly with a different packet loss behavior when the measure is done (one is full, the other is not) => my feeling is that this is not so much a question of identifying the possible causes of inaccuracies, than a problem of defining what packet loss is being measured, but at the very least, I would expect to cover all of the most easily identified ones ; alternatively one may consider suggesting that the LM measurement technique should be designed so that all possible hardware path for a said LSP are tested... ? B18 - section 6.1: §1 says "network management may invoke periodic on-demand bursts of on-demand CV packets, as required in section 2.2.3 of RFC 5860", but I can't find anything on bursts on RFC5860 B19 - section 6.2: a general comment on this section and its sub-sections is that is seems largely redundant with section 5.1 (also on CV but the pro-active side), readability would be highly improved if this section was highlighting the differences with section 5.1 (such a s "mechanisms are the same as section 5.1 with the following exceptions: ...") and avoid repeating common text as much as possible B20 - section 6.2.2: AFAICT, the content of this section is identical to 5.5.2, and could be replaced with a pointer to that section B21 - section 6.3.2 §4: The fact that it is not possible to send an OAM message addressed to the MIP/MEP to unloop the data plane is rather surprising. Does this means that a special processing must be applied to this message ? B22 - In many places, it seems that the text has been written with only the P2P case in mind, and that - at least the wording - does not take into account the case of P2MP... - section 6.4 : "to the sink MEP" => - section 5.1 §1 : "between two MEPs" => ditto - section 5.1 §3 : "processed by the sink MEP" => ditto - section 5.1 §8 : "only the sink MEP" => ditto - section 5.1 §13 : "parsed by the sink MEP" => ditto *Nits: * ( Nits are editorial or layout items. They are things that would ideally be resolved before publication to make the document more readable, and may be raised now to save the RFC Editor work. Usually a reviewer will not be looking for this type of issue, but may find some in the course of their review. ) * Section 2 "terminology and definitions": * it would I think be easier to put the section with definitions *before* the section giving their acronyms * I think that readability would be enhanced if both section 2.1 and section 2.2 were each split into two sub-sections, one for things already defined in other documents, and another one for things introduced by this document itself * 2.1: the following acronyms are used in the text but not defined: ICC, E-LSP, TPE, SPE, EMS, NMS, CC, CV * 2.2: - "Signal Degrade" is defined but not used in the rest of the document - "MEP Source" is defined, but in many places in the document "Source MEP" is used, I guess the two should be made consistent - ditto for "MEP Sink" * 3.1 §4 "This functional model defines...": this paragraph sounds like an ME has the responsibility to monitor and manage a network, ie. that an ME is the human operator or an OSS entity of some kind, the text should probably be rewritten in a better way * ditto for 3.3§2 "MEPs are responsible for activating and controlling ... " : this gives the impression that MEPs are an active entity doing actions, while my understanding was that they were points, ie something close to a location were something is done * 3.1 §5 uses the term "originating MEP" : if this is the same a "source MEP", then "source MEP" should be used (and if not the difference should be explained) * 3.2 §6 "The SPME would use the uniform model of TC code point copying between" => unfortunate TLA collision between "(T)andem (C)onnection" and "(T)raffic (C)lass", even more unfortunate that a lot of people may still be more familiar with the old "Exp" name ; I would suggest expanding "TC" into "Traffic Class" in this sentence (and a reference added to RFC5513 section 4.2 !) * 3.2 §6 "short pipe for TTL handling": readability possibly improved by reminding the reader what the short-pipe model is (no TTL copying) * 3.2 §8 "As any MIP ... is ... , hence ... " => remove "any" or "hence" ? * 3.3 §1: "while in the context of an SPME LSRs for the MPLS-TP LSP can be ..." => missing a comma between "SPME" and "LSRs" => this paragraph is not easy to read, and would deserve beind rewrittent more clearly * section 3.3 §15: "It may occur that the Up MEPs of an SPME are set on both sides of the forwarding engine such that the MEG is entirely internal to the node." => would be easier to read this way: "It may occur that the source and sinks MEPs are on the same node, and are both Up MEPs, each on one side of the forwarding engine, such that the MEG is entirely internal to the node." ...? * 3.8: - "objectives" => I would suggest saying "requirements" instead of "objective" - "in transport network" => "in _a_ transport network", or use plural - "The monitored or managed transport path condition has to be exactly the same irrespective of any configurations necessary for maintenance" => if the intent is to include changes of the transport path that happens due to local repair or end to end restoration, then "any configurations necessary for maintenance" is not very nice, as dataplane changes resulting from control plane procedure are not often called "configuration" nor "maintenance" * section 4: "The MEGs specified in this MPLS-TP framework are compliant with the architecture framework for MPLS-TP MS-PWs [4] and LSPs [1]" -> I believe the text should say "with the architecture framework for MPLS-TP[8], MS-PWs [4] and LSPs [1]" (add "[8], ") * figure 5: - is very difficult to understand and its readability would deserve being improved in order to ease reading the following paragraphs. - adding "LSR" labels in the boxes in the diagram (and making the boxes bigger) would be nice - putting boxes for LSRs 2 and Y at the same size of the other LSRs would be better - avoiding the "LSP" label on the boxes for LSR 2 and Y would also help - the legend (" ^---^ ME ^ MEP ==== LSP .... PW") would be more readable with each item on a separate line * 3.2 §9, 4.1 §1 and 5.1§7: "share fate" would sound better than "fate share" which is not correct english * figure 5: "Figure 5 depicts a high-level reference model for the MPLS-TP OAM framework.": I find the use of the "model" term rather surprising since what I see looks to me more as an "example", as an "illustration", used in the rest of the section to more easily illustrate the concepts defined, rather than an high-level abstract model (which I expect would not be specific, why not just say "example" instead of "model" ? * 4.3, figure 6: it seems that this figure could be removed and replaced by a reference to figure 5 * 4.4 §1: "with associated maintenance entity" => add "an" after "with" * 4.5 §1: ditto * 4.4 §4: "end node" and "intermediate node" could be replaced by the wellknowns LER and LSR terms, but in fact it seems that the whole paragraph be replaced by a straightforward shorter sentence: "A LSME can be defined between any node (LER or LSR) of a given LSP" * 4.5 §1: "An MPLS-TP MS-PW SPME Monitoring ME (PSME) is [...] intended to monitor an arbitrary part of an MS-PW between the pair of MEPs instantiated form the SPME independently from the end-to-end monitoring (PME)." => I cannot parse the sentence correctly as-is, but I can if I change it into "instantiated _from_ the SPME independently _of_ the end-to-end monitoring (PME)." * 4.5, figure 8: it seems that this figure could be removed and replaced by a reference to figure 5 * section 5, list item 4: "[...] loss measurement indication of excessive impairment of information transfer capability" => is this different than a "packet loss indication" ? if yes, then it would be nice to explain more, and if no, then maybe a simpler expression would be nicer ? * section 5.1.2 §2: the text says "If a MEP detects an unexpected globally unique Source MEP ..." but this event is defined in 5.1.1.2 as a "mis-connectivity defect" ; hence the text in 5.1.2 would I think be better rewritten as "If a MEP detects a mis-connectivity defect" * section 5.1.3: milliseconds should be abbreviated as "ms" not as "msec" (current text has a mix of the two) * section 5.3 §2: "generates packets with AIS information in the downstream direction": to avoid misunderstanding on what "downstream" means here (see my comment on Up/Down MEPs), it may be clearer to say "toward the sink MEP(s)" rather than "in the downstream direction" * section 5.6 § 3 and 6.5 §3: "synchronized precision time" => replace by "precise time synchronisation" ? ("synchronized precision time" seems rarely used, instead possibly in the specific GPS context) * section 6, last paragraph: "exclusive" => replace by "exclusively" ? * section 6.1, last paragraph: "target" => replace by "targeted" * section 6.1§3 : uses the term "originating MEP" : if this is the same a "source MEP", then "source MEP" should be used (and if not the difference should be explained) * section 6.3.1 "graphing the percentage of OAM test packets received" => "computing" would be more appropriate than "graphing" * References: G.806 is given as a "Normative" reference, but it appears to me that it is only referred to to complement the Signal Fail and Signal Degrade definitions in section 2.1 ; for this reason, a possibility would be to move this reference to the "Informative references" section. * in 5 places, the term "segment or concatenated segment" is used, it would be great to replace this phrase by "path segment", which is usefully precisely introduced by this document as meaning "segment or concatenated segment" ; you could also consider avoiding "concatenated segment" in all the other places, and use the "path segment" term instead --------------070705020804040208010900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-mpls-tp-oam-framework-09
Reviewer: Thomas Morin
Review Date: 2010-11-20
IETF LC End Date: 2010-11-22
Intended Status: Informational

Summary:  "I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors."

Comments:

Beyond the issues I found with the document (see below), I have a general concern on the readability of the document.

Major Issues:
A1 - It seems to me that the role of this document, among the documents defining the MPLS Transport Profile, should be clarified and/or better explained. One of my assumptions was that what such a "framework" was written to factor out, and document in one place, all of what is common to the MPLS-TP OAM solutions, many of which are expected to be defined because of the multiplicity of OAM functions that are needed. I would expect the document to give a high-level roadmap of the specification documents that will be added to obtain full specifications (for instance: one document for CC, one for CV, or for LM, one for tracing etc. ; with the possibility of grouping the specs for some of these into common docs when applicable). I would also expect the document introduction to indicate where it stands with reference to already defined document on MPLS and MPLS-TP OAM (the important relation ship with GACH specs and PW VCCV is only explained in the sub-section on SPME...).


A2 - The document has in two places a wording that could lead to misunderstandings: the phrase "each OAM solution" is used in 3.3§5 and 3.3§14, which could be understood as an acknowledgement that multiple solution for a same OAM function would be acceptable (eg. multiple solutions for MPLS-TP CC) : this is an important point wrt. interop issues, and need to be clarified.


A4 - I see also a possible issue related to the status of the document : in some places, the wording used, and the level of detail, gives the impression that all of what is said in the document will be enforceable on all MPLS-TP OAM solution specifications; but at the same time, the document is only "Informative" (and is accordingly not written in a way that appears to me as appropriate for a Standard Track document; it does not look like a specification document and does not claim to be). Maybe the solution would be to state clearly which role this document has with reference to other OAM specifications documents : only guidelines ?. See also comment A5 below.


A5 - Not unrelated to the previous comment, it seems to me that this document sometimes goes into very low-level specifications details related to the structure of OAM data exchanged between nodes (OAM messages, OAM packets etc.) and the procedures on how they are exchanged : (a) this does not seem appropriate in a framework document, and (b) is here not even done in an homogeneous manner (not done in all places, not grouped) and often done in a way that lacks the required precision (the required precision for this to play the role of a specification), or lacks explanations on the motivations behind the choice made.

In fact, all this gives the feeling that the authors had a very specific solution in mind when writing this framework, and wrote the framework (or at least parts of it) based on this. Getting consensus on the specifics of a solution seems to me as belonging to a specification document, which this document does not claim to be. It seems that it would be worth considering moving all the details that are low-level specs to appropriate solution specification document (and for cases where very specific indications would have to be kept, documenting the reasons and motivations of why they are in this document).

More specifically:
- the document implies that there are multiple types of OAM packets, and even specifies one of these types, going as far as to indicating that there is a common type for Continuity Checks and Connectivity Verification ("CC-V OAM packets") : isn't it a level of detail more appropriate in a specification rather than in a framework ? and if done in a framework, shouldn't we expect this to be more exhaustive ?
- the definition section seem to impose a certain structure in the OAM data (OAM "packets" containing OAM "messages" themselves containing OAM "information elements") ; this seems a too low level of detail in a framework, which I think is confirmed by the fact that this structure is not really leveraged in the rest of the document (where "information element" is rarely used, and where most of the time "packet" is used)  [as a side node, this seem to possibly exclude a solution allowing a piece of OAM information to be split across multiple packets, e.g. to cope with MTU issues]
- in many different places, the text introduces names (with a capital letter) of some specific fields or information in OAM packets or messages ("Period" (5.1.1.3), "Target MIP" (3.4)), but this is not done evenly across the document since in some places the text is, appropriately, worded in a more abstract manner (such as "OAM messages must carry information on...")
- even though this is not introduced clearly, after reading the document, the reader will understand that most OAM packets are periodic ;
why this choice is made should at the very least be explained (periodic messages is not unexpected for pro-active monitoring messages, but less obvious for alarms report, remote defect indication...)
- imposing that all OAM packets directly carry information about the period is a too low-level detail for a framework (not to mention defining the name of the "field" of the OAM "packet") : why exclude an OAM solution where the periodicity would be announced once but not repeated in all packets, or other solutions...?
- the document indicates that on-demand connectivity verification messages/packets will be sent in "bursts" but no reason for this choice is given: why not only one ? why send the packets in a burst rather than spaced in time ?... (and... what *exactly* makes a sequence of packets a "burst"...) ; note that section 7.1.1 does not use on burst, and introduce reliability in the OAM exchange by using an ACK message


A6 - The document, when introducing the notions of "Up MEP", "Down MEP" and "MIP" (sections 3.3 and 3.4), introduces an assumption of the internal design of an LSR : first of all, I note that this is unusual, since protocol specifications are usually written independently of such aspects and this seems like a good idea because the internals of an LSR are not standardized, and second I see a possible practical limitation due to the specific assumption being made : the assumption being made is that an LSR is made of multiple interfaces with a "forwarding engine" in the middle, and I fail to clearly see the implications in cases where the forwarding engine function is distributed in the LSR with parts of the work done in interfaces ; furthermore in cases where the node is multi-chassis, it seems possibly limiting to not be able to put MIPs in each possible place inside the LSR.  It seems to me that either the specs chooses to talk about what is inside a node, but then should not restrict what can be done, or the spec should try to not make any assumption of how a node is internally designed.
    

A7 - Beyond these comments on the nature of the document, I would have the following concerns about how CCCV is designed here:
  * there seem to be a lot of complexity brought by the choice of mixing CC and CV in the same packets
  * things would seem simpler if a source MEP identifier was always be used, including for CC
  * on the periodicity of "CC-V" messages: the document implies that periodicity is configured on *both* source and sink MEPs, and both must match (at least for bidir.), but nevertheless OAM messages "self-identify" their periodicity, and specifies procedures to detect misconfiguration of the period: this looks to me as more complex than needed and seems to me as offering opportunities for things to break
[Of course, all of this is relatively "low-level", and as per my other comment, could possibly be moved and discussed into specification documents, in which case this comment can be ignored]


A8 -  Issues related to point-to-multipoint:
 * the functional model imposes that a MEP terminates all the OAM packets that it has received : what about a Down MEP on a node that is a bud node for a point-to-multipoint LSP (bud: at the same time a branch node and a leaf node for this LSP) ? if it actually terminates all the OAM packets received, then it seems that sink MEPs that are below him down the point-to-multipoint LSP won't receive any OAM packets. if I'm correct, then it probably needs to be fixed in some kind of way.
 * P2MP and OAM scaling : it seems that some of the mechanisms describe will have issues to scale when applied to P2MP, more specifically the ones where messages are sent back to the source MEP; examples are connectivity verification, loss measurements, throughput estimations and tracing; the scaling issue is that the source MEP will receive an amount of messages proportional to the amount of leaves (made worse by the fact that these are bursts in some cases)
 * Lock Reporting : is this mechanism designed also for P2MP ? how does a lock on a part of a tree impacts other parts of the tree that are not between the portion locked and the leaves below the portion locked ?  (I could guess an answer, but I believe the document should be explicit)


A9 - "TTL addressing": with a fresh eye, my first reaction was to find this mechanism a bit clunky given that the idea consist in overriding the TTL mechanism (which is aimed at reducing the impact of loops) for an OAM purpose, and that in such a case one may wonder what happens when/if these two mechanisms enter in competition.
It could be claimed that IP traceroute is somehow a precedent, but traceroute is not a key building block of the IP architecture (OAM is a key part of MPLS-TP architecture), traceroute is also only used for tracing.
So, I would say that such a particular mechanism would at the very least deserve being introduced in a dedicated sub-section (vs. being buried at the end of a section), and that this section could say more on the side effects of this choice and how they are handled : for instance referring to section 3.2 on SPME (that talks about that) and also describing the expected behavior when/if an OAM message TTL-expires at a node that was not the intended one (and possibly a node not supporting MPLS-TP OAM?).


A10 - Throughput estimation (section 6.3.1): I'm highly skeptical of how such a feature will be applicable in practice because of the following:
 * the use of this feature may create congestion in the network: will an operator use this feature if it may impact have side-effects on customers ?
 * existing congestion in the network may impact the measurements: will the throughput estimation be useful ?
 * the estimation obtained will only reflect the bandwidth available at the moment when the measure is made, but the bandwidth available may not be constant over time
 * the option of having "two-way" throughput estimation looks to me as uselessly increasing the complexity : as noted, the same result is achievable with two one-way measurements, and it will not be limited by the bandwidth of the return path
 * if the two-way option is kept, it should be noted that it will not scale for point-to-multipoint
 * as noted in the document, the feasibility of line-rate processing the OAM packets may severely limit the use of this feature; and just saying that "Whether OAM packets can be processed at the same rate as payload is implementation dependent" does not make issues go away: what about interop between an equipment able to line rate process OAM packet and another not able to ?  I'm wondering why injecting data packets (non OAM packets) one-way and counting what is received on the other end wouldn't meet the goal ; it seems to me that it would avoid issues related to line rate processing of OAM packets


A11 - QoS of OAM packets : in multiple sections, indications are given on the PHB that will be chosen for OAM packets: while I can see how this applies to E-LSPs (PHB determined by the Traffic Class field of the MPLS header), I don't understand how this can work in the case of L-LSPs where only the drop precedence (not the whole PHB) is determined by the TC field, while the scheduling class is determined based on the label of the packet (common to all packets of the LSP, whether they are "real" data or OAM).  The text gives the impression that only the E-LSP case is considered (contrarily to assumptions of the MPLS-TP framework).


A12 - Security: Section 8 is honest, but at the same it is hard to ignore that what it is saying is something close to "we describe features that can disrupt a network, which is vulnerable to MITM attacks and we think that crypto is not going to be applicable, so we will just assume that the network is physically secured".
Of course, a possible comparison would be a routing protocol like ISIS: it is also vulnerable to MITM attacks and today operator seem to be happy enough with assuming that the network is physically secured. But contrarily to what is described here, IS-IS is not used between non-trusted domains, and there are described crypto solution to mitigate these risks. Furthermore, since MPLS-TP OAM is supposed to be able to run even without IP, it cannot I guess get away with saying "let's use IPSec between LSRs".
So, I don't really know how this would be fixable, but at the very least, it seems to me that the document should indicate that the area which needs to be trusted extends usual administrative domain boundaries, since the OAM designed here is supposed to be able to cross domain borders, and that as a result, it should be recommended that the OAM that a domain accepts from another domain should be filtered/policed in some kind of way.
(I'm looking forward on how security area people will react if this review this, but maybe we should warm up the defibrillators.)


A13 - Comments on "Sub-Path Maintenance Elements" (section 3.2): it seems to me that there are two strong limitations to the use of SPME, which may prove problematic (too limiting):
  * one is the fact that SPME seem to be only applicable to co-routed transport path ("[SPMEs], [...] are instantiated to provide monitoring of a portion of a set of co-routed transport paths [...). ") : with an external eye, it seems that having the possibility to do OAM on parts of a path is equally important for all other types of transport path (bidir assoc., unidir p2p, unidir p2mp)
  * another one is the fact that to do OAM on a portion of a transport path it is required to modify the dataplane an add another layer of MPLS encapsulation: at the very least, I would expect reasons to be given for excluding a solution that would allow OAM to be done on a portion of a transport path, as it would seem to me as offering more flexibility (the document *does* identify limitation or complexity due to the addition of a new layer to do OAM on a portion of a path)


A14 - It seems to me that there is sometimes a discrepancy between the high level of expectation on how fine-grained and precise the OAM will be and the obstacles that are identified and that will make these expectations hard to meet in some cases, not always with solutions being described. 
Here are a few examples:
   * SPME and TTL addressing : section 3.2 (§6 item 2) indirectly tells us that the use of the uniform model for TTL handling (copying the TTL between layes) will break "TTL addressing" of the MIPs, but still claim that it should be possible for the operator to use the uniform model ; unless it is explained how the "MIP addressing" mechanism can be adjusted to cope with the uniform model for TTL handling, this seems totally contradictory
   * Multilink : the document acknowledges the fact that link aggregation has to be allowed, and at the same time that it will reduces the effectiveness or even defeat the purpose of the OAM defined here (sections 4.6, 5.5.3 and 6.2.3). One issue is that it seems to me that what stops working well when multilink is used is only partially documented (if I'm correct nothing is said on the fact that the OAM defined here will not meet the purpose of continuity checks done on an LSP end-to-end if multilink is used somewhere in the path ; same for delay measurements)
   * discrepancy between the aims of packet loss measurements and the identified obstacles to have very precise measurements (5.5.2, 5.5.3)
I'm not sure that this qualifies as a "Major issue", but I can't help express my skepticism.


Minor Issues:


B1 - Section 2.1, acronyms:
       * the "CC-V" acronym is not defined => this one is really a bit problematic because it seems to carry a lot of assumptions (see comment above)


B3 - Section 2.2 "Definitions":

       * "Source MEP" is defined as "A MEP acts as MEP source for an OAM message when it originates and inserts the message into the transport path for its associated MEG"  =>  it seems to me that this definition does not properly cover the case where an out-of-band path is used for OAM replies (OAM message is not sent "into the transport path")
 
      * as defined in 2.2, the terms source and sink MEPs are a bit confusing in the case of an OAM function instrumenting a particular direction of a transport path, and involving a packet sent by a MEP to another MEP and this other MEP replying, because the "source MEP" (being defined as the MEP which "originates" an OAM message) is not the same one in both cases, and has nothing to do with the source node of the transport path - this risk of confusion is made worse by the fact that sometimes "originating MEP" is used ; and that diagrams position "sink MEPs" on destination nodes ;  the text also uses sentence contradictory with this definition "x is [...] transmitted by a sink MEP [...] its source MEP [...]" (section 5.2 §1) ;  I wonder if the solution wouldn't be to rather define source and sink MEPs, not wrt to who sends OAM packets, but wrt. the direction of the transport path being monitored, the consistency between these terms must definitely be made better


B3 - on "ME" and "MEG"  definitions

   * Section 3.1 §1 : "a relationship between two points .... The two points that define a ME ... . In between the two points ..."
      => what are "points" ? what is exactly their relationship with LSRs ?
      => additionally, If I'm correct, "two points" should be replaced by "two points (or more in the P2MP case)" to properly cover the P2MP case

   * I found the central notions of "ME" and "MEG" worded in a way that does not make the concept very easy to grasp. I don't have practical suggestions to improve the text, but maybe the text could have a sentence clarifying the following: is a MEP a MEG end point or a ME end point ? (my understanding is that even though an MEP is a MEG end point, it also an endpoint for the MEs in the said MEP (or, in the P2MP case, for one of them).  The fact that MEP are described more in sub-section 3.3, significantly further down the document, does not help : maybe this could also be improved.  Just as an example, reading a sentence like "a node at the edge of a MEG always supports a MEP" gives a strange feeling that the abstraction introduced are not self supporting.

   * Taking a step back, I wonder if MEPs shouldn't be introduced first, then the notion of ME introduced, and  then the notion of MEG ; if this is doable, but this for sure would help understand/explain the concepts


B4 - there is a significant document readability issue in that questions related to how MIP are "addressed" are discussed in the document before being introduced (3.2 §6 talks about "MIP addressing" and TTL handling, ditto in 3.2 §10, plus in 3.4  "a MIP... may be addressed..." ), and even when the corresponding mechanism is explained (section 3.4), the link with the "TTL addressing" nickname of the mechanism is not made.  I would suggest considering the following options:
  * move the section on MIPs (currently 3.4) before section 3.2
  * in this section, dedicate a sub-section on how OAM messages can target a specific MIP, and introduce the TTL addressing idea here
  * also add "TTL addressing" in Section 2.2  "Definitions"


B5 - section 3.2 "SPME and TC monitoring":

   * §2: Does the notion of SPME really excludes, as the text implies, the cases of associated bidir. and unidir. ?  If so, this looks to me as a possibly strong limitation.

   * §5: "The SPME is monitored using normal LSP monitoring." -> what you mean by "normal LSP monitoring" would deserve to be explicited

   * this section is particularly painful to read due to the use of a mix of multiple terms for same (or at least very similar notions) : Nested MEGs, SPME, and Tandem Connection Monitoring . I think that the relationship between these terms should first be explained, and that later on only one of these terms should be used.  Moreover, my feeling on the "Tandem Connection" is that, even if it may very well have historical reasons to exist (in the ITU-T I assume?), it nevertheless is really opaque, since a "Tandem Connection" hasn't much to do with a "tandem" (which as I understand is closer to one or more things put one *after* the other, not one *over* the other or *nested* one in the other); I would find this section hugely easier to read if the very clear term of "Nested MEG" was used (instead of Tandem Connection Monitoring and or SPME).

   * this section would also be easier to understand if it was reminded to the reader that what we are talking about is "a hierarchical LSP instantiated to monitor a portion of a transport path" ; I took me a significant time to infer this (honestly because I did not lookup the definition in the MPLS-TP framework) and you'll certainly spare your readers some effort if you add this precision, very useful by the way since you later talk about the effects of this hierarchy on MPLS-TP OAM

    * "PM statistics need to be adjusted for the encapsulation overhead of the additional SPME sub-layer." => the only thing defined as "performance monitoring" in this document is packet loss measurements, which is not impacted by encapsulation overhead ;  maybe this sentence should say "bandwidth estimation" instead (defined in this document as a diagnosis test) ?


B6 - section 3.3 §10: "An MPLS-TP MEP sink passes a fault indication to its client (sub-)layer network as a consequent action of fault detection." => is it always done, or is it optional ?  what if there is no OAM on the client side to carry any fault indication ?


B7 - section 3.3: "a per- interface MEP is called "Up MEP" or "Down MEP" depending on its location as upstream or downstream relative to the forwarding engine":  my initial interpretation of this sentence was based on the idea that "downstream" referred to the stream of OAM packets flowing from the source MEP to the sink MEP; with this in mind, the definition given here was not consistent with the one in 2.1, nor with the diagram in figure 3 . After some time, it finally occurred to me that the intent was possibly to use "downstream" and "upstream" to refer to the client to server direction (with the client over the server, ie client up, and server down)...  Assuming I'm correct and have guessed the intended meaning, I think that the text should be made more explicit on what downstream/upstream means here, or alternatively, avoid the use of this ambiguous term, and even look for better terms such as client-side MEP and network-side MEP ?


B8 - section 4: this section is quite painful to read due to and abundant use of multi-layered acronyms, an example being LSMEG, for "LSP SPME ME Group" which expands as (take a deep breath)... "Label Switching Protocol Sub-Path Maintenance Element Maintenance Entity Group".... (!!)
   => as a general comment, I think that when introducing acronyms, it is sane to think twice and check if on is making the doc easier to write and/or easier to read
   => here, the acronyms did not help me as a reader, and I would suggest considering removing the acronyms defined at the start of section 4 from the document and using the expanded forms instead: "LSP ME" or "PW SPME ME" for instance, are not long to write, and are easier to interpret than "LME"
or "PSME"
   => I note that these acronyms are not even used in the document : more specifically only the variants without the "Group" at the end are used... at the very least the text should be revised to remove the "Groups" and "G"s from the list at the start of section 4


B9 - section 5.1 §4  "When MPLS-TP is deployed in transport network environments where IP addressing is not used in the forwarding plane, the ICC-based format for MEP identification is used"  => no reason is given  why IP addressing would be excluded in cases where IP is available in the control or management plane (even if IP is not used in the forwarding plane) : why not allow this ?

B10 - section 5.1.2 §5 and §6: "the MEP [...] declares a signal fail condition at the transport path level"  => for a MEP part of an MEG monitoring a PW, I would have expected the signal fail condition to be declared at the PW level


B11 - section 5.1.3 talks about "Performance Monitoring", but is a sub-section of section 5.1 on CCCV : (a) this seems awkward in terms of document structure, and (b) it seems to possibly conflict with section 5.5 that implies that specific packets are used for loss measurements (not "CC-V" packets)


B12 - section 5.1.3: Protection Switching item says "default transmission period is  3.33ms [...], in order to achieve sub-50ms the CC-V defect entry criteria  should resolve in less than 10msec, and complete a protection switch within a subsequent period of 50 msec."
    => if the "sub-50ms" window includes the defect detection time, then there are only 40ms left to complete protection switching (not 50); alternatively, if it does not, then the requirement to detect the defect in less than 10ms due not result from the sub-50ms requirement => the said paragraph need I think to be corrected in some ways
    => moreover, if I'm correct, the entry criteria defined in 5.1.1.1 does not meet the "detect in less than 10ms" criteria (3.33ms*3.5 = 11.655ms) ; for sure, 1.655ms is not much, but it is surprising to see at the same time a very high level of precision in the proposed parameters (3.5 factor, 3.33ms, 10ms detection time) and an arithmetic inconsistency when these parameters are combined: maybe a good idea would be to let more freedom to protocol implementers in the values they can use for transmission period, and in the target values for detection times ?


B13 - section 5.2: why exclude unidirectional transport paths from benefiting of RDI ?  (if the restriction is needed then explain why, else remove the restriction ?)


B14 - section 5.2.1: "the RDI transmission rate and PHB of the OAM packets carrying RDI should be the same as that configured for CC-V" ; since the rate of CC-V message depends on the application (section 5.1.3), how should this sentence be interpreted ?  beyond this, why mandate the exact same rate for both ?  


B15 - section 5.3:

   * §4 talks about "loss of continuity alarms": I can't be sure what alarms mean here, does refer to an OAM message (RDI ?) or to "something" sent to the NMS (assuming there is one) ??  => I can't determine whether or not a sink MEP sends RDI to the source MEP if it receives AIS for a MEG

   * the whole section does not say clearly which entities may send AIS: I would assume all MEPs *and* all MIPs , but it may be nice to make it explicit


B16 - section 5.3: "generate packets with AIS information" => should this be understood as "AIS OAM messages" or "OAM packets with AIS information elements", or more generally as "OAM messages with AIM information"?  (see general comment on how this document specifies the content of OAM messages)


B17 - section 5.5 (on packet loss measurements) :

  * section 5.5: the text could be more explicit and say more about which packets are sent by the source MEP with which information and what is sent back by sink MEPs and with which information ?

  * section 5.5 §2: *when* exactly are packets sent *and* received by the peer MEP ? the text implies that this would only not be done for unidir ; but it seems to my fresh eyes, that using a return path could be considered ; either way, could this point be explicited ?

  * section 5.5 §2 says "The LM  transactions are issued such that the OAM packets will experience the same queuing discipline as the measured traffic [...]" while 5.5.1 says "LM OAM  packets should be transmitted with the PHB that yields the lowest discard probability within the measured PHB Scheduling Class (see RFC 3260 [16])."
     => it looks to me possibly contradictory to impose that real data and OAM LM packets have the same queueing discipline but possibly a distinct drop precedence ; maybe this could be rephrase with less risk of confusion by using terms such as "drop precedence" and "scheduling class"
     => see also comment A11
     => in any case, having a distinct drop preference for OAM packets looks to me as possibly defeating the purpose in some situations: indeed, it seems that the measurement error coming from the difference of treatment between OAM packets and real data could deserve the same worries that the error coming from sampling skew ; why not, for instance, allow the operator to selectively use a TC with the highest discard probability to estimate the worst case of packet loss ?

  * section 5.5.3 provides possible causes of inaccurate LM ; I think additional ones are worth mentioning:
      - the fact that each link in the bundle of links may intrinsically have a different packet loss (e.g. one fiber is clean, the other is not)
      - the fact that a different hardware queues can be used for each link in the bundle of links, possibly with a different packet loss behavior when the measure is done (one is full, the other is not)
      => my feeling is that this is not so much a question of identifying the possible causes of inaccuracies, than a problem of defining what packet loss is being measured, but at the very least, I would expect to cover all of the most easily identified ones ; alternatively one may consider suggesting that the LM measurement technique should be designed so that all possible hardware path for a said LSP are tested... ?


B18 - section 6.1: §1 says "network management may invoke periodic on-demand bursts of on-demand CV packets, as required in section 2.2.3 of RFC 5860", but I can't find anything on bursts on RFC5860


B19 - section 6.2: a general comment on this section and its sub-sections is that is seems largely redundant with section 5.1 (also on CV but the pro-active side), readability would be highly improved if this section was highlighting the differences with section 5.1 (such a s "mechanisms are the same as section 5.1 with the following exceptions: ...") and avoid repeating common text as much as possible


B20 - section 6.2.2: AFAICT, the content of this section is identical to 5.5.2, and could be replaced with a pointer to that section


B21 - section 6.3.2 §4:  The fact that it is not possible to send an OAM message addressed to the MIP/MEP to unloop the data plane is rather surprising. Does this means that a special processing must be applied to this message ?


B22 - In many places, it seems that the text has been written with only the P2P case in mind, and that - at least the wording - does not take into account the case of P2MP...
  - section 6.4 : "to the sink MEP" =>
  - section 5.1 §1 : "between two MEPs" => ditto
  - section 5.1 §3 : "processed by the sink MEP" => ditto
  - section 5.1 §8 : "only the sink MEP" => ditto
  - section 5.1 §13 : "parsed by the sink MEP" => ditto


Nits:

( Nits are editorial or layout items. They are things that would ideally be resolved before publication to make the document more readable, and may be raised now to save the RFC Editor work. Usually a reviewer will not be looking for this type of issue, but may find some in the course of their review. )

* Section 2 "terminology and definitions":
   * it would I think be easier to put the section with definitions *before* the section giving their acronyms
   * I think that readability would be enhanced if both section 2.1 and section 2.2 were each split into two sub-sections, one for things already defined in other documents, and another one for things introduced by this document itself

* 2.1: the following acronyms are used in the text but not defined: ICC, E-LSP, TPE, SPE, EMS, NMS, CC, CV

* 2.2:
  - "Signal Degrade" is defined but not used in the rest of the document
  - "MEP Source" is defined, but in many places in the document "Source MEP" is used, I guess the two should be made consistent
  - ditto for "MEP Sink"

* 3.1 §4 "This functional model defines...": this paragraph sounds like an ME has the responsibility to monitor and manage a network, ie. that an ME is the human operator or an OSS entity of some kind, the text should probably be rewritten in a better way

* ditto for 3.3§2 "MEPs are responsible for activating and controlling ... " : this gives the impression that MEPs are an active entity doing actions, while my understanding was that they were points, ie something close to a location were something is done

* 3.1 §5 uses the term "originating MEP" : if this is the same a "source MEP", then "source MEP" should be used (and if not the difference should be explained) 

* 3.2 §6 "The SPME would use the uniform model of TC code point  copying between" => unfortunate TLA collision between "(T)andem (C)onnection" and "(T)raffic (C)lass", even more unfortunate that a lot of people may still be more familiar with the old "Exp" name ; I would suggest expanding "TC" into "Traffic Class" in this sentence (and a reference added to RFC5513 section 4.2 !)

* 3.2 §6 "short pipe for TTL handling": readability possibly improved by reminding the reader what the short-pipe model is (no TTL copying)

* 3.2 §8 "As any MIP ... is ... , hence ... " => remove "any" or "hence" ?

* 3.3 §1: "while in the context of an SPME LSRs for the MPLS-TP LSP can be ..."
       => missing a comma between "SPME" and "LSRs"
       => this paragraph is not easy to read, and would deserve beind rewrittent more clearly

* section 3.3 §15: "It may occur that the Up MEPs of an SPME are set on both sides  of the forwarding engine such that the MEG is entirely internal to the node." => would be easier to read this way: "It may occur that the source and sinks MEPs are on the same node, and are both Up MEPs, each on one side of the forwarding engine, such that the MEG is entirely internal to the node." ...?

* 3.8:
   - "objectives" => I would suggest saying "requirements" instead of "objective"
   - "in transport network" => "in _a_ transport network", or use plural
   - "The monitored or managed transport path condition has to be exactly the same irrespective of any configurations necessary for maintenance" => if the intent is to include changes of the transport path that happens due to local repair or end to end restoration, then "any configurations necessary for maintenance" is not very nice, as dataplane changes resulting from control plane procedure are not often called "configuration" nor "maintenance"

* section 4: "The MEGs specified in this MPLS-TP framework are compliant with  the architecture framework for MPLS-TP MS-PWs [4] and LSPs [1]"
   -> I believe the text should say "with the architecture framework for MPLS-TP[8], MS-PWs [4] and LSPs [1]"   (add "[8], ")

 * figure 5:
    - is very difficult to understand and its readability would deserve being improved in order to ease reading the following paragraphs.
    - adding "LSR" labels in the boxes in the diagram (and making the boxes bigger) would be nice
    - putting boxes for LSRs 2 and Y at the same size of the other LSRs would be better
    - avoiding the "LSP" label on the boxes for LSR 2 and Y would also help
    - the legend ("   ^---^ ME   ^     MEP  ====   LSP      .... PW") would be more readable with each item on a separate line

* 3.2 §9,  4.1 §1 and 5.1§7: "share fate" would sound better than "fate share" which is not correct english

* figure 5: "Figure 5 depicts a high-level reference model for the MPLS-TP  OAM framework.": I find the use of the "model" term rather surprising since what I see looks to me more as an "example", as an "illustration", used in the rest of the section to more easily illustrate the concepts defined, rather than an high-level abstract model (which I expect would not be specific, why not just say "example" instead of "model"  ?

* 4.3, figure 6: it seems that this figure could be removed and replaced by a reference to figure 5

* 4.4 §1: "with associated maintenance entity" => add "an" after "with"
* 4.5 §1: ditto

* 4.4 §4: "end node" and "intermediate node" could be replaced by the wellknowns LER and LSR terms, but in fact it seems that the whole paragraph be replaced by a  straightforward shorter sentence: "A LSME can be defined between any node (LER or LSR) of a given LSP"  

* 4.5 §1: "An MPLS-TP MS-PW SPME Monitoring ME (PSME) is [...] intended to monitor an  arbitrary part of an MS-PW between the pair of MEPs instantiated  form the SPME independently from the end-to-end monitoring (PME)."
   => I cannot parse the sentence correctly as-is, but I can if I change it into "instantiated _from_ the SPME independently _of_ the end-to-end monitoring (PME)."

* 4.5, figure 8: it seems that this figure could be removed and replaced by a reference to figure 5

* section 5, list item 4: "[...] loss  measurement indication of excessive impairment of information  transfer capability" => is this different than a "packet loss indication" ? if yes, then it would be nice to explain more, and if no, then maybe a simpler expression would be nicer ?



* section 5.1.2 §2: the text says "If a MEP detects an unexpected globally unique Source MEP  ..." but this event is defined in 5.1.1.2 as a "mis-connectivity defect" ; hence the text in 5.1.2 would I think be better rewritten as "If a MEP detects a mis-connectivity defect"

* section 5.1.3: milliseconds should be abbreviated as "ms" not as "msec" (current text has a mix of the two)

* section 5.3 §2: "generates packets with AIS information in the downstream direction": to avoid misunderstanding on what "downstream" means here (see my comment on Up/Down MEPs), it may be clearer to say "toward the sink MEP(s)" rather than "in the downstream direction"

* section 5.6 § 3 and 6.5 §3: "synchronized precision time" => replace by "precise time synchronisation" ? ("synchronized precision time" seems rarely used, instead possibly in the specific GPS context)

* section 6, last paragraph: "exclusive" => replace by "exclusively" ?
* section 6.1, last paragraph: "target" => replace by "targeted"

* section 6.1§3 : uses the term "originating MEP" : if this is the same a "source MEP", then "source MEP" should be used (and if not the difference should be explained) 

* section 6.3.1 "graphing the percentage of OAM test packets received" => "computing" would be more appropriate than "graphing"

* References: G.806 is given as a "Normative" reference, but it appears to me that it is only referred to to complement the Signal Fail and Signal Degrade definitions in section 2.1 ; for this reason, a possibility would be to move this reference to the "Informative references" section.

* in 5 places, the term "segment or concatenated segment" is used, it would be great to replace this phrase by "path segment", which is usefully precisely introduced by this document as meaning "segment or concatenated segment"  ; you could also consider avoiding "concatenated segment" in all the other places, and use the "path segment" term instead




--------------070705020804040208010900--