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

[Gregory Mirsky <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Carlos Pignataro
Sent: Friday, May 25, 2012 7:15 AM
To: Yaakov Stein; [e-mail]
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.