Re: [CCAMP] MELGs - Q&A

Fatai Zhang <zhangfatai@huawei.com> Fri, 22 March 2013 08:24 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 7254721F905C for <ccamp@ietfa.amsl.com>; Fri, 22 Mar 2013 01:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.965
X-Spam-Level:
X-Spam-Status: No, score=-4.965 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_VISIT=2.3, 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 Edqw4ks-JtCN for <ccamp@ietfa.amsl.com>; Fri, 22 Mar 2013 01:24:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 00BFF21F905D for <ccamp@ietf.org>; Fri, 22 Mar 2013 01:24:43 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APR50885; Fri, 22 Mar 2013 08:24:40 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 22 Mar 2013 08:24:35 +0000
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 22 Mar 2013 16:24:38 +0800
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.47]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 22 Mar 2013 16:24:25 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Fatai Zhang <zhangfatai@huawei.com>, Igor Bryskin <IBryskin@advaoptical.com>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] MELGs - Q&A
Thread-Index: AQHOIGPek8R0zdnmbUizkEjN3z7415ivh4owgAA2TQCAATLDIIAAeV3g
Date: Fri, 22 Mar 2013 08:24:25 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF835887C70@SZXEML552-MBX.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>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF835887B75@SZXEML552-MBX.china.huawei.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_F82A4B6D50F9464B8EBA55651F541CF835887C70SZXEML552MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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, 22 Mar 2013 08:24:50 -0000

Hi Pavan and Igor,

I understand more after I read your draft and your explanation again.

I now understand that MELGs are used to solve the competition of "the same resource" in the server layer shared by two or more VLs, so I agree what Igor said that MELGs are important only when you compute concurrently two or more paths.

Do you think is this a corner case?


Best Regards

Fatai

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: Friday, March 22, 2013 9:15 AM
To: Igor Bryskin; Vishnu Pavan Beeram; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

Hi Pavan and Igor,

Thanks for your clarification.

I have seen the Question 1& 2 provided by Pavan.

When I asked "Why is there "mutual exclusivity"?  What is the essence of "mutual exclusivity"?,  I just want to know if "mutual exclusivity" exists because of "fate-sharing" in the server layer?

If the answer is "yes", then SRLG  100%  fits the valide use-case (ie., no need to introduce a new concept).

Please correct me if I missed something on the essence of MELG.

Best Regards

Fatai

From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
Sent: Thursday, March 21, 2013 10:43 PM
To: Fatai Zhang; Vishnu Pavan Beeram; ccamp@ietf.org
Subject: RE: [CCAMP] MELGs - Q&A

Fatai,
[Fatai] I don't understand your definition of MELG(ie., MELGs are used to advertise "mutual exclusivity" information).  If we name it as XXLG, we can define XXLG similarly in your style: XXLGs are used to advertise "XX" informaiton.  My real question is: Why is there "mutual exclusivity"?   What is the essence of "mutual exclusivity"?

Let me try to answer that. With Virtual Links it is possible to advertise two or more VLs with only one of them from the group to be operational at any given time. Recall that VLs could be advertised without having underlying server layer connection (e.g. H-LSP) in place. Therefore, the group of VLs may depend in a mutually exclusive way on a single network resource (e.g. WDM transponder). In order to make TE domain aware of such mutual exclusive dependency, it is suggested to use the concept of MELG. The path computer will understand that two or more VLs are mutually exclusive if they have an MELG in common.

Note, that MELGs are important only when you compute concurrently two or more paths, so that path computer wouldn't select paths with two or more VLs that mutually exclude each other. When you compute one path at a time, MELGs are not important and could be ignored.

Note also that MELGs make only sense for VLs, why otherwise you will advertise two links if only one of them at a time could be used, right? Normally you would advertise only one of them. However, with VLs it does make sense to advertise both as network topology potentiality. Hope this makes sense.

Cheers,
Igor

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: Wednesday, March 20, 2013 11:38 PM
To: Vishnu Pavan Beeram; ccamp@ietf.org
Subject: Re: [CCAMP] MELGs - Q&A

Hi Pavan,


4. How is MELG different from SRLG?

Each construct addresses a separate problem. SRLGs are used to advertise "fate-sharing" information. MELGs are used to advertise "mutual exclusivity" information.

It is possible for TE-links that have a common SRLG to be instantiated/used at the same time. It is not possible for TE-links that have a common MELG to be instantiated/used at the same time - only one of them can be used at any given point of time

[Fatai] I don't understand your definition of MELG(ie., MELGs are used to advertise "mutual exclusivity" information).  If we name it as XXLG, we can define XXLG similarly in your style: XXLGs are used to advertise "XX" informaiton.  My real question is: Why is there "mutual exclusivity"?   What is the essence of "mutual exclusivity"?

In additon, what you said in the second sentence about "possible" vs "not possible" is a kind of policy, there is nothing different between SRLG and MELG here.




Best Regards

Fatai