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

Hi Spike,
I agree with you analysis about option 3. I think there are more guys who 
like option 1, just because option 1 inherits the existing CW mechanism, 
and they do not want to change it as it is already wildly deployed.
For option 1, if some already deployed box supports label request message, 
then the new box can inter-operate with the old box. As I know, some 
deployed boxes do support simple label request message processing for PW.
Anyway, if we were now at the initial designing step of CW negotiation, 
then option 3 is better to avoid many side effects.

BR
Lizhong

> ------------------------------
> 
> Message: 5
> Date: Fri, 3 Dec 2010 12:06:52 +0000
> From: Spike Curtis <Spike.Curtis@metaswitch.com>
> Subject: Re: [PWE3] draft-jin-pwe3-cbit-negotiation-01
> To: "pwe3@ietf.org" <pwe3@ietf.org>
> Message-ID:
> <366E5F2A62306A4783C60773E99A8D6295D0C814EC@ENFIMBOX1.ad.datcon.co.uk>
> Content-Type: text/plain; charset="us-ascii"
> 
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/pwe3/attachments/20101203/f67a7fdc/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
> 
> 
> End of pwe3 Digest, Vol 80, Issue 12
> ************************************
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.