Re: [PWE3] Mandatory Control Word

Greg Mirsky <gregimirsky@gmail.com> Thu, 28 October 2010 17:42 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: pwe3@core3.amsl.com
Delivered-To: pwe3@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785D23A686A for <pwe3@core3.amsl.com>; Thu, 28 Oct 2010 10:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.356
X-Spam-Level:
X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXkUwB9C6roe for <pwe3@core3.amsl.com>; Thu, 28 Oct 2010 10:42:36 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 1B62D3A6834 for <pwe3@ietf.org>; Thu, 28 Oct 2010 10:42:36 -0700 (PDT)
Received: by yxp4 with SMTP id 4so1550555yxp.31 for <pwe3@ietf.org>; Thu, 28 Oct 2010 10:44:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Def/rZG0pw1Ghf8KxkwQHPoSIealYTy9bWvI8/Q651s=; b=tasjQr2uCcV49uHnaFS3V/D4k+PMtpMhtBujwCetAPPM6s52VOjtP/kARDvl+YLEDM Y2/oaxohV7q8xQtnaz4KKbx+ZWq5+2JV1u+lk1jUKVPVWM/zXcCWE5en9u6Oa/aMkLJb ftaVzpG1aYxr+5vZ7MxOUXUtZ1jmaExGo9SyE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qVGYue7OEqFKs4n6aWrb/k2ttwFCZ9IKt0EFs+Ge0VN5chWwG1aCUSYvYX6MM8PwOu HeHtN/QdW9lALXdC5p+yWn2XBYlVlIbM5YZJw+Vh9Gu5/WhuHLNQ8oDHtVx/yJ4e8+if VL4cRbOX94yJRs421+BeOaTfok2UvR/JG1ems=
MIME-Version: 1.0
Received: by 10.142.211.20 with SMTP id j20mr463867wfg.408.1288287868014; Thu, 28 Oct 2010 10:44:28 -0700 (PDT)
Received: by 10.220.186.134 with HTTP; Thu, 28 Oct 2010 10:44:27 -0700 (PDT)
In-Reply-To: <AFA0E20F-4180-4B9E-B30C-66494CB868E6@lucidvision.com>
References: <4CC70E97.7000100@cisco.com> <C0AC8FAB6849AB4FADACCC70A949E2F10929F4068B@EUSAACMS0701.eamcs.ericsson.se> <AFA0E20F-4180-4B9E-B30C-66494CB868E6@lucidvision.com>
Date: Thu, 28 Oct 2010 10:44:27 -0700
Message-ID: <AANLkTinfQUZ9Y0gHkbHZmnZu=ih8sV_huD_ND1-LyeM9@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
To: Thomas Nadeau <tnadeau@lucidvision.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "stbryant@cisco.com" <stbryant@cisco.com>, pwe3 <pwe3@ietf.org>
Subject: Re: [PWE3] Mandatory Control Word
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2010 17:42:37 -0000

Dear Tom,
you definitely are aware of proposal to update RFC 5586 and allow use
of GAL in MPLS-TP PWs. I believe that this proposal is directly
affects RFC 5085 PW VCCV as it adds another VCCV Control Channel type.
If this proposal adopted it, in my view, will affect PW VCCV
interoperability that must be reflected in Mandatory Features of VCCV
Implementations. I see the proposal to make use of PW CW mandatory
(perhaps not "mandatory" but "preferred" or "default" behavior) as
alternative to extension of GAL, not complimentary or orthogonal. I
think that the PWE3 WG may choose one that will minimize operational
impact while restoring consistency in MPLS PW OAM (if only in some
part).

Regards,
Greg

On Wed, Oct 27, 2010 at 10:28 AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:
>
>        Eric,
>
>    What you surmise below is PRECISELY the point that Nick/I/others are making.
> It is clear that in the large majority of deployments, the use of the CW *is*
> the typical configuration. The only real non-use is with ATM PWs to apparently
> "save bandwidth", but the real issue is to keep old equipment working. There
> is no argument that we do not want to obviate older equipment, but what we
> want is going forward to be doing the right thing for interoperability.
>
>     The other observation we've made is that the myriad of options
> available to VCCV result in serious interoperability issues. These
> different modes are available largely due to not making the CW
> mandatory (as well as the bailing-wire and bubble gum approach we
> originally took to encapsulating different PW types).
>
>     The road to interop is simplification.  All we are proposing is:
>
>     a) any protocols/documents in PWE3 that are not RFC at present, be required
>          to use the CW.
>
>     b) any existing protocols in PWE3 and future ones be required to use the CW
> when going to proposed standard status.
>
>     c) adoption of the negotiation of the CW status based on the draft that we proposed
> in the interim to aid in more automatic interop for operators.
>
>        --Tom
>
>
>> Stewart,
>>
>>       I agree with your suggested limitations to new PW types
>> and suggestion to recommend its use for existing PW types.
>>
>>       However, the observation about deployed systems - when
>> taken together with what appears to be a growing impression
>> that use of the control word with all PW types may be a good
>> idea - seems to argue that we would (eventually) need a BCP
>> that specifies use of the control word, and possibly we may
>> even have to publish a "non-use of PW control word considered
>> dangerous" RFC.
>>
>>       I don't see a way to avoid this, assuming that is where
>> we are headed, but it might be good to be clear on whether or
>> not that _is_ where we are headed.
>>
>>       It also causes me to wonder if there are implementations
>> deployed in the field where use of the control word is not a
>> configurable capability.  Certainly, if deployed equipment is
>> all capable of being configured to always use control words,
>> then it is not unrealistic to suggest that configuring things
>> that way would simplify future implementations.
>>
>> --
>> Eric
>>
>> -----Original Message-----
>> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Stewart Bryant
>> Sent: Tuesday, October 26, 2010 1:24 PM
>> To: pwe3
>> Subject: [PWE3] Mandatory Control Word
>>
>> From
>>
>> draft-delregno-pwe3-mandatory-control-word/
>>
>> =======
>> 2.  Mandatory Control Word
>>
>>    The Control Word SHALL be mandatory for all PWE3 encapsulations.  The
>>    use of the sequence number remains OPTIONAL.
>>
>>    As a result of the Control Word being Mandatory, all implementations
>>    of the PWE3 encapsulations SHALL follow Section 6.1 of [RFC4447]
>>    wherein the "PWs MUST have c=1".  This requirement SHALL remain until
>>    such time, if ever, RFC4447 is superceded and the support for Control
>>    Word negotiation is removed as a result of this mandate.
>>
>> ======
>>
>> Given the reality of network deployments I do not see how we can
>> talk about removing the requirement to negotiate the CW in any
>> realistic time frame.
>>
>> It's fine to require the CW for all new PW types, and it's
>> probably OK to RECOMMEND operation with the CW, but it's
>> unrealistic to remove the option given the extent of the deployed
>> systems.
>>
>> - Stewart
>>
>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> pwe3@ietf.org
>> https://www.ietf.org/mailman/listinfo/pwe3
>> _______________________________________________
>> pwe3 mailing list
>> pwe3@ietf.org
>> https://www.ietf.org/mailman/listinfo/pwe3
>>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>