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 89F7B11E812D for ; Tue, 29 May 2012 11:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, 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 syp319-RWgRS for ; Tue, 29 May 2012 11:54:27 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B68B811E8131 for ; Tue, 29 May 2012 11:54:26 -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 q4TIsFjk000840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 May 2012 13:54:18 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 29 May 2012 14:54:15 -0400 From: Gregory Mirsky To: Thomas Nadeau Date: Tue, 29 May 2012 14:54:12 -0400 Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt Thread-Index: Ac09mivRaMWuEPosQq+Yllgc5C0JbwAJEOaQ Message-ID: References: <07F7D7DED63154409F13298786A2ADC9043D1F4A@EXRAD5.ad.rad.co.il> <227FF1F3-72B8-4B44-A89D-BF4ED3902435@cisco.com> <5E889EDF-82C4-4B32-BBBA-D5C8AE3A5A2A@lucidvision.com> In-Reply-To: <5E889EDF-82C4-4B32-BBBA-D5C8AE3A5A2A@lucidvision.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_FE60A4E52763E84B935532D7D9294FF1355470E952EUSAACMS0715e_" MIME-Version: 1.0 Cc: Carlos Pignataro , Yaakov Stein , "pwe3@ietf.org" 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: Tue, 29 May 2012 18:54:31 -0000 --_000_FE60A4E52763E84B935532D7D9294FF1355470E952EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Tom, apologies and please find my comments below (some if not most might duplica= te what already was noted by Yaacov and Carlos): * Abstract "This document describes a unified mode of operation for Virtual C= ircuit Connectivity Verification (VCCV) ..." IMHO, agreement of WG discussi= on 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. * Abstract "The older types will remain optional." IMHO, the WG agreed to ob= solete Type 2 CC PW VCCV. * Introduction "This document and the implementation survey concluded ...": * "This document" as A Unified Control Channel for Pseudowires? * Besides, I believe that if the acceptance of Mandatory Use of Control Word = for PWE3 Encapsulations will make draft-ietf-pwe3-vccv-for-gal- unnecessary= . Reference to the implementation survey draft-ietf-pwe3-vccv-impl-survey-r= esults-00 is missing. * I don't see that the "The Pseudowire (PW) & Virtual Circuit Connectivity Ve= rification (VCCV) Implementation Survey Results" made suggested conclusion. * Introduction "... the ITU-T and IETF have set out to enhance MPLS to make i= t suitable as an optical transport protocol ..." Perhaps should be "packet = transport". * Introduction "In order to support VCCV when an MPLS-TP PSN is in use, the G= AL-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 chan= nel types. * Introduction "This document defines two modes of operation of VCCV ..." Whe= re the document leaves CC Type 3? Isn't it valid mode of PW VCCV operation = that the PWE3 WG decided to keep? * Introduction "In either case, it will be mandatory to implement and use tha= t mode under that scenario." Again, this conclusion is not in sync with wha= t was agreed at PWE3 WG meeting in Paris. * Section 2 "... Associated Channel Types of 21, 07, or 57 are allowed" First= ly, 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 descri= bed in [RFC6073]" This seems to exclude= VCCV CC Type 3 from being used in conjunction with GAL even though Section= 5.1.3 of RFC 5085 explicitly allows combination of PW VCCV Control Channel= s Type 1 and Type 3. * Section 3 "The GAL field ..." Generic Associated Channel Label (GAL) is not= a field but part of MPLS label stack entry. What are values of other field= s of the label stack entry with the GAL - TC, S, TTL? * Section 3 "The first nibble of the next field is set to 0001b ..." Does tha= t imply that GAL MUST be BOS label and thus S=3D1? * Section 4 "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." I t= hink that whether Type 4 MUST,SHALL or MAY be advertised (do not forget Typ= e 3), should be addressed in RFC 5085bis. Regards, Greg ________________________________ From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Tuesday, May 29, 2012 5:54 AM To: Gregory Mirsky Cc: Carlos Pignataro; Yaakov Stein; pwe3@ietf.org Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt Generic statements like this are not useful at this point in the process; p= lease be specific and what you object to and what changes you propose to co= rrect them. This will allow the WG to discuss any changes on the list if th= ey are major. What we want to avoid is making changes on the same issue mul= tiple times due to multiple conflicting change requests, or attempting to f= ix generic comments. --Tom 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-boun= ces@ietf.org] On Behalf Of Carlos 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. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_FE60A4E52763E84B935532D7D9294FF1355470E952EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Tom,
apologies and please find my comments below (som= e if=20 not most might duplicate what already was noted by Yaacov and=20 Carlos):
  • Abstract "This document describes a unified mo= de of=20 operation for Virtual Circuit Connectivity Verification (VCCV) ..." = IMHO,=20 agreement of WG discussion in Paris was to limit document scope to=20 introduction of Control Channel Type 4 for PW VCCV and address unified=20 operation of CC VCCV in RFC 5085bis.
  • &n= bsp;Abstract=20 "The older types will remain optional." IMHO, the WG agreed to obsolete T= ype 2=20 CC PW VCCV.
  • Introduction "This document and the implementation survey conclu= ded=20 ...":
    • "This document" as A Unified = Control=20 Channel for Pseudowires?
    • Besides, I believe that if th= e=20 acceptance of Mandatory Use of Control Word for PWE3=20 Encapsulations will make draft-ietf-pwe3-vccv-for-gal- unnecessary.=20 Reference to the implementation survey=20 draft-ietf-pwe3-vccv-impl-survey-results-00 is=20 missing.
    • I don't see = that the=20 "The Pseudowire (PW) & Virtual Circuit Connectivit= y=20 Verification (VCCV) Implementation Survey Resul= ts"=20 made suggested conclusion.
  • Introduction = "... the=20 ITU-T and IETF have set out to enhance MPLS to make it suitable as=20 an optical transport protocol ..." Perhaps should be "packet=20 transport".
  • Introduction "In order to support VCCV when an MPLS-TP PSN is in= use,=20 the GAL-ACH had to be created ..." G-ACh was created for MPLS-TP LSP, not PW. PW VCCV when PSN= is=20 MPLS-TP can use any of described in RFC 5085 control channel=20 types.
  • Introduction "This document defines two modes of operation of VC= CV ..."=20 Where the document leaves CC Type 3? Isn't it valid mode of PW VCCV opera= tion=20 that the PWE3 WG decided to keep?
  • Introduction "In either case, it will be mandatory to implement = and use=20 that mode under that scenario." Again, this conclusion is not in syn= c=20 with what was agreed at PWE3 WG meeting in Paris.
  • Section 2 "... Associated Channel Types of 21, 07, or 57 are all= owed"=20 Firstly, it should be "0x0021, 0x007, or 0x0057". Secondly, why 0x000A,=20 0x000B, 0x000C, 0x000D, 0x000E, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026,=20 0x0027, and 0x0058 would not be listed as valid ACH=20 types?
  • Section 3 "In the case of multi-segment pseudo-wires, the PW Lab= el TTL=20 MUST be set to the correct value to reach the intended destination PE as= =20 described in [RFC6073]" This seems to e= xclude=20 VCCV CC Type 3 from being used in conjunction with GAL even though Sectio= n=20 5.1.3 of RFC 5085 explicitly allows combination of PW VCCV Control Channe= ls=20 Type 1 and Type 3.
  • Section 3 "The GAL field ..." Generic Associated Channel Label (= GAL) is=20 not a field but part of MPLS label stack entry. What are values of other= =20 fields of the label stack entry with the GAL - TC, S,=20 TTL?
  • Section 3 "The first nibble of the next field is set to 0001b ..= ." Does=20 that imply that GAL MUST be BOS label and thus S=3D1?
    =
  • Section 4 "If the c-bit is not set, indicating that the control = word is=20 not in use, type 4 MUST be advertised, and type 1 MUST NOT be advertised.= " I=20 think that whether Type 4 MUST,SHALL or MAY be advertised (do not forget = Type=20 3), should be addressed in RFC 5085bis.
    Regards,
       =20 Greg
