Re: [CCAMP] MELGs - Q&A

Vishnu Pavan Beeram <vishnupavan@gmail.com> Fri, 22 March 2013 12:56 UTC

Return-Path: <vishnupavan@gmail.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 77F2C21F8514 for <ccamp@ietfa.amsl.com>; Fri, 22 Mar 2013 05:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level:
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_VISIT=2.3, NO_RELAYS=-0.001]
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 c4akf93LkJMG for <ccamp@ietfa.amsl.com>; Fri, 22 Mar 2013 05:56:32 -0700 (PDT)
Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id EE9FC21F8511 for <ccamp@ietf.org>; Fri, 22 Mar 2013 05:56:31 -0700 (PDT)
Received: by mail-bk0-f54.google.com with SMTP id w5so1890846bku.27 for <ccamp@ietf.org>; Fri, 22 Mar 2013 05:56:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xJp3ezTRXyQiHQS8/hjQRZ+NeJ7Hj8EUSYphVugXiEc=; b=0tS/IXhAoZfCWYUma3TNbf6Its6yMvwgyHGSWDdaGBbnQCZotn8R+mMVcrNnztli8f goVPOVSeGxKl1VFRLoySNfiLnB3MTG8tEZSe3gUDahYNBBcg47e0l6oYLmVe17tctJxF 42WIUw2MrI/O9+A1qKDhdg31VE2UvRZkvcIC/a3soKKwVqUaS6yK4LswrQRen9rXAAh6 qclaEH6pHB3nwOXdvwTVWbhrd1xco21FvHkL8KU35Y0utMY1cie+9qcBh6Tng5ngmcTd m7tH32JWZA9PIAwlgzXlX/ZIXBFg25KymNaxwf3h38fe5b08J9vWhYitaRIB40r2wfHM Zeaw==
MIME-Version: 1.0
X-Received: by 10.205.112.80 with SMTP id er16mr955291bkc.12.1363956990769; Fri, 22 Mar 2013 05:56:30 -0700 (PDT)
Received: by 10.205.127.137 with HTTP; Fri, 22 Mar 2013 05:56:30 -0700 (PDT)
In-Reply-To: <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> <F82A4B6D50F9464B8EBA55651F541CF835887C70@SZXEML552-MBX.china.huawei.com>
Date: Fri, 22 Mar 2013 08:56:30 -0400
Message-ID: <CA+YzgTvbQDzh9yVJmO1HuNyQOFDXsccrTbO5Fz7jE28wv4U3dA@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
To: Fatai Zhang <zhangfatai@huawei.com>
Content-Type: multipart/alternative; boundary="14dae9c093c6ecb45004d882fb1c"
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, 22 Mar 2013 12:56:33 -0000

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


On Fri, Mar 22, 2013 at 4:24 AM, Fatai Zhang <zhangfatai@huawei.com> wrote:

>  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****
>
> ** **
>
> ** **
>