Return-Path: 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 ; 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 ; 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 ; 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 To: "pwe3@ietf.org" Date: Fri, 3 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: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 12:05:55 -0000 --_000_366E5F2A62306A4783C60773E99A8D6295D0C814ECENFIMBOX1adda_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Everyone, If there is a requirement to change signaled properties of a PW without tak= ing both ends administratively down, we should establish a consistent mecha= nism across all such properties. The ideal output would be to a have a sin= gle negotiation method which is used whenever any signaled PW property is c= hanged 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 negotiatio= ns 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 c= hanges, the PE can withdraw and resignal its Label Mapping and the algorith= m will give a different result. In contrast, CW negotiation currently work= s 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 carr= y 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 ven= katesan 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 Advertise= ment by sending label request message from PE2. I think, we may have similar issue in status TLV negotiation also. Thanks, Venkat. * To: Ed > * Subject: Re: [PWE3] draft-jin-pwe3-cbit-negotiation-01 * From: lizhong.jin at zte.com.cn * Date: Thu, 25 Nov 2010 19:18:39 +0800 * Cc: vishwas at ipinfusion.com, pwe3 at i= etf.org, thomas.nadeau at huawei.com * Delivered-to: pwe3 at core3.amsl.com * In-reply-to: > * List-archive: * List-help: * List-id: Pseudo Wires Edge to Edge > * List-post: * List-subscribe: , * List-unsubscribe: , ________________________________ Hi Edward, See the comments in line. Thanks. Lizhong Ed > wrote on 2010-11-25 08:47:3= 0: > 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=3D1 be sent without requiring label withdrawal > message and label request message, for example? [Lizhong] maybe not allowed, for this behavior will break existing CW negot= iation 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) > > 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 [mailto:pwe3-bounces at ietf.org] On Behalf Of > Sami Boutros (sboutros) > Sent: Tuesday, November 23, 2010 12:11 AM > To: Raymond Key; pwe3 at ietf.org > > Cc: thomas.nadeau at huawei.com; lizhong.jin at zte.co= m.cn; vishwas at 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 iss= ues. > > 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 > https://www.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3 at ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --_000_366E5F2A62306A4783C60773E99A8D6295D0C814ECENFIMBOX1adda_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 al= l such properties.  The ideal output would be to a have a single negotia= tion 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 tha= t I'm aware of.  Properties like
-<= span style=3D'font-size:7.0pt'>       VCCV types
-<= span style=3D'font-size:7.0pt'>       FAT-PW &nb= sp;
-<= span style=3D'font-size:7.0pt'>       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 policie= s according to some algorithm (usually just a logical AND).  When local configuration changes, the PE can withdraw and resignal its Label Mapp= ing and the algorithm will give a different result.  In contrast, CW negotiation currently works differently: what a PE device signals depends b= oth 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 dev= ices don’t include the new TLV then we just fall back to the procedur= es 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 Advertise= ment by sending label request message from PE2.

 

I think, we may have similar issue in status TLV negot= iation also.

 

Thanks,
Venkat.


Hi Edward= ,
See the comments in line. Thanks.

Lizhong


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

> Hi Raymond,
>  
> Option 1 seems to be simply to re= signal the FEC - with the
> corresponding traffic forwarding impact. Can PE2 send a new l= abel
> mapping with cbit=3D1 be sent without requiring label withdrawal <= /tt>
> 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 conside= red in next version.

>  
> Thanks
>  
> Regards,
> Edward
>
>  
> On Wed, Nov 24, 2010 at 11:12 PM, Reshad Rahman (rrahman) <rrahman at cisco.c= om
> > wrote:
> I agree with Sami. Maybe the othe= r options should be in appendix
> with an explanation of why they were not chosen?
>  
> Regards,
> Reshad.
>  
> From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf Of
> Sami Boutros (sboutros)
> Sent: Tuesday, November 23, 2010 12:11 AM
> To: Raymond Key; pwe3 at ietf.org =
>
> Cc: thomas.nadeau at huawei.com; lizhong.jin at zte.com.cn; vishwas at ipinfusion.com
> Subject: Re: [PWE3] draft-jin-pwe3-cbit-negotiation-01
>  
> I personally like option 1 in thi= s 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 h= ave issues.
>
> Option 2, how will we be able to re-enable CW? isn't that the issu= e
> 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 t= he
> document and post comments on the mailing list.
>  
> Thanks,
> Raymond Key
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org
> https://www= .ietf.org/mailman/listinfo/pwe3
>  
>
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org
> https://www= .ietf.org/mailman/listinfo/pwe3

--_000_366E5F2A62306A4783C60773E99A8D6295D0C814ECENFIMBOX1adda_--