Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt
Yaakov Stein <yaakov_s@rad.com> Fri, 25 May 2012 12:10 UTC
Return-Path: <yaakov_s@rad.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2678D21F854E for <pwe3@ietfa.amsl.com>; Fri, 25 May 2012 05:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.597
X-Spam-Level:
X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJe0dYJgKEMa for <pwe3@ietfa.amsl.com>; Fri, 25 May 2012 05:10:07 -0700 (PDT)
Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 470B321F854B for <pwe3@ietf.org>; Fri, 25 May 2012 05:10:03 -0700 (PDT)
Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 25 May 2012 14:47:09 +0300
Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Fri, 25 May 2012 15:09:59 +0300
From: Yaakov Stein <yaakov_s@rad.com>
To: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>, "pwe3@ietf.org" <pwe3@ietf.org>
Thread-Topic: WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt
Thread-Index: Ac046DaNXWtnHZkqTW6Ri0XHstXaywBgjL4w
Date: Fri, 25 May 2012 12:09:58 +0000
Message-ID: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il>
References: <CBE2A500.2BAFF%matthew.bocci@alcatel-lucent.com>
In-Reply-To: <CBE2A500.2BAFF%matthew.bocci@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.232.33.112]
Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9043D1F4AEXRAD5adradcoil_"
MIME-Version: 1.0
X-Commtouch-Refid: str=0001.0A090208.4FBF7698.00AC,ss=1,fgs=0
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires 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, 25 May 2012 12:10:10 -0000
My comments. Most are editorial (some of the document seems to have been written in haste) but one expresses strong disagreement. As-is I do NOT support this document becoming an RFC! Y(J)S Operators have indicated in [RFC4377<http://tools.ietf.org/html/rfc4377>] [RFC3916<http://tools.ietf.org/html/rfc3916>] 1) please remove the period. 2) there are no remarks from operators on OAM in RFC 3916. Many of the motivations of this survey are detailed in [MAN-CW<http://tools.ietf.org/html/draft-ietf-pwe3-vccv-for-gal-01#ref-MAN-CW>] This document and the implementation survey concluded that operators have had difficulty deploying the protocol given the number of combinations and options for its use. 1) please remove the carriage return. 2) I think "This doument" refers to [MAN-CW] and not the present document. Please say "That document" or otherwise clarify. 3) please give a reference to the implementation survey 4) IMO MAN-CW does not CONCLUDE that there are problems in implementing VCCV. It perhaps states this, but it mainly proposes an alternative. Similarly the survey does not CONCLUDE anything. It merely reports on what various operators said. Perhaps you want to say "it may be concluded based on the implementation survey [SURVEY] ... " In addition to the implementation issues just described, the ITU-T and IETF have set out to enhance MPLS to make it suitable as an optical transport protocol. An OPTICAL transport protocol ????? The requirements for this protocol are defined as the MPLS Transport Profile (MPLS-TP). I believe that by definition MPLS-TP is a PROFILE not an independent protocol. In order to support VCCV when an MPLS-TP PSN is in use, the GAL-ACH had to be created; Had to be ? No, there were alternative solutions proposed, and I can think of several more. It was "standardized". This document defines two modes of operation of VCCV: 1) with a control word or 2) without a control word, but with a ACH encapsulation making it possible to handle all of the other cases handled by the other modes of VCCV. In either case, it will be mandatory to implement and use that mode under that scenario. 1) Now "This document" means THIS document! 2) The rest of the wording here is very confusing. Use of VCCV with a CW is already defined. What is being defined here is a new method of using VCCV for PWs over MPLS-TP with a GAL. 3) The so called "without a CW" encap, in fact has a CW for the VCCV packets. 4) not an ACH encap, but a GAL or a GACh encap. 5) WHAT is mandatory to implement and use ? The PW Label must set the TTL field to 1. How does a label set anything ? The GAL field MUST contain What is a GAL field ? 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. Although I personally prefer using type 1 if there IS a CW, I do not recall hearing WG consensus on this. This statement goes further than 5085. I would like to see people explicitly express support for this. 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. Sorry, but I strongly disagree here!!!!!!!!!!! By a show of hands at the last meeting people agreed that router alert could be eliminated. However, it was NOT agreed that TTL expiry was to be eliminated - quite the contrary! So, without CW there are 2 options - the presently available and deployed one of using TTL and this new one. The requirement to support this mode ONLY has NOT received consensus from the WG. If the remote PE also supports Type 4, then Type 4 MUST be used superceding the Capability Advertisement Selection rules of section 7<http://tools.ietf.org/html/draft-ietf-pwe3-vccv-for-gal-01#section-7> from RFC5085<http://tools.ietf.org/html/rfc5085>. I am not sure I agree with the language. If a PE supports Type 4 but wishes not to use it, what is to keep it from hiding the fact that it supports type 4 ? I think you mean that if a PE advertised that it supports Type 4. Y(J)S From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew) Sent: Wednesday, May 23, 2012 16:30 To: pwe3@ietf.org Subject: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt This email begins a two week working group last call for draft-ietf-pwe3-vccv-for-gal-01.txt Please review the draft and post any comments to the PWE3 list. This working group last call will end on 6th June 2012. Best regards Matthew
- [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-… Bocci, Matthew (Matthew)
- Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-… Yaakov Stein
- Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-… Yaakov Stein
- Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-… Carlos Pignataro
- Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-… Gregory Mirsky
- Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-… Thomas Nadeau
- Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-… Gregory Mirsky
- Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-… Bocci, Matthew (Matthew)
- Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-… Alexander Vainshtein
- Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-… Yaakov Stein
- [PWE3] FW: WG Last Call for draft-ietf-pwe3-vccv-… Gregory Mirsky