Re: [CCAMP] MELGs - Q&A

[Vishnu Pavan Beeram <[e-mail]>]

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