Subject: [PWE3] WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Wed, 19 Oct 2011 23:42:40 +0200

Folks,

It is about time we closed the poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt. We had left this open for longer than originally intended due to the ongoing discussion about the use of the GAL in PWs, which has moved forward now that the GAL-in-PW draft is in the RFC editor's queue.

There was a lot of support for adopting VCCV 2 given the clear need to support VCCV negotiation of a channel type for the GAL. However, these seemed to be some concerns around mandating the new VCCV Type 4 (for the GAL) for PWs without a CW,  particularly given the previous decision to move VCCV towards Internet Standard status.

We have discussed how to proceed with the draft authors, and propose the following:

 *   The WG should adopt VCCV 2, with VCCV Type 1 mandatory for PWs with a CW and Type 4 mandatory for Pws without a CW. VCCV Type 2 and 3 will be optional.
 *   We will not progress RFC5085 towards Internet Standard status at this time. At some point in the future, we will pursue this with an RFC5085bis that reflects the updates resulting from VCCV 2, as and when implementation and deployments allow.
 *   The authors of VCCV 2 should upload a new version of the draft as a PWE3 WG draft, but ensure that they remove any text suggesting that the draft actually rationalises or simplifies the number of modes.

Regards

Matthew & Andy

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 Oct 2011 14:58:01 -0700

Dear Chairs and Authors,
which VCCV Type of Control Channel is mandatory according to proposed
changes for a PW with optional CW? Is that support of VCCV Type 4 now
mandatory and Types 1, 2, and 3 are optional?

Regards,
Greg

On Wed, Oct 19, 2011 at 2:42 PM, Bocci, Matthew (Matthew) <
[email-masked]> wrote:

> Folks,
>
> It is about time we closed the poll for WG adoption of
> draft-nadeau-pwe3-vccv-2-02.txt. We had left this open for longer than
> originally intended due to the ongoing discussion about the use of the GAL
> in PWs, which has moved forward now that the GAL-in-PW draft is in the RFC
> editor's queue.
>
> There was a lot of support for adopting VCCV 2 given the clear need to
> support VCCV negotiation of a channel type for the GAL. However, these
> seemed to be some concerns around mandating the new VCCV Type 4 (for the
> GAL) for PWs without a CW,  particularly given the previous decision to move
> VCCV towards Internet Standard status.
>
>    - The WG should adopt VCCV 2, with VCCV Type 1 mandatory for PWs with a
>    CW and Type 4 mandatory for Pws without a CW. VCCV Type 2 and 3 will be
>    optional.
>    - We will not progress RFC5085 towards Internet Standard status at this
>    time. At some point in the future, we will pursue this with an RFC5085bis
>    that reflects the updates resulting from VCCV 2, as and when implementation
>    and deployments allow.
>    - The authors of VCCV 2 should upload a new version of the draft as a
>    PWE3 WG draft, but ensure that they remove any text suggesting that the
>    draft actually rationalises or simplifies the number of modes.
>
> Regards
>
> Matthew & Andy
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 19 Oct 2011 21:08:48 -0400

Hi Chairs and Authors,

Is the following understanding correct?
1. This I-D defines a new CC Type, CC Type 4.
   a. This new CC Type 4 only applies when a PW does not use a CW, even if advertised.
2. This document updates the usage rules of CC Types. // CC Type 1 when CW, CC Type 4 when there is no CW.
   a. Basically Type 1 and Type 4 are mutually exclusive.
   b. Type 1 and Type 4 are mandatory for then with and without CW, respectively.
   c. Type 2 and Type 3 are effectively not used. // I understand they are "optional" but I do not see the case when they might be used given the others are mandatory.

I think I am missing something regarding 2.c.

Also, since this document 1. adds a CC Type and 2. updates usage requirements, I think that removing all the duplication from RFC 5085 (most of S1 and S1.2) would greatly improve readability and modularity. Things like Fig 1 and Fig 2 are normative from RFC 5085.

Thanks,

Carlos P.

