Re: [CCAMP] MELGs - Q&A

[Khuzema Pithewan <[e-mail]>]

Hi Igor,

For multi-layer (more than 2) network, consider all the layers are meshy (that's when virtual links are useful anyway), MELGs of virtual link will change as and when BW/wavelength availability changes, because potential paths, a virtual link can take will change. Mapping lower layer MELGs to higher layer MELGs won't be practical if done in distributed manner, so it has to be centralized. So you do have central element in each layer that knows all the risk and paths (a PCE?), which can be utilized for layer specific path computation (as it is doing it anyway).

This kind of architecture has all the pieces that are required for Inter-PCE communication (across layers), except the protocol that would actually make the 2 PCEs talk.

You seem to be doing something that you don't like :)

Regards
Khuzema

From: Igor Bryskin [mailto:[e-mail]]
Sent: Friday, April 12, 2013 8:39 PM
To: Khuzema Pithewan; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]
Subject: RE: [CCAMP] MELGs - Q&A

Khuzema,

I am not a fan of inter-layer path computations (nor I am a fan of inter-PCE computations). In my mind path computation for a service or services in layer X is performed only in layer X, i.e. considers only X layer links (real or virtual). As Pavan mentioned SRLGs and MELGs that need to be inherited from lower layers should be translated into X layer link SRLGs/MELGs and specified with X layer specific SRLG/MELG IDs.

Cheers,
Igor


From: Khuzema Pithewan [mailto:[e-mail]]
Sent: Friday, April 12, 2013 10:55 AM
To: Igor Bryskin; Vishnu Pavan Beeram
Cc: Dieter Beller; [e-mail]
Subject: RE: [CCAMP] MELGs - Q&A

Hi Igor,

Ok. This would be useful if network architecture is based on external PCE or mgmt entity as PCE in client layer, but there is no counterpart in server layer, otherwise one could have inter-PCE communication to achieve diverse path in server layer without getting into virtual link and MELG stuff.

Is that correct?

Khuzema

From: Igor Bryskin [mailto:[e-mail]]
Sent: Friday, April 12, 2013 6:36 PM
To: Vishnu Pavan Beeram; Khuzema Pithewan
Cc: Dieter Beller; [e-mail]<mailto:[e-mail]>
Subject: RE: [CCAMP] MELGs - Q&A

Khuzema,


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.
Well, when an ingress node is initiating a service, it is doing so on request from some management entity. This management entity can compute paths for many services with some global criteria in mind, and then specify the resulting paths as explicit EROs in provisioning requests sent to each of the service ingresses. How else, for example,  you can set up several services originated from different nodes that are disjoint from each other? Also, what is the point in your opinion of the statefull PCE work?

Cheers,
Igor

From: Vishnu Pavan Beeram [mailto:[e-mail]]
Sent: Friday, April 12, 2013 8:08 AM
To: Khuzema Pithewan
Cc: Igor Bryskin; Dieter Beller; [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] MELGs - Q&A

Khuzema, Hi!

Please see inline..


 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

[VPB] The behavior is the same as what you would do with SRLGs in a multi-layer architecture. There are architectures that allow the SRLGs in the lowest layer to be exported all the way up to the highest layer. The expectation is that MELGs would be treated in the same vein.

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.
[VPB]  I'm not sure why you think there is no point in having a centralized computation function compute paths concurrently for LSPs with different set of end-points. Even your NMS/planning-software can interact with such computation engine, retrieve all the paths and then go about initiating the path-setup from the ingress of each LSP.

Regards,
-Pavan




From: [e-mail]<mailto:[e-mail]> [mailto:[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]<mailto:[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]> [mailto:[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]<mailto:[e-mail]>
Subject: Re: [CCAMP] MELGs - Q&A

Hi Pavan,
On 25.03.2013 07<tel:25.03.2013%2007>: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]<tel:%2B49%20711%20821%2043125>
Mobil: [phone]<tel:%2B49%20175%207266874>
[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