[PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 13 March 2014 14:45 UTC

Return-Path: <adrian@olddog.co.uk>
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 B87801A06B2 for <pwe3@ietfa.amsl.com>; Thu, 13 Mar 2014 07:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.654
X-Spam-Level:
X-Spam-Status: No, score=-98.654 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 yfbMwqVvYaEq for <pwe3@ietfa.amsl.com>; Thu, 13 Mar 2014 07:45:55 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id DEAE11A09C9 for <pwe3@ietf.org>; Thu, 13 Mar 2014 07:45:54 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2DEjliQ028527; Thu, 13 Mar 2014 14:45:47 GMT
Received: from 950129200 (16.17.90.92.rev.sfr.net [92.90.17.16]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2DEjeGr028368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Mar 2014 14:45:44 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-ietf-pwe3-p2mp-pw-requirements.all@tools.ietf.org>
Date: Thu, 13 Mar 2014 14:45:40 -0000
Message-ID: <1f5201cf3eca$eba049a0$c2e0dce0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac8+yi8VySw+Un7gRPmVXQov6Hu5pQ==
Content-language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20562.006
X-TM-AS-Result: No--14.560-8.0-31-10
X-imss-scan-details: No--14.560-8.0-31-10
X-TMASE-MatchedRID: PEj484mD3U6dLySUmQFkksqXjImgj58bbv16+gil4jedI/DikZ1UPHAX R/gLaDwaOZCEsKKiP1VABfNARaV2wZRMdwEiWk2N84dsinZ5e1gh/JA0dHadpsJ3vzMzuod4jNE THH9N9TYguuCAVXi57j43ftRAH8vTKOuO/OPj12ITMSg6oABUs3rMPEZwURsKRJts9OIxqBPaJ6 dlT/OtpSt7TnnEB8DPnricLPPxEZKyRDt3x3st9xi14cCd2Fej1zuqJnnszJW3vnde8jbubOs7U SOi3SHKLSy8E4R72MwaPoPbpBkOOFe3tVY/4Ewfz5rIW0RbS5h9LQinZ4QefL6qvLNjDYTwfY9h sM0xN70qtq5d3cxkNZgpLtAJDWrv9pgoifbp8lUNWN5r/4NspC1il18AYz3ys/QpBBKczR4=
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/74a7snweO30R1jRpbXsUCJ3zcls
Cc: pwe3@ietf.org
Subject: [PWE3] AD review of draft-ietf-pwe3-p2mp-pw-requirements
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Thu, 13 Mar 2014 14:45:57 -0000

Hi,

I have done my usual review as AD in support of the publication request
for this document. This is now a very solid document : all credit to the
authors and to Stewart's guidance.

As I have only a few minor nits with the text (shown below) I will start 
the IETF last call and raise the issues there. You can address them 
together with any other points that are raised during the last call.

Thanks for the work,
Adrian

===

PSN needs to be expanded in the title, Abstract, and Introduction.

Please check for other acronyms like OAM.

---

Since this is not a protocol specification, the RFC 2119 language does
not apply in the way described in RFC 2119. I suggest you replace 
Section 1.3 with something like...

   Although this is a requirements specification not a protocol 
   specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
   "OPTIONAL" in this document are to be interpreted to apply to 
   protocol solutions designed to meet these requirements as described
   in [RFC2119] .

---

I have a question about the architecture and model shown in Figure 1.
Can the P2MP PW branch at an egress PE by having multiple attached ACs
leading to different CEs?

Perhaps this does not count as a branch in the PW, but it is a branch in 
the service.

---

In Section 3.2

s/P-to-MP MPLS LSP/P2MP MPLS LSP/

---

Section 3.4.2 has...

   The Root PE and Leaf PEs of a P2MP PW MUST be configured with the
   same PW type as defined in [RFC4446] for P2P PW.  In case of a
   different type, a PE MUST abort attempts to establish the P2MP PW.

That seems a little drastic. Do you mean "MUST abort attempts to 
attach the leaf PE to the PW"?

Similarly in 3.4.3.

---

Section 4 might usefully refer back to the discussion of OAM.

---

Section 5 is fine, but it is interesting to consider

   A solution MUST NOT allow a P2MP PW to be established to PEs that do
   not support P2MP PW functionality.  It MUST have a mechanism to
   report an error for incompatible PEs.

Does an egress PE even need to know that it is attached to a P2MP PW
rather than a P2P PW?