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