Re: [CCAMP] MELGs - Q&A

Igor Bryskin <IBryskin@advaoptical.com> Thu, 21 March 2013 14:43 UTC

Return-Path: <IBryskin@advaoptical.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 AE78621F90CE for <ccamp@ietfa.amsl.com>; Thu, 21 Mar 2013 07:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.298
X-Spam-Level:
X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_VISIT=2.3]
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 d-2r-rRoL91b for <ccamp@ietfa.amsl.com>; Thu, 21 Mar 2013 07:43:11 -0700 (PDT)
Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id F206121F90CA for <ccamp@ietf.org>; Thu, 21 Mar 2013 07:43:10 -0700 (PDT)
Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id r2LEgvvT018428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 15:42:57 +0100
Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.620.14; Thu, 21 Mar 2013 15:42:56 +0100
Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0123.001; Thu, 21 Mar 2013 10:42:53 -0400
From: Igor Bryskin <IBryskin@advaoptical.com>
To: Fatai Zhang <zhangfatai@huawei.com>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] MELGs - Q&A
Thread-Index: AQHOIGPeoOQf0fNS1kG7ulofq5GmQJivzRoAgABxTHA=
Date: Thu, 21 Mar 2013 14:42:52 +0000
Message-ID: <CDAC6F6F5401B245A2C68D0CF8AFDF0A191B0ED0@atl-srv-mail10.atl.advaoptical.com>
References: <CA+YzgTvskemP5yyUHXWr8iHWB0V_jh8Q_hAudxNQnCA0++0Xiw@mail.gmail.com> <F82A4B6D50F9464B8EBA55651F541CF8358877E9@SZXEML552-MBX.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF8358877E9@SZXEML552-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.21.1.111]
Content-Type: multipart/alternative; boundary="_000_CDAC6F6F5401B245A2C68D0CF8AFDF0A191B0ED0atlsrvmail10atl_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-03-21_04:2013-03-21, 2013-03-21, 1970-01-01 signatures=0
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: Thu, 21 Mar 2013 14:43:14 -0000

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