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

[Yaakov Stein <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Yaakov Stein
Sent: Friday, May 25, 2012 15:10
To: Bocci, Matthew (Matthew); [e-mail]
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt

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: [e-mail] [mailto:[e-mail]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, May 23, 2012 16:30
To: [e-mail]
Subject: [PWE3] WG Last Call for draft-ietf-pwe3-vccv-for-gal-01.txt

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