From: Thoma= s Nadeau=20 [mailto:tnadeau@lucidvision.com]
Sent: Tuesday, May 29, 2012 5:5= 4=20 AM
To: Gregory Mirsky
Cc: Carlos Pignataro; Yaakov Stei= n;=20 pwe3@ietf.org
Subject: Re: [PWE3] WG Last Call for=20 draft-ietf-pwe3-vccv-for-gal-01.txt


Generic= =20 statements like this are not useful at this point in the process; please be= =20 specific and what you object to and what changes you propose to correct the= m.=20 This will allow the WG to discuss any changes on the list if they are major= .=20 What we want to avoid is making changes on the same issue multiple times du= e to=20 multiple conflicting change requests, or attempting to fix generic=20 comments. 

--Tom

Do not support as in the current form document g= oes=20 beyond mere definition of the new Control Channel type for=20 VCCV.
And concur with concerns expressed by Yaacov and= =20 Carlos.
 
  =  =20 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: Yaak= ov=20 Stein; pwe3@ietf.org
Subject:<= /B> Re:=20 [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=20 understanding (and please correct this with a citation if I am incorrect)= is=20 that there was consensus for this document to define a new CC Type 4 usin= g=20 GAL, but there was not consensus to have this document redefine all Contr= ol=20 Channels and their requirement levels (i.e., deprecating or creating rule= s of=20 use). 

From the minutes at http://tools.ietf.org/wg/p= we3/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= =20 clear from the filename "vccv-for-gal", which was changed from the "vccv-= 2" of=20 the 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= =20 Yaakov 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=20 written in haste)

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

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


 
  If the c-b=
it is set,
  indicating the use of the control wo=
rd, type 1 MUST be advertised
  and type 4 MUST N=
OT be advertised.
Although I personally prefer using type 1 if there IS=
 a CW,
I do not recall hearing WG consensus on this.<=
/PRE>
This statement=
 goes further than 5085.
I would like to see people explicitly express =
support for this.
 
  If the c-bit is no=
t set,
  indicating that the control word is not =
in use, type 4 MUST
=
  be advertised, and type 1 M=
UST NOT be advertised.
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=20 discussed the best approach for "unification" in Paris and subsequently o= n=20 email, and it is closer to doing a 5085bis than having a document that do= es=20 not update to redefine. I object to VCCV-for-GAL going beyond VCCV for=20 GAL.

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

Thanks,

-- Carlos.



_______________________________________________
p= we3=20 mailing list
pwe3@ietf.org
https://www.ietf.org/m= ailman/listinfo/pwe3

--_000_FE60A4E52763E84B935532D7D9294FF1355470E952EUSAACMS0715e_--