Re: [Pals] Soliciting reviews for draft-ietf-pals-vccv-for-gal-00.txt

["Andrew G. Malis" <[e-mail]>]

Carlos and Sasha,

In addition to Sasha's reply, I would like to add in response to Carlos' Q5
that the WG has repeatedly agreed (and documented in RFC 7079, section 2.1
in particular) that there are too many existing deployed implementations of
PWs without the CW that we cannot mandate the CW for all PWs. It would be
great if we could, but unfortunately that ship has sailed.

Cheers,
Andy

On Fri, Dec 26, 2014 at 1:00 AM, Alexander Vainshtein <
[e-mail]> wrote:

>  ​Carlos,
>
> Lots of thanks for a prompt response and especially for a set of
> well-defined questions.
>
>
>  So far I can offer my versions of answers to Q1:
>
>
>
>    - A common problem with both Type 2 and Type 3 is that they *effectively
>    mandate IP- (and sometimes even UDP/IP-) based encapsulation for OAM
>    packets they carry. *IP Protocol number and, possibly, UDP Destination
>    port are required for  demuxing different OAM protocols running in VCCV.
>    This has never been an issue when RFC 5085 has been discussed, but advance
>    of MPLS-TP changed the attitude IMO.
>    - VCCV Type 2 has an additional  problem of its own - it simply *does
>    not work for MS-PWs. *RFC 6073 explicitly states
>    - VCCV Type 3 also has an additional problem of its own  -  *it could
>    result in leaking OAM packets into the attachment circuit *if the
>    originator has mistakenly set a wrong TTL value in the PW label LSE. At the
>    same time PW segment OAM for MS-PWs mandates usage of VCCV Type 3.
>
> From my POV VCCV Type 4  solves all these problems for PWs that do not use
> the CW.
>
>
>  Hopefully these notes will be useful.
>
>
>  Regards,
>
> Sasha
>
>
>   ------------------------------
>  *From:* Carlos Pignataro (cpignata) <[e-mail]>
> *Sent:* Friday, December 26, 2014 3:09 AM
> *To:* Alexander Vainshtein
> *Cc:* [e-mail]; Andrew G. Malis
> *Subject:* Re: [Pals] Soliciting reviews for
> draft-ietf-pals-vccv-for-gal-00.txt
>
>  Hi, Sasha,
>
>  Exactly — so some of the questions that this creates are:
>
>    1. What’s not working on Types 2 and 3 that a Type 4 would solve?
>    2. If the answer to Q1 and the problem to be solved is interop — would
>    creating a new Type to deprecate (effectively in practice or explicitly)
>    two CC Types be the fastest way to interop?
>    3. If new HW is needed for a Type 4, what’s the backwards
>    compatibility and deployment plan?
>    4. If CC Types 1 and 4 are proposed to be forward-looking used, should
>    this doc come clean at deprecating Types 2 and 3?
>    5. Instead of a new CC Type 4, would mandating CW for all PWs (and use
>    of CC Type 1) solve this more effectively?
>
>
>  I think Q5 is a key one that ought to be discussed.
>
>  Hope this quick review and these questions help.
>
>  Thanks,
>
>  Carlos.
>
>  On Dec 25, 2014, at 12:52 AM, Alexander Vainshtein <
> [e-mail]> wrote:
>
>  ​Carlos,
> After reading your review I have looked up RFC 7079.
> This document shows that for Ethernet PWs VCCV Type 2 and VCCV Type 3
> taken together are used by the operators *almost as frequently as VCCV
> Type 1*:
>
>  o Ethernet Tagged Mode - RFC 4448 *[Sasha]  7 vs. 6*
>  * Control Word (Type 1) = 7
>  * Router Alert Label (Type 2) = 3
>  * TTL Expiry (Type 3) = 3
>
>
>  o Ethernet Raw Mode - RFC 4448 *[Sasha]  A draw: 8 vs. 8*
>  * Control Word (Type 1) = 8
>  * Router Alert Label (Type 2) = 4
>  * TTL Expiry (Type 3) = 4
>
>
>
>  If anything, this looks to me as a blocker for deprecation of these
> types (even if  VCCV Type 2 is not suitable for MS-PWs as indicated in RFC
> 6073)
>
>   Lots of thanks for pointing to this document!
>
>  Regards,
> Sasha
>  ------------------------------
>  *From:* Pals <[e-mail]> on behalf of Carlos Pignataro
> (cpignata) <[e-mail]>
> *Sent:* Wednesday, December 24, 2014 8:35 PM
> *To:* Andrew G. Malis
> *Cc:* [e-mail]
> *Subject:* Re: [Pals] Soliciting reviews for
> draft-ietf-pals-vccv-for-gal-00.txt
>
>  Andy,
>
>  I took a very quick scan through this document, and have a number of
> concerns.
>
>  At the heart of the concerns, this document seems to be doing a number
> of different things that are not reflected in the Title and Abstract. While
> the title is “VCCV Default CC Types”, this document seems to be doing much
> more than defining default CC Types, including:
> 1. Defining a new CC Type 4
> 2. Setting a Default for when with and without CW (as per the Title), but
> also
> 3. Implicitly Obsoleting Type 2 and Type 3 (non-default)
> 4. Requiring new hw capabilities for the Type 4.
>
>  I believe those things should be explicitly done.
>
>  Some more comments (including editorials) follow, prefaced with “CMP”:
>
>  PWE3                                                           T. Nadeau
> Internet-Draft                                               lucidvision
> Updates: 4447, 5085 (if approved)                             L. Martini
>
>  CMP: s/PWE3/PALS? >
>
>     This document updates RFC4447 and RFC5085.
>
>  CMP: More importantly, what exactly is this document updating on those
> two? Adding a new CC Type does not mean update RFC 4447 or RFC 5085. I
> Section listing the exact updates to those specs is necessary. My view is
> that this doc can update 5085 (Section 7), but not sure how it updates 4447.
>
>     Note to be removed at publication: this document started out as
>    draft-ietf-pwe3-vccv-for-gal and got to version -02.  When PWE3 was
>    absorbed into PALS the next version published was draft-ietf-pals-
>    vccv-for-gal-00
>
>  CMP: I thought that initially, draft-ietf-pwe3-vccv-for-gal-02 was only
> defining the new CC Type 4, while draft-nadeau-pwe3-vccv2-00 would do other
> updates including Defaults, obsoleting CC Types, etc.
>
>     state.  Operators have indicated in [RFC4377], and [RFC3916] that
>    such a tool is required for PW operation and maintenance.  To this
>    end, the IETF's PWE3 Working Group defined the Virtual Circuit
>    Connectivity Verification Protocol (VCCV) in [RFC5085] . Since then a
>    number of interoperability issues have arisen with the protocol as it
>    is defined.
>
>  CMP: I see the fact that PWE3 WG defined that RFC as a distractor, and
> irrelevant in the larger scheme of things. Also, you should point to
> [RFC7079] to describe and quantify the interop issues instead of just
> saying they exist. Lastly, how creating a new CC Type not also create intro
> issues? That should be answered.
>
>  7.  Manageability Considerations
>
>     By introducing default VCCV CC types, and improving the compatibility
>    with MPLS-TP, the compatibility of implementations is improved and
>    management and configuration of the network becomes simpler.
>
>  CMP: This is a bold statement, that does not appear to be immediate. I
> expect initially to see the manageability worst before it improves. This is
> adding a new mode before letting time to remove all the other ones.
>
>  Thanks,
>
>  Carlos.
>
>
>  On Dec 22, 2014, at 9:33 AM, Andrew G. Malis <[e-mail]> wrote:
>
>  PALSers,
>
>  i know that you would all like a little something to distract you from
> the holidays ... :-). Well, maybe not. But anyway, Stewart recently revised
> the VCCV for GAL draft (see below), and while short (just four pages of
> real content), we would like to have a good indication that it represents
> WG consensus, so we need at least some of you out there to read it and
> comment, even if that comment is "I've reviewed it and looks great to me".
> As I noted, it's a short draft, so it shouldn't take all that long.
>
>  You can read the draft at
> http://tools.ietf.org/html/draft-ietf-pals-vccv-for-gal-00 .
>
>  Thanks,
> Stewart and Andy
>
>  ---------- Forwarded message ----------
> From: <[e-mail]>
> Date: Wed, Dec 17, 2014 at 12:00 PM
> Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
> To: [e-mail]
> Cc: [e-mail]
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Pseudowire And LDP-enabled Services
> Working Group of the IETF.
>
>         Title           : VCCV Default CC Types
>         Authors         : Thomas D. Nadeau
>                           Luca Martini
>                           Stewart Bryant
>         Filename        : draft-ietf-pals-vccv-for-gal-00.txt
>         Pages           : 8
>         Date            : 2014-12-17
>
> Abstract:
>    This document specifies the default Virtual Circuit Connectivity
>    Verification (VCCV) (RFC5085) control channel type to be used when
>    the pseudowire control word is present and when it is not present.  A
>    new VCCV control channel type using the Generic Associated Channel
>    Label (RFC5586) is specified for use when the control word not
>    present.
>
>    This document updates RFC4447 and RFC5085.
>
>    Note to be removed at publication: this document started out as
>    draft-ietf-pwe3-vccv-for-gal and got to version -02.  When PWE3 was
>    absorbed into PALS the next version published was draft-ietf-pals-
>    vccv-for-gal-00
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pals-vccv-for-gal/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-pals-vccv-for-gal-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft
> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
> directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>  _______________________________________________
> Pals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pals
>
>
>