[PWE3] FW: WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt

Dear Authors, et. al,
in London we’ve discussed work on the VCCV Control Channel Type 4. I thought that these comments from long ago may be helpful in your work on the next version of the document.

                Regards,
                                Greg

---------- Forwarded message ----------
From: Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>>
Date: Tue, May 29, 2012 at 11:54 AM
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt
To: Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>
Cc: Carlos Pignataro <cpignata@cisco.com<mailto:cpignata@cisco.com>>, Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>, "pwe3@ietf.org<mailto:pwe3@ietf.org>" <pwe3@ietf.org<mailto:pwe3@ietf.org>>

Dear Tom,
apologies and please find my comments below (some if not most might duplicate what already was noted by Yaacov and Carlos):

  *   Abstract "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.
  *    Abstract "The older types will remain optional." IMHO, the WG agreed to obsolete 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-results-00 is missing.
     *   I don't see that the "The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results" made suggested conclusion.

  *   Introduction "... 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".
  *   Introduction "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.
  *   Introduction "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?
  *   Introduction "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<http://tools.ietf.org/html/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 Channels 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 fields 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 that imply that GAL MUST be BOS label and thus S=1?
  *   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 think that whether Type 4 MUST,SHALL or MAY be advertised (do not forget Type 3), should be addressed in RFC 5085bis.
    Regards,
        Greg
________________________________
From: Thomas Nadeau [mailto:tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>]
Sent: Tuesday, May 29, 2012 5:54 AM
To: Gregory Mirsky
Cc: Carlos Pignataro; Yaakov Stein; pwe3@ietf.org<mailto: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; please be specific and what you object to and what changes you propose to correct them. This will allow the WG to discuss any changes on the list if they are major. What we want to avoid is making changes on the same issue multiple times due to multiple conflicting change requests, or attempting to fix 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-bounces@ietf.org> [mailto:pwe3-bounces@ietf.org<mailto:pwe3-bounces@ietf.org>] On Behalf Of Carlos Pignataro
Sent: Friday, May 25, 2012 7:15 AM
To: Yaakov Stein; pwe3@ietf.org<mailto: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 was consensus for this document to define a new CC Type 4 using GAL, but there was not consensus to have this document redefine all Control Channels and 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<http://tools.ietf.org/wg/pwe3/minutes#section-20> min - General discussion on VCCV for GAL

          There appear to be two separate issues on the table:

          1<http://tools.ietf.org/wg/pwe3/minutes#section-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<http://tools.ietf.org/wg/pwe3/minutes#section-2>. What to do about legacy modes, particularly router alert and TTL

          expiry. This is a separate issue regarding the progress of RFC5085<http://tools.ietf.org/html?repository=http://tools.ietf.org&rfc=5085>

          (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 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 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 written in haste)

I believe that the number of editorial issues actually amount to technical concerns. For example, the Title, Abstract, and Introduction speak of things in the scope of a 5085bis. Moreover, the Introduction repeats Figures 1 and 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 blocking 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 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.

Similarly, this seems to contradict the actual document scope. We discussed the best approach for "unification" in Paris and subsequently on email, and it is closer to doing a 5085bis than having a document that does not update 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<mailto:pwe3@ietf.org>
https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
pwe3@ietf.org<mailto:pwe3@ietf.org>
https://www.ietf.org/mailman/listinfo/pwe3