On Oct 19, 2011, at 5:44 PM, "Bocci, Matthew (Matthew)" <[email-masked]> wrote:

> The WG should adopt VCCV 2, with VCCV Type 1 mandatory for PWs with a CW and Type 4 mandatory for Pws without a CW. VCCV Type 2 and 3 will be optional.
> We will not progress RFC5085 towards Internet Standard status at this time. At some point in the future, we will pursue this with an RFC5085bis that reflects the updates resulting from VCCV 2, as and when implementation and deployments allow.
> The authors of VCCV 2 should upload a new version of the draft as a PWE3 WG draft, but ensure that they remove any text suggesting that the draft actually rationalises or simplifies the number of modes.
> Regards
> 
> Matthew & Andy

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 Oct 2011 18:16:21 -0700

Hi Carlos,
I think that Type 3 might be most useful in MS-PW VCCV. Though I can not
recall that MS-PW VCCV been discussed in details.

Regards,
Greg

On Wed, Oct 19, 2011 at 6:08 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>    c. Type 2 and Type 3 are effectively not used. // I understand they are
> "optional" but I do not see the case when they might be used given the
> others are mandatory.
>
> Also, since this document 1. adds a CC Type and 2. updates usage
> requirements, I think that removing all the duplication from RFC 5085 (most
> of S1 and S1.2) would greatly improve readability and modularity. Things
> like Fig 1 and Fig 2 are normative from RFC 5085.
>
> Thanks,
>
> Carlos P.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 19 Oct 2011 21:26:30 -0400

Hi Greg,

I agree. However, what draft-nadeau-pwe3-vccv-2 seems to be doing is adding Type 3-type characteristics to Type 4:

	"The PW Label must set the TTL field to 1. In the case of multi-segment pseudo-wires, the PW Label TTL MUST be set to the correct value to reach the intended destination PE as described in [RFC6073]."
I do not recall seeing a discussion on MS-PW implications of vccv-2, even if null. But, for SS-PW, I am still a bit confused.
Thanks,
Carlos P.

On Oct 19, 2011, at 9:16 PM, "Greg Mirsky" <[email-masked]> wrote:

> Hi Carlos,
> I think that Type 3 might be most useful in MS-PW VCCV. Though I can not recall that MS-PW VCCV been discussed in details.
> 
> Regards,
> Greg
> 
> On Wed, Oct 19, 2011 at 6:08 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> Hi Chairs and Authors,
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 Oct 2011 21:03:06 -0700

Hi Carlos,
thank you for pointing, I've missed that.
The text andASCII-art might be more clear. I've refreshed my memory of RFC
6073 and the provision to use Type 3 technique for OAM is from there. Hence
Type 3 can be combined with both Type 1 and Type 4 VCCV. I believe I've
missed that discussion on MS-PW VCCV completely.

Regards,
Greg

On Wed, Oct 19, 2011 at 6:26 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>   	"The PW Label must set the TTL field to 1. In the case
> of multi-segment pseudo-wires, the PW Label TTL MUST be set to the
> correct value to reach the intended destination PE as described
> in [RFC6073]."
>
>>    - The WG should adopt VCCV 2, with VCCV Type 1 mandatory for PWs with
>>    a CW and Type 4 mandatory for Pws without a CW. VCCV Type 2 and 3 will be
>>    optional.
>>    - We will not progress RFC5085 towards Internet Standard status at
>>    this time. At some point in the future, we will pursue this with an
>>    RFC5085bis that reflects the updates resulting from VCCV 2, as and when
>>    implementation and deployments allow.

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 20 Oct 2011 08:44:59 -0400

