IETF Logo Mail Archive

Re: [CCAMP] MELGs - Q&A

Dieter Beller <Dieter.Beller@alcatel-lucent.com> Mon, 25 March 2013 21:52 UTC

Return-Path: <Dieter.Beller@alcatel-lucent.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 806B921F86E8 for <ccamp@ietfa.amsl.com>; Mon, 25 Mar 2013 14:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.141
X-Spam-Level:
X-Spam-Status: No, score=-9.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8]
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 tEnSNgkswPyw for <ccamp@ietfa.amsl.com>; Mon, 25 Mar 2013 14:52:16 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2DE21F86EB for <ccamp@ietf.org>; Mon, 25 Mar 2013 14:52:15 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r2PLq9N8003066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Mar 2013 16:52:11 -0500 (CDT)
Received: from destgsu0709.de.alcatel-lucent.com (slsv7at.de.alcatel-lucent.com [149.204.245.107]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r2PLq8at017504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2013 22:52:09 +0100
Received: from [135.244.176.104] (beller.lra.lucent.com [135.244.176.104]) (authenticated bits=0) by destgsu0709.de.alcatel-lucent.com (8.14.3/8.13.8) with ESMTP id r2PLq5iY022620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2013 22:52:07 +0100 (CET)
Message-ID: <5150C704.2040007@alcatel-lucent.com>
Date: Mon, 25 Mar 2013 22:52:04 +0100
From: Dieter Beller <Dieter.Beller@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Vishnu Pavan Beeram <vishnupavan@gmail.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>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF8431571FF@SZXEML552-MBS.china.huawei.com>
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
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: Mon, 25 Mar 2013 21:52:18 -0000

Hi Pavan,

On 25.03.2013 07:29, Fatai Zhang wrote:

Hi Pavan,

 

I am not sure how much VL (Virtual Link) will be used in the practical deployment and how often concurrent path computation will be used.

I guess we are coming back to the essential point: "and how often concurrent path computation will be used."

This means we are trying to figure out under which conditions MELG routing extensions
could be beneficial.

IMHO, they would only make sense, if:
  • a path computation function supports the calculation of k shortest paths concurrently
  • if there is only a single path computation function instance per domain (pce approach)
    If path computation is done in a distributed fashion the benefit goes away because
    the instances calculate paths independently!
I suppose that if a pce approach is used, i.e., path computation is centralized including the
TE-DB, MELG routing extensions are not needed because the information about mutual
exclusive VLs can be kept in the central TE-DB when VLs are configured.

Hence, it is quite doubtful whether MELG routing extensions are really useful unless their
applicability is broader.


Thanks,
Dieter

 

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

 

 

 

Best Regards

 

Fatai

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; 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



_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp

--

DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
CORE NETWORKS BUSINESS DIVISION
OPTICS BU, SWITCHING R&D

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub · Dr. Rainer Fechner · Andreas Gehe

v2.23.0 | Report a Bug | By Email