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

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

I agree with both Stuart and Sasha that an uncontroversial draft specifying
Type 4 should be our first deliverable, followed by a separate draft on
deployment and migration strategies.

Cheers,
Andy


On Tue, Jan 6, 2015 at 12:38 PM, Alexander Vainshtein <
[e-mail]> wrote:

>  Stewart and all,
>
> From my POV splitting the problem and delivering a non- controversial
> document that just defines VCCV Type 4 (covering such issues as Flow Label,
> ELI/EL etc.) is preferable, not in the least because it would onen the way
> for interoperable implementations being deployed.
>
> Discussion on migration strategies could then use actual Type 4 experience
> as a reference point
>
> My 2c,
>
>
>
>
> Thumb typed on my LG,
> Sasha
>
> ------ Original message ------
> *From: *Stewart Bryant
> *Date: *06/01/2015 19:25
> *To: *Carlos Pignataro (cpignata);Andrew G. Malis;
> *Cc: *[e-mail];
> *Subject:*Re: [Pals] Soliciting reviews for
> draft-ietf-pals-vccv-for-gal-00.txt
>
> I think that there is agreement that
>
> 1) We need Type4
>
> 2) We cannot mandate Type1
>
> However where there is discussion over the migration strategy and how it
> is defined.
>
> I wonder if the WG would prefer
>
> a) I add more text on migration path, what we deprecate  etc to this draft
>
> or
>
> b) That I split the problem and just create Type 4 here, and then write a
> draft
> on preferences, migration etc, etc.
>
> An uncontroversial RFC just creating Type 4 is probably feasible before
> the next
> IETF.
>
> - Stewart (as editor)
>
>
> On 24/12/2014 18:35, Carlos Pignataro (cpignata) wrote:
>
> 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
>
>
>
>
>
> _______________________________________________
> Pals mailing [e-mail]://www.ietf.org/mailman/listinfo/pals
>
>
>
> --
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>