> Also, since this document 1. adds a CC Type and 2. updates usage requirements, I think that removing all the duplication from RFC 5085 (most of S1 and S1.2) would greatly improve readability and mo…

	Yes, you have it right. We've simplified the number of modes (CC types) to just two: one for when you use the CW and one for when you do not. To achieve this, each one is now mandatory to support, so it MUST be signaled as available in the capability advertisement and MUST be chosen as the primary mode to use in each case. The other modes are left as optionally supported for backwards compatibility if the hardware cannot support the new mode (which over time should be a non-existent case) and will ultimately be stripped from the document when we go to standard (not RFC) status.  This keeps things simple and clean, and also supports an ordered deprecation of the older modes. 

	This approach thus satisfies the operational feedback (i.e.: from Nick, et al)'s survey/etc... in that it simplifies the operational use of VCCV down to two modes that can/will be run automatically with each of the two PW type encapsulations in that when they turn up a PW and enable VCCV, the implementation should automatically be able to bind one VCCV mode/type to that PW and run it. No more interop operational complexity.   It also addresses those that wanted to support the older modes for a short time longer.

	--Tom

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 20 Oct 2011 11:28:34 -0400

Tom,

Please see inline.

Carlos P.

On Oct 20, 2011, at 8:45 AM, "Thomas Nadeau" <[email-masked]> wrote:

> 	Yes, you have it right. We've simplified the number of modes (CC types) to just two: one for when you use the CW and one for when you do not.

This is counter what Matthew said, which is:
"remove any text suggesting that the draft actually rationalises or simplifies the number of modes"
Also, are you saying this is basically adding a new CC Type and obsoleting two CC Types?

> To achieve this, each one is now mandatory to support, so it MUST be signaled as available in the capability advertisement and MUST be chosen as the primary mode to use in each case.

This is the key to one of my points: this effectively makes CC Type 2 and CC Type 3 to be never used. If you have a MUST support MUST use for when CW word, and another MUST support MUST use for when no CW, then the other two are not used. That is different than what Matthew said:
"VCCV Type 2 and 3 will be optional"

> The other modes are left as optionally supported for backwards compatibility if the hardware cannot support the new mode (which over time should be a non-existent case) and will ultimately be stripped from the document when we go to standard (not RFC) status.  This keeps things simple and clean, and also supports an ordered deprecation of the older modes. 

I understand the long-term proposal, but would this make things uncompliant now?

> 	This approach thus satisfies the operational feedback (i.e.: from Nick, et al)'s survey/etc... in that it simplifies the operational use of VCCV down to two modes that can/will be run automaticall…

In support of a long term simplification, it seems like either the negotiation gets more complex now, or Types2/3 are made obsolete?

Thanks,

-- Carlos.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 20 Oct 2011 11:38:34 -0700

Hi Tom,
could you please clarify the following:

   - for PW with mandatory use of CW support of Type 1 VCCV CC is mandatory
   and support of VCCV CC Types 2, 3, and 4 is optional
   - for PW with optional use of CW support of Type 4 VCCV CC is mandatory
   and support of VCCV CC Type 1, 2, and 3 is optional
   - if Type 1 and Type 4 supported and CW being used, then Type 1 VCCV CC
   takes precedence over Type 4
   - Type 3 VCCV CC must be implicitly used on MS-PW even though not being
   advertised

On Thu, Oct 20, 2011 at 5:44 AM, Thomas Nadeau <[email-masked]>wrote:

> Yes, you have it right. We've simplified the number of modes (CC types) to
> just two: one for when you use the CW and one for when you do not. To
> achieve this, each one is now mandatory to support, so it MUST be signaled
> as available in the capability advertisement and MUST be chosen as the
> primary mode to use in each case. The other modes are left as optionally
> supported for backwards compatibility if the hardware cannot support the new
> mode (which over time should be a non-existent case) and will ultimately be
> stripped from the document when we go to standard (not RFC) status.  This
> keeps things simple and clean, and also supports an ordered deprecation of
> the older modes.
>
> This approach thus satisfies the operational feedback (i.e.: from Nick, et
> al)'s survey/etc... in that it simplifies the operational use of VCCV down
> to two modes that can/will be run automatically with each of the two PW type
> encapsulations in that when they turn up a PW and enable VCCV, the
> implementation should automatically be able to bind one VCCV mode/type to
> that PW and run it. No more interop operational complexity.   It also
> addresses those that wanted to support the older modes for a short time
> longer.
>
> --Tom
>
>
>
> Thanks,
>
> Carlos P.
>

