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

["DelRegno, Christopher N (Nick)" <[e-mail]>]

Tom raises a valid point, but I’m not sure how often we should poll the industry, looking for the answer we may desire.

Some anecdotal info from my vantage point, for what it’s worth:
Our use of VLAN-mode and Raw-Mode Ethernet PWs with CC Type 1 has grown dramatically over the last four years.  However, the use of Type 2 or Type 3 has not decreased as there is little motivation to migrate a customer’s EVC (read outage) from Types 2 & 3 to Type 1.  So while the ratio of Type 1 to Types 2/3 for Ethernet PWs has grown, the number of Types 2/3 Ethernet PWs has remained steady, if not increasing slightly.

Likewise, the FR/ATM encaps, while decreasing, have not disappeared.

My major discomfort comes from phrases like: "When the PWE3 Control Word is not used, the new VCCV CC Type 4 defined in this section MUST be used.”  My need is that it must be SUPPORTED.  However, mandating its use seems problematic.

For example, consider a  network (or parts/regions thereof) where older equipment is in use and Type 1 is A) not enabled or worse B) not supported.  This equipment may be running old code and not upgradeable to newer code/hardware which supports Type 1.  This network is running along fine with Type 2 or Type 3.  Now, add in Vendor X’s new draft-ietf-pals-vccv-for-gall-xx-compliant system.  1) It will NEVER be able to setup PWs with the legacy equipment in Scenario B, and only with per-VC config changes could it in Scenario A.  2) I would NEVER be able to migrate from the old to the new without some sort of flag day, network wide migration, which wouldn’t happen.

Since we have so many networks in flight with large numbers of non-CC-Type-1 PWs in service, we need a more considerate approach than mandating Type 1 OR Type 4 only.

Nick


From: Thomas Nadeau <[e-mail]<mailto:[e-mail]>>
Date: Friday, December 26, 2014 at 9:46 AM
To: "Andrew G. Malis" <[e-mail]<mailto:[e-mail]>>
Cc: "Carlos Pignataro (cpignata)" <[e-mail]<mailto:[e-mail]>>, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Pals] Soliciting reviews for draft-ietf-pals-vccv-for-gal-00.txt


It might be worth checking this state again. RFC7079 is FOUR years old now.

—Tom


On Dec 26, 2014:8:47 AM, at 8:47 AM, Andrew G. Malis <[e-mail]<mailto:[e-mail]>> wrote:

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, December 26, 2014 3:09 AM
To: Alexander Vainshtein
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> on behalf of Carlos Pignataro (cpignata) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, December 24, 2014 8:35 PM
To: Andrew G. Malis
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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<http://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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pals


_______________________________________________
Pals mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pals