Return-Path: 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 0C13C21F8750 for ; Fri, 25 May 2012 10:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Z2uMmXUjtaOZ for ; Fri, 25 May 2012 10:01:23 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B902521F873C for ; Fri, 25 May 2012 10:01:23 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q4PH1FTu025612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 May 2012 12:01:21 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 25 May 2012 13:01:16 -0400 From: Gregory Mirsky To: Carlos Pignataro , Yaakov Stein , "pwe3@ietf.org" Date: Fri, 25 May 2012 13:01:15 -0400 Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt Thread-Index: Ac06gNDEKW3yYBHESl2FVbKhRfTofwAFsfYg Message-ID: References: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> <227FF1F3-72B8-4B44-A89D-BF4ED3902435@cisco.com> In-Reply-To: <227FF1F3-72B8-4B44-A89D-BF4ED3902435@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1355463FCF0EUSAACMS0715e_" MIME-Version: 1.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:01:27 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1355463FCF0EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do not support as in the current form document goes beyond mere definition = of the new Control Channel type for VCCV. And concur with concerns expressed by Yaacov and Carlos. Regards, Greg ________________________________ From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Car= los Pignataro Sent: Friday, May 25, 2012 7:15 AM To: Yaakov Stein; pwe3@ietf.org Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt PWE3ers, I too have strong concerns about this document being WGLCed. A meta-concern centers around the scope of this document. My understanding = (and please correct this with a citation if I am incorrect) is that there w= as consensus for this document to define a new CC Type 4 using GAL, but the= re was not consensus to have this document redefine all Control Channels an= d their requirement levels (i.e., deprecating or creating rules of use). >From the minutes at http://tools.ietf.org/wg/pwe3/minutes we can see that: 20 min - Genera= l discussion on VCCV for GAL There appear to be two separate issues on the table: 1. VCCV support = for a PW associated channel that uses the GAL as an alert mechanisms (VCCV Type 4). This is really the subject of the= draft. 2. What to do ab= out legacy modes, particularly router alert and TTL expiry. This is a separate issue regarding the progress of RFC508= 5 (or some future RFC) to Internet Standard status. And this I-D should only deal with issue #1 but not #2. This is also clear = from the filename "vccv-for-gal", which was changed from the "vccv-2" of th= e individual submission to make very explicitly clear this scope. However, the title of this I-D is still "Unified Control Channel". Additionally I would like to highlight in agreement two issues that Yaakov = brought up. On May 25, 2012, at 8:09 AM, Yaakov Stein wrote: My comments. Most are editorial (some of the document seems to have been wr= itten in haste) I believe that the number of editorial issues actually amount to technical = concerns. For example, the Title, Abstract, and Introduction speak of thing= s in the scope of a 5085bis. Moreover, the Introduction repeats Figures 1 a= nd 2 and the Acronyms even repeats unused ones (L2SS, LCCE are meaningless = and unused in this doc). >From my perspective, the collection of these editorials amount to a blockin= g comment. 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 coul= d 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 o= ne of using TTL and this new one. The requirement to support this mode ONLY has NOT received consensus from t= he WG. Similarly, this seems to contradict the actual document scope. We discussed= the best approach for "unification" in Paris and subsequently on email, an= d it is closer to doing a 5085bis than having a document that does not upda= te to redefine. I object to VCCV-for-GAL going beyond VCCV for GAL. As it stands, I do not support this document move forward as is. Thanks, -- Carlos. --_000_FE60A4E52763E84B935532D7D9294FF1355463FCF0EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Do not support as in the current form document goe= s beyond=20 mere definition of the new Control Channel type for VCCV.
And concur with concerns expressed by Yaacov and=20 Carlos.
 
  &n= bsp; Regards,
        Greg

From: pwe3-bounces@ietf.org=20 [mailto:pwe3-bounces@ietf.org] On Behalf Of Carlos=20 Pignataro
Sent: Friday, May 25, 2012 7:15 AM
To: Yaakov= =20 Stein; pwe3@ietf.org
Subject: Re: [PWE3] WG Last Call for=20 draft-ietf-pwe3-vccv-for-gal-01.txt

PWE3ers,

I too have strong concerns about this document being WGLCed.

A meta-concern centers around the scope of this document. My understan= ding=20 (and please correct this with a citation if I am incorrect) is that there w= as=20 consensus for this document to define a new CC Type 4 using GAL, but there = was=20 not consensus to have this document redefine all Control Channels and their= =20 requirement levels (i.e., deprecating or creating rules of use). 

From the minutes at http://tools.ietf.org/wg/pwe= 3/minutes we=20 can see that:
          20 min - General discussion on=
 VCCV for GAL
          There appear to be two separate issues on the table:
          1. VCCV support for a PW associated channel that uses the=
 GAL as an
          alert mechanisms (VCCV Type 4). This is really the subject of the=
 draft.
          2. What to do about legacy modes, particularly router ale=
rt and TTL
          expiry. This is a separate issue regarding the progress of RFC5085
          (or some future RFC) to Internet Standard status.

And this I-D should only deal with issue #1 but not #2. This is also c= lear=20 from the filename "vccv-for-gal", which was changed from the "vccv-2" of th= e=20 individual submission to make very explicitly clear this scope.

However, the title of this I-D is still "Unified Control Channel".

Additionally I would like to highlight in agreement two issues that Ya= akov=20 brought up.

On May 25, 2012, at 8:09 AM, Yaakov Stein wrote:
My=20 comments. Most are editorial (some of the document seems to have been wri= tten=20 in haste)

I believe that the number of editorial issues actually amount to techn= ical=20 concerns. For example, the Title, Abstract, and Introduction speak of thing= s in=20 the scope of a 5085bis. Moreover, the Introduction repeats Figures 1 and 2 = and=20 the Acronyms even repeats unused ones (L2SS, LCCE are meaningless and unuse= d in=20 this doc).

From my perspective, the collection of these editorials amount to a=20 blocking comment.


 
  If the c-bit=
 is set,
  indicating the use of the control wor=
d, type 1 MUST be advertised
  and type 4 MUST NO=
T 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 s=
upport for this.
 
  If the c-bit is not=
 set,
  indicating that the control word is not i=
n use, type 4 MUST
<=
SPAN lang=3DEN style=3D"FONT-SIZE: 9pt">  be advertised, and type 1 MU=
ST NOT be advertised.
Sorry, but I strongly disagree here!!!!!!!!!!!
By a show of hands at the last meeting people agreed that router alert c=
ould be eliminated.
=
However, it was NOT agreed that TTL expiry was to b=
e eliminated – quite the contrary!
So, without CW there are 2 op=
tions – the presently available and deployed one of using TTL
and=
 this new one.
The requirement to support this mode ONLY has NOT receiv=
ed consensus from the WG.

Similarly, this seems to contradict the actual document scope. We disc= ussed=20 the best approach for "unification" in Paris and subsequently on email, and= it=20 is closer to doing a 5085bis than having a document that does not update to= =20 redefine. I object to VCCV-for-GAL going beyond VCCV for GAL.

As it stands, I do not support this document move forward as is.

Thanks,

-- Carlos.



--_000_FE60A4E52763E84B935532D7D9294FF1355463FCF0EUSAACMS0715e_--