IETF Logo Mail Archive

Re: [CCAMP] MELGs - Q&A

Fatai Zhang <zhangfatai@huawei.com> Fri, 29 March 2013 01:23 UTC

Return-Path: <zhangfatai@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446D321F8464 for <ccamp@ietfa.amsl.com>; Thu, 28 Mar 2013 18:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Level:
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSg+0Sc6+iPj for <ccamp@ietfa.amsl.com>; Thu, 28 Mar 2013 18:23:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9116921F845E for <ccamp@ietf.org>; Thu, 28 Mar 2013 18:23:07 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARF49241; Fri, 29 Mar 2013 01:23:06 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 29 Mar 2013 01:22:38 +0000
Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 29 Mar 2013 01:23:02 +0000
Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.42]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.01.0323.007; Fri, 29 Mar 2013 09:22:57 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Thread-Topic: [CCAMP] MELGs - Q&A
Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g///IfQCABM8nkIABmHSAgARX5nA=
Date: Fri, 29 Mar 2013 01:22:57 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF84315EE01@SZXEML552-MBS.china.huawei.com>
References: <CA+YzgTvskemP5yyUHXWr8iHWB0V_jh8Q_hAudxNQnCA0++0Xiw@mail.gmail.com> <F82A4B6D50F9464B8EBA55651F541CF8358877E9@SZXEML552-MBX.china.huawei.com> <CDAC6F6F5401B245A2C68D0CF8AFDF0A191B0ED0@atl-srv-mail10.atl.advaoptical.com> <F82A4B6D50F9464B8EBA55651F541CF835887B75@SZXEML552-MBX.china.huawei.com> <F82A4B6D50F9464B8EBA55651F541CF835887C70@SZXEML552-MBX.china.huawei.com> <CA+YzgTvbQDzh9yVJmO1HuNyQOFDXsccrTbO5Fz7jE28wv4U3dA@mail.gmail.com> <F82A4B6D50F9464B8EBA55651F541CF8431571FF@SZXEML552-MBS.china.huawei.com> <CA+YzgTsM+Zzs2GBOwnAb5ZuuBwWgSZWKVtUx+XRrnrW0+v4NnA@mail.gmail.com>
In-Reply-To: <CA+YzgTsM+Zzs2GBOwnAb5ZuuBwWgSZWKVtUx+XRrnrW0+v4NnA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.72.159]
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84315EE01SZXEML552MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] MELGs - Q&A
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2013 01:23:10 -0000

Hi Pavan,

I think the usage or function of "U-Bit" (Uncommitted) is almost equivalent to my intention, but there is a little difference.
I more like to have a flag outside of MELG sub-TLV to indicate if a link is a Virtual link or *regular* link (and then path computation can be aware of this).

For the "U-Bit" defined in your draft, I think there is some logic issue. I think a virtual link is always *virtual* (ie., uncommitted). If a virtual link is committed, then this "virtual" link becomes a *regular* link (and the other virtual links sharing the same resource of the sever layer will become unavailable (or will be withdrawn) , and then MELG becomes useless (as what Igor said that "MELGs make only sense for VLs").



Best Regards

Fatai

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Tuesday, March 26, 2013 10:45 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A


Fatai, Hi!


Do you think if it makes sense to add a flag (in routing advertisement) to indicate a link is a VL or not?


When Virtual TE (VTE) Links are used, it would be useful for a client path computation element to know if a given VTE link is already committed or not. This information allows the computing element to show preference to the committed virtual TE links - and thus avoid unnecessarily instantiating an uncommitted virtual TE link when you have an equally good available committed TE link. The "U-Bit" in the MELG construct  is useful in this regard.

So, to answer your question - If the MELG construct is used as defined in the draft, I don't see a need to add any other separate flag to indicate if a link is a Virtual TE Link or not.

-Pavan


From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; ccamp@ietf.org<mailto:ccamp@ietf.org>

Subject: Re: [CCAMP] MELGs - Q&A

Fatai, Hi!

Good to see that you understand the construct now.

This is not a corner case. The utility of the construct becomes quite significant if you have an application that does concurrent path computations on an abstract topology.

Regards,
-Pavan

v2.23.0 | Report a Bug | By Email