---

From: "DelRegno, Christopher N (Nick)" <[email-masked]>
Date: Thu, 20 Oct 2011 16:01:01 -0400

As others have pointed out as well, my biggest concern with VCCV v2 is the MUST support and MUST use for the non-control-word case.

>From the draft:
A PE supporting Type 4 MAY advertise other CC types
as defined in RFC5085. If the remote PE also supports Type
4, then Type 4 MUST be used superceding the Capability
Advertisement Selection rules of section 7 from RFC5085.

This means that Type 2 and Type 3 would never be used once Type 4 support is implemented.
Per the Implementation Survey (percent of respondents using the CC Type):
PW Encap                                            Type 1   Type2/3
Ethernet Tagged Mode                 41%        35%
Ethernet Raw Mode                       47%        47%
Frame Relay (1:1 Mode)               18%        12%

So, while Type 1 tends to predominate the implementations and usage, Types 2 & 3 aren't insignificant.

In the majority of my networks, we won't be using GAL for quite some time, if ever.  As such, the proposed VCCV v2 not only doesn't solve my network VCCV interop issues, it forces me to essentially reprovision my entire network when VCCV v2-compliant software releases are deployed.

I think you'll find that the interop issues with VCCV aren't related to which type I choose to use, its which type is supported by the various implementations.

I would recommend the following amendment:

1)      If CW is used, Type 1 MUST be supported.

2)      If CW is not used, Type 4 MUST be supported.

3)      If CW is not used, Type 3 MAY be supported.

4)      Type 2 use is deprecated.

If CC used should be negotiated in the following order:

1)      Type 1 (default)

2)      Type 4

3)      Type 3

4)      Type 2 use is deprecated.

I can't see mandating the USE of Type 4, or any type for that matter.  The VCCV RFC should mandate SUPPORT for one type for each option (e.g. CW and no CW) to ensure interoperability.  But given where we have been and where we are now, we cannot mandate the USE of CC types among many supported.  The operator has the right to choose whichever control channel he/she pleases, based on his/her own motivations.

So, assuming we make the appropriate modifications once it becomes a WG draft, I support making it such.

Thanks,
Nick

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, October 19, 2011 4:43 PM
To: [email-masked]
Subject: [PWE3] WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Folks,

Matthew & Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 24 Oct 2011 09:41:31 -0400

> Also, are you saying this is basically adding a new CC Type and obsoleting two CC Types?

	What we want to do is make VCCV v2 only contain the two modes with all others being optional (i.e.: "MAY" IETF language). 

> "VCCV Type 2 and 3 will be optional"
	I think what Matthew was saying is that we just do not say that we "rationalize or simplify" the number of modes.  That doesn't mean we obsolete them at all.  It was our intent to make all of the others optional until such time that we went to standard with the vccv-v2 rfc. At that time we would make the first vccv RFC "obsolete" or "historic".

> I understand the long-term proposal, but would this make things uncompliant now?

	No.  VCCV 2 describes a new preferred order and CC mode, but doesn't obsolete the older modes.  So implementations that work with the older modes are fine. What we change is only how a "vccv-v2 compliant" device chooses to use them, which which modes are used by default.  Section 4 explains that.

	--Tom

---

From: <[email-masked]>
Date: Tue, 25 Oct 2011 16:01:55 +0200

Dear All,

I share the concern and resolution request raised by Nick regarding the “MUST USE” condition.

Otherwise, the way forward as proposed below looks good to me, too.

Best regards,
Manuel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of DelRegno, Christopher N (Nick)
Sent: Thursday, October 20, 2011 10:01 PM
To: 'Bocci, Matthew (Matthew)'; [email-masked]
Subject: Re: [PWE3] WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

From the draft:

So, while Type 1 tends to predominate the implementations and usage, Types 2 & 3 aren’t insignificant.

