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

Hi Sasha,

Thanks for these very useful perspectives! This is a very useful reply.

I think none of these reasons are listed in the draft Andy was asking about. One of the issues is that conflating the creation of a new CC Type with the prioritization of type usage (defaulting, obsoleting, etc) obscures the reasons for change, making them more vague. Is it for interoperability, mpls-TP, non-IP OAM, ms-pw? Should the creation of a cc type be separate from the rationalization of the existing ones?

I agree with your points below. But also, as you pointed out, types 2 and 3 seem widely used despite all their bugs.

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Dec 26, 2014, at 1:00 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> 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) <cpignata@cisco.com<mailto:cpignata@cisco.com>>
Sent: Friday, December 26, 2014 3:09 AM
To: Alexander Vainshtein
Cc: pals@ietf.org<mailto:pals@ietf.org>; 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 <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> 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 <pals-bounces@ietf.org<mailto:pals-bounces@ietf.org>> on behalf of Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>>
Sent: Wednesday, December 24, 2014 8:35 PM
To: Andrew G. Malis
Cc: pals@ietf.org<mailto:pals@ietf.org>
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 <agmalis@gmail.com<mailto:agmalis@gmail.com>> 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: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Wed, Dec 17, 2014 at 12:00 PM
Subject: I-D Action: draft-ietf-pals-vccv-for-gal-00.txt
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
Cc: pals@ietf.org<mailto:pals@ietf.org>

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<http://tools.ietf.org/>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
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
Pals@ietf.org<mailto:Pals@ietf.org>
https://www.ietf.org/mailman/listinfo/pals