Re: [PWE3] draft-jin-pwe3-cbit-negotiation-01

Spike Curtis <Spike.Curtis@metaswitch.com> Fri, 03 December 2010 12:05 UTC

Return-Path: <Spike.Curtis@metaswitch.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 856C63A6A4B for <pwe3@core3.amsl.com>; Fri, 3 Dec 2010 04:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, J_CHICKENPOX_73=0.6]
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 pE9v5IiEsj1C for <pwe3@core3.amsl.com>; Fri, 3 Dec 2010 04:05:44 -0800 (PST)
Received: from enfiets1.dataconnection.com (enfiets1.dataconnection.com [192.91.191.38]) by core3.amsl.com (Postfix) with ESMTP id 142813A689A for <pwe3@ietf.org>; Fri, 3 Dec 2010 04:05:44 -0800 (PST)
Received: from ENFIMBOX2.ad.datcon.co.uk (172.18.74.17) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 3 Dec 2010 12:07:39 +0000
Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX2.ad.datcon.co.uk ([172.18.74.17]) with mapi; Fri, 3 Dec 2010 12:06:57 +0000
From: Spike Curtis <Spike.Curtis@metaswitch.com>
To: "pwe3@ietf.org" <pwe3@ietf.org>
Date: Fri, 03 Dec 2010 12:06:52 +0000
Thread-Topic: [PWE3] draft-jin-pwe3-cbit-negotiation-01
Thread-Index: AcuMpa2DaOpJztxeQlSpg8VS1WIj3wGPIGgg
Message-ID: <366E5F2A62306A4783C60773E99A8D6295D0C814EC@ENFIMBOX1.ad.datcon.co.uk>
References: <AANLkTikU8Oy0g2kchKJWOUPmKCiKaj-cwB=s8ijYvdRy@mail.gmail.com>
In-Reply-To: <AANLkTikU8Oy0g2kchKJWOUPmKCiKaj-cwB=s8ijYvdRy@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_366E5F2A62306A4783C60773E99A8D6295D0C814ECENFIMBOX1adda_"
MIME-Version: 1.0
Subject: Re: [PWE3] draft-jin-pwe3-cbit-negotiation-01
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: Fri, 03 Dec 2010 12:05:55 -0000

Hi Everyone,

If there is a requirement to change signaled properties of a PW without taking both ends administratively down, we should establish a consistent mechanism across all such properties.  The ideal output would be to a have a single negotiation method which is used whenever any signaled PW property is changed via configuration.  Option 3 in the draft would bring CW negotiation more in line with the way that other signaled properties are negotiated.

We've gone down a different path than Option 1 for most other PW negotiations that I'm aware of.  Properties like
-       VCCV types
-       FAT-PW
-       PW Status TLV
are negotiated by each PE signaling according to local policy.  Then, each PE reaches a decision by comparing the local and remote policies according to some algorithm (usually just a logical AND).  When local configuration changes, the PE can withdraw and resignal its Label Mapping and the algorithm will give a different result.  In contrast, CW negotiation currently works differently: what a PE device signals depends both on local policy and on what it has received from the remote peer.

A disadvantage of Option 3 is that it isn't backwards-compatible.  However, the proposal could easily be modified to be so by adding a new TLV to carry the CW information.  If both PE devices don't include the new TLV then we just fall back to the procedures described in RFC 4447.

Thanks,
Spike

From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of venkatesan mahalingam
Sent: 25 November 2010 1:36 PM
To: pwe3@ietf.org
Subject: Re: [PWE3] draft-jin-pwe3-cbit-negotiation-01

Hi,
Option 1: Control Word Re-Negotiation by Label Request looks good to me.
I think, it is not violating any LDP Downstream Unsolicited Label Advertisement by sending label request message from PE2.

I think, we may have similar issue in status TLV negotiation also.