In the majority of my networks, we won’t be using GAL for quite some time, if ever.  As such, the proposed VCCV v2 not only doesn’t solve my network VCCV interop issues, it forces me to essentially reprovision my entire network when VCCV v2-compliant software releases are deployed.

I think you’ll find that the interop issues with VCCV aren’t related to which type I choose to use, its which type is supported by the various implementations.

1)  Type 1 (default)

2)  Type 4

3)  Type 3

I can’t see mandating the USE of Type 4, or any type for that matter.  The VCCV RFC should mandate SUPPORT for one type for each option (e.g. CW and no CW) to ensure interoperability.  But given where we have been and where we are now, we cannot mandate the USE of CC types among many supported.  The operator has the right to choose whichever control channel he/she pleases, based on his/her own motivations.

Thanks,
Nick

Folks,

Matthew & Andy

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 27 Oct 2011 09:45:22 -0400

Nick, authors,

One question and one observation:

Q: Is there data in the implementation survey that quantifies usage for
CC Type 2 and CC Type 3 separate?

Note: Basically what you are proposing, if I understand it correctly,
are two things:

 1. Specify CC Type Support requirement -- this is new, does not exist
    in RFC 5085, and I think you make a great observation as to the root
    cause of interop issues.
 2. Specify a usage precedence/preference order -- this is not new, see
    S7 of RFC5085.

Observation: Based on the note above, adding a CC Type 4 is basically
orthogonal to solving issues to the other three CC Types. In fact, it
adds a new entry in the preference list. Did I get this right?

So I think either this doc attempts do deprecate two CC Types, or it
doesn't. And if it doesn't, this is adding a new CC Type without
changing much else?

Thanks,

-- Carlos.

On 10/20/2011 4:01 PM, DelRegno, Christopher N (Nick) wrote:
>
> As others have pointed out as well, my biggest concern with VCCV v2 is
> the MUST support and MUST use for the non-control-word case.
>
>  
>
> From the draft:
>
> In the majority of my networks, we won't be using GAL for quite some
> time, if ever.  As such, the proposed VCCV v2 not only doesn't solve
> my network VCCV interop issues, it forces me to essentially
> reprovision my entire network when VCCV v2-compliant software releases
> are deployed.
>
>  
>
> I think you'll find that the interop issues with VCCV aren't related
> to which type I choose to use, its which type is supported by the
> various implementations.
>
>  
>
> I can't see mandating the USE of Type 4, or any type for that matter. 
> The VCCV RFC should mandate SUPPORT for one type for each option (e.g.
> CW and no CW) to ensure interoperability.  But given where we have
> been and where we are now, we cannot mandate the USE of CC types among
> many supported.  The operator has the right to choose whichever
> control channel he/she pleases, based on his/her own motivations.
>
>  
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Bocci, Matthew (Matthew)
> *Sent:* Wednesday, October 19, 2011 4:43 PM
> *To:* [email-masked]
> *Subject:* [PWE3] WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
>
>  
>
> Folks,
>
>  
>
> originally intended due to the ongoing discussion about the use of the
> GAL in PWs, which has moved forward now that the GAL-in-PW draft is in
> the RFC editor's queue.
>
>  
>
> seemed to be some concerns around mandating the new VCCV Type 4 (for
> the GAL) for PWs without a CW,  particularly given the previous
> decision to move VCCV towards Internet Standard status. 
>
>  
>
>   * The WG should adopt VCCV 2, with VCCV Type 1 mandatory for PWs
>     with a CW and Type 4 mandatory for Pws without a CW. VCCV Type 2
>     and 3 will be optional.
>   * We will not progress RFC5085 towards Internet Standard status at
>     this time. At some point in the future, we will pursue this with
>     an RFC5085bis that reflects the updates resulting from VCCV 2, as
>     and when implementation and deployments allow.
>   * The authors of VCCV 2 should upload a new version of the draft as
>     a PWE3 WG draft, but ensure that they remove any text suggesting
>     that the draft actually rationalises or simplifies the number of
>     modes.
>
> Regards
>
>  
>
> Matthew & Andy
>
>
>