Re: [PWE3] Danny McPherson's Rtg-Dir review of draft-ietf-pwe3-p2mp-pw-requirements
Jounay Frédéric <Frederic.Jounay@orange.ch> Tue, 13 May 2014 13:32 UTC
Return-Path: <Frederic.Jounay@orange.ch>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 30B381A013B;
Tue, 13 May 2014 06:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.519
X-Spam-Level:
X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3,
RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, UNPARSEABLE_RELAY=0.001]
autolearn=no
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id zQh1T7KAe43E; Tue, 13 May 2014 06:32:51 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com
[195.245.230.162])
by ietfa.amsl.com (Postfix) with ESMTP id 321671A012A;
Tue, 13 May 2014 06:32:49 -0700 (PDT)
Received: from [195.245.230.51:48079] by server-2.bemta-3.messagelabs.com id
35/F3-23530-BFE12735; Tue, 13 May 2014 13:32:43 +0000
X-Env-Sender: Frederic.Jounay@orange.ch
X-Msg-Ref: server-13.tower-33.messagelabs.com!1399987961!3485340!3
X-Originating-IP: [213.55.206.8]
X-StarScan-Received:
X-StarScan-Version: 6.11.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23592 invoked from network); 13 May 2014 13:32:42 -0000
Received: from unknown (HELO chbbochs054.orange.ch) (213.55.206.8)
by server-13.tower-33.messagelabs.com with RC4-SHA encrypted SMTP;
13 May 2014 13:32:42 -0000
Received: from CHCROCHC051.orange.ch
([fe80:0000:0000:0000:704b:3a68:12.14.247.83]) by chbbochs054.orange.ch
([172.25.9.54]) with mapi; Tue, 13 May 2014 15:31:57 +0200
From: =?iso-8859-1?Q?Jounay_Fr=E9d=E9ric?= <Frederic.Jounay@orange.ch>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>,
"draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org"
<draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org>, 'Danny McPherson'
<danny@tcb.net>
Date: Tue, 13 May 2014 15:31:56 +0200
Thread-Topic: [PWE3] Danny McPherson's Rtg-Dir review of
draft-ietf-pwe3-p2mp-pw-requirements
Thread-Index: Ac9M/iD4IE2H4j8CQBCtnHo5w4RK/wAf9e/QCEu2ZbA=
Message-ID: <78046FD1C8FE0345AFBC11640A8DF6E201864A31C2B8@CHCROCHC051.orange.ch>
References: <022001cf4cfe$25fd5fc0$71f81f40$@olddog.co.uk>
<78046FD1C8FE0345AFBC11640A8DF6E201864A00807C@CHCROCHC051.orange.ch>
In-Reply-To: <78046FD1C8FE0345AFBC11640A8DF6E201864A00807C@CHCROCHC051.orange.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/5WMmyPITeSgNSUFUSrgU6oyB8CI
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: [PWE3] Danny McPherson's Rtg-Dir review of
draft-ietf-pwe3-p2mp-pw-requirements
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Pseudowire Emulation Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>,
<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3/>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>,
<mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 13:32:53 -0000
Hi Danny, all Just to inform you that the [FJ] comments addressed below have been now integrated in the new version 08 https://tools.ietf.org/wg/pwe3/draft-ietf-pwe3-p2mp-pw-requirements/draft-ietf-pwe3-p2mp-pw-requirements-08-from-07.diff.html We hope that the changes remain faithful with your expectations Thank you for your support BR, Fred 1. Only single-segment PWs are addressed, not multi-segment PWs. I understand why this is the case currently although I wonder if the requirement akin to "a single NMS" such as provided in S.4 should be conveyed forward? I suppose it should simply be out of scope. [FJ] Indeed this section was meaningful when MS-PW was considered. I don't see the added value of this chapter in the case SS-PW. I'd suggest to remove the section 4 "Manageability considerations" 2. In order to align with descriptive text in S3.1 it might be useful if the Reference Model in Figure 1 depicted where root and leaf PEs reside in the topology, and perhaps also that multiple CEs could be downstream from a single leaf PE (the latter point Farrel made in his AD review as well, IIRC). [FJ] I agree with the proposal to show 2 CEs behinf one Leaf PE, as described in http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-00 . I'd suggest we add ROOT and LEAF, as follows |<-----------P2MP PW -------------->| Native | | Native ROOT Service | |<----P2MP PSN tunnel --->| | Service LEAF V (AC) V V V V (AC) V --- S 3.2: - A single P2MP PSN tunnel MUST be able to serve more than one P2MP PW traffic in an aggregated way, i.e., multiplexing - "not destined to Leaf PE at the service layer." reads a bit odd and ambiguous, might use a bit of expansion. [FJ] we might rephrase it. "but using this P2MP LSP would imply non-Leaf PEs (i.e. not part of the P2MP PW) to receive unwanted traffic" --- S 3.4.6: - "In the example depicted below, a standby P2MP PW is used to protect the active P2MP." -- might consider adding a "PW" after the last P2MP in this sentence. [FJ] agreed "In the example depicted below, a standby P2MP PW is used to protect the active P2MP PW." - It might be useful to identify the "leaf" and "root" layer in Figure 3 & 4 as well. [FJ] agreed to add ROOT at the top and LEAF at the bottom of the figures. (I'd prefer this solution than adding new acronyms in the Terminology section. -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Jounay Frédéric Sent: Tuesday, 01 April 2014 10:12 To: adrian@olddog.co.uk; draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org; 'Danny McPherson' Cc: rtg-dir@ietf.org; pwe3@ietf.org Subject: Re: [PWE3] Danny McPherson's Rtg-Dir review of draft-ietf-pwe3-p2mp-pw-requirements Hi Adrian, Danny, All, Thank you for this new review. Please find below [FJ] how we intend to address the comments in a new version If all co-authors agree, we will update with Yuji the new version BR, Fred -----Original Message----- From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, 31 March 2014 18:28 To: draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org Cc: rtg-dir@ietf.org; pwe3@ietf.org Subject: [PWE3] Danny McPherson's Rtg-Dir review of draft-ietf-pwe3-p2mp-pw-requirements draft-ietf-pwe3-p2mp-pw-requirements Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other comments that you receive, and strive to resolve them through discussion or by updating the draft as appropriate. Document: http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-07 Reviewer: Danny McPherson Review Date: March 31, 2014 Intended Status: Informational Document Overview: This document presents a set of requirements and a framework for providing a P2MP PWs over MPLS PSNs. A P2MP PW is a mechanism that emulates the essential attributes of a P2MP telecommunications service such as a P2MP ATM VC over a PSN. The I-D describes the general architecture for P2MP PWs with a reference model, discusses data encapsulation, and outlines specific requirements for setup and maintenance of P2MP PWs, with a focus only on Single-Segment PWs. This version was lasted updated in February of 2014, although it has existed as a PWE3 WG document since March 2009, and as an individual contribution (draft-jounay-pwe3-p2mp-pw-requirements) since February of 2007. Among other applications, it provides primitives that can be employed for Virtual Private LAN and Virtual Private Multicast services, such as those specified in the L2VPN WG. I have no substantial concerns with this document. There are several comments and nits below. 1. I am not sure if from an IPR perspective the claims regarding IPR that apparently no longer apply to this version of the document need to be explicitly acknowledged as such by the relevant co-authors? Nits === General: 1. Only single-segment PWs are addressed, not multi-segment PWs. I understand why this is the case currently although I wonder if the requirement akin to "a single NMS" such as provided in S.4 should be conveyed forward? I suppose it should simply be out of scope. [FJ] Indeed this section was meaningful when MS-PW was considered. I don't see the added value of this chapter in the case SS-PW. I'd suggest to remove the section 4 "Manageability considerations" 2. In order to align with descriptive text in S3.1 it might be useful if the Reference Model in Figure 1 depicted where root and leaf PEs reside in the topology, and perhaps also that multiple CEs could be downstream from a single leaf PE (the latter point Farrel made in his AD review as well, IIRC). [FJ] I agree with the proposal to show 2 CEs behinf one Leaf PE, as described in http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-00 . I'd suggest we add ROOT and LEAF, as follows |<-----------P2MP PW -------------->| Native | | Native ROOT Service | |<----P2MP PSN tunnel --->| | Service LEAF V (AC) V V V V (AC) V --- S 3.2: - A single P2MP PSN tunnel MUST be able to serve more than one P2MP PW traffic in an aggregated way, i.e., multiplexing - "not destined to Leaf PE at the service layer." reads a bit odd and ambiguous, might use a bit of expansion. [FJ] we might rephrase it. "but using this P2MP LSP would imply non-Leaf PEs (i.e. not part of the P2MP PW) to receive unwanted traffic" --- S 3.4.6: - "In the example depicted below, a standby P2MP PW is used to protect the active P2MP." -- might consider adding a "PW" after the last P2MP in this sentence. [FJ] agreed "In the example depicted below, a standby P2MP PW is used to protect the active P2MP PW." - It might be useful to identify the "leaf" and "root" layer in Figure 3 & 4 as well. [FJ] agreed to add ROOT at the top and LEAF at the bottom of the figures. (I'd prefer this solution than adding new acronyms in the Terminology section. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3
- [PWE3] Danny McPherson's Rtg-Dir review of draft-… Adrian Farrel
- Re: [PWE3] Danny McPherson's Rtg-Dir review of dr… Jounay Frédéric
- Re: [PWE3] Danny McPherson's Rtg-Dir review of dr… Andrew G. Malis
- Re: [PWE3] Danny McPherson's Rtg-Dir review of dr… Jounay Frédéric