Re: [CCAMP] MELGs - Q&A

[Khuzema Pithewan <[e-mail]>]

Igor,

If my understanding of MELG is correct, It works only (or has use only) for a specific case of centralized parallel path computation in 2 layer network.


1.       When Network has more than 2 layer i.e. Packet-OTN-DWDM, the Packet (client) layer will be talking to its immediate server layer i.e. OTN, which in turn is talking to DWDM layer. Using MELG, client layer path computation can take care of resource exclusivity of virtual link for immediate server layer i.e. OTN layer.  However if there is resource exclusivity at DWDM layer, this mechanism doesn't work. You need to do loose routing or use distributed PCE model

2.       For cases of concurrent computation (case#2-5), you are mainly talking about global optimization and diversity among multiple services. You can do the path computation, but to actually enact the computed path the signaling needs to be done from the source end of those LSPs.  So there is no point in doing concurrent computation at one network element for the services starting from multiple network elements. At best it looks to me a problem to be solved by network management/planning software.

Thanks
Khuzema


From: [e-mail] [mailto:[e-mail]] On Behalf Of Igor Bryskin
Sent: Tuesday, March 26, 2013 7:19 PM
To: Dieter Beller; Vishnu Pavan Beeram
Cc: [e-mail]
Subject: Re: [CCAMP] MELGs - Q&A

Dieter,

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

To be honest, this surprises me quite a bit, Let me give you some of many reasons as to why concurrent path computations are needed and why this is better than computing one path at a time:


1.      Computing several diverse paths for the same service in the context of service recovery. I hope you realize that computing one path at a time on many configurations produces no or sub-optimal results. I also hope you realize the problem of selecting two paths with one of them  having a link with common MELG with a link from another path;

2.      Computing paths for multiple services to be sufficiently disjoint from each other;

3.      Computing paths for multiple services to achieve a global optimization criteria (e.g. minimal summary total cost);

4.      Computing paths for multiple services for the purpose of removing the bandwidth fragmentations;

5.      Computing paths for multiple services to plan shared mesh protection/restoration schemes

6.      Etc.

Also think about this:

1.      If concurrent path computation was not important, why PCEP includes the machinery to do that?

2.      My understanding of the statefull PCE is that it does pretty much nothing but concurrent path computations

You also said:
>> 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.
How this logic does not apply to other link attributes such as SRLGs?
What if path computation is not centralized?

Cheers,
Igor

From: [e-mail] [mailto:[e-mail]] On Behalf Of Dieter Beller
Sent: Monday, March 25, 2013 5:52 PM
To: Vishnu Pavan Beeram
Cc: [e-mail]
Subject: Re: [CCAMP] MELGs - Q&A

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:[e-mail]]
Sent: Friday, March 22, 2013 8:57 PM
To: Fatai Zhang
Cc: Igor Bryskin; [e-mail]<mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

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: [phone]
Mobil: [phone]
[e-mail]<mailto:[e-mail]>

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