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

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Wed, 23 May 2012 15:30:25 +0200

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

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 25 May 2012 12:09:58 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, May 23, 2012 16:30
To: [email-masked]
Subject: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt

Best regards

Matthew

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 25 May 2012 13:42:55 +0000

I received an off-list email in response to my previous email,
which convinced me to issue a clarification of my disagreement.

The proposal is to require any PE not using a CW to advertise and use the new Type 4 VCCV.

As I voiced my concerns at the meeting, if accepted,
this would ex-post facto delegitimize thousands of deployed devices,
that up-to-now were completely RFC compliant.

There are on rare occasions when breaking with the past is a good idea.
As a completely imaginary example,
I could understand someone who is of the opinion that IPv4 should be turned off on core Internet routers.

However, for the WG to accept such a course of action there would need to be a very strong reason to do so,
and a very strong consensus would be needed.
No strong reason has been given
(other than a vague mis-referenced statement about operators  having had difficulties);
and there was no consensus whatsoever to accept this course of action.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Friday, May 25, 2012 15:10
To: Bocci, Matthew (Matthew); [email-masked]
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt

Y(J)S

   Many of the

   and options for its use.

   In order to support

   scenario.

What is a GAL field ?

  If the c-bit is set,

  If the c-bit is not set,

and this new one.

Y(J)S

Best regards

Matthew

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 25 May 2012 10:15:07 -0400

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 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 alert 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 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.

> 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.

> 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.

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.

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 25 May 2012 13:01:15 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Carlos Pignataro
Sent: Friday, May 25, 2012 7:15 AM
To: Yaakov Stein; [email-masked]
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt

PWE3ers,

>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.

  If the c-bit is set,

  If the c-bit is not set,

and this new one.

Thanks,

-- Carlos.

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 29 May 2012 08:54:14 -0400

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

> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 29 May 2012 14:54:12 -0400

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:[email-masked]]
Sent: Tuesday, May 29, 2012 5:54 AM
To: Gregory Mirsky
Cc: Carlos Pignataro; Yaakov Stein; [email-masked]
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt

--Tom

    Regards,
        Greg

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Carlos Pignataro
Sent: Friday, May 25, 2012 7:15 AM
To: Yaakov Stein; [email-masked]<mailto:[email-masked]>
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt

PWE3ers,

  If the c-bit is set,

  If the c-bit is not set,

and this new one.

Thanks,

-- Carlos.

_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3