Thanks,
Venkat.

 *   To: Ed <maillist.ed at gmail.com<mailto:maillist.ed@DOMAIN.HIDDEN>>
 *   Subject: Re: [PWE3] draft-jin-pwe3-cbit-negotiation-01
 *   From: lizhong.jin at zte.com.cn<mailto:lizhong.jin@DOMAIN.HIDDEN>
 *   Date: Thu, 25 Nov 2010 19:18:39 +0800
 *   Cc: vishwas at ipinfusion.com<mailto:vishwas@DOMAIN.HIDDEN>, pwe3 at ietf.org<mailto:pwe3@DOMAIN.HIDDEN>, thomas.nadeau at huawei.com<mailto:thomas.nadeau@DOMAIN.HIDDEN>
 *   Delivered-to: pwe3 at core3.amsl.com<mailto:pwe3@DOMAIN.HIDDEN>
 *   In-reply-to: <AANLkTim6e==d_P2suW14YRtTDM-9H_Zu_oWjd03oRASe at mail.gmail.com<mailto:AANLkTim6e%3D%3Dd_P2suW14YRtTDM-9H_Zu_oWjd03oRASe@DOMAIN.HIDDEN>>
 *   List-archive: <http://www.ietf.org/mail-archive/web/pwe3>
 *   List-help: <mailto:pwe3-request@ietf.org?subject=help>
 *   List-id: Pseudo Wires Edge to Edge <pwe3.ietf.org<http://pwe3.ietf.org>>
 *   List-post: <mailto:pwe3@ietf.org>
 *   List-subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
 *   List-unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>

________________________________

Hi Edward,
See the comments in line. Thanks.

Lizhong


Ed <maillist.ed at gmail.com<http://gmail.com>> wrote on 2010-11-25 08:47:30:

> Hi Raymond,
>
> Option 1 seems to be simply to resignal the FEC - with the
> corresponding traffic forwarding impact. Can PE2 send a new label
> mapping with cbit=1 be sent without requiring label withdrawal
> message and label request message, for example?
[Lizhong] maybe not allowed, for this behavior will break existing CW negotiation mechanism.

>
> Also, does the the changing of the control word from PREFERRED to
> non-PREFERRED need to be considered as well?
[Lizhong] good idea, should be considered in next version.

>
> Thanks
>
> Regards,
> Edward
>
>
> On Wed, Nov 24, 2010 at 11:12 PM, Reshad Rahman (rrahman) <rrahman at cisco.com<http://cisco.com>
> > wrote:
> I agree with Sami. Maybe the other options should be in appendix
> with an explanation of why they were not chosen?
>
> Regards,
> Reshad.
>
> From: pwe3-bounces at ietf.org<http://ietf.org> [mailto:pwe3-bounces<mailto:pwe3-bounces> at ietf.org<http://ietf.org>] On Behalf Of
> Sami Boutros (sboutros)
> Sent: Tuesday, November 23, 2010 12:11 AM
> To: Raymond Key; pwe3 at ietf.org<http://ietf.org>
>
> Cc: thomas.nadeau at huawei.com<http://huawei.com>; lizhong.jin at zte.com.cn<http://zte.com.cn>; vishwas at ipinfusion.com<http://ipinfusion.com>
> Subject: Re: [PWE3] draft-jin-pwe3-cbit-negotiation-01
>
> I personally like option 1 in this draft, describing how to re-
> enable control word via dynamic LDP signaling.
>
> However, you would need to clarify the steps more..
> saying in step 3 that PE2 MUST send a label request and in step 5
> that PE1 MUST respond to the label request with the configured CW
> setting on PE1 which was set, as well in step 6 PE2 MUST wait for
> PE1 label binding before sending it's label binding with CW set.
>
> As well, it may be good extending the flow chart described in
> appendix A in rfc 4447 with option 1.
>
> Not sure, if it is worth mentioning the other options since they have issues.
>
> Option 2, how will we be able to re-enable CW? isn't that the issue
> we are trying to fix?
>
> Option 3, This is avoiding to solve the problem.
>
> Option 4, I don't think this will fly.
>
> Thanks,
>
> Sami
> At 01:53 AM 11/19/2010, Raymond Key wrote:

> Hi PWE3 working group,
>
> In the recent IETF79, we have presented the draft "Pseudowire
> Control Word Negotiation Mechanism Analysis and Update"
> http://tools.ietf.org/html/draft-jin-pwe3-cbit-negotiation-01
>
> This draft describes the problem of control word negotiation
> mechanism specified in RFC4447. Based on the problem analysis,
> possible solutions and their potential shortcomings are also discussed.
>
> The authors would like to have more feedback from the mailing list
> before working on the next version. Grateful if you could review the
> document and post comments on the mailing list.
>
> Thanks,
> Raymond Key
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org<http://ietf.org>
> https://www.ietf.org/mailman/listinfo/pwe3
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org<http://ietf.org>
> https://www.ietf.org/mailman/listinfo/pwe3