[PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal

Gregory Mirsky <gregory.mirsky@ericsson.com> Fri, 24 October 2014 01:30 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CA03D1AD3A4; Thu, 23 Oct 2014 18:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fLE0GVSIJjRh; Thu, 23 Oct 2014 18:30:50 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B651ACCDE; Thu, 23 Oct 2014 18:30:49 -0700 (PDT)
X-AuditID: c6180641-f79916d00000623a-7e-544951a788c3
Received: from EUSAAHC005.ericsson.se (Unknown_Domain []) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C8.AC.25146.7A159445; Thu, 23 Oct 2014 21:06:16 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([]) by EUSAAHC005.ericsson.se ([]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 21:30:48 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: "draft-ietf-pwe3-vccv-for-gal@tools.ietf.org" <draft-ietf-pwe3-vccv-for-gal@tools.ietf.org>
Thread-Topic: Mail regarding draft-ietf-pwe3-vccv-for-gal
Thread-Index: Ac/vIeuwKMVoDTSZTruVwqIxhAGYbw==
Date: Fri, 24 Oct 2014 01:30:48 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B865AB6@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B865AB6eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXRPuO6KQM8Qg9Pt7BYLHpxhtVjzbx2T Rd+nLSwOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8ad70fZCvbPYqzo/XCEuYFxWStj FyMnh4SAicSsK3+YIGwxiQv31rN1MXJxCAkcZZQ4NeM5E4SznFHi46O/rCBVbAJGEi829rB3 MXJwiAgkSjw9pAMSZhZwkXjbMpMZxBYGGnp8xUM2iBJLiSevWUDCIgJ6ElPOvALbxSKgKtHT c40FpIRXwFdi2UJRkDAj0AnfT61hgpgoLnHryXyo0wQkluw5zwxhi0q8fPyPFcJWlNjXP50d oj5fYvKGlWBv8QoISpyc+YRlAqPwLCSjZiEpm4WkDCKuI7Fg9yc2CFsb6KLXzDD2mQOPmZDF FzCyr2LkKC1OLctNNzLcxAiMl2MSbI47GBd8sjzEKMDBqMTDq+DkGSLEmlhWXJl7iFGag0VJ nFezel6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbBeVueL+C9G3v9tnjf/VcTxY8VR4dk T62qMXq3JmlLt2PY69t/gz/pqL3ZZlxtohfDdkPA8baUwKopZX83irFenjt376/lYV3OTRd+ XGVzW8CnVb7pbFSFnu+kL9v2v15Wf+XR8mtKIbovq6MsfQ5KXDnjuzZggbrbSZ9pJWkbp37c FmqUJjVViaU4I9FQi7moOBEAF3IeZ3gCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/Qh1FtlKgmSa0j1MQMhEI7jjBFuc
Cc: "pwe3@ietf.org" <pwe3@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: [PWE3] Mail regarding draft-ietf-pwe3-vccv-for-gal
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: Fri, 24 Oct 2014 01:30:55 -0000

Dear Authors, Editors, et. al,
thank you for your work on this document that is very important to PW OAM. Please kindly consider my comments below:

*         Abstract

o   "This document describes a unified mode of operation for Virtual Circuit Connectivity Verification (VCCV) ..." IMHO, agreement of WG discussion in Paris was to limit document scope to introduction of Control Channel Type 4 for PW VCCV and address unified operation of CC VCCV in RFC 5085bis.

o   "It describes new rules requiring this mode to be used as the default/mandatory mode of operation for VCCV." I think this statement is over-reaching. Use of Control Channel Type 4 may be suggested as preferred in some scenarios, such as CW not being used, SS-PW or e2e MS-PW. I think that the strongest statement could be "New implementations of PW VCCV SHOULD support CC Type 4."

o   "The older types will remain optional." IMHO, the WG agreed to obsolete Type 2 CC PW VCCV.

*         Requirements Language and Terminology.
These acronyms are not used in the document: AVP, L2SS, LCCE, PW-ACH

*         Introduction

o   "... the ITU-T and IETF have set out to enhance MPLS to make it suitable as an optical transport protocol ..." Perhaps should be "packet transport".

o   "In order to support VCCV when an MPLS-TP PSN is in use, the GAL-ACH had to be created ..." G-ACh was created for MPLS-TP LSP, not PW. PW VCCV when PSN is MPLS-TP can use any of described in RFC 5085 control channel types. And RFC 5586 explicitly excluded GAL from being used on PWs in the first sentence of Section 4.2.

o   "This document defines two modes of operation of VCCV ..." Where the document leaves CC Type 3? Isn't it valid mode of PW VCCV operation that the PWE3 WG decided to keep? I believe that only Type 3 can be used in MS-PW to address S-PE whether CW  being used or not.

o   "In either case, it will be mandatory to implement and use that mode under that scenario." Again, this conclusion is not in sync with what was agreed at PWE3 WG meeting in Paris.

*         Section 2
"... Associated Channel Types of 21, 07, or 57 are allowed" Firstly, it should be "0x0021, 0x007, or 0x0057". Secondly, why 0x000A, 0x000B, 0x000C, 0x000D, 0x000E, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, 0x0027, and 0x0058 would not be listed as valid ACH types?

*         Section 3
"In the case of multi-segment pseudo-wires, the PW Label TTL MUST be set to the correct value to reach the intended destination PE as described in [RFC6073]" And that would be the case of VCCV CC Type 3 used in combination with CC Type 4. I think it must be so noted that VCCV CC Type 3 and CC Type 4 can be used in combination since Section 5.1.3 of RFC 5085 explicitly allows combination of PW VCCV Control Channels Type 1 and Type 3.

*         Section 4
"The first nibble of the next field is set to 0001b ..." Perhaps "the first nibble of the next octet ...". And does that imply that GAL MUST be BoS label and thus S=1? Should that be explicitly stated?

*         Section 5

o   "If the c-bit is set, indicating the use of the control word, type 1 MUST be advertised and type 4 MUST NOT be advertised." MUST in connection to Type 1 implicitly requires support of CC Type 1. I think that this is too strong statement and propose change it to "Type 1 MUST be advertised if supported" or just "Type 1 MAY be advertised".

o   "If the c-bit is not set, indicating that the control word is not in use, type 4 MUST be advertised, and type 1 MUST NOT be advertised." As in previous comment, MUST in connection to CC Type 4 is too strong and implies it being supported. Similar change suggested.