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

From: Lizhong Jin <[email-masked]>
Date: Tue, 25 Oct 2011 00:20:42 +0800

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

3)      If CW is not used, Type 3 MAY be supported.
The above two points still confuse me. If CW is not used and type 4 MUST be
used, why type 3 is optional?

Thanks
Lizhong

> ----------------------------------------------------------------------
>
> Date: Thu, 20 Oct 2011 16:01:01 -0400
> From: "DelRegno, Christopher N (Nick)" <[email-masked]>
> To: "'Bocci, Matthew (Matthew)'" <[email-masked]>,
>        "[email-masked]" <[email-masked]>
> Subject: Re: [PWE3] WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
> Message-ID:
>        <
> [email-masked]
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> 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.
>

> 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
> i=
> s 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
> V=
> CCV interop issues, it forces me to essentially reprovision my entire
> netwo=
> rk when VCCV v2-compliant software releases are deployed.
>
> I think you'll find that the interop issues with VCCV aren't related to
> whi=
> ch type I choose to use, its which type is supported by the various
> impleme=
> ntations.
>
> 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
> n=
> o CW) to ensure interoperability.  But given where we have been and where
> w=
> e 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
> dra=
> ft, I support making it such.
>
> Thanks,
> Nick
>